Why Software Gets Delayed & What to Do About It

That said, there are a few key reasons why projects deliver late. Understanding these reasons makes it easier to address and remedy common problems. It doesn’t mean your projects will always get completed on time with 100% reliability. However, by addressing common issues you can eliminate frequent tardiness and make sure that a late delivery is a rare occurrence.

Planning & The Optimism Trap

A major reason why projects deliver late is that the original deadline wasn’t realistic. Sometimes, in wanting to please the customer, account executives, project managers, and even technical leads can put on rose-colored glasses about the challenges the project entails. Applications always get more complicated the closer you look at them. In addition, there are all kinds of things that could come up along the way that you weren’t expecting.

To avoid this common and simple pitfall, a good strategy is to build in buffer time to all your deadline estimates. Then, if you happen not to run into problems, you can delight the customer by delivering early. However, it’s far better to have a conservative timeline and beat it than to promise a quick turnaround and not meet expectations.

Time, Resources, or Scope

Every project (software or otherwise) exists on three axes of project management: time, resources, and scope. If you want to build a big project with a lot of features, you’re either going to need a lot of time, a lot of resources, or both. On the other hand, if you want to get a project done quickly, you’ll probably need to severely restrict the scope and pour resources (money and manhours) into the project to get it completed.

These three axes of project management are inseparably linked. Adding “just one more thing” to a project’s scope necessarily changes either the delivery date or the amount of resources dedicated to the project. Software projects are often late because requirements change over time and more functionality gets added without changing the delivery date to match the new workload. Nobody wants to push back a deadline, but recognize that any good software development shop needs to be honest about the trade-offs when a client asks for one more thing to be added to the project.

Doing the Unknown

Good project managers build buffers into their delivery timelines because there are always unexpected things that arise. Projects get more complicated the more you work on them. What seems like a simple implementation can often turn into a confusing puzzle once you get into the nitty-gritty of passing and returning values, building APIs, and making various libraries or frameworks work together.

Donald Rumsfeld, when he was Defense Secretary in 2002, illustrated the challenges of planning a project. He said there are three types of factors in any project: known knowns, known unknowns, and unknown unknowns. It sounds like a riddle at first, but it’s an important point. There are things we know that we know. There are also things we know we don’t know. But the most challenging part of any planning effort and the hardest to quantify are the things we don’t know that we don’t know.

In the case of software project planning, there will be challenges we can’t anticipate and won’t foresee until they happen. Of course, with experience, the number of unknown unknowns decreases. Still, there is always an element of the unknown in every project. Recognizing that fact and adding a buffer for the unknown and unexpected is the responsibility of a good project manager.

Waterfall vs. Agile

One way to reduce your exposure and risk to unknowns is to use an iterative approach. If you only plan a small portion of the project at a time, then you have greater control over the factors at play and can quickly assess and test how things are going.

That’s one of the key reasons for using an agile methodology when developing software. With every sprint and review, we can immediately see what’s working, what the client likes/dislikes, and modify our next steps to address any issues. Agile projects find problems quickly and course correct immediately.

With traditional waterfall-style project planning, the long time between releases makes delays more likely. Problems take longer to discover, and running into a problem is a huge hurdle that could derail the whole project. In an agile environment, a major issue is a signal to the developers to reassess their current plan and tweak the approach. In waterfall, where project specs are set in stone from the beginning, it is much harder to work around issues.

No or Slow Feedback from Real Users

Of course, an agile approach relies on feedback from the people who will actually be using the software. All too often that feedback is slow to arrive. Then, the agile team gets blindsided when a feature they released weeks ago, and which they’ve been building atop, receives delayed criticism from stakeholders. This feedback delay often means developers waste effort and have to retrace their steps, slowing down development.

In order for a project to deliver successfully on time, developers need fast feedback loops from the right people. Another related issue is when the wrong people test the software. If an executive at the client’s company tests the software, instead of the boots on the ground employees that will use the software daily, then the feedback may be incomplete or ignore the needs of the software’s actual future users. The people who will actually use the software need to be the ones who test the minimum viable product and subsequent releases. They also need to share their feedback quickly and directly with the development team for the highest-quality, most efficient agile results.

Delivering On-Time

Being aware of common pitfalls and following the best practices above doesn’t guarantee that every project will always deliver on time. However, these recommendations can go a long way toward setting clear expectations and solving most delays that software companies face. If everything goes exactly to plan, you’ll be pleased to be so far ahead of schedule. If you run into issues, you can rest easy knowing you planned ahead for the challenges and have wiggle room to work out a solution.

About Black Slate

Founded in 1991, Black Slate delivers technology andto Fortune 500, Government and Leading Technology institutions. Learn more about us. Whether you are a developer interested in working for a company that invests in its employees or a company looking to partner with a team of technology leaders who provide solutions, mentor staff and add true business value, we’d like to meet you.