Are You On a Death March? Accelerating Late Software Development Projects

Late projects: it’s a PM's worst nightmare, yet for many it’s a way of life. The development team started a new initiative and committed to (or were forced into) a deadline. Now the project is running way behind. How did we get here? More importantly, how do we fix it?

How Did We Get Here? 6 Reasons Why Dev Projects Are Late

1. Market Pressure

The market is more competitive than ever. Silicon Valley is awash with cash and able to turn around new products lightning fast. It’s no wonder we have more billion dollar SaaS companies than ever. But releasing digital products is now critical to all industries, not just Silicon Valley. Government, insurance, manufacturing companies, pharma, banks are all releasing web, mobile and voice applications as well, and their IT departments have no choice but to sign up to this same fast pace.

2. Estimation Is Really Hard 

Despite several decades of mainstream software development, estimating the time to build a new application is still more art than science for many. Software is not a repeatable process like baking a cake. There are patterns, yes, but great digital apps are always trying to break new ground, and estimating how much time and effort that innovation will require is difficult to quantify. 

3. Political Pressure

Even if you know the project carries risk, as the PM, you have tremendous pressure from the exec team to deliver. You could tell them it will take a year longer to deliver, or... you could take your chances and give them a more optimistic view. The former might get you fired. The latter you live to see another day. It’s no wonder some will cave to the political pressure and provide a rosier view, even when they know it’s fraught with risk. 

4. Not an A-Team

Delivering digital applications is a multi-disciplinary sport. You need a product manager, an architect, a team lead, developers who specialize in different things - frameworks, UI, algorithms, prototyping. There are different UX Design skillsets such as researchers, interaction designers and visual designers, and different QA specialists, from manual testers to specialists in automation. Got AI in the mix? You might need a data scientist and a data engineer. And on it goes. 

For sure, not everyone is going to be an “A player”, but the difference between a great dev and an average dev is staggering.  Your key roles must be filled by top talent. 

5. Unchartered Territory: AI, IoT, Voice, Blockchain

New technologies like AI and blockchain offer a world of possibilities, but many of these possibilities may not actually be able to be implemented in practice, even with a huge budget. It's easy to promise "The product will automatically predict X with high accuracy." where X could be anything from detecting a security breach to predicting stock prices to finding the perfect outfit for you wear. But even if the prototype is already 70% accurate, it may never get to 80%, or whatever you need it to be to be commercially viable.

6. Changing requirements, 3rd party dependencies, outsourcing, and all the rest

And of course there are all the ‘classic’ software problems that have only intensified over the years. Digital applications are rarely built in isolation and often depend on business stakeholders who constantly change their mind on requirements, 3rd party vendors who are late on their part of the project, and the myriad problems of outsourcing. Add it all up, it’s no wonder projects are late.

How To Rescue a Software Development Project That is Way Behind

First you need a clear and honest diagnosis of why the project is running behind. From the list of reasons above - is it team members not performing? Constantly changing requirements? Unrealistic estimates from the start? It can be hard to be objective about this, so having a trusted expert ‘audit’ your situation can help you to see things more clearly. 

Second, is the project rescuable without first resetting expectations with your leadership and customers? Many PMs will make tweaks to the team and project: add one more dev, drop one feature, and announce that the project will take a few more weeks than planned. But is it really only a few more weeks? This often devolves into the PM regularly going back to leadership and announcing delay after delay. “Just another few weeks and we’ll deliver, this time for real.” Each time you announce a delay, you lose credibility. 

Instead, if you are going to announce a delay or make a change to the team: go big. “This project is going to be 6 months longer, and here are the detailed reasons why. But we are going to take big action to make sure we get it right this time, so that we don’t incur any further delays.” It will be more painful to announce a bigger delay, to really reset expectations. But you’ll have more credibility in the end when you deliver on your promise.

Finally: rescuing a project really does mean implementing big change. PMs will be hesitant to swap out an underperforming team member because that person has knowledge that might get lost. They may not want to add more team members because it means ramp-up and a short-term drag on the team. They may not want to outsource to a partner because of the added risk and unknowns. But this is short-term thinking. Play the long game and you will deliver on time and with credibility.