Blog Detail

From time immemorial organisations have given their project managers permission to fail. This is generally through their constant inability to contain their urges when it comes to change. This manifests itself in time and cost overruns, not always with appropriate authorisation. Through poor control by senior managers, their project managers have inherited the wisdom that time and cost can be flexed when under pressure. They will ‘get away with it’ because the customer is complicit in the mismanagement of the project and both parties become accustomed to the failure and see it as the ‘norm’. So why does this continue to happen when we have good, solid, long-standing project management methods under the likes of PMI, APM and PRINCE2 which propose excellent governance processes as regards change control? I postulate that it all comes from human frailty…an inability to say ‘no’, an inability to stick to process guidelines, an inherent desire to ‘save face’, a need to please and many other cultural and personal foibles.

One of these weaknesses is the apparent need to complete something whilst ensuring EVERY requirement has been met and delivered.  

This fixation seems to have developed alongside the traditional project management methods where all the requirements are dredged-up before the project starts and then there is a concern that if they are not delivered, or they are de-scoped, the customer will never get them…after all, we all know that ‘Phase 2’ never comes!

So how about NOT fixating on that list of requirements?  

How about harnessing a cultural foible so that the project managers stop failing and start winning?  In a recent article by John Edmonds, Head of Training at Pearce Mayfield, he said: “It is culture, not rules or strategies that shape great organisations.” Therefore with this in mind, if an organisation can’t stick to process guidelines (culturally speaking) then let it use that fact to its advantage by operating in a more agile way.

By all means paint a vision of what is required by the end of the project; definitely, come up with some high-level requirements; positively prioritise those requirements; plan the delivery and then set the time and cost in stone – NEVER to be moved (see Fig 1.).

These are the fundamentals of Agile Project Management where the flexibility (agility) comes from accepting that change is inevitable in a project and that we don’t really need ALL the features listed at the outset.  Indeed, a number of them will alter over time due to practical, technological and process changes. 

Now comes the difficulty.

How to break the culture of needing everything to be delivered rather than being satisfied that “less is more” and that business benefit, maybe without all the bells and whistles, can still be delivered.  At first sight, it looks like a bridge too far but if you follow the principle of focusing on the business need, then the project will deliver exactly what the business NEEDS and not a load of additional features that may not be used.  This will allow the project managers to ‘win’ for a change by delivering to time and budget, which in turn will increase the confidence of the business that they will get a working solution by a specific date and for a specific cost that will deliver business benefit.  What’s not to like about that?

The key to all this is PRIORITISATION

In this case the MoSCoW prioritization technique as applied by the customer/user and not the technicians so that the true business need is satisfied.  The technique requires the business to prioritise the requirements under the following headings:

Must Haves, Should Haves, Could Haves and Won’t Have in this timeframe

The problem is holding on to a full understanding of what those headings actually mean throughout the life of the project and prioritising everything based on that understanding.  So, putting it on the line, what do these terms actually mean and how much effort will be applied to delivering them in any particular timeframe?

If we look at the split of effort it can be seen that the Must Haves (at 60%) provide a tolerance of 40% if the team can ONLY deliver those features, which is why the project manager can guarantee their delivery.  However, the sponsor will expect at least both the Musts and Shoulds to be delivered…and why wouldn’t they?

This split of effort is applied at the project level, at the increment level and at the time box level, thus inserting enough tolerance into the project so that the Must Haves can be guaranteed.  I have witnessed the incorrect use of the MoSCoW prioritization technique where all the Must Haves are loaded into the front end of the project, which means there is no tolerance for the first two or three timeboxes.  This leads to a failure to deliver these timeboxes due to there being no tolerance on the effort and we are back on the merry-go-round of failure once again!

So, coming back to the original assertion that tradition has permitted our project managers to fail, it is now time to embrace that cultural foible that entices us to ‘fiddle’ and change our minds (within reason) because project deliverables need to shift and change as the project evolves.  We can then support our project managers and set the trend of winning by adopting an agile project management approach.