Iced budgets are better than ice cream
Walking on water and working by specification are possible if both are frozen.
Edward V. Berard
True but add frozen budgeting to the mix.
In spending money, like in all the other areas of a project, you will find unexpected situations, situations that don’t conform to the original plan. When you find that in your path i have one truism for you: don’t run out of money.
The goal of a frozen budget is to always have enough money for what is left to do on the project. Don’t step aside, don’t upgrade expectations in the middle of the gantt’s critical path. If you find that some acquisition is really, really required then buy the cheapest you can get that does the job. Remember: that does the job.
“Made in China/India” is always an option to keep your budget frozen.
Frozen budgets are very important in case the project fails. It will indeed feel like a lottery ticket — you risked, you lost. But if you alter your initial budget and spend even more and then the project fails, it will be like a bad casino experience — you will constantly wonder what the hell got into you that made you go on and spend all that money on nothing.
Project wise, i’d rather have a working bicycle with Chinese wheels than a non working one with original german wheels. The initial point of even starting a project is to, well, wrap it up. You will always be able to iterate and make it better later.
As you manage the budget of a project i learned that when you need to purchase cheap its all about spending on functioning, not on reliable. The only thing you have to worry about is for the cheap product to work. It most likely wont last, but if it works enough time its actually buying yourself the opportunity to iterate on the project later. Cheap doesn’t mean not working. It means less reliable, less supported, less sophisticated but it does the job, even if sometimes with less performance.
But don’t fear cheap ONLY as long as its in the middle of the action. Have the guts to assume responsibility and go for that indian team ☺ However, if cheap arrises as an option at the planning stage don’t choose it. At the planning stage you should choose optimal. And then, later on, at the iterative stage you should choose best in class.
Keep in mind that frozen budgets are not about self esteem or efficiency but about not running out of money. If the money finishes before the critical path you are doomed. It will turn the project into ongoing operations in a snap without you even noticing because usually the missing part of the budget will eventually be put in place by crumbs and leftovers from other projects, other departments, other managers and so on.
Don’t drop features, make them less.
Less features is really a motto for agile projects in the planning stage. But what if the risk of underestimated effort for features happens? Lessen it. If its critical don’t drop non critical ones but reduce the underestimated one in size and quality. If its not critical drop it all the way. Non critical tasks/features that spawn as underestimates are the most dangerous events in a project, since usually these cannibalize half of the project. Drop them like they’re hot, as soon as you notice the baseline to be lagging behind.
These dropped non critical, underestimated tasks will get a chance to be revised later on in the planning of the iterative stage so don’t feel sorry ☺ not you, nor your fellow dev team. Have patience and stay focused.