Project Failure and Project Budget

Summary

As children, we all LOVE fairy tales! The beautiful princess… the handsome prince… the evil dragon… the wise king… the crafty wizard. They are the stuff of legend, they make our imaginations literally soar, and we love them for that.

Then we grow up to discover that there really aren’t any dragons, the prince has character flaws, the wizard isn’t that smart, the king has no strategic vision, and the princess has to pull off most of the stuff by herself. Life is not what we thought it was.

But some of us remain in awe of one of the most common fairy tales in the world…

… that you can get great custom software on the cheap.

You can’t.

Why? Because millions of people have written billions of lines of code for more than half a century, thousands of analysts have studied it, and the industry has evolved a suite of best practices based on actual demonstrated performance - or lack of it. Data shows that NOT following best practices is one of the most risky and needlessly costly things anyone can do.

Custom software costs exactly what it costs. In general, trying to beat the system and get custom, built-from-the-ground-up software on a budget lower than what best practices dictate only appears to be successful on contract signing day. That feeling of winning the day and getting something on the cheap will usually fade away as the project progresses. The famous Six Phases of a Project illustrates this all too well

Attempting to build custom software on an insufficient budget is the second most common cause of project failure. As I mentioned in my previous article, the biggest cause of project failure is poorly defined scope. Notably, the inexperienced software buyer may not be aware of the indirect costs associated with what appears to be the less expensive option. Finally, there frequently are strategies for cost reduction which allow the goals of the project to be accomplished.

This article is the second in a ten part series “Primary Factors For Project Success”. Projects succeed all the time, but not by chance.

How Low Project Budgets Cause Project Failure

Project budgeting is an artform. It’s not as simple as negotiating the lowest possible price and then demanding excellence from your vendor or team. Of course, there’s always a point of waste and diminishing returns. Finding the balance is a key skill of a project management professional.

Your project budget will define the framework and mindset by which your project will be executed. If your vendor is so hungry that they’re willing to take on a project with a budget that’s realistically too low, then you’re probably choosing the wrong vendor. In such a case, your vendor may not be thinking about the full lifecycle of your project, what industry pros like to call the Software Development Life Cycle. They might just be borrowing against the future and hoping that “magic happens” to rescue them before your project is over.

When a project is budgeted too low, the first thing that’s often left out is risk management. The cost-strapped project manager is forced to be a wishful thinker, hoping that no technology risk events occur, hoping that no team members drop off the project at a key time, hoping that junior programmers will somehow become senior overnight, hoping… hoping… hoping.

Let’s look at budget-related causes of project failure:

1. Vendor instability

If a vendor accepts your too-low budget on a project, your first question should be, “Why?” Maybe, just maybe, this is a sign of stability... your vendor is looking at this project as a relationship builder. More often, however, it’s a sign of desperation on the part of the vendor. 

1. Inadequate staffing

Especially with remote teams, a common way a vendor can promise a budget that’s too low is to present one team to the client, but use a much less skilled team to do all, or most, of the work behind the scenes. It’s an old-school trick called “bait-and-switch”. It’s yet another example that, if your budget is cut to the bone, your vendor will need to compromise on the quality of the engineers to get the solution built.

3. No reserves for risk events

A vendor willing to take on a project with a budget that’s too low likely does not perform extensive risk management. Software development is hard. If you aren’t managing risks and planning for risk events, your project will fail. If your project doesn’t have the budget to handle risk events, your project will fail.

4. Quality compromises and shortcuts

Code developed under budgets that are too low frequently is of very poor quality. The projects with the biggest budget shortfalls will be nearly guaranteed to have barely usable, poorly architectured code that will fail miserably when anything at all changes in the underlying environment, or new requirements are added. More often than not, you will end up literally throwing away all the work products from your project and having to start over or give up on the project.

5. Reduced project prioritization and attention

If your vendor has accepted a project with a budget that’s too low, it’s likely that the management of that company is short-handed, inexperienced, and spread too thin. Whatever attention they might have paid to your project must instead be focused elsewhere in order to close their cash flow gap.

What Are The Indirect Costs of Low Cost Software Development?

1. Project risk

Risk is an unavoidable part of the cost of ANY project, including your. The risk you accept stays with the project until the risk horizon has passed. Mitigation of the risks costs the organization both financially and in opportunity.

Poorly budgeted projects, counterintuitively, are often the most expensive projects. Imagine you negotiate a tremendous deal on your project and you get a vendor to take the project on a budget 50% lower than what other bidders quoted. Then, eight months later, when you’re supposed to be going to market, your vendor needs one more month. Then, one more month. Finally, you lose patience and have someone inspect the code. To your shock, you learn that your code is terrible, the project is way off course, key developers are no longer available, documentation does not really exist, and your funds invested to date are a loss.

Suddenly, your cheap project is much more expensive than it would have been, had you funded the project adequately at the start.

Even if an adverse event like that does not occur, if your organization is aware of the project risk and plans around that risk, instead of paying sufficiently to minimize it, then the opportunity cost to your organization -- in this example, delaying market entry -- can be quite high.

2. Management time

Frequently, the cost that an organization experiences in the time required to manage and oversee the project is underestimated and overlooked. For a variety of reasons that I will address in a subsequent video, projects with low budgets tend to have a larger management overhead to the client organization.

3. Reduced quality

Insufficient budgets are often paid for in reduced quality of the final product. To achieve a high quality result, you need to budget your project adequately to accomplish your project goals.

4. Slower time to market

Projects with low budgets are frequently also burdened with overly aggressive timelines. This toxic combination of risks on a project almost guarantees project failure and massive schedule overruns.