The Secret to Project Approval: It’s What They Get that Matters, Not What it Costs
Ever hear this one? “Every time I propose a major IT project, the senior management takes it apart. And even when they do greenlight the project, inevitably I am told to make it cheaper.”
Well, you know what happens next. The well-meaning IT leader cuts a few corners and reduces certain elements of functionality to hit the price management demands. The IT leader implements the semi-gutted project. Then, when the users and management experience the new system, the complaining begins. “What happened to function X? Why aren’t there more custom reports? Why is everything so slow?”
While it may be factually correct to say that the situation is management’s fault for slashing the project’s budget, as far as management is concerned, it’s the well-meaning IT leader that is to blame.
And guess what, they are right.
I know, I should take the side of the poor IT leader who found himself tossed around like a rag-doll during budget negotiations. I should chastise the C-suite for failing to understand the simple fact that when you cut the budget of a project there will inevitably be a price to pay. But it’s not management’s job to worry about this. It’s the IT leader’s job to establish and maintain a clear link between project cost and project outcomes in the most unmistakable terms.
Unfortunately, most IT leaders forget this is what management needs. They assume senior managers are thoughtful and rational about IT budgets and their related scope, and therefore understand the obvious connection between budgets and functionality. Well … in a way they do … but only when they are reminded of it.
Elicit a Different Response from Management
In most cases senior managers react reflexively to any IT budget request with the rather stale line: “Can’t you do it for less?” As if us IT guys had forgotten the 27,000 floggings we received in the past for proposing expensive projects. They simply can’t help themselves. It’s a developed senior management response.
Given that this is the core of the problem, what’s an IT leader to do?
Unfortunately, many IT leaders hear management’s cries of “Make it cheaper!” and they assume management only cares about the project’s cost. So they respond by trying to shave cost in any way they can in order to “save” the project. Inevitably, this results in some form of performance, quality or feature reduction. And voilah … we have the classic IT/business disconnect.
Stopping the Cycle
You’re going to stop that cycle today by making one mental shift. You see, senior management care much more less about the absolute cost of a project than what you might think. Sure, they’d always rather spend less on a project than more. And yes, sometimes they really can’t afford the ambitious projects you propose. But when it comes down to it management cares more about what they get from the projects than how much it costs. (It’s that ROI thing we always talk about.) And it’s your job, when you’re proposing a project, to sell what a project will deliver well before you present how much the project will cost. Essentially, it’s about fixating on what the project will deliver. The business outcomes. The impact arising from the project.
When you lead with this information, and engage the senior management on the target outcomes and impact, the budget discussion that follows becomes very different.
Seek Leverage, not a “Sure Thing”
Clearly no pitch is a sure thing. You may successfully guide management through the project’s benefits and still they might not like it. Fair enough. But when they do, you will have already established such a firm link between project cost and project outcome that you will have the leverage you need to fight back. Instead of agreeing to a lowered budget and then scrambling to try to do the same project for half the cost, you will be able to tell management “Sure we can reduce the project’s cost, but if we do, we will have to vary the outcomes in these concrete ways.”
At that point you will produce an analysis providing the itemized cost of your project. On each line you will have one of the lovely features you just sold management on linked clearly with how much that feature will cost the business. You will then tell management you are happy to discuss which of the features they are interested in cutting to reach the project cost they desire.
One of two things will happen here. Either management will see this list and find it impossible to cut any of the features (in which case you will be able to implement your full project at the budget it demands). Or, management will go through the list and select the features they can live without to reduce the project’s cost. Either way, it’s a win for the business and IT.
If the second scenario occurs, consider getting an actual signature on the spot, just for effect and for the record. Trust me on this one. It can be very powerful to produce a signed scope reduction memo at just the right point in the future. Like when you have implement the reduced scope of the project and management asks “Where did X feature go?”
Not only have you broken the capricious cost-reduction cycle, you have set up a new type of relationship with senior management regarding budget approvals.
Best of luck. And as always, let me know how it works out for you.
