I'm working on several things at the moment at three different sites. Two are process improvement and one is product development. What dawned on me today was that the conjecture that we need a new process fails - many times - to ask the question; what is wrong with the current process?
- Is the process broken? or
- Do the people not follow the process?
I've observed that those proposing a new process assume - without confirming - that the current process is broken and the new process will fix the problem. This is the "red herring" sales strategy. It's rampant in everything in today's modern world. From drug advertising to coffee makers.
"What you have now is not sufficient for your needs, here's a better product, service, or process."
The challenge for us on the receiving end of this message is to sort out the problem from the solution.
I work in a broad spectrum of software/hardware domains. Ranging from the construction of deep space exploration craft to embedded real time software systems. Although these domains are software focused (my core skill set), their approach to process improvement or execution is much different. But they share one thing - they are all challenged to separate process from execution. All three firms are subject to the manipulations of the process sellers. "If you add this process, your life will be better." My job is to be "conscience of the client." I learned this term from a senior consultant long ago. This approach to advice giving inverts the role of the consultant from a solution provider to one who asks the hard questions of the solution provider on behalf of the client. If the had asked and answered those hard questions, then the consulting firm would not be needed or at least needed in the common way - getting the past decisions turned around so the firm can get back on track.
So what does this mean for project management, especially agile project management and agile development processes?
- Where is the bookable value of any process improvement initiative?
- What is the REAL problem here? Execution or Process?
- Where are the REAL wins for the improvement effort?
- Are we searching for a business solution or do we want to be famous for deploying our process? (This is a easy trap to fall into for agile development processes).
- What process elements are we NOT using of our current process, that if we were to start using them, we'd have the solution?
- What are the core principles of the new process that are measurably different from the current process in ways that can be recognized by the decision makers. "Is this new process simply old wine in a new bottle?"
This last question is the challenge for any "agile." There are certainly new ideas in agile.
- Continuous feedback - rather than phased gates
- One site customer - in addition to specification
- Event planning - rather than effort planning
But the idea that the production of value is missing from existing processes, or that existing process are not based on trust is simply sales talk. There is no evidence that the process is broken. It's the execution of the process that is broken.
So start by fixing the execution of the process, THEN look for improvements.
