First of all, let me say that it is perfectly possible that you have done everything right and according to the book but your project still fails. We have certainly seen a few “just wasn’t the right time and place” kind of scenarios in the past.
However, as with everything in software development with the right tools, mindset and methodology you can get much more consistently closer to target results.
Here are some quick worldwide stats to start you thinking:
- Only one of every fourth software project is successfully completed
- 55% of software projects suffer from lack of time to deliver the product
- 94% of the software projects failing is due to non-technical issues
- An average software project runs 66% over budget
Well, you could just say that software developers are just terrible at estimating and that is it but in reality a software project has so many more variables than just pure software technology and these added factors usually play a much bigger role in making or breaking a project.
Here are the highlights:
- Not enough or bad communication
- Lack of flexibility built-in
- Insufficient Project Management
- Unrealistic expectations
- Not Enough Emphasis On Soft Skills
Communication, communication and communication
I can’t stress this enough and I know it sounds obvious and simple but over the last 11 years of my career I got reminded every single day that communication is the single most important aspect of a successful project. This is said pretty often but the ‘why’ is usually not explored enough.
The projects (and our lives in general to be a bit philosophical) are all about constant change. Even with the best and most careful planning, even with the most steady market and even with the most patient stakeholders you need to brace yourself that there will be changes on a daily basis. Some are miniscule, some are bigger, some can be avoided but one thing is for sure, things will constantly change, period. Once you accept that, it is clear that tackling the challenges that changes introduce will always require communication. Not only that, but they will require high quality and consistent communication.
Let me list a few examples:
- I have sent this in an email 2 months ago, haven’t you seen it?
- …but I agreed on this with the other dev in a call
- I asked this earlier but as there was no reply I came up with my own plan
- My manager cancelled the meeting but I will show him the notes later
I think you get the idea. The communication needs to be continuous, consistent, clear and transparent above everything else.
It is a good idea to have recurring standups or meetings not only internally but with your client and even end-users as well. For me, one of the most important communication forums is the presentation of the work delivered. This can be about a fairly small component in an internal development sprint demoed online or a huge milestone, presented live in front of all the decision makers but this is often the moment of truth because let’s be honest, we pay the most attention when something finally gets near to the finish line.
TIP: try to invite all stakeholders to these important meetings
Lack of flexibility built-in
To continue the previous line of thought, you need a development method and mindset that allows change, adapts to change and takes advantage of change. Your teammates often get scared by this because for them in essence this means that the project goal is a moving target.
I like to approach this from a different angle, we know more today than we did yesterday so it is a process of continuous refinement and when done right can even deliver better results than originally planned.
What you need is:
- An agile or hybrid agile method instead of a rigid, set in stone development plan
- Enough buffer time built-in in every milestone
- Double the initial time you feel sufficient for user testing
- A long term product vision in place of a set feature list
- A collaboratively maintained always up to date priority list
Please don’t get me wrong, adding new features two days before the planned release date is probably not the right kind of flexibility you are looking for. However, priorities shift, new people come, new aspects are discovered, new technologies get added.. and I could go on so flexibility is an absolute must for every successful project.
Insufficient Project Management
We already agreed that you need good communication and flexibility, you need to communicate change and you need to manage change. There is a dedicated role for that and that is usually in the hands of your project manager(s).
If your project doesn’t have a project manager assigned (even if it is just a sales rep or developer jumping in) you are almost guaranteed to get into trouble. I think that this is no real shocking news but we do see some common misunderstandings around the responsibilities of a good PM:
- “The PM needs to talk to everyone and personally keep everyone up to date”: yes and no. The main goal of a good PM is to enable the free flow of information and ensure members are communicating efficiently. Instead of personally trying to be the main hub of information, creating the right habits within the team and building a healthy framework is the ultimate goal.
- “The project manager takes side on the developer front”: a good PM keeps track of the budget, keeps track of the progress and keeps track of all the tasks so the PM is ultimately on the project success side and this is a fairly neutral ground. It can’t be too deep into the development details because then it is hard to see the customer value but equally, it can’t be too much on the client side because then technical feasibility and project budget go out of the window quickly.
- “Project managers are just paper pushers”: Ouch, this personally hurts 🙂
From the outside, you mostly see project managers organizing meetings, making notes, updating tasks, forwarding information so it is clear to see where this notion comes from but these are just some of the tools to ensure the success of the project. You have to have someone in charge of the PM tasks who owns the deliveries otherwise you are almost guaranteed to fail.
One additional thing I would personally add as a PM task is expectation management which I find increasingly more important. This goes both ways, expectation management within the dev team and expectation management on the client side as well.
Unrealistic expectations
Sometimes even fairly experienced senior tech leads tend to underestimate the complexity and resource consumption of a project to the point where it might seem like estimation is more like an art form and not an exact science but at least some of these things can be adjusted as we go along and learn more about the details.
However, as a quick example we recently had a really exciting client project and shortly after the start there was a really strong need coming from the management to add a 4K video playback feature. You would think “this should be fairly straightforward as the technology is readily available” and this is partially true but after doing some research and setting up a plan it quickly turned out that the additional cost in both development and infrastructure for this single feature would be 6 times more than the entire budget the complete project had.
This is a trend we see as we use more and more software every day and they got really good over the years so the baseline got really high and people tend to measure against some of the most widely available so biggest user base products. It is like having a good recipe for a new soda and trying to beat Coca-Cola. We tend to forget that most of the apps we use every day are built by hundreds of developers over many years and there is an incredible amount of money invested in them.
Also, software technology is still one of the most rapidly evolving of all today and so readily available, you can build a website from easy templates at home so we tend to forget that software development is still an engineering subject and building something new from scratch needs a deep understanding of the subject so you have to trust the experts.
The best tip we can give is to constantly educate all stakeholders involved and even if it is just a birds eye view, try to get them closer to all the different tasks needed to be carried out.
Not Enough Emphasis On Soft Skills
Might strike as an odd one but this might be one of the most important on this list. We have seen so many different types of organizations run into the same challenges because they are over-focused on the technicalities and tasks but not on applying enough energy towards training, coaching, team building and soft skills.
- Unclear requirements and priorities
- Ignoring the end-user or the needs of the business
- Friction and unclear roles within the team
- Struggling at the final delivery phase
These are some of the symptoms that can be partially cured by focusing more on the previous list and dedicating extra energy on the human element of the software as it is at the end an intellectual product created by people.
This topic is something we love to discuss with colleagues and clients as well and we would love to hear your opinion as well. Please reach out to us and share your experiences or prove us wrong as we want to hear from you!
