August 12, 2010

Writing a ‘Business Case’?

Posted in Deliverable Artefacts, Project Management tagged at 12:34 pm by Molly

A BC documents the justification for your project.  It is based on:

  • financials > estimated costs (development costs, resource costs, etc.)
  • risks (and I would say issues too since you are highlighting risks, I feel they go hand in hand, and issues may have already occurred so its worth noting them)
  • benefits (cost savings, quality, ROI, other business benefits etc.)

The ‘Project Board’, ‘Steering Committee’, ‘Project Sponsor Board’, whatever it’s called in your organisation will monitor the viability of your project against your BC – so keep it up to date!

Business Case Contents

  • Reasons for the commencement of your project:
    The reasons for the project should be stated, clearly and concisely to your readership.  Ask yourself “why this project being performed?”.  If you are getting stuck at this stage then it indicates that further thinking and questioning is required (to your project sponsor, your project board and maybe directly with your customers) before going to the next steps.
  • Costs (all associated costs):
    Derived from your existing project plan – based on the resources needed (developers, vendors, suppliers, hardware, additional software to purchase, licences, programmers, administrators etc) and timescales. It should be possible to come up with a quantifiable estimate from discussions with the suppliers and developers.  It’s not a figure that you pluck out of the sky, its a justifiable ‘budget’ based on tangible costs and time. Ongoing operational costs, over a given time after project closure, might also be included to give your project sponsor additional cost implications, especially relevant if a third party is going to support the new system (I am mainly talking about IT at this stage).   It maybe helpful to breakdown the costs further depending on the project (e.g. design costs, additional building/premises costs,  training etc.)
  • Benefits – Tangible & Intangible
    This could add huge muscle behind your project if you can express the benefits of the BC to your audience, and remember your audience is not just the IT section/department!  Sometimes the softer potential benefits are skimmed over in this subject, so let’s take a more meaningful approach.  Express the benefits that will be reached against what is the current situation now – easy?  Some of your benefits may be measurable or ‘tangible’ in monetary terms (cost savings here and there, reducing hardware spend or costs, increased revenues, more money in the organisations accounts, following regulations or legislation (and not being penalised) etc.). Others will be ‘intangible’.

    Let me deviate for a short time and let’s take a closer look at the intangibles because they can sometimes be more important to the business than an IT director cares to think about at this stage, but equally needs to be documented so that your project can be JUSTIFIED – that is the bottom line after all.  Intangible benefits certainly deserve more respect than they are given as they form part of the business’s worth, and include such items as ‘brand image’ or  ‘reputation’, ‘market share’ etc. yet decision makers have not accepted this financial reality in its entirety.  Why?  Not quite sure, but I will hazard a guess at the lack of hard numbers for the ROI and frankly how do you quantify ‘brand image’?  If organisations put as much effort into identifying the ‘intangible’ benefits, do you think their strategic goals would improve, or their market share would increase or their competitive streak would show an increased advantage?  Maybe its time to sharpen the ideology and refocus project strategies and maybe its time project managers start asking these questions from the business owners – it would be a good starting point for a transparent round table information gathering, not hiding it under the table out of sight.  So should project managers be describing intangibles as tangibles?  A core skill of senior managers is the ability to make the right decisions in the face of less than factual (intangible) information.  Yes there is an element of risk involved, but given some hard facts, doesn’t that risk reduce, and doesn’t this transparency we are talking about increase the stakeholder confidence in management.

An example: a newly bought or developed ITSM (Service Management) system/tool will benefit the IT Service Desk by reducing resource times on each incident, improving customer service & its perception, problem resolution is forwarded to specialist groups rather than clogging up resources on 1st line support, improvement in process management is achieved, service desk managers can evaluate where further staff resources are required or can be drawn back to reduce costs etc.

  • Risks (keep a Risk Log or Register)
    (ID, raised by, date, description, probability, impact, score, actions, owner, escalation, risk reference, open/closed)
  • Timescales (summarised from your Project Plan > Gantt chart > MS Project)
  • Investment Appraisal
  • Assumptions & Evaluations

The BC is derived from the Project Brief (or Mandate), the Project Plan and most importantly the customer, the end user who benefits from the project within your organisation (project sponsor).

Let’s take a look at what information is required in a Project Manager’s ‘Business Case’.

Advertisements