Thoughts on delayed software project

Pinterest LinkedIn Tumblr

How often do 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 go through uncontrolled changes and 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. What would be the reasons? Short deadlines, with too many promises, if that’s sounds familiar. And admittedly, I saw far fewer delayed projects in advertising agencies than product/platform companies that I worked for. That will be my future post on why agencies are doing better execution than product companies.

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

Step back, re-evaluate and make radical changes

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

Identify the key stakeholders and communicate

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

The goal here is to identify the right stakeholders and, by that, those who have decision-making power and those who get impacted by 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 and create action items.
  • Keep track of important decisions and communicate them 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, which you need to consider when you re-think your action plan. The data is usually available from everyone’s past performances, and you need to get them into actionable insight and plan accordingly. Do not assume.

Think twice when you want to add more engineers

Adding more people to rushed projects usually does not give the expected outcome. If you do, make sure you assess some factors such as onboarding time, the learning curve of your project, and the engineer’s technical capabilities.

To summarize 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 working 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 three items in this list.

Discard. Prioritize. Discard. Prioritize

For many people, this is a painful process.

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

Antoine de Saint-Exupéry

Try to focus on essential and critical needs. Differentiate your expectations and your customer needs. These are two different facts, and you must determine them and understand them thoroughly before continuing.

Make action items for every stakeholder meetings

This is probably applicable to all the meetings. It’s essential that you take clear action items from a meeting, make people responsible for those actions, and follow up afterward.

Accept the luck factor

You might be unlucky as things didn’t work out. 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 randomly. Therefore, the bonuses that they received were 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 involves 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 peace with that and believe many things are out of your control, and that’s fine.


And finally, don’t forget to take a breath while working towards your deadlines. You must have a clear mind to look at the problems differently.