Author Archive

How to Write a Business Case in a ‘Post-Truth’ World – 5 Rules for the Project Manager

Author:  Richard Peel, theprojectmanagerscoach.com

This article was previously published in a slightly different form by PM Today Magazine, April 2018  

Now that we are surrounded by cries of “fake-news”, and the information provided by ‘experts’ has become distrusted by many, what is to become of that bastion of indisputable fact, the Business Case?

Many of us were under the impression that the ‘truth’ was the truth and all we had to do was find it and present it.  However, as the bubbles we live in burst we now realise (well, hopefully we realise) that our truth may not be the same as another person’s truth.

At a trivial level, the ‘black’ shirt I wore last night was, my wife tells me, a ‘navy blue’ shirt; we have different perceptions of colour. I saved £10- on a fancy cork-screw in the sales, or I wasted £15- on something we don’t need and clutters-up the cupboards; sometimes we emphasise different facts to build our differing ‘truths’.

Now; if there are actually different truths on the same topic, they start to sound like opinions.  So that suggests that the business case is presenting an opinion, rather than fact. And if we are dealing with opinion it then becomes more important than ever to understand whose opinion, whose ‘truth’, is being presented.  Who is ‘owning’ this business case?  Is it the Project Manager?

More often than not The Project Manager has written or prepared the business case.  The project manager may be more familiar with the detail behind some of the figures that are presented.  The Project Manager is usually keen that the business case is approved, because of the time and energy they have invested and the enthusiasm they may well have built for seeing an idea brought to fruition.

However, as we all know; the owner of the Business Case is definitively the Sponsor. (This is the ‘truth’ stated by our project management profession’s various institutes, associations and methods.)

The Business Case is a simple contract between the Sponsor and corporate governance where the Sponsor says: “If you give me this funding, I will give you these benefits”. There is also some contextualisation within the business case; in terms of timeframe (which is really a dimension of benefit as the benefits increase the earlier they are delivered), how great/slight are the risks are that this business case will not be realised, and how robust are the commercial and management arrangements; but essentially the business case is a simple ‘quid pro quo’ – cash now for benefits later.

Clearly this contract can only be entered into by the person who can ‘stump-up’ the benefits; and that person is not the jobbing project manager.  It is the Sponsor in the area of the business benefitting who can demonstrate a reduction in their budget, higher operational productivity or some other form of benefit.

So; we have a business case which is the Sponsor’s ‘truth’.  What does this mean for the Project Manager?

Here are 5 rules for the project manager who is asked to write a Business Case (and you will be):

  1. The Sponsor’s name must appear as the ‘author’ / ‘presented by…’  on the paper that is submitted.   You may win a mention for all the work you have done with the entry ‘Prepared By…’
  2. The Sponsor must present the Business Case paper to the approvals body.  It is their bargain (‘quid pro quo’) and they have to be visible as striking it.  As Project Manager, you may be called-upon to provide detail to the context of project delivery, project planning or the breakdown of the project costs; as you will probably have a better understanding of those.  Do not allow yourself to state the benefits; or if you must, then couch them in terms of  ‘[The business area] has stated that they will be able to realise [whatever the benefits are] by [whatever the date is] based on the scope of the project as presented here.’
  3. Present only information which you can stand behind, e.g. your cost estimates; your time schedule.   If the Sponsor has insisted on costs or timescales being presented that you do not agree with, do not allow yourself to be the person presenting them.   If you have to; then do so in the context of the realistic risks associated with achieving them.  Unless we like changing jobs frequently, we will not allow our credibility to be spent too quickly.  PMs may be seen as expendable.
  4. Canvas views before you write the business case; in particular those of the members of the approvals body, and address their truths / concerns in the document.
  5. Include other people’s ‘truths’ as alternative options.   Recognise the other people’s ‘truths’; stand in their shoes and present why they are right as well as why (in your truth) they are wrong (or less right).

Some may say that you just need to build the case you need to get it ‘over the line’ and approved.  However, I would counsel against being perceived as a purveyor of ‘fake news’.

(c) Copyright Richard Peel; all rights reserved


Decision-based Stakeholder Engagement

This article has previously been published in Project magazine.  It is copyright (C) Richard Peel

The Problem

So often we start stakeholder engagement from the ‘wrong end’:

 “Identify anyone who is affected by or interested in the project.”

 We’ve heard that a thousand times.  But what generally happens is that we end up with long lists of ‘everyone and their dog’ and even after the usual ‘analysis’ we realise that we can’t possibly engage with so many different groups of people.

Too much data swamps our good intentions and stakeholder maps are drawn and consigned to the bottom of a drawer; whilst people just get on and do their best.

The Solution

So, what should we do?  Try asking this instead:

“What decisions do I need from stakeholders, for my project to succeed?”

 Tip:  Start with the end in mind – what specifically do we want our stakeholders to do?

 Typical decisions that are critical to the success of our project include:

Resource allocation Usually funding and people; and depending on the type of project, perhaps accommodation; cranes; power generators; etc. – Will we be given them? When?
Regulatory / statutory body approval e.g. Planning permission; access to infrastructure networks – Will they be timely?
Suppliers’ decisions to bid for work Will we attract the right companies?

 

Here, in navigating these decisions, is the end-purpose for our engagement with stakeholders.  This gives us a sharp, clear focus for what we do next.

 

Key Steps to Decision-Based Stakeholder Engagement

The 6 steps to decision-based stakeholder engagement are to:

  1. Identify the key decisions that are required to secure the success of our project
  2. Identify the people that will take those decisions
  3. Identify their key advisors
  4. Understand the concerns of the decision-takers and their advisors relating to the specific project decision
  5. Address the concerns
  6. Check engagement.

 

Step 1: Identify the Key Decisions

We know that these key decisions are the things that really matter to us because we’ve already documented them.  They are represented as:

  • Milestones in our plan – ‘design approval’; ‘receive supplier bids’
  • Causes in our risk log – ‘specialist engineering resource not made available’; ‘regulatory approval delayed’
  • Decisions in project calendars – ‘Go/No Go Gate for contract let’
  • Assumptions – ‘project accommodation and computing is available’.

 Tip:  The timing of the decision is often as important as the outcome; delay is typically what kills a project

 

Step 2:  Identify the People Who Will Take the Decisions

Here we need to avoid the trap of just identifying the organisations or even the roles.

Tip:  It’s people that take decisions; with their own unique personal history, view of the world and ways of operating. So, engage with the person; not the role or the organisation

 We might think that we know what concerns a Finance Director and what questions they will ask.  But what if that person was previously a Plant Manager?  What if that person has had their ‘fingers burnt’ by a project like this one before?  We need to work with the individual.

 

Step 3: Identify Key Advisors

Decision-makers are usually senior people.  Some of these people will give our decision personal attention and some will be up-to-speed on all the detail required.  Others will rely on trusted advisors to make evaluations which they will then act upon.

We need to understand who has influence and engage with them also.

 Tip:  When decisions are being taken remember the power outside the room too

 

Step 4:  Understand Stakeholder Concerns

As a project manager, we have worked long and hard with our team to come up with a solution and an approach. We simply don’t have the time to go back over things if we are going to hit the deadlines and stay within budget.  Consequently, we sometimes see the people raising concerns as ‘blockers’.

But wait a minute.  What if they do have an insight that we missed?  What if we don’t have all the answers?  Early engagement gives us the opportunity to gain their insights without delaying the project.

 Tip:  There are no “blockers”; just people providing advice for free.  They just might be saving us a whole lot of work further down the line

 This is why the often-used approach of categorising people as ‘supporters’ and ‘blockers’ really does not help.  All too easily we can fall into the trap of engaging with those that agree with us and neglecting the very people who could help us by bringing an alternative view.  Hands-up those who can honestly say they don’t avoid the ‘blockers’.  Better to view them as ‘critical friends’.

The problem with not talking to people is that you end up making assumptions about what they think.  The only way you really know what people think is by asking them directly and actively listening.  So, try the following approach:

  • Meet your ‘critical friend’ where they can give you their honest view (so possibly not in a group; a one : one generally works best)
  • Ask them what their concerns are around the specific decision
  • Play back the concerns to them in the meeting; so that they can correct your understanding if you haven’t got it right
  • Capture their solutions to the concerns as well (even though you may propose an alternative solution later on)
  • Follow-up with an informal note after the meeting to restate what you understood as their concerns and proposed solutions
  • Log the stakeholder concerns in a project log

It sounds very formal and structured, doesn’t it?  Well we manage risks like this, and change, and issues; so, it does make sense to manage our stakeholder engagement equally well.

 

Step 5:  Address the Concerns

Now we have a log of concerns we can start putting in place actions and action owners to address them.  It is sensible to go back to the stakeholder and agree with them that the actions will indeed address their concerns.  We can’t make assumptions.

Examples of types of action we might take are:

  • provide requested information
  • brief a trusted advisor
  • make a change to our plans.

Step 6:  Check Engagement

Finally, we need to know whether we are on track with our stakeholder engagement.  Will we get the decision we need when we need it?  We measure delivery progress, we measure risks, we measure benefit realisation, and we measure costs; so why aren’t we measuring stakeholder engagement?

Tip:  If what gets measured gets done; why aren’t we measuring stakeholder engagement?

 A good approach is to ask the stakeholder:

 “If you were taking the decision today, how likely would you be to say ‘yes’; on a scale of 1 to 5?”

 You are making the question very specifically about the decision in-hand.

Ask this question as a prompt to understand their concerns in Step 4.  If they score less than ‘5’ ask them what it would take to move them up to a ‘5’.  Again, this forces a discussion about specifics.

After taking action to address the concerns, ask the question again.  If the stakeholder scores less than ‘5’ we are back into Step 4 and understanding their concerns again.

 

In conclusion, we start our stakeholder engagement at the ‘right end’ by understanding what we need our stakeholders to do.  We then work with them to get them to the place where they can do it.

 


Does your project feel like Salmon fishing in the Yemen?

Salmon Fishing in the Yemen’ has been a book and now it’s a film with the wonderful Ewan McGregor and Emily Blunt. I went to see it last night, with my bucket of popcorn and my mobile responsibly switched to silent; and sitting there I thought, does this remind you of anything?

Of course it does. It’s a vanity project with a strong sponsor but no business case; a project manager who has been cajoled into taking it on but who doesn’t believe in it at all (‘totally unrealistic’); a big-bang approach with major risks that no one has made any effort to manage (do farmed salmon have a homing instinct?- can we find that out without flying salmon-filled Chinooks out to Yemen? – yes we can!); appalling stakeholder management – bullying a senior stakeholder who takes revenge by creating damaging media exposure, and seemingly no attempt to work with local people’s concerns.

Read More…


feature

feature