The top 5 reasons your project is failing…

Thought I’d go back to my PM roots with this blog and touch on some project management 101. I guess some of these seem pretty obvious but after a busy few weeks, I’ve again come across customer projects failing and pretty much all the issues, once broken down, could be attributed back to one of these 5 things. So here they are:

1)    Not defining a clear enough scope.

Easily number one, by a mile. What on earth happened to Product Breakdown Structures? Regardless of approach, whether this be Agile, Waterfall, Lean, it really doesn’t matter. This doesn’t mean draw up your big Christmas Tree diagram for each product, feature, activity or component, maybe do it in your head, maybe just jot it down, but still, how can a final scope be agreed if all the scope hasn’t been identified and given an owner?! The key to this is to ensure those delivering the scope are coached into breaking down activities and requirements further, establishing if they’re critical (or “Must Have’s”) and who is responsible. That’s a key role for the project lead, it’s vital.

2)    Not establishing a RACI Model.

How often are we “waiting for approvals”? Or quarrelling over accountability and ownership of a task, risk or issue? I can’t remember the last time I spoke to a customer who had a RACI (responsible, accountable, consulted, informed) in place. Now with most organisations, this will include contractual arrangements related to the RACI, as it’s typical to have business and IT operations spanning multiple suppliers, many of whom impact each other’s ability to deliver and probably won’t have contractual arrangements between them (SIAM model anyone?).

3)    Not engaging subject matter experts.

I’m not trying to pressure people into spending money on consultancy businesses here. It could be that the skills are elsewhere in the organisation or that current resources can be upskilled over a period of time to cater for the future project requirements. Nevertheless, don’t be surprised to have problems managing and administering your cloud services for example (i.e. in Azure), when the last competency gained by your techy was in Windows Server 2008R2. You wouldn’t ask the bricklayer down the road to design and build your house extension, would you?

4)    Ineffectively managing stakeholder engagement.

First stop is aligning expectations. In fact, not just aligning these, but ensuring they are realistic. When I engage C-Level stakeholders, it never ceases to amaze me how many inside the same organisation have different interpretations of what is being delivered, or what the change initiatives are setting out to implement.

Building upon the expectations should then be effective and honest communications around progress. Again, it’s a regular occurrence for me to see project leads or portfolio managers masking over the true status of projects, whether this be through fear of being held accountable or more likely a naivety that the project will always pull the time back, usually with the crazy assumption that “we’ll just throw resource at it in the final weeks and it’ll all be fine” or “it’ll be fine if we transition with a list of snags, BAU will sort them”. There’s a lot more to stakeholder engagement than this and one of my previous blogs covers it in much more detail.

5)    Slipping on documentation.

You’re probably thinking “surely not? A top 5 issue?”. I’m afraid so. The following seems so basic, but the impact is huge when you consider the potential scenarios. The problem is, in a lot of these situations, these omissions or slippages don’t get caught out, but when they do the project usually ends up in disarray.

  • Not getting verbal decisions, agreement or commitment in writing. What if the stakeholder involved doesn’t deliver and denies all knowledge of what was agreed? What if a change of scope was actioned without an approved change request and suddenly the scope reverts back? Who covers the time lost with nothing agreed in writing? Good luck relying on “good will”.
  • Not documenting, updating and following up on RAID information. Maybe not even documenting a risk in the first place. If it matures into an issue, potential mitigations were missed and then there’s impact on time, cost, quality etc.
  • Sending out reports late. Again, they’re distributed for a reason. A late report can mean a late decision, a late action against a risk or issue, maybe even softer impacts such as loss of stakeholder confidence.
  • Not documenting the original project or programme brief. Perhaps not writing a statement of work. Even if they are written, has someone slipped on ensuring these are approved and formally baselined. How can you track against objectives or success metrics without these? How can you be held to or hold others accountable to scope if the scope wasn’t approved in the first place?

There’s various other elements to these top 5 issues and there’s probably a lot of other common issues I’ve not mentioned that others may debate should be in the list. From my experience though, catering for the above ensures budget matches scope, scope matches expectation and the on-going delivery is managed effectively, being implemented by a team with the required capabilities to ensure best practice in their methods and quality outputs from their effort.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s