Saturday, 18 April 2015

Project failure, a sermon

I'm writing this because @SusanneMadsen suggested that I should do it.  Susanne was talking on Twitter about why do projects continue to fail and what can we do about it?

I wrote my masters dissertation on project success, taking that success was the opposite of failure and post Chaos and others we seem to be pretty clued up about how projects fail.

So, Susanne posted and I responded with the following reasons:
  • ·       People and politics
  • ·       Rushing into delivery
  • ·       Lack of need
  • ·       Poor requirements
  • ·       Delivering a thing and not change itself

I will attempt to break these down further in the next few paragraphs.

This post is not a reflection of my masters research, or an in-depth response, but more about what I feel are some of the reasons why projects fail right now.

People and politics

People are necessary for projects to succeed.  They are also a major reason for failure.  When we embark on a project, we should only do so after having engaged with stakeholders. So, if you're engaging with stakeholders, nothing can go wrong, right? Actually, yes.  People in business are often like little warring tribes, all trying to score points off each other, battling out and messing each other around.  As the BA/PM you walk into all that and stir it up. So, people will sometimes misinform you, feed you false information and generally make nuisances of themselves.  They'll use control of resources at their command to pull the rug out from under you, tell tales to try and get projects stopped and generally just cause absolute mayhem.  In this respect, being a PM is sometimes an absolute nightmare. The only thing that I think you can truly do to ensure that this doesn't happen, is to change in such a logical way that no-one can really dispute it.  You have to have a really robust argument and be able to explain it fully.  You also have to communicate constantly throughout the change. People will always create waves (NIH, etc) but you can try and do things to reduce the effectiveness of their undermining.

Rushing into delivery

Often, once someone has "sold" the idea of the project to someone senior, it'll be a mad scramble to get on with things and show movement. It's at this point that we need to just pause and take a breath.

Sure, the idea is great...but should we really do it? We need to thoroughly investigate what we're doing and plan it properly. Only then should we get on with it.

I recently saw a pretty reasonable sized effort that had been wheelspinning for around 12 months for this very reason. People were just getting on with doing "stuff" that they thought would contribute, but really they were getting on with a number of disparate legacy stuff that aligned vaguely with where they thought it should go.

12 months on, and everything is only now starting to actually gain traction and move forward.

So, you might say "yeah, sure but at least they were moving forward". Indeed, but there was little link between things, and that meant that they were potentially investing without much thought. Benefits, benefits, benefits. Look at how things need to change structurally, then move things to suit. Don't just say "we need a new time management system", because you can probably do what you need with the old one and if you've not thought about what you're doing, then the new system probably won't be right either.

So you'll deliver on time and in cost, but it'll be the wrong thing and therefore you'll have 100% failed.

Lack of need

Often, people just buy and upgrade things without thinking "Do we need this?" We need to develop systems thinking.  Do we sweat the asset that we already have?  What benefits does upgrade bring?  Why are we changing?

Perhaps it all seems like I'd rather stay the same, with my bakelite TV, pipe and slippers.  No way, change can't happen fast enough for me...but it has to be the right change.  We can't just invest in things wildly, spray and pray.

We need to think what we need to be doing and ensure that we hang investment off that.

Poor requirements

The problem with this is often that stakeholders don't know what they want.  But why should they?  In my Business Analysis work, I ask people to talk about what they do and try to improve how they do things, then within that looking at how they interact with technology.  This is not shoehorning them into a solution - often it's about prototyping and getting them to work with simple systems to "mock up" an interim solution.  During that journey, they become a better, more informed customer for a final solution.

The other thing that has become evident is that the more you think about how to streamline things and mock up prototypes, the more that people start to get why we're trying to change things. They start to engage and get involved. The change that is finally implemented is much more successful because people have thought about it in depth.

So, rush ahead at your peril.

Delivering a thing and not change itself

Here, have some ICT.

6 months down the line, "why aren't you working better?".

Well, that new ICT didn't come with any training and you didn't explain why you needed us to use it, so it's over there in the corner under the pile of coats. We have some great video conference equipment.  The quality is fantastic.  But it doesn't deliver the benefits.

Why?  Well, in order to reduce travel, you have to cut out lots of travelling.  But video conferencing only cuts out about 5 meetings a day for the whole organisation.  Everyone else still has to travel.

Culturally, most people like to go and see the person that they're talking to, buy them a coffee and perhaps they also get chance to see some other colleagues for a catch up while they're there.  So video conferencing works for a small number of staff per day, but not the vast majority.  So, small benefits realisation.

If there had been some number crunching, you'd work out that having meetings slightly later in the day would save more money than anything else.  Also, giving people a connected laptop allows them to pull up the relevant info during the meeting and therefore have less meetings.

So, look at the change itself.  What do you need to achieve?  Plan the delivery to include training, staffing, communication and handover (with suitable service levels).  Then keep revisiting things post delivery to ensure that it's all getting used as planned.

So, with all that in mind, it's not really surprising that we don't have the success that we crave.

No comments:

Post a Comment