This post originated from an RSS feed registered with Agile Buzz by Laurent Bossavit. Original Post: Building blocks of project plans Feed Title: Incipient(thoughts) Feed URL: http://bossavit.com/thoughts/index.rdf Feed Description: You're in a maze of twisty little decisions, all alike. You're in a maze of twisty little decisions, all different. Latest Agile Buzz Posts Latest Agile Buzz Posts by Laurent Bossavit Latest Posts From Incipient(thoughts)

I've recently read DeMarco and Lister's "Waltzing with Bears", a short and useful book on risk management which confirmed some of my own prejudices on the subject.

One idea in particular stood out and made me look at project planning in a new light:

A very simple test for risk management is to look at the project plan laid out in Project or in any other scheme, and ask the people involved, the people who understand the project, to point to a task that might not happen at all. In most projects the personnel will stare at you in complete lack of comprehension. They say, “Well, why would we have something on the project plan that wouldn’t happen at all” and my answer to that is: because that’s a risk.

If you have a background in programming, consider the following analogy, which might be more convincing to you. One early breakthrough in our field was Structured Programming. One key idea of Structured Programming was that a vast number of algorithms, even extremely complex ones, could be expressed in terms of just three fundamental elements:

• Sequence - do A, then B, then C
• Alternation - depending on some condition X, do one of A, B, or C
• Iteration - repeat A, until some condition X becomes true

For instance, a simple algorithm to report an account balance is, at the top level, a sequence: "initialize balance amount to previous balance", "add transactions to amount", "display amount". The second step is further broken down by expressing it as an iteration: "repeat 'add current transaction amount to balance amount' until 'there are no more transactions'." Within this, the logic to handle each transaction may be expressed as a choice between two different processes, one for a credit and one for a debit.

In terms of this model, most people's understanding of project planning is restricted to just one building block: Sequence. This is insufficient; you would be unable to express most algorithms if all you had at your disposal in a programming language was a way of stringing operations together in sequence. Project planning approaches in strict Waterfall mode are similarly unable to cope with realistic levels of complexity. Well-managed Waterfall projects may of course react in more sophisticated ways to actual events; I'm only saying that the description of a project plan as a sequence of tasks cannot be an accurate representation of most projects.

More modern approaches embrace iterative development - essentially adding the Iteration building block. That does not mean that we dispense with the Sequence building block - within an iteration, there are still things that will be done in a determined order. Still, iterative processes emphasize only two of the three building blocks from structured programming; no provision is made at a relatively high level for Alternation.