A Project "Narrative" - Hindrance or Help?

First published in The Agile Journal, 18 May 2011

Years ago an article appeared in Project Manager Today which elaborated upon why projects so often fail. It certainly ties in with my own experiences of process dysfunction and the symptoms I have learned to identify.

Basically the article says that the true project management life cycle goes like this:

1.      Initial Enthusiasm

2.      Dawn of Reality

3.      Panic

4.      Blame of the Innocent

5.      Rewards for the Uninvolved

You may be more familiar with the following canonical representation:

1.      Conception

2.      Analysis

3.      Design

4.      Construction

5.      Servicing

Because of linear flow, the above undoubtedly invites comparison with the Waterfall Model. However it is also possible for similar structures to feature in round-trip methods. The Rational Unified Process, for example, describes a phased iterative and incremental progression from Inception through Elaboration to Construction and Transition. And at proAgile we model a phased Agile progression with the "5 D's of Agile Innovation" (Discovery, Definition, Development, Delivery and Deployment). A sequence of steps that are indeed redolent of the ones listed above. So you may well ask: Why On Earth Are You People Doing This?

Well, I've often found that it can be useful to provide some degree of narrative continuity. It's a level of reassurance which might otherwise be lacking for stakeholders. Of course, as Agile custodians, we know that the project is iterative, and we know that its success will be proven and demarcated via ongoing delivery. But many stakeholders aren't used to working that way yet...and moreover, they may be funded by investors who are looking for a traditionally staged project schedule before they'll pony up the dough.

Now, that's all well and good. As far as it goes it's innocuous. You may have been on similarly staged projects yourself, where managers divvy up sprints so that a convincing narrative can be faked. But it can be dangerous. There is a symbiotic relationship between a linear representation and the rather cynical model enumerated by Project Manager Today. I suggest that the associated risks be dealt with studiously.

The risks are essentially political rather than technical. You see, one of the key features of Agile development is that stakeholders are engaged and empowered throughout the project. They have to provide input in the form of business specialists, analysts, and visionaries, and quite possibly the provision (or training) of product owners as well. They are stakeholders in their own success, and as such they have to be involved in an ongoing dialog of requirements prioritization and release evaluation. That's why offering a narrative continuity can be dangerous. You might create the impression that all they have to do is "push a button" and the software process will trundle along without intervention on their part, with nice reports being generated at major stage gates. A magical code factory where industrious Munchkins rattle through a ready, complete, and accurate feature set like they were churning out chocolate bars. How do we avoid such imprudent whimsy?

Well, I'd say that the mitigation strategy has to be one of - and I apologize for my language here - expectation management. I'm not a fan of that term, being as it is a pointy-haired euphemism for "OK, you'd better line the suckers up for disappointment". But in this sense I really do mean it as "managing expectations". You have to make it clear that buy-in is needed throughout the project and that scope will need prioritizing and adjusting at regular intervals, especially if time and cost are fixed. If you don't get that buy-in, you might have to raise an exception and do something that leads to real disappointment. You might even - as project manager - have to insist on suspension of the project until you are satisfied that the proper commitment is there. I've done that in the past, and although it certainly gets people's attention, it's not something I look forward to doing again in the future.

So manage the expectations. Remember that if you don't keep on top of this, you'll either be looking at project suspension (fail early fail fast), or the encroachment of a waterfall project by stealth - one very like that described in Project Manager Today. And if that happens here is how you can expect your project narrative to pan out:

• Step 1 is what I would call the canape and white wine stage. That's when the ink is on a contract between the stakeholders who have stated their vision, and the contractor who (very often) put in the lowest bid. All that is left is for the technical types to push the button and make it all happen.

• Step 2 is when the problem is scoped out in some kind of realistic way. Projections will be made and exploratory prototypes may be developed to firm out requirements. The first noises are heard about the scope needing to be slashed or resources and/or time increased.

• Step 3 is when the big-wigs start to hear about the problems. The evangelists will start to distance themselves from the project so as not to be tainted by association.

• Step 4 is when the big-wigs who never made the jump must salvage their political reputations by blaming others. Morale will plummet and technical types will leave in droves, lowering morale and productivity yet further. This is the death march stage of the project.

• Step 5 is when the failed product has been "delivered". The initial scope will be revised to match the reality of what has been produced. The project will be declared a success, and the politically connected rewarded accordingly.

But since the required product still doesn't exist, you might get lucky yourself. The opportunity might be there to start again at Step 1 with a new project for the lowest tender. What larks! Canape and white wine, anyone?