There really is an Uncertainty Principle for IT systems. Uncertainty arises from the fact that users will not know what they really need until they begin to work with a new system. The traditional waterfall approach to building systems (finish one phase before falling into the next) ignores this principle, and ignores the inevitable business changes that occur between freezing the specifications and delivering a system. But the waterfall methodology continues to be widely used.
One of the questionable advantages of the waterfall approach is that it allows management to pretend that project decisions are based on solid return-on-investment (ROI) numbers. Very early in the process, the requirements are frozen. At that point, it’s possible to develop a detailed cost estimate. Calculating ROI is then possible. Everyone walks away feeling they have made rational business decisions.
Of course, actual requirements come unfrozen and actual costs increase beyond predicted cost. There are better ways, at least for many IT projects. The first popular alternative was called Rapid Application Development, or RAD. Spiral Development from Barry Bohem came next (see his presentation at this Web site ).
More recently, several “lightweight” development methodologies banded together under the Agile Alliance banner (www.agilealliance.org). The theory is solid, but practice hasn’t always followed theory.
Agile system development projects, because of their incremental or evolutionary nature, reduce the impact of the Uncertainty Principle. Their short delivery cycle reduces risk because the cost of any cycle is sharply contained. But not all Agile projects are a success. They require active and continuous user involvement. They require talented development teams that constantly works to simplify the design. And they require a management that does not demand a detailed ROI calculation.
Many Agile project problems can be traced to the fact that controls are based less on a written plan and more on a shared understanding. The absence of an extensive written plan can be an advantage, but it also introduces a risk that the team’s shared understanding may be weak. Some planning is only prudent. The trick is to do just enough planning. The Data Systems Development Method (DSDM) is one Agile approach that includes up-front written plans.
DSDM is interesting on several fronts. It’s a proprietary methodology that requires payment of a license fee. But it was developed and is maintained by the non-profit DSDM Consortium. The fee is relatively modest — no more than the cost of day or two of a consultant’s time.
The Consortium’s website, www.dsdm.org, provides considerable information. And there are several good introductory books, e.g. “Framework for Business Centred Solutions Handbook”, published by the DSDM Consortium and available through their site.
DSDM includes a feasibility study, followed by a business study, followed by functional model iteration, and then on to design and build iteration. The method inverts the traditional system development approach.
Each design and build iteration takes place in a fixed time box. The team is charged with delivering the best possible working system within the available time and resources. The functionality to be delivered will be adjusted to fix within the time box. What functionality is selected for delivery with be guided by the business priorities established before the cycle begins.
The full DSDM methodology is a complete package, including careful definition of all the roles that must be played during the project. If the Uncertainty Principle bothers you, and you’re thinking about an Agile approach, DSDM should be considered. It may not generate the same fierce level of commitment as eXtreme Programming (XP), but evidence from the field suggests that DSDM projects stand a good chance of success…and they get around the Uncertainty Principle.
QuickLink 053973
–Fabian is a senior management and systems consultant in Toronto. He can be reached at robert@fabian.ca.
