Project gating? CFOs at Shell and Coca Cola really believe in it.

Shell CFO calls for open-minded approach to innovation – says the headline.
I was sent the article at the foot of this blog; it comes from Accountancy Age, Wednesday May 22nd, 2013 and shows that effective project management and accountancy are intertwined; you can’t have effective projects without having the financial systems to track them and you can’t honestly say you are in control of your business if you don’t have effective project accounting.

A good matrix accounting systems will ensure you understand the real business

A good matrix accounting systems will ensure you understand the real business

In the article, the CFOs of both Coca Cola and Shell praise the virtues of a gated approach to projects, where we see the whole project but give authorisation a stage at a time (depending on risk). These CFOs see gates as vital control points, being the decision point on whether to continue and terminate a project. It’s all about sensible business investment. Gates serve as points to:

  • Check the business case
  • Check the merits of the project against other work that could be done
  • Check we have the resources both to undertake the project and operate the outcome
  • Check the plan for the remainder of the work is achievable
  • And finally, provide the funding for the next chunk.

They are the BIG decision points and should not to be confused with what are often called “quality gates”, which look at, quality (believe it or not!). Like many terms in business, “gate” can be over-used and abused.

Properly applied, project gating can radically change business performance. I saw one case where product development output went up ten-fold due to effective gating, rather than the “shove it all in the hopper” approach. Time to market was also reduced dramatically.

To get this right, organisations need effective “project portfolio management”, where the project portfolio is effectively part of the business plan. This is where the business needs originate. If portfolio management is to work effectively, we need to be good at programme and project management as whilst the demands for projects come from the “portfolio”, the feedback on achieving the portfolio’s objectives depends on how well the projects are undertaken.

I was at the London Gartner Forum last year and the vital linkage of business strategy to portfolio to project kept coming out in the talks. Gating was seen as essential for this.

So what could this mean for your organisation?

Projects are the vehicles for change and making the business of tomorrow. A good strategy or business plan, without “good execution” is worth nothing. Programme, project and change management are vital disciplines in making it happen.

Programme and project performance can only improve so far through the efforts of project managers. It is only through effective portfolio management we can hope to improve further by making sure our projects really do meet the business need and ensure we stop authorising projects which we haven’t the resources to do – that just slows down everything and stresses our people.

If benefits result from projects, then it makes sense that funding goes to the projects and NOT to the departments who spend the money. . . and definitely not on an annual basis (unless you business is so old fashioned as to be based on the Venetian traders’ model). If you give any department money they will spend it, regardless, so really on cost centre budget control will prove disappointing!

If you are to give money to projects you need good project accounting capabilities which work on the “matrix” and not just down the silos.

The great thing is that companies like Coca Cola and Shell recognise this; the sad thing is that the state of corporate management is that such an approach is news worthy and that so many organisations are still tied to cost centre accounting and ad-hoc spreadsheet driven project “accounts” (if any). What sort of company are you in?

Learn more about this
To learn more about gates, see Part 2 of The Project Workout.
To learn more about effective project accounting, see Chapter 17 of the Project Workout.

Here is the article:
QUOTE: MANAGEMENT ACCOUNTANTS must be less “mechanistic” and take a more open-minded approach to innovation, according to the chief financial officer of Royal Dutch Shell. Writing in a report by CIMA and the AICPA on innovation in the finance function, Simon Henry, CFO of oil and gas giant Shell, has urged finance functions to play a greater role in driving company innovation.
Shell has an innovation programme that includes a $1.5bn (GBP 1bn) annual R&D budget and also invests around $4bn on innovation within the business. According to Henry, the role of finance within this is multifaceted.
“A finance function needs to be able to understand the business well enough to know what is a worthwhile activity, but also, in this part of the business, to have a bit more of an open mind. It is less mechanistic, and has the ability to live with ambiguity, to identify risk and to manage it,” Henry said.
“The business is all about proper evaluation of risk, whether it’s technological, market or otherwise. We want to encourage innovation and not stifle it, but not in a totally uncontrolled way.”
Describing Shell’s approach, Henry said the company has a ten stage “gate process” to provide funding for innovative projects.
“At each stage gate you can say, this is going to be funded by Shell through to the next four stage gates, at which point we’ll take another decision. Or we put it into a joint venture and we keep an equity stake. So there are different routes to commercialisation,” he said.
Similarly, Coca-Cola has adopted its own stage gate process to control how an idea gets prioritised and funded,
“We want to see the whole project and we want to budget for it, but those funds are not given at one go up front. Each stage has budgets allocated to it, and targets and metrics. If you get to the first gate and if you’re on track, you pass through that gate and get the funding for the next phase. And if you get through to launch, we can spend many, many millions of dollars,” said Doug Bonthrone, director of global services strategy at The Coca-Cola Company.
UNQUOTE

What is a “stage-gate”?

More management jargon?

Do you come across people using the term “stage-gate”? If so, are you sure they really understand what they are talking about? Do they understand what this term means and where it comes from? All too often, I find people use as the term as yet another piece of management jargon and don’t really understand it (just like “workstream”!)

This is the type of muddle people come up with:

Example A starts well, in that there are a number of stages depicted. Unfortunately we know nothing about where the decision points are. Where does the project start or end? Also, the stages are called “stage-gates”, further confusing things.

Bad practice A

 

Example B has the same issues as example A except that a number of decision points have been added. This, however, doesn’t clarify matters much, for example, is stage gate 1, the first stage of the project or the activity before the project starts?

Bad practice B

 

Example C has all the issues raised in examples A and B, except in this case it seems the decision points (gates) are labeled as “stage-gates”.  I wonder what the stages are called – gate-stages? Notice the numbering, which infers that the “gates” are decisions at the end of a stage, rather than decisions to start a new stage.

Bad practice C

Where it came from.

“Stage-gate” is actually a registered trademark devised by Robert Cooper, to describe his stage-gate process for new product development. If you do a web search for R G Cooper or “stage-gate” you’ll find lots of good articles. If you read them, you’ll see that there is no such thing as a “stage-gate”; it is simply the name he gave to his new product development process.  Like my own work on project management, he talks about “gates” and “stages” as being different but related.

Depicting frameworks
In the Project Workout I use circle, arrow and diamond icons to ensure that the above mistakes do not happen. This form of iconography is now enshrined in the latest British Standard (BS6079 Part 1). If you haven’t seen it, then you really should get a copy.

  • A circle depicts activities which happen before a project starts or after it is completed.
  • A diamond represents a gate.
  • An arrow represents a stage.

Like this extract from a figure in the Project Workout:

Extract from the Project Workout.

 

Summary

So, if you are designing a project lifecycle for your project, don’t fall into the real-life traps highlighted in the bad examples above above; make sure you understand the difference between a gate and a stage; avoid “stage-gate” (you may have to pay royalties!) and make sure your depiction of the lifecycle is clear and unambiguous.

More help?

  • Book: Chapter 3 of the Project Workout tells you all about project lifecycles, helping you to design one that works for your situation. Chapters 5 to 11 describe the detail for each stage and then in Chapter 12 it tells you how you can tailor it.
  • Articles: You’ll also find some articles you can download from the community pages of my projectworkout.com site.
  • Video: Here is a video taking you through the project lifecycle in the Project Workout
  • Click for yourself: you can investigate the model in the video above yourself. Go to the community pages in my projectwout.com site.
  • Another blog on the topic:Lifecycles and fuzzy back-ends.

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.

Lifecycles and fuzzy back-ends

I have just spent a really great few days at the APM’s PMO conference near Birmingham, UK. My task there was to give a “master class”, three times, to about 60 of the delegates, on the topic of “Lifecycles”. This covered project, programme and portfolio lifecycles, as defined in the latest APM Body of Knowledge.  I promised the delegates, I’d write a blog about some of the key points which came out of those sessions. As project lifecycles are the most complex and the most critical, I’ll concentrate on that. By the way, congratulations to Eileen Roden for organising such a great conference!

Where does it all go wrong?

In designing gated and staged project lifecycles, I have found mistakes are usually made in the following key areas: the front end and the back end and in the middle! So, lots of scope for problems there!

Getting gates wrong
Firstly, people often treat gates as “exit points” from a stage. I have never met a senior manager who makes decisions walking backwards, so this approach does not match basic human behaviour. Gates are better seen as entry points to the next stage and are, therefore, about making decisions as to what to do next. If you want to look backwards, then have a “review”.

Problems at the start
All too often, I see frameworks with minimal initiation activity, immediately followed by a load of development and testing basically going from ‘idea’ to ‘do it’ in one small step. In all but the simplest projects, such a leap is naïve and may account for why so many projects are ill-defined and doomed to failure. By all means, make it easy to start the project off, but do ensure there is rigour in the actual investigative work itself. A project comprises both investigative work and “doing” work.

Problems in the middle
I sometimes see lifecycle stages with no decision point prior to them. If there is no decision point, then there is no need for a separate stage. Remember, project stages are chosen to manage risk. They are NOT steps in a process. The way risk is managed is by dividing the project into stages, each of which is preceded by a decision point (gate) prior to starting each stage. The riskier the project, the more lifecycle stages there should be.

Problems at the back end
I see many project plans which stop as soon as the output has been handed over. The only time this might work is IF the delivery has been perfect and there is no remedial or snagging to do and the outputs do not need fine tuning, launching or communicating . . . i.e. almost never. This is why the last stage of the Project Workout’s lifecycle covers initial operations, with closure happening only at the very end.

At the back end, people often confuse Project Closure with Post-Project Review. The former looks at project efficiency and delivery, whilst the latter looks at benefits realisation and operational effectiveness. These two views cannot usually be combined as the measurement points are separated by time.

Also note that ‘Identify project” and ‘Review project outcome” are not stages of a project. They are activities which happen before and after the project, respectively.

Depicting frameworks
The use of the circle, arrow and diamond icons in lifecycle diagrams is designed to ensure that the above mistakes do not happen. This form of iconography is now enshrined in the latest British Standard (BS6079 Part 1). If you haven’t seen it, then you really should get a copy.

A five stage project lifecycle taken from the Project Workout.

Naming project gates (and stages)
As best practice is that gates are entry points to stages, then the most logical name for a gate is the name of the stage that follows. Thus the Definition Gate precedes the Definition Stage. Very simple . . . really. The only common exception is the RFS (Ready for Service) gate where the term is self explanatory. When choosing names for your stages, however, be very careful. I suggest you avoid words which can be misunderstood. In my experience the words “Concept” and “Implementation” should be avoided as they can be interpreted in many different ways and cause confusion. Similarly, avoid the word “Execution”: the International Standards Organisation has not used it in their draft project management standard as a majority of member states took exception to it as it can also mean “judicial killing” and hence translation into other languages can be problematic.

More help?

  • Book: Chapter 3 of the Project Workout tells you all about project lifecycles, helping you to design one that works for your situation. In Chapters 5 to 11 it describes the detail for each stage and then in Chapter 12 it tells you how you can tailor it.
  • Articles: You’ll also find some articles you can download from the community pages of my projectwout.com site.
  • Video: Here is a video taking you through the project lifecycle in the Project Workout
  • Click for yourself: you can investigate the model in the video above yourself. Go to the community pages in my projectwout.com site.