The three causes of failure

Projects usually fail because of three primary reasons: Communicate, engage and skillset. If we knew this happens when things fail, then why don't we address them better at the start of a project?

I have found that projects that find themselves in trouble fail because of three primary reasons. I say primary as all other causes can be derived from combinations of these three. They are Communicate, Engage and Skillset. If three are the cause of failure, then only one is needed to recover from any situation. Honesty. The trouble is, that one can be the hardest for people to accept as the catalyst to recovery. Who wants to admit they're not in control of things?

For many, the causes are not new. "The scope was wrong", "Didn't you check it?", and "Why didn't you tell me there is a problem?" are all too familiar on problematic projects. Clients blame their delivery teams, delivery teams blame their clients, and everybody is...'right'. Once I hear phrases like these in project meetings I know its time to get back to basics. Unresolved, meetings become emotive; language turns accusatory; participants become indignant; and apathy sets in as people protect their own interests. You can see palpable trouble brewing.

If you could apply a systematic approach to work through each of these failure areas, can situations really be recovered? Yes. Once you know what the issues are, you can implement steps to fix them. It's not knowing them that causes the problems in the first place. I've learnt from experience that the order that you tackle them gets you better results. Helping teams understand that there is a process that can be followed also allows those teams to be more honest during recovery. If it's not just them and 'this project' then honest discussion is easier to embrace. If you alienate or embarrass the team during the discovery process, they won't be honest, and you'll struggle to get to the actual cause of failures.

Engage - Or Engagement. This is often the simplest area to start with as it is generally viewed as input based. Lack of input equals lack of output. It's an easy blame. Engagement is more than quickly determining if teams haven't been briefed properly. This is because it includes the way teams are briefed. All the information may be there but teams need clarity in their roles. Their expected performance should be linked to the project information. The failure comes when the expected outcomes aren't being achieved. Expectation and engagement are closely linked. If you can determine what was expected, then you can see where this hasn't been met.

Skillset - It's best to tackle this next as it can the toughest to get through. The idea here is to match the actual skills of the team to the tasks they have chosen to undertake. I've never met anyone who set out to do a bad job but I have met many people who have taken on more than they can actually do or get done. When in recovery mode, team members need to deliver 'that which they can absolutely be relied upon to deliver", not "the things they like working on". Its a simple concept, but when you match individual skillsets against the project tasks, you'll quickly find gaps. The gaps are important. Refocussing teams, rearranging their tasks or changing team members to fill the gaps will get a more efficient outcome.

Communicate - It's often described as the mother of all project problems. Too much or too little. Most projects don't define how much is required or what type is needed. By following the above process you may have already come to the realisation that communication is a big problem at each step. This is at every level from those engaging others to those working on the project elements. You can address the level of communication that led to the discovery of issues in the first two steps and thereby enable a real change in the outcome. It can be cathartic for a troubled project team.

Of course, this process of determining faults as above are just my observation. They may not the panacea to every project problem. Although with the projects I have worked on with delivery issues, this method provides a great context to help recover situations. The kicker is of course, that if we knew this happens when things fail, then why don't we address them better at the start of a project? I have a view on this too which I called The Wonder of Why. Combined I'm finding them a very simple and powerful delivery platform.

Ignite Your Thinking

What Do You Think?