Updating the trough of despair – Do projects always double dip?

When I first learned project management we were really into waterfall concepts like crashing the schedule and EVA.  In fact I really enjoyed the process of Pert charts and planning.

But I stated to notice that many difficult things ended up being deferred to “release 2” then “release 2.1” and then “post-release business as usual”.  This actually meant they didn’t get done.  So I was talking to an experienced PM from a consultancy and he introduced me to the concept of “the peak of expectation and the trough of disappointment”.

At first I thought he was being cynical, but I gradually learned that managing these peaks and troughs is what good project management is about, even beyond the fun of Pert and Gant charts.

As my PM friend explained it to me:

• Every project starts with a bunch of eager people hoping to change the world.  Often the scope expands as the project starts and people realise that this project could be the vehicle for huge opportunities to improve the world.
• In a bad project this continues with more and more time spent in “analysis”.  Or worse the team start purchasing huge amounts of licences and infrastructure on the assumption they will deliver the project scope exactly as planned.  Then the go off on fact finding missions, training and other adventures while the huge budget of the project slowly dwindles.
  • Some projects stay in analysis paralysis and never move forward (this is missing from my advanced diagram).  Many others, though, suddenly notice that the deadline is approaching and the budget is being burnt.  This is a real disappointment to the happy project crew who feel a sense of panic and despair (the pit of despair).  This is the real danger point for the project because the team is tempted to de-scope the hard bits (or call them “release two” and hope some later team will do them). In the worst cases people start implementing “hard coding” and “tactical solutions” to hit the deadline.  When this happens they may find themselves descending into the valley of doom – a place from where the project can not recover.
  • Most projects though do not fail in the trough of despair. Instead they do de-scope some things, and they also find solutions that they did not think of for many other things.  The trough of despair turns out to not just be the danger point but the point where reality clashes with dreams and the most innovative solutions can be produced.
• Even in a really well run project though, the same ebb and flow occurs.  The team dream big to start with and then test their ideas with prototypes or more analysis.  They then face disappointment as some things turn out to be too hard to do properly or compromises are made for different stakeholders.  And here they also spend the time questioning and challenging their ideas to come up with creative solutions.
• The final phase in the model is that the team spend the final 20% of the project working on will really be in the release and bringing home their innovative solutions (or hard-coded nightmares).  Morale is usually high even under the pressure of releasing (if it is not then this is a warning sign of trouble).  People can see the end of the road and they can turn their work into reality.  This is the heights of reality.

I have found that long projects end up with a longer and deeper trough of despair and this is a good argument that you can’t plan for a project that is too long.  If you don’t release anything for two years this is really bad and even over 6 months is scary.

Agile projects should in theory change this flow by releasing frequently, as should really well run waterfall projects.  But in reality I find many agile projects release to “pre-production” and not the end client.  So the same flow seems to occur (in my experience anyway).

But wait there’s more … I think there is another dip to come

I spent a couple of years working as a release manager and a production support manager (or production support improvement dude) and I often found that I was disappointed with the trade-offs the project had made along the way.  I had missed the trough of disappointment and had no idea why some seemingly limited decisions were made.

My initial conclusion was that project managers are dodgy and want to roll out what is easy rather than what is needed …. until I remembered that I had been one of those dodgy project managers and had really struggled with ideas.

So now I think there is a seemingly inevitable second dip in expectations and satisfaction.  Whenever a system goes live we learn that reality did not quite suit our model of it. We also cop the full impact of all the trade-offs we made in a project … even the sensible ones.  So there will always be someone not happy, or some really obvious thing that we missed.

And even if the project is going on to a second release, there is a period of adjustment where the crew want to move onto cool new features while they are caught up with enhancing or fixing the things they thought they were done building.  So there is a period of some turmoil and struggle.

I guess you could call it the second trough of disappointment, or the Chasm (or creek if you are lucky) of user concerns.

What can we do?

We can release more often to make the dip shallower and shorter.  That is probably the best thing to do, but of course there is a cost to having more releases.

I guess we can do better requirements or communication to meet stakeholder expectations but this will never really be enough.

We can tell people to “suck it up” and put up with the stress.

But the other thing we can do is see it coming, brace ourselves and allocate resources to taking on the feedback and continue to build the system after it is released.

Again this is an opportunity to collapse into the valley of doom or to use the opportunity to start finding ways to meet individual user expectations while still simplifying maintenance and overall consistency of experience.