|
Corporate Hoore offers a complete business case developement service.
The following extract from our intellectual capital database shows the level of skill
we can bring to bear on your business case.
Summary
- Project name
- Focus most of your readers' attention on the name of the project. If possible make this the only decision-point of the entire business case.
- Objectives
- Use outcome-oriented objectives where possible, for example "To reduce $2m cost by closing down our only factory."
- Case for action
- If any.
- Costs
- Ensure that the budget is large enough to carry your termination payout should the project go awry.
- Benefits
- If any.
- Risks
- Concentrate on risks which are unlikely to happen, and focus all discussion on the magnitude of their impact.
- Recommendation
- If any.
Objectives
- Try to keep your objectives as subjective as possible.
Scope
- In scope
- Put as little as possible in this section. Use boundaries of product and market wherever possible. Use time and space as necessary.
- Out of scope
- Include everything you can think of here. We usually include the Encyclopaedia Britannica in this section.
- Neither in nor out
- This section should be completed in pencil, ready for rapid amendment as required.
Assumptions
- These are your get out of gaol cards. Seasoned practitioners put their entire business cases in this section, thus rendering it impervious to all attacks. For added security, define all your assumptions as "out of scope."
Financials
- Investment (capital, expense, funding source)
- Always suggest a funding source outside the scope of the steering committee.
- Return (revenue, cost, likelihood)
- Ensure likelihood of cost is higher than that of revenue.
- Key metrics (payback period, NPV)
- All NPV debate should centre around the inappropriateness of the discount rate. If that is impossible, calculate your NPV over at least 100 years.
- Sensitivity analysis
- Find out what your boss is most sensitive about (eg the effect of this business case on his or her option package) and model that.
Governance, Resourcing and Stakeholder Management
- Steering committee
- Name your boss plus his or her two worst enemies.
- Project owner
- Your manager's manager's name here. NEVER appoint your manager as project owner: there is a chance that they may turn up to project review meetings.
- Project manager
- Your name here. Check spelling. If there are more than one project manager, put your name last.
- Project team
- You and your friends' names here. Check that they are on the payroll. Check that they like the same kinds of restaurants as you.
- Staff buy-in
- Nothing is acheived in organisations today without a complete poll of the staff, from CEO to the cleaner. Therefore most of your project time should be spent on becoming popular with staff. Giveaways and general pork-barrelling are encouraged.
Deliverables
- Definitions
- Generally speaking, reference to deliverables should be avoided at all costs. If they cannot be avoided, they should be listed in the assumptions section. If that doesn't work, define the deliverables in this section, but use language that conveys the infinite subtlety, usually Lithuanian.
- Audiences
- Always put "As specified." Do not include any method for specification.
- Timetable
- Use a day/month format to ensure you do not commit to a particular year.
Strategy (Borderline projects only)
- Values and mission
- Recite the values and mission of the organisation if they exist. If the organisation has no values or mission, make them up and put them in the assumptions section above.
- Strategic drivers
- As above
- Environmental SWOT
- Create an alternate universe where your project is integral to the fabric of space and time. Calculate the strengths, weaknesses, opportunities and threats to your project in that universe.
- Exit strategy
- If you have ever managed a project or indeed been in an organisation where someone mentioned the word, you'll know that 99.99% of all projects fail. Given this, it is highly advisable to have an exit strategy which you can claim success for in all but 0.01% of cases.
- Proof of concept
- Proofs of concept are for wimps.
Monitoring, Reporting and Evaluation
- Leave this section out if possible. If not, refer to Appendix A.
Risks
- Create a 2-axis matrix and populate it with a series of bombs, stars and arrows.
Turn the matrix on its side. Put it at the back of the business case. (Preferably behind Appendix A.)
Appendix A
- Always include "Appendix A" in your table of contents but do not create it.
If someone asks a question, refer them to Appendix A.
When they discover that they did not receive it, insist that you sent it in a separate email.
If you are finally pressured into delivering something,
contact us for a range of pre-packaged appendicies at affordable prices.
|
|
