Failed Process or Failed Execution?
Glen Alleman MSSM
Applying Systems Engineering Principles, Processes & Practices to Increase Probability of Program Success for Complex System of Systems, in Aerospace & Defense, Enterprise IT, and Process and Safety Industries
I'm currently working on several jobs at three different sites. Two are process improvements, 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?
I've observed that those proposing a new process assume—without confirming—that the current process is broken and that the new process will fix the problem. This is the "red herring" sales strategy, rampant in today's 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. They range from constructing deep space exploration craft to embedded real-time process control 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 they had asked and answered those hard questions, the consulting firm would not have been needed or at least required for a standard way - getting the past decisions turned around so the firm could get back on track.
领英推荐
So what does this mean for project management, especially agile project management and agile development processes?
This last question is the challenge for any "agile." There are undoubtedly new ideas in agile.
However, the idea that existing processes lack value production or 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.
Project Manager | Consultant | Speaker | Author | Coach
3 周agreed. My 2c
Systems Analyst, IS/IT Project Manager, Product Manager, Agile/Scrum Processes and Work Processes instructor
3 周Thank you for this. It is what we were taught and advised upon assuming the role of systems analysts. Indeed, without 'facts'—the discussion turns to be hand-waving or gut-feeling driven; hence, one should use something like Rummler-Brache's method (us, there are others). Having said that—I was in situations, where after detailing the shortcomings and limitations of current processes, showing the benefits of proposed, improved ones (faster, cheaper, safer, more accurate, more reliable, more versatile...)—I had to face a long- faced group of present-state 'advocates', who 'explained' why things should remain as they are... Your points are important factors in any initiation effort.
Project Server Architect at MI-GSO | PCUBED
3 周The real fun begins when you figure out that the problem is that they are following a valid, working process but doing it badly so it LOOKS like they aren't following it. :-)
Sr, Project Manager / Quality Assurance / Continuous Improvement Exceeding Expectations.
3 周There’s an old maxim, “People don’t fail, processes do.” I was taught in any given failure event, you ask the question, “At what point did the process fail? The answer determines where the problem lies, process or execution.