We hear so often of failed IT projects. So why does this happen? Or better yet, is there a simple way to avoid failure? Well no, of course there is no simple answer, but I do think one thing is vital to success. Communication.
What is success?
What is success? How is it defined? The most realistic and simplistic definition is that everyone is happy. Note that this does not mean it was completed within the original budget. It doesn’t mean the final functionality meets the initial specification. It doesn’t mean it went live on the original planned date.
All of these things can and usually do change. This is because in most cases the parameters of the project change as it progresses: requirements change; estimates are only estimates; and external factors influence the project (e.g. taking resource away from the project or other priorities take precedence).
So does that mean a project can’t be successful? Something is bound to change so how do we still say it was a success?
I believe the answer is good, clear, frank and honest communication throughout the project and to all people involved.
The plumber
An analogy that I like to use is that of a plumber. The same rules apply. Say you need a plumber to do some work for you. He comes along and has a look at your place and gives an estimate. But he's done this based on looking from the outside. He hasn't opened up your wall yet. When he starts the job and does get in there he may find some issues along the way. Perhaps there is something blocking his way.
Now he knows what the final outcome needs to be. He even knows how to do it. But one of two things will happen here. He might go ahead anyway and do what is required and then bill you twice what was estimated. You’ll likely be up in arms over this. How could it cost so much! You were told the price and this is twice the amount! An unsatisfactory project.
On the other hand, he may stop when he realises that there is a problem, get hold of you and let you know that if he continues it will cost a whole lot more. You're not happy but you get to make the decision. At the end of the project the outcome is exactly the same. It cost the same. The result was the same. But it was a success!
The only difference in these two results is communication.
The software developer
Software development is the same. As a project progresses there will be bumps along the way. If everyone keeps their head down and doesn't let anyone know, hoping that somehow on the last day it will all come right there is likely to be a project failure.
Take a small example. A one week task. As it progresses it is clear it is going to take closer to two weeks. If no one says anything we are likely to:
- miss the deadline, even if people work the weekend
- have people stressed, possibly working longer hours
- have a budget overrun either costing the customer more or eventually being written off by the developer
And no one is happy. The customer didn't get what they were promised. It wasn't on time and it might have cost more than expected. The developer isn't happy. She had to work longer hours but is still in trouble for not achieving a successful project. Her employer is not happy because they may have had to write off time and they have an unhappy customer on their hands.
On the other hand, if after day 2 or 3 when it became clear that one week was not enough, everybody stopped and started talking there is likely to have been a very different result.
It’s all about people
No one likes a shock. No one likes being left out of the loop. And people especially don't like being denied the chance to make a decision. At day 3 in the example above a frank and honest discussion with the customer is likely to have had a far more positive outcome. The customer gets a choice. It's completely up to them. It will cost more and take longer, but only if they want to do it.
Software projects are all about people. And good honest discussions show that most people are very reasonable. Everyone knows that some of this stuff is impossible to predict or estimate. So as soon as there is more certainty it's time to talk about it. And from there the project now has new parameters for defining success.
It's very important not to stop there though. Everyone needs to be informed of this. Especially stakeholders. The stakeholders are likely to have empowered someone else to make these decisions. When the parameters of a project change they need to be informed too and they need to know why. Otherwise they are still on page one - and guess what? The project still looks like a failure to them.
Good communication is mandatory
Communication is an enormous topic and there has been an immense amount of research on it. Communication alone won’t make a project successful but it certainly can be the difference to whether a project is considered successful or not.
We take communication very seriously at Sandfield. So much so that we have the consummate Roseann Gedye train us regularly (https://roseannsprinciples.com/). Everybody in the organisation is trained. It doesn't matter the role.
Lead your projects to success
To give yourself the best chance of success ensure that good communication is practised throughout the project. Set up regular meetings to review honest progress. Re-estimate what’s left to do throughout the project, don’t just assume it’s on track.
Ensure the right level of information goes to the right people. It’s not just project managers that need to know, everyone does! Stakeholders especially. And they need to be given the opportunity to make decisions when things change.
This might all seem simple and obvious but it’s amazing how often it is ignored. Too often people just carry on doggedly, thinking they are doing the right thing trying to get it all done. Keeping everyone up to date needs to be a habit.
And remember, most people really are reasonable. If you give them complete, accurate, timely information and have frank discussions, it is possible to have a successful project even when there are some bumps in the road!
