Continuous Process Improvement (CPI) is based on the idea of observing, standardizing, measuring, adjusting and reevaluating processes. This strategy is used to determine inefficiencies in any system or process, make quantifiable changes to that system to either eliminate wasted steps or increase quality and first pass yield. This works very well in the Manufacturing and Operational world where there is little variation in process, or at least there should be little variation. BOM’s should be used at parts lists, standard work instructions followed to produce final goods. There should be little uncertainty in the process, little variation so small changes can be made and evaluated.
You should also know by now that I am a proponent of using CPI methods and strategies upstream in the product design cycle in order to release product that fits within the manufacturing model. This is called Design for Manufacturing. There are many areas within the design cycle that can be standardized, such as the items I had discussed in the Process blog post. The design topic that I have skirted around is the creative process itself while developing product. This is also the topic that most engineers throw out like a red herring every time the word ‘process’ comes up in conversation. In reality, I tend to agree to a certain extent, but life is all about grey area.
Plain and simple, you can’t schedule creativity.
As a lead of a design team, I can not impose a schedule on the team that says ‘You must be creative on Tuesdays and Thursdays between 10-2’. I also can’t put benchmarks on concepts and ideas, such as to say that 4 new ideas must be presented by Friday at 4. It simply does not work that way. Being an engineer by nature, I fully understand that ideas come at strange times, 24 hours a day 7 days a week during the oddest of times. A fair amount of my better ideas have come in the shower, some late at night when I awake from a dream. Some come from things I see out in the world that tie back to a particular problem, or sometimes they come from something cool I see but don’t have an application for… yet. I recall seeing a handrail on a subway car in Taiwan that split from one rail into 3, it was so elegant and simple that I have it locked away for that special application. The point is, it happens, and not to a tempo.
Why does this matter? Well it matters because engineers (me included) tend to use this argument when tasked with a deadline or schedule. I have been on both sides of the fence so I understand that schedules and processes are not intended to schedule the creative side of the equation, they are intended to estimate the admin and documentation side of the cycle. I can certainly attest that product design is all about ‘not knowing what we don’t know yet’, but that is not an excuse for rejecting processes or project estimates. Estimate what you know, estimate what you don’t know, add it all up for a stab in the dark.
I recently encountered an engineering team that was very steadfast in their resistance to estimate a project schedule. The arguments kept coming back to the creative cycle and being unable to estimate how long it would take to complete a task without knowing how to solve it first. The juxtaposition from a management perspective is that a commitment of resources can’t be made without knowing the magnitude of the commitment, and the engineering team did not want to throw out an estimate because of fear of making a commitment. In the end I believe this was a trust issue between the engineers and management.
So how do we get around this? From a management perspective, I try to communicate early on that schedules and estimates are just that. Estimates. It is also important to communicate the difference between routine tasks that are easily estimated and uncertainly areas so that a good picture can be developed of the overall timeline. Is there a lot of uncertainty, or just a little? The part of the task that is ‘just work’ can be quantified. Lastly, it is important to reiterate that no one will be burned at the stake if dates slip for legitimate reasons. Budgetary estimates are needed to gauge the feasibility of projects up front, a 100% accurate estimate given after the task is completed does not add value.
Do you have a strong feeling one way or another? Let me know and leave a comment.