As many readers will know, the idea of “continual process improvement” is a pillar of the quality management movement. By improving processes, the root cause of problems that allow mistakes to be made can be eliminated, thereby allowing the organization to produce higher quality goods and services.
Although the idea of continual improvement started in the manufacturing sector, in the mid 1990’s the idea gained ground in the IT sector as well. Models such as the Capability Maturity Model (CMM) and ISO-9000 were commonly referenced and many organizations (especially the off-shore IT development centers) pursued certification against one of the available models. Although in recent years agile techniques have formed a counter point to the heavy process models that CMM and ISO-9000 often led to, many larger organizations still tout process improvement when courting new customers.
The mantra that lies behind process improvement is the idea that reliance on the heroic performance of individual workers can be replaced with a reliance on the maturity of the organization’s process capabilities. In essence the capability of the individual performing a role becomes less important than the maturity of the process they are using.
It’s a seductive premise to those who face the challenge of running a large IT center. Rather than having to worry about building and managing the capabilities of every individual in the organization you simply focus on improving the processes you use. The problem is that in the IT sector it’s a premise that is based on a fallacy.
To quality purists that’s a provocative statement; surely, Toyota is living proof of the concept’s validity? That is certainly true and I am not questioning the concept’s validity. What I am questioning is the applicability of the idea to the IT sector.
In the manufacturing sector, process improvement is usually achieved by engineering decisions out of the shop floor. Individual decisions made by individual workers are one of the primary sources of variance in a process. By eliminating the need to make decisions in a process, a key source of variance is immediately removed. The automotive sector is the perfect example of the idea in action. Over the years the vast majority of the decisions needing to be made when assembling a car have been either eliminated or radically simplified and many cars are now assembled by robots.
While removing decisions from the shop floor has worked beautifully in the manufacturing sector, it’s an idea that has only limited applicability in the world of IT. While some decisions can be engineered out of the process of creating a software product (such as how to organize a team, what intermediary deliverables to produce, etc), the vast majority of the decisions made in a project cannot be anticipated in advance and hence cannot be eliminated from the project.
The net result is that in the IT sector, process improvement can never be the definitive quality improvement tool that it has become in manufacturing. While process improvement can help eliminate the need to make some decisions from a software project, decisions concerning strategy, requirements, design and implementation are different in every project. As a result, the outcome of a software project will always be heavily linked to capabilities of the individuals involved. While some large software development centers don’t want to face up to that reality, it’s a reality many customers now understand and more buyers of software services are now interested not only in your process maturity, but also in how you train and manage your teams.