Peter Gallagher | Change in the time of process
Connecting state and local government leaders
The seductive promise of uniformity and perfection transmitted through process control has reached the point where it is making us weaker.
We all know change is the lifeblood of the information technology industry. It is the one thing IT can depend on. It’s what makes the industry challenging. And change demands flexibility.
However, we also know that change elevates the threat of disruption, especially for complex legacy applications. And too much change, too much flexibility, will certainly increase risk.
It has been an IT passion to battle the risks of change by incorporating the controls promised by improved process management. Obsession is not far off as a description of our passion for process control frameworks with names such as PMBok (Project Management Body Of Knowledge), CMMI (Capability Maturity Model Integration) and ITIL (Information Technologies Infrastructure Library). We have fallen madly in love with process control. Every organization is searching for that perfect set of process control documents, for things like configuration management, testing or quality, to guarantee consistent delivery and operational support. Implementing process control has been a growth business for many people, especially those in IT security.
But has the desire for a rigorous, documented process blinded us to the reality of change?
Another sector that is also going through change, the automotive industry, may have some lessons for IT. Auto manufacturing is the birthplace of the masters of process control, with the Toyota Production System (TPS) standing as an exemplar. The much-studied TPS connected suppliers and processes in unimagined ways to create high quality at the lowest cost. However, TPS proved hard to copy. Even though the company's competitors developed similar specifications, TPS somehow kept Toyota ahead.
The history of these automotive production systems demonstrates that it is a mistake to confuse the process tools or specifications with the functioning of the system itself.
For example, at Toyota continuous change is the root driver of rigorous process specifications guided by TPS. The Toyota example illustrates how an evolving process model that is owned by the people performing the tasks, with guidance from strong technical leaders, can create value. Each iteration of a process is really an experiment that needs to be evaluated and improved upon. Making change consistently in a scientific way is what the TPS process is all about. Agility and flexibility is the goal rather than rigid procedure. Controlling change, not finalizing a procedure, is the real objective.
Everyone agrees that continuous improvement is a good thing, but should it be at the core of what we do when it comes to process management for IT systems?
The seductive promise of uniformity and perfection transmitted through process control has reached the point where it is making us weaker. We need to understand change for what it is – it's what we do every day. Empowering people to make changes in a controlled manner, improving the flexibility of our teams and allowing room for some failures are all things we need to embrace to stay competitive.
Giving up the hierarchical control embodied in the enforcement of an “official” standard operating procedure in favor of shared learning and individual or group responsibility is the challenge of change in the Web 2.0 world – not just for IT, but for the entire government. Rigid process can even inhibit innovation -- which, given IT’s reliance on change, is something we have to, well, change.