Go to the place where the work is performed, that is the Gemba walk. This does not apply just to manufacturing, but also line managers and their respective departments as well as to project management. You want to know what is going on, what could be better, go unto the work space and watch and talk with the people doing the work.
Where the work is performed, depends upon the work. For example, if you are the manager of a product testing department, the place where the work is performed is likely the lab, Go where the Hardware In the Loop (HIL) rigs and see how things are going, go to the test rooms where the environmental (hot and cold) and other stimuli (vibration) are administered to the product. Learn how this work is actually being done. Ask questions about how the work is going. What sort of things are difficult and why? What can we do to make the … Continue reading
In preparation for our trip to Eindhoven University of Technology to lecture on Configuration Management, we provide a brief excerpt on the evolution of the horseless cariage.
Traditionally new market segments open due to the need to solve a problem. Such problems may be real as in the case of the environmental crisis solved by the automobile or the need may be concocted. New markets and products are rarely developed through the inspiration of a single individual. The automotive market came about through a synergy of the existing body of knowledge and other environmental conditions both in the marketplace and in the nature.
One topic of discussion at the world’s first international urban planning conference in 1898 was the growing health concerns due to horse excretions and the creatures that accompanied them. As the primary means of locomotion for wagons and other forms of transport, horse populations exceeded human population in cities.*
Manufacturers of “horseless carriages” using steam, electric, … Continue reading
Business is predicated on providing value to the customer, but it does not end there. The business itself needs to see value in the work, so this is really a value chain that is only as strong as the weakest link. If the value to the customer is too low or not existing, no customers will purchase the product. If the value to the business from the product is too low, there will be no investment
What is value
Value is the difference between the utility received and the cost for things.
Value = Utility – Cost
Value = Benefit – Cost
The utility may be customer dependent, but this must be understood, as this will drive the subsequent work. Not knowing what the customer values, clouds how we approach the work. We will write more about the conundrum later. It suffices to say no value to the customer means no value to the business, … Continue reading
What does not work -duration
Besides wasting time planning out many months into the future as if we could see and control that far ahead, there have been studies over the years that have established an inverse correlation between the length of time a project runs and project success rate. Perhaps this does not sound so odd, given the more tasks we have or the more work we must do, the greater the risks. Consider a product and the opportunities for failure, the more parts, the more opportunities for failure or more failure points.
There is no silver bullet when it comes to product development. However, there are some things that studies tell us what does not work.
First, the planning and long-term project or treating the job like we know the details 6 months to 3 years in the future. There are studies from the Standish group that illustrates the project s longer than 6 months in duration have … Continue reading
I had a brief chat with Tom Cagley of the famous SPaMcast the other night about teams. We periodically take time to talk about product development topics, and I frequently appear on SPaMCast podcasts. Last night we talked about teams an whatever magic makes a collection of individuals move to the point of performing better than the sum of he constituent parts.
I have worked professionally for nearly 30 years, and a decade before that as a field worker, fast food worker, and what we self-referred to as a yard dog – the guy who moves trailers, puts hitches on vehicles, cleans up vehicles and much more. In my 30 years professionally, I can recall being on 3 groups that were what could be referred to as a team. In fact, the story of one of those teams can be found in the book by Peter Taylor in The Project Manager Who Smiled book.
If there were a perfect recipe for creating a … Continue reading
I have been in twitter and real discussions about safe spaces for the product development team to do their work. I can understand this, nobody should get hurt at work, that is one of the reasons for OSHA, and internal work instructions and equipment. However, we are not talking about the physical world in our modern discussion of safety in the work space. There is nothing wrong with tension, or discomfort. Of course we are not talking about guns, cars and knives at work, but then again, most of those referring to safe space at work are really talking about words in the work place and not physical harm. We are talking about the removal of even mental discomforts from the work space. The problem is, this mental discomfort is frequently the source for progress.
The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man. … Continue reading
It is clear to me that some people think an agile approach means you can willy-nilly delete things in the process. This is also true for conventional project, but I do not think for the same reasons. For conventional projects, it seems time pressures cause elimination of certain functions or processes to keep the schedule. For agile, again no study but based on observed discussions, the elimination seems to be because there is no doctrine or perceived process that is required to be adhered. This means things can be arbitrarily altered or changed, or even eliminated. That is certainly true, but you must consider the consequences of not performing the activity (for example product demonstration)? From my perspective, there is a balance between adherence to a process (repeatable and baseline for learning ) and adapting to the circumstances.
What does this product demonstration do, can I eliminate it, and what will likely be the consequences?
For the record, I am … Continue reading
If commitment to the requirements is a significant source of failure, it is followed close behind by the management of changes or additional requirements that come from doing the work. Though many project managers may believe that once a project is underway, there shall be no changes; that is a myopic approach. Change happens. As we conduct our project we will learn as we learn we will update the expectation and details of our product via specifications and requirements documentation. Our project life-cycle layout will facilitate this incremental and iterative approach to the product which will include the requirements. For example, in the automotive world, we typically have a project life-cycle that produces a variety of prototypes that increase in sophistication as we make progress and approach the final production iteration of the product. We may have a first part that may be largely a mock up from which we will learn, update the specifications and then move to the next … Continue reading
Continuous Deliver and Embedded Automotive
I have worked on projects that employed continuous delivery for embedded products. The embedded product was an automotive component. The core of the software (the operating system) was specified using conventional approach. This operating system consisted of the maximum model requirements for this globally used component. The component looked and acted differently depending upon market segment and geographic location, for example, there were two different European incarnations and more than two for the markets of the United States. This was not just some parameter setting or configuration differences, but whole scale differences in feature content and manner of execution.
As we indicated, the operating system, though we called it an execution engine, was specified and developed using an incremental approach. This incremental approach was based upon a prioritized set of features. That prioritization was based on what it would take to produce a vehicle that would operate safely allowing for testing of key features. In the … Continue reading
CMMI and Project Management
There are intersections between Capability Maturity Model Integration (CMMI) and project management beyond the specific or obvious project management areas listed below in the staged representation:
Project Planning is Level 2 Project Monitoring and Control Level 2 Risk Management Level 3 Quantitative Project Management Level 5
There are other non-obvious intersections between CMMI and project management. Consider requirements management and requirements development for example. We submit that CMMI makes project management easier. Let us first look at requirements management and the connection to project management.
This is a set of processes (in staged representation level 2) that we will use to evoke and understand the customer needs. These are in level 2 because these are fundamental to success. The specific goal is to ensure the requirements are managed and inconsistencies between project plans and work products are identified [CMMI]. Requirements are the detailed incarnation of the project scope. Poor requirements understanding will mean … Continue reading