Developing a project business case

Projects are approved via a business case. A business case provides the information to answer the question why should a project be invested in? It explains what the project is, why it should be done, what it will take to do, the benefits and costs of doing it, and any other information needed to decide whether to do the project or not.

Any significant project, or one that requires the use of shared resources such as IT staff, will need a business case. To develop a business case:

1. Find out if there is a standard business-case format to use. Most businesses have standard business-case templates for different types of investments.
2. Choose the template appropriate for the type and scale of investment your project will require. A minor project should only require a 1–2-page business case. A major programme may require significant effort to create the business case, to be contained in a long document with several chapters.
3. Make sure you understand the objectives of the project. If the objectives are not clear, even the most positive business case should not be pursued.
4. Identify benefits:
   • Financial benefits – revenue, cost reductions, cost avoidance.
     • Use your organisation’s financial approach, e.g. do you calculate NPVs? If so, what discount rate should you apply?
   • Other measurable benefits – customer service, staff satisfaction, fault rates, complaint levels, etc.
     • Try to focus on benefits that are related to the business’s key performance indicators.
   • Intangible benefits – strategic alignment, competency improvement.
     • Not everything is financial, and not everything is measurable – but try to make intangible benefits as realistic and meaningful as possible.
5. Identify costs:
   • The costs to run and deliver the project. Staff costs, consumables, external staff, any facilities you must hire for the project, e.g. office space.
   • Costs for any investment the project has to make (normally capex or capital costs).
   • Operating costs that the organisation will incur once the project is delivered.
6. Write text supporting the project:
   • Why is the project being done, what will it achieve, how will it achieve this?
   • What is the level of risk in the project – delivery, implementation and business risks?
   • What assumptions have been made to create the business case?
     • Check they are reasonable and consistent with others made in the organisation.
   • What sensitivities exist in the business case?
     • Some aspects of benefits and costs may vary with limited impact on the business case, others may only alter by a small percentage to change the business case from positive to negative or vice versa.
7. Think what the key questions will be about this project. Try to answer them in the business case. Who reviews and approves business cases? What will they need to know to make a decision one way or another?
8. Identify who will sponsor the business case. This needs to be a manager of sufficient seniority to be a credible sponsor of a project of this scale. For a small project this may be a junior line manager; for the largest programme it must be an executive, perhaps even the CEO.
9. Ask the sponsor, and anyone else who will read it with an open mind, to review the business case and advise you.
   • Does it make sense?
   • Would he or she approve it?
   • Are there any inconsistencies or ambiguities that need to be sorted out?
   • What questions does he have on reading it?
   • Update and enhance the document accordingly.
10. Check review and business case approval process. Submit the business case.
11. Manage the business approval process:
    • Involve yourself and make sure you understand progress through the process.
    • Keep your sponsor briefed and make sure she knows what meetings to attend.
    • Check that the project is being discussed at the right meetings.
    • Be ready to answer questions and overcome objections. Develop presentations to support business case approval as necessary.

Aligning projects with business needs

If an organisation is going to invest in a project, it must be a relevant project that is truly aligned to the needs of the business. Alignment is a judgement requiring debate with project stakeholders.

To see if the project is aligned, and to determine what must be done to align it if it is not, try to answer the following questions:

1. What will this project deliver that is of value to this organisation?
2. Do you understand the organisation’s strategy?
   • Is this project aligned consistently with it? (See page 237.)
   • Having finished the project, will the organisation be nearer to achieving its strategy?
3. Does this project solve a problem or fulfil some mandatory requirement such as a legal or regulatory ruling?
   • Why is the problem that this project solves important for this organisation now?
4. Is the way the project solves a problem or takes an opportunity really the best way?
5. Is the opportunity cost of this project worth bearing?
   • What alternative uses could the resources this project will require be put to?
   • Is the project a better investment than any alternative?

Gaining buy-in for a project

Projects need the support of managers and staff in the organisation.

1. Be prepared by being able to answer the three questions:
   • Why is it important to achieve the goal this project will achieve?
   • Why is this project the best way to achieve this goal?
   • Why is this project a better use of the resources than alternative investments?
2. Think through challenges this project may face, and work out how you will overcome them. (See page 217.)
   • Will people generally like or dislike the project? How will you use or overcome this?
   • Will people generally understand the project and what it is trying to achieve? How will you use or overcome this?
   • Are there any rules or assumptions (explicit or unspoken) in this organisation that this project will challenge? How will you reassure people?
   • Is the project in competition for resources with other initiatives? How will you show that this project is a better use of the resources?
   • Is the organisation capable of doing this project? Has anything similar been done successfully or unsuccessfully before? How will you build on or learn from that experience?
3. Identify the stakeholders in the project:
   • Who will benefit from the project?
   • Who will suffer through the project?
   • Who else is interested in the project?
   • Think about internal customers, internal suppliers, users, financiers, staff and who benefits or loses from the project. Should you consider anyone external to the firm – such as customers, trade unions, suppliers?
4. Understand power, influence and attitude towards the project of each of the stakeholders:
   • Power and influence: how capable are each of the stakeholders of disrupting or helping this project?
   • Attitude: how likely is each of the stakeholders to help or disrupt the project?
5. Categorise the groups of stakeholders:
   • High power and influence with positive attitude to the project: try to get them to support the project actively and to work to overcome any resistors.
   • High power and influence with negative attitude to the project: try to overcome their objections. If this is not possible, use your supporters to block their influence.
   • Low power and influence with positive attitude to the project: try to choose your project team from this group.
   • Low power and influence with negative attitude to the project: use general communications and presentations to try and convince.
6. Focus on the most important groups or individuals and determine action to utilise the support and overcome any resistance to the project.
7. Engage in dialogue with prioritised stakeholders:
   • Gain commitment for support from important stakeholders.
   • Set expectations to a realistic position. Often simply discussing the project and explaining what it will really do is enough to overcome some objections.
   • Respond – and, if necessary, amend the project.
8. Build ongoing stakeholder and expectations management into your work for the project. Gaining buy-in for a project is essential at the start of the project and throughout the project’s life.

Is this a project or not?

Not all tasks are best delivered as a project. There are no absolute rules on whether something is a project or not, but there are some criteria which can indicate if a project is the best way to complete the task.

There are alternatives to projects. The boundary between a project and the alternatives is not absolute. The following table gives a flavour to the alternatives:

Critical success factors for projects

There are factors that are fundamental to project success, called critical success factors or CSFs. At the start of the project, think about CFSs.

Lists of CSFs can go on and on. There are many context-specific success factors. This checklist is based on factors that are important in most situations. If a project is non-compliant with a particular CSF it may still succeed, but the project manager must focus on that area.

A project is most likely to be successful if it has:

• Clear project objectives and explicit success criteria.
• Sufficient senior management support, including a project sponsor with sufficient time to allocate to the project.
• A valid and robust business case, with well-understood sensitivities and risks.
• Involved stakeholders and customers.
• Supportive stakeholders and customers.
• An able project manager, capable of managing this type of project, of this scale, in this type of environment.
• An appropriate project strategy.
• A project plan of sufficient detail.
• The right type and scale of resources including the project team.
• Well-chosen team members who will work constructively as a team.
• Clear roles and responsibilities for the project team members (including between the project manager and project sponsor).
• Ongoing communication by the project manager that keeps everyone informed.
• Ongoing communication by the project team that informs the project manager of what is going on.
• Good progress monitoring.
• Ongoing interaction and feedback to project team members.
• Appropriate use of the right project management processes, e.g. issue management, risk management, change control.
• A project manager who understands CSFs and creates an environment that is consistent with them.

There are checklists throughout the book that will help with each of these.

Project management processes checklist

This checklist contains questions about your project management capability and the situation of the project you are currently running. If you answer No to a question, the relevant checklists can be referenced to help you with this activity.