Standards May Be Lethal to Your Projects

However, it has become apparent that those strategies have mostly failed to deliver on their promise. Of course, standards make sense when viewed as a guideline. However, Their thorough implementation was rarely successful, and “process improvement initiatives” turned out to have a failure rate of nearly 100%. That has been blamed for numerous reasons, but unsuccessful standards implementation usually occurs because of the human factor. I often think of a typical quality standard as a scalpel. In the hands of an experienced surgeon, it can do wonders. In the hands of a psychopath, it can spread fear and terror. I guess that there are many more psychopaths than surgeons in this world, and even if this were not the case, a single psychopath can thoroughly ruin the reputation of scalpel manufacturers for a long time. Typically, these risks were ignored, and the management went on to implement these standards. The rationale is compelling: standards are viewed as a key to ensuring quality. Implementing standards is good news because nobody wants to travel on a plane, which resulted from a chaotic project. The corporate reality, however, soon sets in: no one has the time for standards, there is a distinct lack of experts in each standard, and developers have heroically resisted the bureaucracy that often results from standards implementation. The typical “anti-patterns” in the implementation of standards include the following:

• The standards implementation schedule is unrealistically short.
• The provided budget is unrealistically low.
• The expectations of the results are unrealistically high.
• The additional effort of project staff to implement the standards is greatly underestimated.
• The standards implementation is run by young consultants (without any project experience).

The idea that employees look forward to and tackle new standards vigorously is utopian. Nobody eagerly awaits a chance to try new development processes and documentation standards. There just isn’t the time for that. The so-called process optimization, operated under such circumstances, is more likely to kill projects. They are destroyed when standards are implemented in such a manner. The end result usually consists of a pile of new work instructions gathering dust on the shelf, a ban on even mentioning the standards at all, and a secret agreement with the project’s customer to more or less ignore the standards and follow some kind of an “I hope it goes well” approach. Is all hope lost? Are standards absurd? Should we stop improving our processes? The solution starts with the insight that projects must be organized straightforwardly. This does not mean that all projects must now be purely agile. Complex, large projects won’t succeed if their organization consists only of stand-up meetings and burn-down charts. Besides, it would be too risky in industries where system flaws may put lives at risk. Last but not least, OEMs (especially the automotive industry) are unlikely to stop demanding proof of standards compliance; quite the opposite is expected. The solution consists of two factors: firstly, the implementation of the essential elements found in popular standards like CMMI or Automotive SPICE, and secondly, the employment of a carefully staffed expert project team. It sounds vague, but in my experience standards must not be implemented literally; they MUST be vague, or they WILL fail. Here is my approach to successful standards-based process improvement in projects:

• The consultants hired for the job must have first-hand experience of similar projects. No freshly graduated junior consultants will do.
• Define a minimal subset of the standards. Among other things configuration management, project planning, good design practices (such as expert reviews), and quality assurance (including testing at all levels) are indispensable. “Processes” such as “risk management” should not be considered separate entities.
• Develop standards for both assessors and developers to implement, designed so that they don’t get in each other’s way.
• Emphasize activity results, templates, and tools. Downplay the activities themselves.
• Ensure you can rely on project staff as being absolute experts.

The last point is crucial. There are organizations where a lot of infantry is used. Where individual skills are unnecessary, the chain of command and the procedures are always crucial. Contrary to that model, other organizations breed SWAT teams. The project teams are small, and they don’t have to be large, because they are made of highly productive, highly motivated, and well-paid experts. In such teams, standards can be fun if they are adequately tackled. The apparent rhetorical question is, of course, is the SWAT model something entire industries could adopt as best practice? The answer, of course, is: no, there are not enough experts of that caliber out there. However, I have not promised that my pragmatic approach is easy to implement. Nevertheless, I consistently notice that when it comes to being an industry leader, especially in new product development, success can only be expected when you recruit the best people. It is everything but easy. Still, I am now absolutely convinced that the most promising strategy is that minimalist processes in teams of experts create incredibly agile “T-Rex” organizations. Companies like Google have already demonstrated this. Google hires highly paid, high-profile experts. At the same time, these experts enjoy plenty of space, mainly thanks to minimalist processes. And Google’s profitability is something every company would love to have.

---

Let’s start a conversation on LinkedIn or X.com (formerly Twitter).