How To Manage Delayed Software Project

Google+ Pinterest LinkedIn Tumblr

How often you see yourself in a delayed software project or a missed deadline? According to a 2017 report from the Project Management Institute (PMI), 49% of IT projects going through uncontrolled changes and therefore, get delayed. Not to mention, 14% of them fail miserably.

Source: PMI

While I was thinking about how many delayed projects I experienced before, I noticed I’ve been in some of them, more or less. Short deadlines, with too many promises, if that’s sounds familiar. And admittedly, I saw far less delayed projects in advertising agency compare to product/platform companies that I worked for. What would be the reasons? That will be my future post on why agencies are doing better in execution compare to product companies.

In this post, I’ll discuss how you can survive the mess that probably created by you or your peers, your client, or maybe your boss. Who knows. But hey, this is a time to take some tactical action.

Step back, re-evaluate and make radical changes

The first and most important step to take is, re-evaluate your solution and thought process. I’ve seen many times the idea is based on weak assumptions (not researched or though deliberately) or people just feel stuck with a problem that is non-existent. The goal in this stage is, reflect on your current workflows instead of continue building.

It is also a great time to re-evaluate the dependencies of your project and where it’s possible to cut the losses. Sometimes your team is not the only one responsible for the current situation. It can be part of your software that needs to get shipped by a vendor that is way behind their delivery dates. This may be a time to find a more reliable vendor or even continue it in-house.

Usually sticking with a bad decision is more costly, so be aware of the pros and cons of whether do you want to continue with what it is.

Identify the key stakeholders and communicate with them effectively

Now, this might look obvious, but in reality, when people are rushing, we forget and skip clear communication. We need both action and communication in order to deliver good products in large teams.

The goal here is, identify the right stakeholders and by that, those have a decision making power, and also those who get impacted with your actions. And finally, create a clear communication line between them. The practical todo can be:

  • Doing a daily check-up or daily standup. Bring up risks, frustration, and listen to your peers carefully.
  • Keep track of important decisions and communicate it as early as possible
  • Communicate blocking decisions, issues, or anything that might put your deadline at risk. That’s a time to challenge the status quo without hesitation if that’s what you need to do.

Understand the real team capacity & their output

What do I mean by real? Real in that sense, not everyone has the same output in the team and this is a part you need to consider when you re-think your action plan. The data is usually available from everyone’s past performances and you just need to get them into actionable insight and plan accordingly.

Think twice when you want add more engineers

Adding more people in rushed projects, usually not giving the outcome you are expecting. I wouldn’t say this is bad for every situation, but make sure you assess some factors such as onboarding time, the learning curve of your project, and the engineer’s technical capabilities.

To summerize the points, let’s see when it’s okay to do that:

  • The other engineer uses the same tech stacks and tools
  • The other engineer is know how to act on rushed projects (Many don’t and that’s okay)
  • The other engineer is work with your team frequently and she knows what you are up to
  • The other engineer is dynamic and transparent with his thoughts/actions/methods
  • The other engineer built something similar previously

Make sure you tick at least 3 items in this list, otherwise you make your problem bigger than what it is.

Discard. Prioritize. Discard. Priotize

This is for many people, it’s a painful process and I get it.

Perfection is not when there is no more to add, but no more to takeaway.

Antoine de Saint-Exupéry

Try to keep the focus on important and critical needs and make a difference between your expectations of your project and your customer needs. These are two different facts and it’s important you differentiate them and understand them fully before you continue with the delayed software project.

Make action items for every stakeholder meetings

This is probably applicable to all the meetings. It’s important you take clear action items from a meeting and make people responsible for those actions and follow up afterward. A meeting without a clear action plan is just a time-waster.

Accept the luck factor

You might just unlucky as things didn’t work out for your project. There is fascinating research by Daniel Kahneman, a famous psychologist about luck.

When he visited an investment firm at Wall Street, he calculated that the traders, who were highly prized for their ability to “read” the markets, performed no better than they would have done if they made their decisions at random. The bonuses that they received were, therefore, rewards for luck, even though they found ways of interpreting it as skill. “They were really quite angry when I told them that,” he laughs. “But the evidence is unequivocal — there is a great deal more luck than skill involved in the achievements of people getting very rich.”

There is a great deal more luck than skill involved in the achievements of people getting very rich.

Daniel Kahneman

Make a peace with that and believe there are many things that are out of your control and that’s fine.


And finally, don’t forget to take a breath while working towards your deadlines. It’s important you have a clear mind to look at the problems from different perspective.