Project and Programme Management #02

This post focuses on identifying and clarifying the objectives and scope of a project or programme.

Before I do that I just want to respond to some feedback on my first post in this series. Some have taken issue with my assertion that a programme is like a “big project”. Yes of course a programme is actually far more than that, but what I want to emphasise in this series is the “getting started” aspects, potentially in organisations where there is no existing project or programme management culture. So over the course of the series I’ll be building towards a more defined project and programme methodology.

Objectives and scope – what’s the difference?

Essentially the objectives of a project or programme are what is to be delivered in terms of outputs and outcomes, and the scope is anything that imposes any limitations or constraints. For example the objective “make a cup of tea” might have the scope that the tea:

• Must be Darjeeling, loose leaf
• Should be served piping hot
• Should have only a drop of milk
• Should be served in ten minutes

Both of these can be very tricky to define because where do you stop in terms of accuracy? For example, instead of “piping hot” should one specify the exact temperature? And how much milk is “a drop”?
So let’s look a little deeper into defining these.

Outputs and outcomes

I mentioned outputs and outcomes above. These are part of what divides projects from programmes. In my first post I said that programmes could be seen as a collection of projects; but whilst this is true, it is rather simplistic. Another distinction between projects and programmes is that projects deliver specific things: “a cup of tea” – or more realistically: a new IT system, an office relocation, a new garden shed. Outcomes are the things that are derived from the outputs. You don’t just want a new IT system, you want to put it to some sort of use. A brand new garden shed might be built really well (i.e. the output has been delivered) but if it doesn’t fit all your garden tools, the outcome of being somewhere to store your tools safely and dry has not been met. Typically a project finishes when the output has been delivered, and it’s left to the business to derive the outcomes. In programmes, however, outcomes, not outputs, are the measure of success.

In his book Benefits Realisation Management, Gerald Bradley uses the image of a fried egg. The yellow yolk represents the project stuff – the outputs (or enablers, as he calls them). The white represents all the changes in the business that need to happen to successfully adopt and embed the outputs – i.e. this represents the outcomes. Bradley measures outcomes in terms of benefits, and this is a subject I’ll return to in the future.
So your fist job is to decide whether you are to deliver outputs (in which case it’s likely to be a project) or outcomes (in which case it may well be a programme).

Defining outputs

Let’s say the mandate (this is project speak for the brief that you’re given to do the work) is something like “I want a new HR system.” Immediately you will probably start to think of things like: “How much money is available?”, “What resources will I have?”, “Is there a time limit?” and, probably most importantly, “What does the system need to do?” You have begun the definition process. But you want to do it properly, so here are my suggestions for how to go about this.

Clarify the mandate

The first thing to do is to have a meeting with the sponsor: the person who has asked you to do the work and who is also likely to the person paying for it. You need to get as much information from them as you can, and there are some simple tools you can use for this purpose. The first is a standard tool within the Agile project management approach: MoSCoW. This stands for Must have, Should have, Could have and Won’t have this time. It needs to be set within a structured context, and this will depend on the overall, high level objective. But generally you can divide it into the following main categories: savings, better services, research and innovation, mandated, and strategic. Sometimes more than one of these will apply.

So start off with these categories and ask the sponsor to say what they want to achieve in each area. For out HR system you might end up with something like:

Cost

• Prepared to make an investment so long as the system pays for itself within three years and thereafter can demonstrate real savings
• Savings are to be achieved, at least partly, by a reduction in HR staff resulting from more efficient and automated systems (e.g. manager and employee self-serve for things like booking leave, reporting sickness, etc.)

Better services

• The new system will provide self-serve. Not only will this deliver savings but it will provide a more effective system for managing employee records – for example they will be kept up to date because staff can update their own records, and reporting of events will be much quicker.
• This will provide better and more accurate management information, so things like workforce planning can be done with more than a “finger in the air”.

Research and innovation

• Not relevant here.

Mandated

• The system needs to have relevant safeguards to protect personal records (Data Protection Act).
• The system needs to have a full audit trail maintained to the standards defined by our internal auditors.

Strategic

• We plan to go for Investors in People status and the system will help towards this goal.
• Our five-year plan includes a savings target of 25% and this will contribute significantly towards that.

You will find that a lot of these overlap: don’t worry. At this stage it’s important to try and capture as much of this detail as possible.

Once you have obtained a reasonable “shopping list” you can start to use the MoSCoW approach. Start with the M and the W. Ask questions like: “If it were only possible to deliver one thing, what would it be?” and also, “If it turned out that we couldn’t deliver everything, what could go?” and build from that. (Don’t ask “What has the greatest priority?” because you’ll probably get the answer that everything is equally important). You should be able to get a list of what’s in and what could be out. At this stage of planning you don’t need to be definite about could and won’t, but if the sponsor volunteers any ‘won’t this time’ deliverables, grab them like gold dust!

Then work on the ‘what’s in’ list. Ask questions like “If we couldn’t deliver all this at once, what needs to come first?” Gradually you should be able to start building a ‘must have’ and a ‘should have’ list. Should haves are those things that are important, but could potentially be delivered in a later phase.
So you’ll hopefully end up with a list of must haves, should haves and could haves – and if you’re lucky, some won’t have this times. After you’ve done your detailed plan, you can revisit the could haves if time is a problem, because you can then ask “If you want me to deliver by date X, which of these could have items can I drop?”

You should now be in a position to write a detailed mandate: a description of what is to be delivered with some idea of priority (but not necessary timescale). You should get the sponsor to check this out and sign it off.

Problems

In a perfect world you’ll have a good, detailed mandate. In the real world, people change their mind as time goes on (i.e. the scope changes: often called scope creep). Be prepared for this. Scope creep is not necessarily a bad thing: it’s when it’s uncontrolled that it’s bad.

Another reason for scope creep is that people find it hard to define what they want accurately, no matter how thorough you have been in gaining requirements. As they see a solution start to emerge they can realise that they didn’t describe something accurately enough, for example. Again, be prepared for this – control the change but don’t try to resist it.

Another common problem is conflicting requirements. These can arise from a sponsor who wants impossible results (I want the perfect system for free right now). These need to be surfaced and dealt with head on. More problematic is when there is more than one sponsor or there are several powerful people involved, and they have conflicting agendas. The Head of HR wants the perfect system and doesn’t care how much it costs; the Finance Director wants to keep costs down to the minimum. I’ll be dealing the stakeholder management in a later post. For now, it’s important that you try to identify any such conflicts and discuss them with the sponsor. If there is more than one sponsor, try to get agreement that only one person has the final veto.

Coming up:
The business case.