Thoughts on delayed software project

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 undergo uncontrolled changes and experience delays. Not to mention, 14% of them fail miserably.

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 sounds familiar. And admittedly, I saw far fewer delayed projects in advertising agencies than in product 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 is to reevaluate your solution and thought process. I’ve often seen that 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 to reflect on your current workflows instead of continuing to build.

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 high-quality products on a large scale.

The goal here is to identify the right stakeholders, specifically those who have decision-making power and those who are impacted by your actions. And finally, create a clear communication line between them. The practical task 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 extract actionable insights from them 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 knows 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

Focus on essential and critical needs. Differentiate your expectations and your customer needs. These are two distinct facts, and you must determine and understand them thoroughly before proceeding.

Make action items for every stakeholder meetings

This is probably applicable to all the meetings. It’s essential to take clear action items from a meeting, assign responsibility 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 renowned psychologist, on the topic of luck.

When he visited an investment firm on 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 them 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 peace with that and believe many things are out of your control, and that’s fine.