At a recent corporate IT meeting, I heard an interesting observation from a group of managers looking for ways to reduce their projects' time to market. They said the biggest bottleneck in their development process wasn't the usual activities of analysis, design, coding or testing. Instead, it involved delays in approving contracts for relationships with vendors, subcontractors and strategic partners.
Once such a bottleneck is recognised and acknowledged, there are several obvious ways of addressing it, such as standardised contract templates or pre-approved contractual relationships with a few vendors. But if everyone is focusing their process-improvement energy on other aspects of the development process, the problem may never be solved.
At first glance, it sounds like the solution is to develop a thorough, detailed model of the systems development process, then improve it. Or perhaps launch a full-scale re-engineering of business processes, in which we follow management guru Michael Hammer's advice to "obliterate, not automate" the existing process and replace it with something radically better. This is probably good advice for 90 per cent of IT organisations that are still languishing at Levels 1 or 2 on the Software Engineering Institute's process maturity scale, which means that they have either no process or an unwritten one.
But beyond that, there's a more subtle problem. Most models of software development processes that I've seen are static models. That is, they may be very detailed and sophisticated, but all they describe are the input, process and function aspects of each step. They lack information about the dynamics of the process, such as the time delay between one activity and the next or the possibility of feedback loops to a previous activity. The time delay may even be formally acknowledged as a factor, but it's nevertheless a reality in a project's day-to-day life. For example, the functional specification (one step) has been finished, and the manager's approval (the next step) is a rubber-stamp formality.
However, the manager is on a three-week vacation, and, as a result, everything grinds to a halt until he returns.
And the presence of feedback loops may be acknowledged within the formal process model, but it often has such an innocuous form that nobody realises that, in the worst case, it can degenerate into an infinite loop.
For example, approval activity could acknowledge the possibility that a responsible manager might find some problems and mistakes in the functional specification and send it back to systems analysts for review and correction. Suppose, in the worst case, that the manager has been replaced by the time the revised specification is sent for approval. The new manager has a different opinion to his predecessor about the details of the specification, so he rejects it again and sends it back for another iteration. Since cycle time is such a crucial aspect of systems development, all this suggests that the process model should be a system dynamics' model that takes into account time delays and feedback loops. There are numerous inexpensive, easy-to-use tools available for building such models; the insights they provide in many development organisations are profound.
Among other things, they often demonstrate that a ten-fold improvement in coding productivity will have negligible impact on the overall development schedule for a project, but a cumbersome bureaucratic review process can have a disastrous effect on the project team's ability to finish its work on schedule.
Bottom line: If you're interested in process improvement - especially in today's world of Internet time' and rapid prototyping to speed up systems development - a key thing you should consider after you've documented and implemented a reasonable' process is to simulate its dynamic performance, so that you can find bottlenecks before it's too late.