How can you make a project succeed by raising budget?

Question

So I was reading this Answer and it brought to mind a question I've held for a while but never got around to asking.

If you've got a late project with fixed scope, schedule, and quality, you're supposed to be able to fix it by increasing budget, but... how?

It's obvious how removing scope or increasing schedule will save a failing project. But as per The Mythical Man-Month (and as per my own experience), adding people to an already-late project will just make the project even later.

So... exactly how could infinite money be used to save a fixed scope/schedule/quality project?

Answer 1

The answer will be peculiar to the individual project. Wallace's law of project management the PM's primary job is to inform stakeholders of the effect of any change on Scope, Schedule, and Quality.

Your question is perceptive - it is the reason that they hire a PM. A good PM will always have an answer "If I gave you an extra N% budget, how would you spend it? How would you improve scope, schedule or quality with additional money?"

Some of the answer is in your project plan - you've calculated the critical chain and alternative critical paths through the project plan - which of those alternatives is more plausible with additional budget?

Some of the answer is in other questions that you've already developed. What are your constraints? Which choices have you had to make because of budgetary choices that would be changed if the budget were raised.

most of the answer is in your risk/issue log. Which risks/issues could be opportunities if you had additional budget?

minor quibble; budget can't make a project succeed. Infinite budget doesn't create an infinite probability of success. Budget is a constraint, and the probability of project success is always most determined by the most restrictive constraint. If budget is infinite, then scope or schedule will govern the project. A car can't go if the gas tank is empty, but it won't go any faster if the gas tank is overfilled. If the budget is low enough to constrain the project, it is easy to predict how increase budget will improve the probability of success; if the budget is high enough, then it is difficult to predict how additional budget will affect project success. The phrasing of the question is somewhat distracting from the real issues. "How can you make a project succeed by raising budget?"? 2/3 of the time you can't - because the project is not constrained by budget. But that's a quibble with the phrasing of the question.

Answer 2

Budget as the Unbound Constraint

Throwing money at a sunk cost won't "save" a failing project, but if you don't allocate adequate resources to meet your other project constraints then a project can't succeed in the first place. For example, if you have three developers manning a process that takes seven people, the project is unlikely to finish on time. Adding four more developers a week before the project is supposed to be released will not help (see Brooks' Law), but adding adequate resources at the last responsible moment—allowing time for bringing equipment, processes, and personnel up to speed—may allow a project to meet its time or scope constraints.

It's better if you right-size the budget up front. A larger budget allows you to invest in good people, framework and skills training, efficiency-enhancing tools, higher quality materials and equipment, etc. Under-funding a project creates a constraint, but a budget (by itself) is not usually a sufficient enabler.

Consider the following example:

1. Given that the project has a hard deadline of 6 months from now (fixed schedule),
2. And a feature set that is non-negotiatiable (fixed scope),
3. When the project is planned
4. Then budget (cost) must be adjusted to fit the scope and schedule.

In other words, you have three sliders that impact one another. You can lock no more than two of them, e.g. "Speed, cost, or features; pick any two!" The more constrained your other sliders are, the more flex you require in the unbound dimension.

If you don't adjust the budget vertex to meet the requirements of the fixed vertices, you don't end up with a triangle—you often end up with an unfunded (or underfunded) management target. Once that happens, you should immediately revise your project vision to read: "We create failure through magical thinking."

Answer 3

The iron triangle of cost, scope, time, pick only two, is a model of project constraints. It's a good model, but sometimes confuses people who think they can only work on one dimension, while keeping the other two fixed. If the time and scope of the project are together so constraining that no amount of money can offset them, then your project won't succeed by raising the budget. If I give you a quatrillion of trillion dollars to put another man on the moon by tomorow afternoon, you won't be able to do it. And it's the same with software projects.

If you throw money at problems too late or expect to much from it, you still have the problems. If your project is late, and you bring in money too late, it won't save your project. Todd's answer covers this well so I won't insist on it any further. What I want to point out though is the fact that money is an enabler. Things that were "fixed" might all of a sudden not be fixed anymore.

For example, say your project consists of optimizing an application to run efficiently on small virtual machines, making use of hardware resources efficiently thus keeping cloud costs low and allowing for more efficient horizontal scalling in the future. You identified the work that needs to be done and you have two months to do it (for some reason). After one month the team dicovers that they will most likely miss the deadline. They can't reduce scope because all that's defined in there is needed for everything to work. And they can't move the deadline because that's fixed. So you bring in the money. Lots of it.

You can bring in more people but in doing so, you discover Brooks' law applies, and now the team thinks they will be even later. But time and scope are still fixed. Or are they?

If you take the money and put it into the biggest virtual machies you can find, as many you can find, you no longer care about the scope of the project at all. Your fixed scope all of a sudden disappears entirely. It wasn't so fixed afterall. Your application can now be a resource hog on the cloud, and you don't care because you have money to pay the bills.

So in conclusion:

• it's not three constraints, pick just two. It's actually a balance of all and changes in one affect the others in some other way.
• a budget increase can save your project but only if applied at the right time and on the right things.

Answer 4

Scope, Schedule and Quality define "What" the project should deliver, however they don't define "How" it will deliver. As stated in other answers, more budget can allow the "How" to be flexed. In my mind, I see the "Golden Triangle" as more like a "Golden Pyramid", where the base triangle is formed of the "Cost, Time, Scope" constraints, and the height of the pyramid defines the "Quality". Hence all four are interlinked.

It is true that throwing resources indiscriminately at a project is seldom effective, however if the timing is right, more resources may be able to bring in a project on time and to quality. How? - well, there is no single right answer, but breaking the project into more manageable chunks and allocating the right resources to the right elements of the project will generally be better than just chucking more developers into the mix without restructuring the project to accommodate them.

Alternatively, more funds may also allow a different approach entirely. For example, rather than building a solution in-house to avoid the cost of buying an expensive yet commercially-available solution, the extra money may change that decision. You will still provide the expected outcome - but you will buy the solution rather than building it. But once again, if you wait until too late in the project, you'll fail.

What I am saying, then, is that if you identify issues early enough, you can take steps to spend more money effectively to deliver the project. And that's the key: timing is everything. Crossing your fingers and hoping it will "be alright on the night" until it becomes clear that it won't, is a recipe for disaster. Proper project management, tracking, monitoring, risk analysis, planning, and conversations with your project sponsor will always pay dividends, and allow you to make changes early enough to be effective, by identifying issues at the earliest possible point, then spending the necessary money (or changing other aspects of your approach) to address the emerging issues.

Answer 5

Yeah, would be great to have a universal answer to "how to raise money" :) But if you have to choose I think high quality beats being in-time most of the time.

Sure, we oftentimes behind the schedule and someone from above starts pressuring and we give in and speed up. But if we end up with a bad product we'll be always (!) remembered as bad programmers. I hear people complaining about quality of products that finished years ago - users still hate those developers because they keep using inconvenient tools (in reality developers weren't bad).

At the same time if we don't finish some crucial features - we'll be in the dog house for a bit, but then it's possible that the project is going to be funded further because of business demands.

But if you joined a project that has a lot of problems - it's likely that you can fix some of the issues and speed it up.

Answer 6

I am a believer of Brooks Law but I disagree with the notion that it is 100% true 100% of the time with 100% of projects. Different tasks have different degrees of resource elasticity where adding workers will have varying results in both schedule and quality, depending on the task, depending on the environment, depending on available work materials, depending on a host of known and unknown variables that impact outcomes.

So I think an infinite budget, if such a thing were a reality, could and would favorably impact a trouble project facing schedule or quality issues on some projects, in some environments, for certain types of root cause issues. I believe it to be something a PM and team would have to evaluate on a case by case basis and I suspect that, with other random variables that affect our results, you'd win sometimes, lose other times.

I feel like my answer is vague and ambiguous; however, I also think complex projects dealing with complex humans in complex environments are equally vague and ambiguous. It requires analysis, innovation, experiments, and risk taking.