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.

No white space = unhealthy company

In an earlier blog I talked about the three necessary conditions if you are to manage your resources effectively (see Link). Resource management is a hot topic in many companies and is the primary driver for them implementing programme and project management systems.

In this blog, I’ll talk about what I refer to as “white space” and why, if you haven’t got this, your company or organisation is in an unhealthy state.  So what is “white space”? The gap between what your resources are committed to and the total resource you have available is ‘white space.’ It is the resources that you have not yet committed to a given activity or project. If you fulfil conditions 2 and 3 from my earlier blog, you will know your white space:

White space = resources available – resources already committed

In the very short term this should be small. It will grow as you look further into the future.
White space is fundamental to a organisation’s on-going health. If you haven’t any in the short to medium term, you are paralysed. You have no one available to change the business to meet new threats or exploit new opportunities unless you withdraw them from previously committed work. White space gives you the resources to effect change in the future.
‘We are in a fast moving environment’ is the common mantra nowadays. If this is truly the case, then you need to ensure that you have ‘white space’ resources ready to meet future needs. You know the people will be required but you are not yet sure exactly what for. If you have no people to change things, things won’t change.

White space must cater for two distinct needs:

● First, it must cover the need to undertake initial investigations from new proposals. People must be available at very short notice to do these and must be highly knowledgeable if the investigations are to have any value.
● Second, you need the resources to undertake the future projects or work.

Compare the former to a company putting a bid together – if this is done by inappropriate people, the timing of when bid and what bids are needed is unpredictable, the bid may be lost or the company may have committed itself to a financial disaster. Just because business projects are  ‘internal’ it does not mean you need not apply the same rigour as you would with external matters. It’s your organisation’s future at stake in both cases.

White space

The figure represents ‘white space’ in graph form. It could apply to a complete organisation, a division, a function or whatever. However, unless you can build this picture you will be taking risks every time you need to set off another initiative.

One of the challenges I have found is that many organisations plan on an annual basis and the financial controllers insist that every work item for the year is itemised and budgeted for, believing that this will ensure efficiency; they simply won’t allow “white space” and expect managers to have 20:20 forecasting vision . . . even in a fast moving environment.  White space is what enables an organisation to be nimble, fast moving or agile (choose your own buzz word).

You can find out more about resourcing in Chapter 16 of 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.

I thought you were doing that!

If you haven't got accountability right, you could look pretty stupid.

If you haven’t got accountability right, you could look pretty stupid.

Whenever I am called into a conversation on who’s accountable for this or responsible for that, things soon get out of hand as everyone starts to argue what “RACI” means and forgets about why they are there. By the way, it should be “ARCI”, but that doesn’t sound very nice.

Putting that aside, let’s look at this from a different angle, which looks at mind-set and behaviour. I came across this approach from a New Jersey company called London Peret Roche.

Accountable: what a person is accountable for; it includes WHO they are accountable to. If they aren’t accountable to anyone, they won’t be held to account and no-one will be counting on them.

Responsible: As a “grown-up”, I act responsibly. If I see a banana skin on the floor, I pick it up and put it in the bin, so no-one slips and breaks their neck. I wasn’t “accountable” for the banana skin; I merely acted responsibly i.e. as if I was the cause.

We all need to work together in programme and project teams and often are “counting on each other” to deliver or do certain things. If I spot something wrong in someone else’s area, I shouldn’t just ignore it, just because I’m not accountable. I should let the “accountable person” know and even offer to help them solve it, if I have the knowledge and skills needed. In programme and project teams we all succeed or fail together.

So let’s look at this in the context of a programme or project and see how this works.

The person who is accountable is not necessarily the person who does the work, but the one who sees that it is done. This is useful in planning projects. You should be familiar with the accountabilities of the project sponsor and project manager. The project manager is accountable to the project sponsor for managing the work on a day-to-day basis, ensuring the deliverables are in place at the required time, quality and cost. He or she cannot do it all, or in many cases manage it all. We all should also know how a project should deconstructed into life cycle stages. This decomposition can be followed through with major packages of work being made the accountability of a particular, named, team manager. These work packages may be divided into smaller work packages and ultimately into individual activities and tasks. This deconstruction is called a work breakdown structure. It is fundamental to good governance and planning and also forms the basis of reporting and escalations. So you see, accountability starts at the top and trckles down. If you aren’t clear on accountability, you have no governance in place.

In practice, single point accountability means every task, activity and work package at any level in the work breakdown structure has a person named as accountable for it. This has four advantages:
– It is clear what is expected of each person.
– Overlaps should be eliminated as no deliverable can be created within two different work packages.
– If a gap in accountability appears (due to loss of a team member, for example or a plain error), the next person up the tree is accountable to fix it.
– If scope, cost or time proves to be inadequate to create the deliverables, it is clear who is accountable for raising these issues.

In practice, accountability is shown in the way that project plans (bar charts) are designed. The examples given in the planning chapter (21) in the Project Workout, clearly show accountability.

In programmes and projects it is essential that accountabilities are clearly stated and are unambiguous so everyone knows who is called to account and who they are accountable to. Similarly, team commitment should be fostered, which promotes responsible and open behaviour by all team members. Knowing who is accountable is not about placing blame (blame games seldom achieve anything but angst), it should be about clarity over who is doing what and knowing who to talk to.

For more on tis see The Project Workout, Chapter 18, page 286.

When a plan is not a plan at all!

The word plan is used frequently in day to day conversations and most people have a good idea of what a “plan” is. However in a programme and project management context things may not be quite so clear. One common mistake people often make is to believe the “plan” is just the timescale, as shown in a Gantt Chart. However, whilst the timescale (or schedule plan, to give it its formal name) is vital, it is only one part of the overall plan. The other aspects include:

  • costs,
  • resources,
  • accountability,
  • WBS
  • and, often, benefits.

These are often bundled together into a narrative document such as a Programme Plan or Project Plan.

This holistic view of the term “plan” is what is used in PRINCE2, BS6079, PMI and APM publications . . . and that is also how we use the term in the Project Workout. You can find out more about planning in the Project Workout, Part 4.

Good programme and project plans can take many forms and any enterprise approach should allow a programme or project manager a wide degree of freedom in how to document this. Standard Product Descriptions, which contain tailoring guidelines are good place to document such guidelines.

So, next time you are asked for a “plan”, check what the person is really looking for and don’t jump to conclusions that what you define as a “plan” is the same as theirs.

Don’t waste your time planning!

Do you sometimes (or often!) hear the words, “Don’t waste your time planning, just get on with it!“? Do you agree? If not, do you know how to respond? This blog looks at one fundamental aspect of planning, the schedule plan, and explains why planning is vital.

What a well produced plan tells you
You will find the management of the schedule is one of the most important and fundamental of project management techniques. So much so that many people (wrongly) think that schedule management is project management. At a simple level, the schedule tells you how long the programme and project, or any part of it, will take. In addition to giving dates, a well produced schedule plan also tells you:

  • who is accountable for every aspect of the programme or project;
  • escalation routes;
  • reporting channels;
  • the approach being undertaken;
  • the major deliverables from the programme or project;
  • interdependencies (gives and gets);
  • the timing of key review points and major decisions;
  • payments;
  • constraints (such as “freeze periods);
  • benefits recognition points.

The schedule is also the basis on which cost and resource plans are constructed. However, unlike costs and resources, which are seen by only a few people, key dates are very visible. A well publicized delivery date is, when missed, very hard to hide. While “time” may not be the most important aspect on some projects, an observer may develop their own perception of “success” or “failure” purely from the performance against the publicized target dates. The ability to build and manage the schedule plan is one of the essential skills that all programme, project and team managers should have. Planning is far too important to delegate to junior team members, especially in the early stages when the overall strategy and approach are being developed. The plan sets the course for the remainder of the work.

The benefits of good planning
Done effectively, the schedule plan will benefit your sponsor, you and the team by providing:

  • a   baseline against which to measure progress (without a plan, words such as “early” or “late” have no meaning);
  • a common understanding of the approach being taken to achieve your sponsor’s objectives;
  • a breakdown of the project workload into manageable pieces (work packages) based on the deliverables/outputs wherever possible;
  • a clear way of showing interdependencies between activities and work packages within the project and to/from other external projects;
  • a listing of accountabilities for different work packages and activities;
  • a tool for evaluating when corrective action is needed.

Further, the actual activity of creating a plan by using the full team serves to forge a team spirit and a high level of common understanding and commitment.
Know your risks
All programmes and projects are undertaken within an environment of risk. Good planning is done in the full knowledge of those risks. You should therefore:

  • avoid avoidable risks by planning the project in a different way;
  • contingency plan for the unavoidable risks.

All organisations need to make provisions for risks in their financial accounts; without planning how can you know what these are?

Enough planning is enough
A good plan is not necessarily a detailed plan with lots of activities. Micro-planning can be damaging as it is time wasted. The granularity of the plan needs to reflect the risk associated with the work, the phase or stage of the work and the need for effective monitoring and control. A key tenet of planning is plan the immediate work in detail and the rest of the work in outline. This applies whether using “classic” or “agile” approaches.

Plans can change!
Once a plan is produced and agreed it should be baselined and used to gauge progress. However, that is not the end of the story. Things may change either within the project or outside it, which will cause us to re-plan and re-baseline. Never consider a plan to be fixed, but only introduce changes when you really know what the impact is.

Finding help in the Project Workout
Chapter 21 of The Project Workout covers schedule planning and the accompanying CD includes is a Microsoft Project template, which includes all the key “best practice” features described in the book.
Chapter 25 deals with change control.