Why Your Software Project Will Take Too Long

Is your company embarking on a software project and planning to handle it in-house? There are some things you should be aware of, namely that your software project is almost guaranteed to take too long. If Benjamin Franklin had been born about 300 years later, he’d have amended his list of things that are certain to be death, taxes, and software project delays.

It’s not that the IT departments or Innovation Officers of major organizations are incapable of producing quality software products. They aren’t. However, most leadership teams end up being shocked (and dismayed) at how long the software projects take. And longer timelines almost invariably equate to higher costs.

But the reasons behind why software projects will take too long do not fall entirely on the shoulders of the IT department. Read about the factors at play across departments and up and down the org chart that contribute to what we (not-so-fondly) refer to as Forever Software Projects.

1. No clear business case for why to build

One of the biggest reasons software projects get stuck in early planning stages and never take flight is because there isn’t a business case for building the product. It can be the flashiest or most compelling idea, but if the cost to build it can’t be justified, it won’t make it as a line item in the budget. Even if cost isn’t the primary dampener, a software project without a business case causes hesitancy and lack of confidence, which will make it difficult to socialize among key decision makers.

2. There is no owner

An issue that frequently arises within in-house software projects is one of accountability. Often, the person driving the need for the project may be in marketing or sales or may even be the CFO. This person, however, is not accountable for the completion of the project and may not even be involved once they have obtained the necessary permissions and funding to kick off the project. After the software project commences, it becomes unclear who is ultimately responsible for – and qualified to be involved in – planning, execution and launch. Lack of owner means lack of accountability, and no one to light the fires necessary to push through obstacles or delays.

3. Lack of expertise in digital product development

A software project often lands in the lap of the IT department. But that doesn’t mean the team has the talent to undertake it. While this department may be skilled and qualified in technology, they might not have actual experience with turning an idea into actionable steps. Unanswered questions like “Who is made responsible for timeline and deliverables? How are priorities ranked?” become snowballing problems. This lack of clarity can delay or even prevent execution entirely.

Lack of expertise can also cause issues like choosing the wrong software for the project. For example, it takes hands-on experience to know the importance of choosing the right software platform suited to the application being built.

4. Misalignment of stakeholders

Even once a software project is approved, it doesn’t mean stakeholders are aligned on anything other than the “Yes.” Projects are delayed when stakeholders can’t agree on how the product should be built, what features are important, how it’ll launch, and much more. This is especially true when project influencers are in different departments. Clashing priorities or end goals for the software may stall or completely sink the software project.

We have seen this happen when one stakeholder got tired of waiting and found a builder so they could get what they wanted out of the project. This created a “too many cooks in the kitchen” situation, and the project never got off the ground.

5. Product concept is not tied to priority business objectives

Timing is everything. A project may have a strong business case and still fail, because it’s not aligned with current business objectives. It takes determination and ongoing momentum to see a software project through to successful launch. If all hands on deck are focused on driving particular business objectives, the drive won’t exist for a project that doesn’t contribute to those efforts.

6. Changes in scope or specifications

A project requires thorough and comprehensive planning including full specifications or requirements. A project owner must ensure that these are clarified and nothing is left ambiguous or unsaid.
Project management is very different from product management. We covered this in the blog Software Product or Software Project: Know Which One You’re Creating. An IT team that doesn’t constantly develop software might not be sporting a project manager and a product manager. This can lead to gaps in the information collected and the expectations communicated at the beginning, which can then cause major delays as parts of the project are pivoted.

Clarity in the Beginning Prevents Software Project Delays Later On

Hiring a digital design and build firm is a no-brainer for a funded, early stage startup with only a couple employees, but we find ourselves being hired just as often by large established organizations who have in-house IT teams. Usually, these companies have previously traveled down the path of developing new software or deploying updates and realized that they’ll ultimately spend less time and money and emerge with a superior product if they hire outside experts.

They’re right.

We find it easier to align decision makers with competing interests as an agnostic outsider, rather than an internal leader with their own personal stake in the game. We have done enough projects to be able to predict issues before they arise, stamp out ambiguity, crystalize objectives and expectations, and guide the project down the shortest, clearest path to success.

Our advice to established companies is to continue to do what they do best, and let us do what we do best. When ENO8 is on the job, Benny Franklin can keep his list of certainties to two items.