Question #9

The book never talked about the business case of using this approach. For example, early implementation of functionality is early achievement of ROI. This needs to be shifted from a theoretical exercise to one that is compelling to the executive who will be paying for the project. I can see that one of their concerns will be loss of control.

There is a fairly sophisticated chartering activity I take projects through to get to the underlying assumptions and organizational goals. Once we lay those out so everyone understands them, the nucleus of the team creates a release plan with the business and develops the business case. This in turn is briefed to management for approval. Only with that approval does the project actually get initiated. The expectation I always set up for teams is that the critical 20% should be in the first release, because there will always be another project whose critical 20% has a higher priority that the second release of this project. Most projects will never have a second release and those few that do, will really be an entirely different project.

Once everyone understands this, we establish an iterative cadence to the development and go balls to the wall across the release pausing after each iteration only to 1) look back on how we did it and change the process if necessary and 2) ask the business if the assumptions made in the charter still hold and/or whether anything has changed at the business level such that we need to replan.