It happens, projects can not always go to plan. There are many reasons, from unclear objectives, insufficient project team members, and project managers not communicating correctly (heaven forbid). But as learned in John C. Maxwell’s book, sometimes we learn, sometimes we fail; it is important that we learn from project failures, instead of just finger-pointing at a scapegoat.
We’ve all been there. Projects have gone over the time given, or when the project has been released there have been errors. We as humans (and machines too) are prone to making mistakes. This can be caused by stress from working tight deadlines. When working to tight deadlines, it is easy to miss something and not to work to our highest standard because our mind is thinking about multiple things while working to a tight deadline. We get stressed because our mind is about achieving something and what might happen if we don’t hit the deadline.
When deadlines aren’t met, or issues do arise we automatically think this has been a failure. It could essentially mean that everything has not been scoped correctly or all risks weren’t noted and mitigated. But, there have been many projects that go over budget and time.
The Sydney Opera House was originally estimated to take 4 years to complete with a budget of $7 million – it actually took 14 years, and construction cost $102 million 😐
The same applies to a lot of video games and some Hollywood movies. They miss the original estimated release date and sometimes that results in major bugs in games and unfinished editing or unfinished VFX effects. Games that went over budget include Killzone 2 and Cyberpunk.
If stress is an issue, take a look at these hints on how to work more healthily and also to work on time.
Despite the aforementioned projects exploding over budget, they were eventually done, with praise. The Sydney Opera is definitely not a failure. When you think of Sydney, the picturesque building by the river is probably what comes to mind.
But how can we start learning from project failures?
Normally when a project goes not to plan it is easy for management to start blaming developers, project managers or other creatives. A blame culture can occur and stress can impact workers.
Ideally, we should create a safe environment for developers. Encourage them to learn from the experience. I like to use project feedback forms once a project has been created. This is to provide an insight into what they think went well, what could have been improved and any issues they came across. Without these answers, it might not have been obvious what issues there were. We get caught up in our own issues, it can be difficult to miss other people’s issues. For information, read Brilliant Project Manager.
It is also useful to ask all stakeholders similar questions too.
Retrospective project management is not a new concept, but it is something that seems to be overlooked in software development. Most of the time I had time to reflect on a completed project during a one-to-one meeting. By then I could’ve forgotten any issues or perhaps I might’ve started on a new project.
It is so easy to finish a project, wrap it up, pass it on and then move on to a new project, but by not learning from project failures we could be missing out on some key, and important facts that could help us on future project planning.
To conclude
Use candour in your workplace. Create a relationship with your developers and other creatives that allow you to speak to your openly with each other. It is important not to get annoyed with developers and to start shouting and belittling them. Instead, ask questions as to why something didn’t go well. I have even heard of some places that have failure parties.
Of course, it is important to attain authority so that the same mistakes don’t happen again and that quality is still high.
