Standards may be helpful to system developing organizations, but often they turn out to be part of the problem or even become the actual problem.
CMMI, SPICE, ISO 900X, ITIL, ISO 26262 – these are the hyped standards of the past ten years. They were supposed to help us deal with the software crisis; these standards promised to ensure consistent product quality. It has been a general consensus for a long time that standards prevent projects from descending into complete chaos. In every corporate organization I know that develops software and electronic systems, the need to implement at least one of these standards was a strategic axiom.
However, it has become obvious that those strategies have mostly failed to deliver on their promise. Of course, standards make sense when viewed as a guideline. Their thorough implementation, however, was very 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. My guess is that there are many more psychopaths than surgeons in this world, and even if this were not the case, a single psychopath is able to 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 very convincing: standards are viewed as a key to ensure 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 involved in the implementation of the standards is greatly underestimated.
- The standards implementation is run by young consultants (without any project experience).
The idea that employees look forward to new standards and tackle them vigorously is utopian. Nobody is eagerly waiting for 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 simply 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 a “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 in a very simple way. 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, in industries where system flaws may put lives at risk, it would be just too risky. And last but not least, OEMs (especially the automotive industry) are unlikely to stop demanding the proof of standards compliance; in fact, quite the opposite is to be expected.
The solution consists of two factors: firstly, the implementation of the most basic 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 for successful standards-based process improvement in projects:
- The consultants hired for the job must have the 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 even be considered as separate entities.
- Develop standards for both assessors and developers to implement, designed so that they don’t get in each other’s way.
- Place the emphasis on 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 not important, 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 tackled properly.
The obvious 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. But 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.