You want to get something out of your boss, but you don’t know how to get him to say “yes”. The trick is to provide a Business Case – something he can use to justify his decision to buy that software, send you on that course, upgrade that server.
I’ve had to write a few of these over the years, and I’ve found that the best things are to keep them short (ideally a single page for a simple purchase / upgrade etc), and keep them punchy – no excess verbiage, no waffling. And to make sure you really get their attention, you need to show a payback – how soon can the boss expect to see a return on the investment (if appropriate), or how much of a threat is being mitigated by this work.
The basic outline I use is as follows:
Business Case for X
Here you provide the background to the request – the current situation, or identified opportunity
Give whichever of the following sections are appropriate:
- Overview – what you propose to do
- Outline costs
- Outline Schedule – when the work would be done, by whom, how long it would take
- Risks of doing the work
- Risks of not doing the work
Benefits from the work
Don’t forget to include payback period!
A more complex version of this document is also used extensively within the PRINCE2 methodology, particularly during the start-up phase, and during end stage assessments to ensure that there’s still a valid business case for the project. After all, if there is no longer a valid business case for this project, then why continue?
There’s no guarantee that a good business case will get the project / work / purchase authorised. In part these things always depend upon the attitude with which it is presented, the attitude of the one authorising the cost, their level of risk aversion, or, and let’s be honest here, the plain bone-headedness of those signing off expenditure. Not thinking of anyone in particular, goodness me, no.