Change, communications and sponsorship

Since the Project Workout was first published, I have advocated projects as the vehicles for achieving strategic objectives or as I often say, projects are the vehicles of change. When I first wrote this in the late 90s, most people were still focused on deliverables and outputs, but, I am pleased to say the drive to towards benefits driven project management as standard is gaining momentum. This blog picks up on Steve Delgrosso’s views.
PMI’s Pulse of the Profession reviews are really starting to focus on the outcomes from projects being the most critical thing from senior management a senior management viewpoint (hurray!). Steve DelGrosso, from PMI, gives his views on what the priorities need to be, if organisations are to keep pace with the escalating rate of change. In his view, these are:

  • Priority One – communications
  • Priority Two – sponsor engagement

This mirrors McKinsey’s Colin Price’s findings about the essential role of the project sponsor in his book, Beyond Performance Management. It also mirrors the view that to be effective, senior management must not only have a vision, but also be able to communicate it.
A look at PMI’s research shows that organizations report that only 52 percent of their strategic initiatives are successful. The failure of strategic initiatives has a significantly greater financial impact than just project failure: they say that nearly 15 percent of every dollar spent on strategic initiatives is wasted–US$149 million for every US$1 billion spent. By comparison, PMI’s 2014 Pulse of the Profession® study finds that US$109 million is wasted for every US$1 billion invested in projects.

So, not much seems to have changed since David Munt, founder of GenSight, did a similar study in 2002. His research suggested between 35 and 50 per cent of all investment is directed to unsuccessful projects and that about 30 per cent of project investment by FTSE 100 organisations in 2000 actually destroyed shareholder value!
Strategic initiatives are the programmes and projects though which an organization’s strategy is implemented. By their nature, strategic initiatives drive change to transform an organization from current state to future state.
Failed projects can result in huge financial losses for an organization, but a failed strategic initiative has an impact far beyond just the costs of the initiative. When an organization embarks on change, it’s likely that systems, processes, vendors and perhaps even the overall organizational mindset (or mission) will be impacted. Failure to successfully enable sustainable change can lead to an organization losing its competitive advantage.

Select the right projects to support your strategy Selecting the right projects will help you achieve your objectives by realising benefits which support your strategy.

Select the right projects to support your strategy

I have a feeling there will be a lot more blogs on this topic as it challenges the prevalent “iron triangle” or “triple constraint” view of project management, and builds on it. Developers of standard and proprietary methods take note! In the meantime, have a look at The Project Workout, Chapter 3, page 50 and Chapter 15, page 198, in particular.

Project management excellence is not enough

Beware of doing too many projects, even if they do fit your strategy and have a good business case.

Beware of doing too many projects, even if they do fit your strategy and have a good business case.

The opening plenary sessions of the 2013 Gartner PPM and IT Summit in London, set the tone for a mind-set shift in how Gartner looks at “IT management”.  To date they have focussed in on “IT” and the “CIO”, and, in my view, perpetuating the gap between what they term “IT” and the “Business” . This year, to my delight, they were starting to talk about “the business” and IT’s part in it. It’s a brave thing to do, but the right thing to do. Most organisations still have their IT split off as separate organisational units ,with a separate strategy and loads of money, which tries to work out what “the business” wants and then all too often fails to meet those expectations. What is guaranteed though, is if you give an IT department money, they will spend it all, even if the business need is unclear. . . . that’s the “business’” fault!

Mike Langley from PMI was a key note speaker and gave his view on the all important question of “how do we ensure our (IT) projects fit our strategy?”  Notice I put “IT” in brackets – the department is irrelevant as we want all our projects to align with strategy . . . don’t we?

Mike based his talk on PMI’s recent “Pulse of the profession” survey.

We are all familiar with “strategy” and “execution” (sorry for using the “e” word, but when at an American conference, you can’t get away from it!).  The story is that the business leaders set the strategy and then the “business” implements it. If it goes wrong, it’s usually the fault of the business and their dreadful requirements and poor implementation!  What new research for Harvard Business Review is now talking about is that implementation is part of strategy and we should not separate them. (look out McKinsey and Bain!.) After all, if your strategy doesn’t include how to implement itself, then it’s a poor strategy.  The new buzz words for making this happen is “portfolio management”. This is a discipline of making sure that the programmes, projects and other activities that a business decides to do are the rights ones in terms of strategic direction, fit and balance in terms of risk and skills use. It’s all about selecting the right projects.

Mike says his research shows that organisations which are good at portfolio management are more agile, and have better project outcomes. Portfolio management is integral to how the top level leaders want to manage their business; it’s an integral part of business planning. Traditional business planning adds up costs of departmental budgets, checks against revenue and makes sure there is “interlock” if different departments need to work together.  Usually this is done a year or so in advance and is therefore totally pointless for organisations in fast moving environments. It is however a neat and simplistic way to blame people when things go wrong or costs to much. Hence, getting portfolio management working right is as much to do with mind-set as having the processes, systems and operating model.

Getting this right, means organisations can continuously tune their plans, not be tied to outdated annual budgets and use their people and money where the benefit is most attractive.  The money will follow the business need, not the department doing the work. Now that is what I call true organisational agility and if you have read the Project Workout, it will be very familiar to you.

This isn’t new as a concept, but it is something many organisations struggle with.  Have a look at this article: Excellence is not enough from the Project Workout “articles” web page.

Is your parrot (I mean project) dead?

A risk register is sometimes not enough.Dead Parrot

Projects are not simple things to manage, even when there is a book, like the the Project Workout, to help you.  So, how do you know if your project is “healthy” and likely to meet the business objectives it was set up to achieve? How do you know it’s not well and truly dead, like the proverbial Monty Python parrot?

Well, a quick look at the risk log may help, together with a view on the issues. The schedule plan updates should show you how you are doing against your baselined plan. (what do mean you don’t have a baseline?)

These are all good ways to gain a feel; they are your day to day instruments. Sometimes, though, it’s good to rise above all the detail of methods, tools, reports and logs and consider in an holistic way, “Will this project really do what we need?”.

The Project Health Check

This is where the project health check comes in. It asks five searching question on each of the following areas of project management:

Project plan
Resources
Ownership
Justifiable case
Expertise
Clear solution
Targeted control

If anyone of those is not adequately covered, then your parrot may indeed be dying.

Let’s have a look at the output from an example:

Example of an output from the Health Check

Example of an output from the Health Check

Overall the tool’s analysis suggests the project is medium risk. Well, you might say, that’s ok, isn’t it? However, if you look at the problem areas you can see they relate to:
Solution – we don’t know what we’re building
Resources – we haven’t got anyone to do whatever it is
Expertise – we don’t fully have the expertise we need.

Now this cluster makes sense. All the management stuff is okay, but if we haven’t got the expertise for the specialist work, then perhaps that’s why we don’t yet have a solution. Also, if there is no solution yet, you can’t really know what resources you need.

So is it okay? If you are in the investigative stages of the project then, yes, you could be okay, assuming you take action to fill the gaps. If however, you are in the development stages or later, then your parrot is probably going to die.

As with all these types of tools, they are there to help you think and self-delusion in answering the questions will reinforce any delusional opinions. For that reason, it’s often good to do this type of assessment in groups and gain a consensus; the value of the discussion will far out weight the paper result.

When would you use this?

I suggest that you use at as an input to every gate decision to provide the decision makers with a summary of the ares which need attention. You can also do it “ad-hoc” in response to any concerns which have been raised.

Is it worth it?

Yes. One company I work ed with employed some consultants to review 12 of their most critical projects. The consultants used their own, very extensive, tools and check lists. When they’d finished their work they took this tool and applied it to all twelve projects. The found a full correlation. In fact, they said if the company had applied this tool first, as a filter, they could have saved 60% of the consulting fee as most of the projects were fine.

You can find the tool in the CD which accompanies the Project Workout.

Defining your projects

The most important thing to is know WHY you want a project.

The most important thing to is know WHY you want a project.

Let’s follow on from last week’s blog on success and see what you can do to see if you are taking on board the messages. Successful projects need to lead to successful business outcomes and unless a project is adequately defined, it is unlikely to achieve anything, except perhaps a hole in your budget. Take any project that you are associated with and check that it is satisfactorily defined:

  • If you don’t know why you are doing the project, consider terminating it.
  • If you don’t know what you are delivering, regard your costs and timescales as unstable and your risk high.
  • If you don’t know when it will be done, carry out more investigations until you do know.
  • If you don’t know how you will approach the project, regard risk as high and investigate further.

“Project Definition” is a term used in The Project Workout, alternatives include:

  • Project Initiation Document or Dossier (PRINCE2)
  • Project management plan (PMI, APM)

Use this checklist to review any projects currently in progress.

  • Has a project definition been written, reviewed by the stakeholders and approved by the project sponsor?
  • Do the scope and objectives of the project meet the needs of the business?
  • Have the benefits been fully assessed and quantified wherever possible?
  • Do the benefits match the needs?
  • Have all significant risks been identified, categorised and taken into account in the plan and business case?
  • Has a comprehensive and satisfactory work breakdown been developed?
  • Does the work breakdown reflect the deliverables to be produced?
  • Are all key logical relationships between projects and activities clear?
  • Has the plan been developed to minimise or offset the risks?

The only way a project can be delivered is through its deliverables. For each deliverable check:

  • is the deliverables relevant and feasible both to produce and use?
  • Have quality criteria been established?
  • Is it clear who is accountable for preparing each deliverable?
  • Is it clear who will review the deliverable prior to acceptance?
  • Is it clear who will approve each deliverable?
  • Has sufficient time been allowed for reviewing/amending each deliverable?

For more on this see The Project Workout, Part Four which takes you through project set up and gives you some templates you can use.

Whose success is it?

In my “enemies within” blog, we looked at how management get the project performance they deserve. In that blog we explored the important role of the programme and project sponsor in making sure that an organisation’s programmes and projects succeed. But what does “success” mean? Success is too often interpreted through the differing eyes of stakeholders.

Successful project management ensures the delivery of a specified scope, on time and to budget (PMI’s triple constraint). It is related to how efficiently a project is managed. This should be assessed during the project closure review, documented in a project closure report and measured by timeliness of delivery milestones, adherence to budgets and quality. This is commonly associated with the role of the project manager.

A successful project realises the business benefits it was set up to achieve as stated in a business case. It is related to the effectiveness of the project in meeting the objectives set. The post implementation review (post-project review) assesses this. Measures of success here must be indicative of the business objectives being achieved. This review therefore has to happen some time after the output of the project has been put into use. It is associated with the role of the project sponsor.

A successful organisation drives towards its strategic objectives while fulfilling expectations of shareholders, managers, employees and other stakeholders. Measures for this are at a corporate level and should be financial and non-financial, such as a balanced score card. This is associated with the role of the chief executive.

A project which has been successfully ‘project managed’, however, may actually deliver little of value to the organisation. Further, a ‘successful project’ may not further the strategic objectives of the organisation, as its objectives may be out of alignment organisations seeking to optimise their total portfolio of projects through the effective combination of project management, sponsorship and portfolio management. A failing company can be full of ‘successful project management’ and ‘successful projects’ all driving in different directions.

The PMI’s recent report, Pulse of the Profession 2013, has actually picked up the above themes, so may this will help senior business leaders realise the potential that effective and efficient project management has to drive their organisations.

Gartner goes one step further and state that organisations which grasp this first will have a enhanced competitive advantage over the others.

Whatever you do must help you move towards your strategic objective. Otherwise there's no point.

Whatever you do must help you move towards your strategic objective. Otherwise there’s no point.

References:

Enemies within – why it doesn’t work

Far too many projects fail.

Far too many projects fail.

Project management, in the modern sense, has been with us a long time now. Some people have spent most, if not all their careers engaged in it in one form or another. Research and anecdotal evidence, however, seems to indicate that we still don’t “get it”. Reports continue to be written on “causes of project failure”. Eminent committees are set up to “get to the root of the problem”, international and national standards are created and yet:

  • we still see failure.
  • we still see organisations which ignore the benefits.

Why is this? If I could answer that, then I would be able to charge massive consulting fees! The question is rather like that posed in “Hitchhikers guide to the galaxy” asking, “What is the meaning of life?”  As we all know, the answer is “42” – which doesn’t help us one jot. If I ever came across anyone who knew the solution to stopping “project failure”, I would be very skeptical.

So why can’t people grasp the significance and advantages of business-led project management? We have:

  • lots of good books – like the Project Workout!
  • National and international standards such as BS6079 and ISO21500
  • Leaned societies, like the APM and PMI
  • Conferences galore

Actually, when the Project Workout came out in 1997 it was probably the first to put project management in a business context; earlier books were focused on project management techniques.

Cover all four basesBack to the topic! Having good methods and process supported by good tools and systems with clear accountabilities is necessary but not enough. The critical difference comes from an organisation’s culture; how they behave and their values. Give me the right culture and mediocre process over poor culture and brilliant process, any day. Organisations where project management “doesn’t work”, are likely to have a culture which actively prevents it from working. For example, for project management to be effective, we need more than just good project managers; for example:

  • project sponsorship is vital if the projects are to be linked to strategy
  • portfolio management (called business programme management in the Project Workout) is necessary to balance risk and choose those projects which will get you towards your strategic intent faster
  • finance systems, which enable project sponsors, managers and teams to see, their operational figures “live”
  • resource management so you can take account of constraints in choosing and implementing your projects.

Hunter Thompson, in 1970, said “In a democracy, people usually get the kind of government they deserve and they deserve what they get.” In this he blames the people in a democracy. Organisations, however are not democracies and so I would turn that quotation on its head:

Senior teams get the project management performance they deserve“.

The CEO sets the culture and “the way they want to run their business” and the following list indicates where the culture and values promote failure, rather than success. Running a project is difficult enough, but we often make it more arduous than it need be by creating problems for ourselves. Here are a few examples:

  1. Reorganising – either the company or a part of it. Tinkering with your structure is usually NOT the solution to your problems, it just confuses people. If you are a senior executive, however, reorganising is a great way to hide non-delivery!
  2. Functional thinking – not taking the helicopter, the organisation-wide view. This often happens when executives’ or individuals’ bonuses are based on targets which are at odds with the organisation’s needs, e.g. sales bonus rewarded on revenue, regardless of profit or contribution.
  3. Having too many rules – the more rules you have, the more sinners you create and the less happy your people become. Have you ever met a happy bureaucrat?
  4. Disappearing and changing sponsors – without a sponsor there should be no project. Continual changing of the ‘driver’ will cause you to lose focus and forget WHY you are undertaking the project. Consider terminating such a project to see who really wants it!
  5. Ignoring the risks – risks don’t go away, so acknowledge them and manage them. If I said that a certain aeroplane is likely to crash, would you fly on it? And yet, every day executives approve projects when a simple risk analysis shows they are highly likely to fail.
  6. Dash in and get on with it! – if a project is that important, you haven’t the time NOT to plan your way ahead. High activity levels do not necessarily mean action or progress.
  7. Analysis paralysis – you need to investigate, but only enough to gain the confidence to move on. This is the opposite to dash in and ignore the risks. It is also a ploy used to delay projects: ‘. . . I haven’t quite enough information to make a decision, just do some more study work.’
  8. Untested assumptions – all assumptions are risks; treat them as such.
  9. Forgetting what the project is for – if this happens, terminate the project. If it is that useful, someone will scream and remember why it is being done.
  10. Executive’s ‘pet projects’ – have no exceptions. If an executive’s idea is really so good, it should stand up to the scrutiny that all the others go through. He or she may have a helicopter view, but might also have their head in the clouds.

I’m sure you can add to that list, so please do, by adding a comment. Over the next few months, I’ll investigate a number of the above symptoms.

In the meantime, you can find out more about these from The Project Workout (4th edition):

  • lessons on what works: Chapter 2
  • enemies within – page 41
  • sponsorship: Chapter 4
  • portfolio management: Chapters 14 and 15
  • resource management: Chapter 16
  • finances: Chapter 17

Business change through effective sponsorship

Is leading from the front always right?

All organisations have to change at some time, some more frequently than others. Something, somewhere always needs to be created or improved. Many leading organisations are now directing and managing change by using business-led, programme and project management techniques. As organisations have become more integrated through the use of complex systems and processes, the effectiveness of managing change through the traditional functional hierarchy has diminished. Programmes and projects, in the modern sense, are now strategic management tools, ideally suited to the complex organisations of today. Business leaders ignore the newly reborn discipline of enterprise-wide programme and project management at their peril. It is no longer the preserve of specialists in the engineering or IT sectors, but something every director and manager should have in their ‘tool box’. Well directed and managed programmes and projects enable an organisation to react and adapt speedily to meet the challenges of the competitive environment, ensuring the organisation drives towards attainable and visible corporate goals. Effective business-led programme and project management will increase the likelihood of business success by ensuring visibility, accountability and control over business change activities. In particular by:

  • linking business needs directly to visible actions plans;
  • enabling you to manage across every department in your organisation;
  • ensuring accountability can be assigned, safe in the knowledge any gaps are covered;
  • providing a flexible and responsive method to respond to changing needs;
  • focusing on priorities;
  • enabling you to track progress toward your business objectives.

It is not just the “project geeks” saying this now, but also strategy consultants, like McKinsey & Co. All senior executives should be leaders of change within the organisation. For some this may be a new experience. They will be in the position of advocating a new order, acting in the interest of the wider company needs rather than those of the department or line director they serve. For the first time, they may be operating outside their own departmental or functional structure. They will have to work with people they don’t have direct authority over and this may require all their influencing and leadership skills if they are to achieve their aims.

To summarise, the sponsor is the business advocate accountable for directing a programme or project to ensure the business objectives are met and benefits realised. In simple terms the sponsor role can be referred, exactly as that:

  • Programme sponsor
  • Project sponsor.

The UK public sector calls the roles “Project Executive”, for a project and “Senior Responsible Owner” for a programme. These are derived from the MSP and PRINCE2 methodologies respectively.

If I am a programme or project manager, what can I expect of my sponsor?  And what can I do if he or she doesn’t meet those expectations? You should expect your sponsor to:

  • Take an interest – their interest! It’s their programme or project!
  • Communicate their vision;
  • Be clear on what outcomes they need;
  • Agree the governance;
  • Keep you informed of the business context;
  • Challenge you;
  • Be realistic;
  • Make decisions and give you direction; and
  • Accept that all risks are their risks!

If you don’t get what you need, try acting as if they are the perfect sponsor:

Remember it’s “their project”, not yours;

  • Make your “personal contract” with them;
  • Assume they want to undertake their role;
  • Make requests for direction and decisions;
  • Look at the world through their eyes – outcomes and benefits;
  • Make the risks plain – their risks;
  • Report the world through their eyes;
  • Don’t assume or expect them to understand your “jargon”; and
  • Don’t try to take over their role.

You can read the full article from the Project Workout Community, articles section. In the meantime, who do you think is accountable for “making change happen”? Is there a simple answer? Is a project manager a change manager? Is a change manager a project manager? I suspect it all depends on how you views those words.

A cautionary tale on business cases

Some years ago, a major communications company was expanding its network to gain access to potential customers. They prided themselves on having a good handle on cost management, especially capex. Each department knew exactly how much they could spend each year and it was tracked weekly. They held weekly Capital Approval Board meetings to control the release of the funds.

The business case
So, along came the project team and asked for a lot of money to buy a telecoms switch to handle the traffic from their five million additional potential customers. The revenue projections were good and return enormous . . . and the wise men on the Capital Approval Board approved the project.

The following week, another project team came along and said, “You know that lovely new switch you approved? It doesn’t like getting wet, so here is a submission to construct the building around it to keep it dry”. The revenue figure was the same as before as, without this building, the switch wouldn’t work and no customer revenue would flow . . . and the wise men on the Capital Approval Board approved the project.

A week later, another team arrived. “You know that lovely building and switch? Well, it won’t work without electricity, so here is the submission for the uninterrupted power supply electrical systems for it . . . and the wise men on the Capital Approval Board approved the project.

Yet another week or two later, yet another team arrived. “You know that switch, and powered building you approved? Well, switches don’t like getting hot, so we need you to approve the air conditioning system which is needed to keep it cool.  If you don’t, you won’t get any revenue . . . . the wise men on the Capital Approval Board were getting a little annoyed, but approved it as they really wanted all that lovely revenue.

The final straw came a month later. “You know that lovely switch in its cool, dry environment with lots of power? Well, it’s useless unless it is connected to the core network; the calls and data will have nowhere to go. If you really want the revenue (which we have attributed to this project’s business case), you have to approve this business case as well. The CEO (who chaired the Capital Approval Board that day) exploded.

True business led project management
The result was that from then on, projects were not bounded by departmental budgets (opex or capex) but by the work needed to get the revenue or other benefit. Projects became bigger as they included all the work needed, across any departments needed, and only ONE business case was developed to cover the lot. There were also far fewer projects, making it easier to see what was going on and the multiple counting of revenue and benefits decreased dramatically. Individual departments contributing to a project could no longer veto or reprioritise the “portion” as they no longer owned the project.

Look in the mirror – what do you see?
This blog is based on a true story from the 1990s, but even now, I see companies which fall into the trap mentioned above. Are all your projects “complete”? Do they include all the work needed to achieve the benefits? Or has the project been “salami sliced” into smaller “enabling projects”, each of which, in isolation, contributes nothing and just consumes resources?

When efficiency has the opposite effect

If I make every part of my organisation super-efficient, I’ll have a really efficient organisation, won’t I?

Well, if you believe this, then the whole of the theory of constraints seems to have passed you by. Squeezing every bit of efficiency out of every bit of an organisation generally has the opposite effect. It can make matters worse or even prove disastrous. On a similar note, one part of an organisation making itself super-efficient may also make the whole organisation perform worse.

We live in the real world, not a theoretical world, things can and do go wrong (no matter how often you bang the desk and shout at people!). The world is too complex and inter connected to be able to predict causes and effects across an entire organisation and the environment which influences it. Against this back-drop, let’s look at these two cases.

Case 1 – a production facility
Take a simple factory line. Raw goods go in one end, are worked on in a series of machines and then finished goods come out the other end. Each machine has a probability of breaking down. The thing that matters is not that every machine is working to maximum efficiency, but that the throughput of the whole line, from raw materials to finished goods, is maintained and is efficient overall. If a machine breaks down, this stops downstream machines working as they have nothing to process. Manufacturers deal with this by having “buffer” stocks of partially finished goods, so the line can continue working even if an upstream machine is out of action for a time. The size of the buffer is related to the probable “outage” time. If there were five machines, each with a probability of breakdown of 0.1, then at any point in time there is a fifty:fifty probability the line will be out of action. If someone had insisted that the “buffer stocks” represented waste and required them to be removed, that production line would be out of action half the time. When any one machine breaks down, the whole production line stops. So much for efficiency!

Case 2 – having one really efficient part
In the second case, imagine a sales group who, in isolation, devised a really effective and efficient sales approach. They did this because they had an instruction, from on high, to be as efficient as possible. So like good corporate citizens they halved their sales costs and quadrupled the volume of sales. You’d think this was rather good wouldn’t you? WRONG! If the fulfilment departments couldn’t keep pace with the increased sales volumes, there would be a lot of dissatisfied customers.. . . in fact “service” may now be so bad, customers want their money back and will never buy again; and you get a slamming in the press. Not quite what was wanted.

So, when looking at efficiency, you cannot look at any part in isolation; you need to look at the whole chain and decide where the “constraint” is and manage it. Certainly you can improve efficiency, but it must always be in relation to the whole system. Find the constraint, remove the constraint, check the throughput and then move on to the next constraint.

In a later blog we’ll look at how theory of constraints affects project working . . . but I think that is enough for you to chew on, for now. In the meantime, if you want to know more about the theory of constraints look up Goldratt.

Business cases, lies and gambles

Earlier in the year, I was at an Isochron forum at which Simon Harris gave his personal perspective on “business cases”. His presentation didn’t pull any punches; he described most business cases as lies on the basis that most of them are constructed to “clear a hurdle”. A little bit of “optimism” or a smattering of “delusional thinking” was all it needed to create a great case and get a pat on the back . . . . and the funding. His recent article in Project Manager Today takes on the same topic but with slightly less colourful language. Basically, he is challenging organisations’ attitudes and values around deciding their futures. Looking at Simon’s list of “headlines”, it becomes apparent that a portfolio, programme and projects approach is a great vehicle for managing investments. Not only can they deal with capital efficiency, but also cash, risk, resourcing, cross-company working, capital efficency to name a few.
Here is my “listening” on Simon’s points. Do you agree? Do you take a different view?

Facts, not justification
Most business cases are written by the advocate to “justify” an already fixed view , rather than presenting an unbiased appraisal of the actors influencing the investment decision.

Investment, not gamble
When betting, you place a known amount of money with the bookie, for a known return, should you win. In business cases, you spend an unknown amount of money (it keeps changing!) for an uncertain return. It makes the business case sound worse than a gamble, doesn’t it? This is where good project governance comes in. In a gamble you spend all the money NOW.  A wise buiness leader (project sponsor), manages the risk by taking a staged approach and makes incremental decisions as he or she gains more information. That is what project lifecycles are for!

The place of portfolio management
The responsibility of those appraising business cases is to compare the return on this one, against everything else we are doing and could do. This requires a “portfolio management” approach. Without a portfolio approach, you have no context for the decisions – it is merely a “one at a time” game.

Sunk costs are really sunk
As a project progresses, the amount being spent decreases (unless you really have a disaster on your hands!). The money spent is “sunk”. What is important is the return on the “still to spend” amount and how it compares with other options. Of course, if you do not have a portfolio approach, you can’t do this. If the return is poorer than other options, then terminate the investment. Of course, the sunk costs will have to be written off (if they are capital) but risk provisions should take account of that.


Money is easier to deal with than people

Oddly, money is usually the easiest thing to deal with, if you have sufficient cash. You can store it and it is very simply what it says it is – money. Naturally, accountants like to treat some as “capital” and some as “opex” but that is another game. If money is all that is looked at when appraising business cases, then an organisation is in big trouble. Unless there is the right number of skilled people to work on the investment and operate/use its outputs, there will be no benefit, just a cost. It’s why the government business cases look at “achievability”.

Be sensitive to sensitivity
One thing is certain, the forecast of both costs and benefits will be wrong. This why it is better to think in terms of ranges and envelopes, within which an investment is still viable. This is where sensitivity and scenario analyses come in. As time progress, the future should become clearer and the return on the “still to spend” amount stabilising. It’s all about risk management.

Of course, you also need to keep track of costs on “project investments”, wherever they are spent. That is what modern matrix accounting is for.