Starting a project? Start with WHY!

The primary question to ask when you get assigned to a project or programme should always be “why?”. Simon Sinek gained lots of fame and following with his TED talk and book Start with Why - I will argue the same hold for project management. I do not want to echo Sinek’s point that deals with leadership, inspiration and motivation - although these are tremendously relevant and indispensable elements in managing a project or programme as well. Rather I will argue that the answer to the why-question is crucial if you want to have a successful project.

The answer to the why-question - rarely an easy answer - is typically referred to as the project justification or project rationale. If you write this justification down, the document is usually called a Business Case. Given the importance of the project justification, it is good practice to write it down. That does not mean I want you to create a 20-page document - it might be even more, but it could be far less as well. It all depends on your specific project.

Too often creating a business case means filling in pages and pages of a template, in order to get the budget approved. As soon as the project is funded, nobody will look at the business case anymore. It is one of the many bureaucratic hurdles organizations create, often originally aimed at improving a flaw but over time grown into an administrative feat. Let me clear at the outset: this is not what I am advocating for. Despite the negative connotation it might have, I will continue to use “business case” as the answer to the why-question.

As a minimum, you should from time to time look back at the business case to check that the reason you started the project is still relevant. We live in an ever-changing world, so the solution your project is developing might become obsolete.

Creating the business case for a project forces you to think about the situation the project should address and how the project answers to that situation. The situation the project addresses concerns typically one or more business needs and/or opportunities. A business need could be something that helps bridging the gap towards executing the business strategy, it could be a response to a legal requirement, it could be a replacement or repair to continue the operations… An opportunity could be driven by the market, like a consumer problem to solve or a customer request, or it could be an efficiency or effectiveness improvement...

The business case links a project therefore to the organisation’s strategy. That is already an important reason to create one: it links the project into the wider business context, which could motivate the team by making their work meaningful. At an organisational level, the business cases of all the projects should be synthesised to avoid duplication of effort or initiatives with mutually inconsistent objectives. In what follows I will focus on the advantages of a business case for managing the project - the organisational benefits at portfolio level will be addressed in another piece.

Why? The business case

Again, I am not suggesting that you write a long academic discourse. There are, however, a few elements that you should clarify. You can go through the list below a few times when starting a new project: first answer the questions on a high level, typically to compare different solutions to the problem; when detailing the project further, the answers to these questions should become more detailed as well.

• First, what is the situation that triggers your project? This is often the problem you want to solve, like your organisation is losing market share to competitors or needs to comply with new legislation.

• Next, how is your project addressing the situation? Here you conceive your solution, your final deliverable. To continue on the examples above, this could be a loyalty card to regain market share, or a new process to gather compliance data.

• Then, what positive effects do you expect to result from the project? These effects should be thought of as something measurable, so you can objectively verify that you have achieved them at some point. Often the acronym SMART is used: make it Specific, Measurable, Achievable, Realistic and Time-bound. This is the point you start to look at the future, and predicting the future is very difficult. (Read my piece about planning to find out why this is anyway important.) These positive effects are called “benefits”. The benefits of the loyalty card could be a 10% market share 2 years after the project is closed.

• Usually, a project will not only have positive effects, but also negative consequences. It is important to consider those as well. So, what are the negative effects - or “dis-benefits” - you expect from the project? For example, when you introduce a new product on the market, this product might cannibalise the revenue from another product your organisation sells. Or the compliance process might introduce extra workload.

• So far, in the previous points, you will have had to make quite a few assumptions: how sure are you about the solution to the situation, how likely will the benefits and dis-benefits be realised? On top of these assumptions, there are other uncertainties that might impact your business case: event that, if they occur, increase costs and/or decrease benefits. It is therefore important to consider the risks to your business case.

• By now you have an idea about the value the project will bring. It is key to balance that value with the cost of the project. How much do you expect it will cost to build the solution you envisioned? And how much will you need to pay to keep operating the solution after the project, e.g. recurring license costs, extra people that will be hired in your marketing department to run the loyalty scheme attached to the loyalty card, etc.

You probably see how answering the questions above is an iterative process: when you become aware of a need or opportunity, there might be several solutions with different benefits and dis-benefits, with different risks and different cost projections. At this early stage you use the business case at a very high level to compare different ideas. Once an idea is chosen for further exploration, you have already identified the aspects that require further investigation and your answers will become more detailed. As an organisation you could link release of funding to activities to clarify the business case, even through delivery. As mentioned above, the world will change, and you will gain new knowledge and insights when you are delivering the project, so regularly reviewing - and updating - your business case is recommended.

Start with WHY, but it is not the end

You have built a justification for your project, that is great! But that is not the only reason to start with the why-question. There are many more questions a project manager should answer. The why-question will provide important input to those answers.

Who?

In answering the different questions in the business case, you have identified benefits and dis-benefits. These (dis-)benefits are always positive or negative for someone. So starting from your (dis-)benefits you can identify your stakeholders.

Benefits can only be realised if the solution your project developed is being used. The people that will use the solution are therefore key stakeholders to engage in your project. You can deliver your project on time and on budget (the traditional success measures), but without proper use, you will not be able to call your project a success.

Knowing how different people are impacted by your project helps in engaging them. So start from the benefits and dis-benefits and map the effect of these on your different stakeholders. The result is called a benefits distribution matrix. Remember that what one stakeholder considers a benefit can be a dis-benefit for another stakeholder. As a very obvious example, your CFO might consider a headcount reduction a benefit, but the people being laid off will very likely think of it as a dis-benefit.

The (dis-)benefits are not the only source of stakeholder identification. (Read my piece on an anthropologist’s approach to stakeholder engagement.) But the users on whom benefit realisation crucially depends should be viewed as primary stakeholders. They should for sure be represented in the decision-making body of the project (often referred to as the Steering Committee).

A final stakeholder element for which the business case can provide input is communication. The justification for the project can be used to underpin stakeholder communication, as it contains both the situation the organisation is in and how the project solution will help out in addressing it. Certainly in bigger projects or transformation programmes, where a serious change is required from the people, this part of the business case should be crafted carefully, typically in the form of a vision of a better future. It helps that people can picture the metaphorical burning bridge to bring them on board.

What?

The next question to answer in a project is what the project will deliver: the scope. Again, you start from the why. In the business case you have sketched out the context for the scope description: the solution to the situation.

The what question comes after the who. Your stakeholders, certainly those that will have to use the solution in order to realise benefits, will have requirements. These have to be captured and translated into a specification of the project’s deliverables.

You will use the business case to evaluate the requirements of your stakeholders. They will want more than you can afford, so you need to prioritise. The must-have scope includes those deliverables that are indispensable to realising the benefits. Should-have scope comprises deliverables you could do without for a while, but which you cannot work around sustainably, e.g. because your costs will explode - think about a manual workaround for an automated process. Finally, some scope will be nice-to-have. These are the delighters for your stakeholders.

Note that it does not matter whether you define your scope upfront (in a waterfall method) or progressively elaborate and iterate (in an agile method). In both cases, something should only be considered part of the scope if it helps to deliver the solution that addresses the situation in the business case. In a waterfall project, change requests will be raised when more or new information becomes available (in an agile environment as well, but then they are part of iterative specification) and these should also be evaluated against the business case: does this new scope help realise benefits (or prevent dis-benefits)? As always, the world is not black or white. You should not be too restrictive, other objectives might be addressed with a change request and more efficiently delivered by your project. It is, however, important to be clear about this. In the end, this will mainly pertain to budget allocation.

When?

With the what-question answered (possibly only on a high level) you can (start to) think about when the deliverables will be ready. Of course, you will create a bottom-up schedule, starting from estimates about how long the work needed will take, taking dependencies and people availability into account. But your business case should be consulted as well.

Your benefits could very well be time dependant. For example, if your project is not ready before a major business event, say the Christmas sale period, it could take delay benefit realisation too far to still be viable. Or if you work towards legal compliance, the date the law comes into effect imposes a deadline.

So, to answer the when-question, you take the answer to the why-question into account as well.

What if?

A project will never go completely as planned. I mentioned the uncertainties already in thinking through your business case, but you will identify other risks - which do not directly impact the business case - that will need to be managed. And there will be events which you did not expect but still happened and you have to deal with.

An important rule when dealing with issues and risks is to not jump to conclusions. You need to understand what the problem (really) is. And here comes your why in the picture again: understanding the problem means, at least partially, understanding the impact on your business case.

After you understand the problem, you still do not jump to a conclusion. Every problem has several solutions - I typically say “if you found only one solution to your problem, you don’t understand the problem well enough”. (Let me know if this quote can be attributed to someone!) Which of those possible solutions is the best one? Your business case is again the signpost. The impact of each solution on the business case will determine which is the best solution.

In conclusion

The why-question is extremely important to answer to get your project going. The answer (continuously) justifies the existence of your project, but it provides also the basis for identifying stakeholders, for defining scope and milestones, and for choosing solutions to risk and issues.