“[we provide] processes that can stand the scrutiny of unprecedented oversight.”
Are they really saying that the objective of their proposed “methodical, rigorous and standard processes,” which are “demanded by the complexities of 21st century weapon systems,” is to prevent criticism? Yes, they are. I’m not surprised it’s come to this, but it is a little bit funny to see the CYA mentality stated so explicitly and with such boldness.
Withstanding scrutiny & oversight is fine, but it shouldn’t be the bottom line. What happened to delivering capabilities (which the briefing NEVER MENTIONED!)?
In a process-centric environment, compliance is apparently sufficient to shield poor performers from criticism. The team didn't deliver what the end user needed? Well, the boss won't object to the poor performance as long as the team complied with the process. Maybe we need to make the process more rigorous. Let's start a Continuous Process Improvement Initiative.
When an organization is process centric, people know it. So rather than seeking to simplify our excessively complex systems, processes and organizations (and focus on results), they instead develop rigorous and standardized processes, as a talisman against accusations of inadequacy.
If processes are going to be of any value, they should make the product better. They should streamline operations, enable smart decision making, foster better problem solving, encourage innovation, and deliver the required systems faster & cheaper. When we use them primarily as shields against scrutiny, something is horribly wrong.
If processes are going to be of any value, they should make the product better. They should streamline operations, enable smart decision making, foster better problem solving, encourage innovation, and deliver the required systems faster & cheaper. When we use them primarily as shields against scrutiny, something is horribly wrong.
2 comments:
In our organization we have a step in each process to “Validate” the product. It’s the most important element of any process, but unfortunately, it’s the most misunderstood and undervalued one. In case you don’t know what it means (didn’t I tell you it was the most misunderstood?), it ensures that the product being produced meets the end user’s intended needs. Well now there’s a novel concept!
Before we evolved into the process-centric organization we are today, a typical engineer would have viewed the validation of the product he/she was developing as “duh – of course I’m designing for the end user’s needs”. I think it was engrained in their very DNA. Don’t get me wrong, I believe we still strive to meet the user’s needs, and it’s most of the same engineers doing the work that were around before the processes drove their work flow. However, our processes have reduced validation to a step that occurs at one point in the process’ flow. It’s now overshadowed by all the other steps, and since we’ve given a nebulous name, most engineers don’t even understand what it means.
How did meeting the user’s needs ever become a step in a process? Where did the term “validation” come from? Since when can you execute 15 steps of a process to develop a product and not consider the user’s needs in every one of them? Well, maybe the CMMI text books can clarify it all for us.
I was once instructed to address the CYA requirement as priority number 1.
It led to friction.
Serious friction, because if you have to invest all your limited resources on CYA then nothing valuable ever gets built.
Unfortunately, culture leads all these discussions and individuals hurt themselves when trying to overcome culture like that.
They should give out merit badges.
Post a Comment