Even though the business case tells me what product I'm building, detailed outcomes of software projects, viewed from afar are not very predictable. But... up close, they are.
Agile projects are strategically stationary but tactically emergent
And, 'stationary' means... ? Stationary means that no matter when or where you view the project, it's strategic intent and outcome are invariant --- the same, unchanging.
And, 'emergent' means... ? Emergent means that detailed requirements may be created, deleted, updated, or deferred as circumstances reveal themselves and the project moves along.
How do we move from stationary in the far view to stationary in the near (up close) view?
- First, write a business case. And, from that a project charter. Those two dots should connect. These get you strategic intent and far view stability. These need not be heavy documents; often, a single page will drive a lot of project.
- Second, adopt the idea that for each segment of work put in process (WIP) on a Kanban board or a sprint or iteration, the backlog for that unit of work is fixed and frozen. This gives up close stability. And, tactical estimates can be done on such a fixed scope of work.
- The sponsor is going to come with a top-down budget and schedule. In a real business, there are budgets, period.
- The project must respond to the business case. The response is usually made in the project charter.
- The project charter has two constituents: 1. The project's counter proposal to the top-down budget, and 2. the estimate of risk to close the gap between the business budget and project's counter-proposal.
- Business value and budget on the one hand
- Project risk (liability) and capabilities on the other hand
Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog
