Not UK? Change country

Scope - don't leave home without it

by Vince Hines,February 2008

One of the primary reasons often cited for project failure is scope change. Change within a project is not itself a bad thing and will happen whether we like it or not. After all, every project is by definition a unique event and with anything that is unique there is inherently a certain amount of risk. With risk, comes change.

So although we recognise that change is inevitable, there is a limit. Having a robust agreed scope of work is a vital weapon in the armoury of any Project Manager. You will be judged on the success of your project timescales, cost and quality way before anyone takes a look through your Change Control Log.

PRINCE2© gives two early project processes, Project Start-up and Project Initiation. Start-up comes before Initiation but if you are not familiar with PRINCE2 terms it’s difficult to know. Start-up includes creating the Project Brief, whereas Initiation then builds on this to create the widely used PID (Project Initiation Document).

Even if you are working in a less formal environment you must still take the time to define an agreed scope before rolling up your sleeves and producing deliverables. There are many good reasons for this, but for me the primary one is because an agreed scope protects the Project Manager. This document effectively becomes your “contract” with the organisation. You have been asked to deliver xyz and you will be judged on that delivery. The more well defined xyz is, the better chance you have of success, or at least having a common understanding with your senior managers about what is expected.

The “contract” should include details on what is to be delivered, how, when by whom and where. It should also include details on acceptance criteria. How do we know when a deliverable is completed to the appropriate quality level? Just as importantly it should also list assumptions, constraints, dependencies and clarification on what is NOT including in the scope.

Practical Scoping Workshops

So thinking in practical terms, what can we do to ensure the project scope is well thought out? One simple technique that works well is the “post-it notes exercise”. Hold a workshop with those involved in the project, making sure technical experts and maybe those with past experience of similar projects are involved. Together identify the deliverables that need to be achieved in order to result in a completed project. The deliverables should be manageable chunks of work that can be given a clear owner. Whilst running Introduction to Project Management training courses for clients I often use the example of building a conservatory. Some of the deliverables (things to be achieved) include; approved planning permission, ordered parts, dug foundations, built walls, installed windows and so on. Each of these are written onto a post-it note and stuck on a large A0 piece of paper or white board.

Once the list of deliverables is exhausted you can then move them around on the paper or white board to show the general time sequence and draw lines between the post-it notes so show specific dependencies. This results in a first high level plan that can be entered into your planning software. This method has two distinct advantages, (i) the whole team are bought into the deliverable list & dependencies (ii) you can use this same list to provide a logical framework on which to assess project risks, costs, resource requirements and ownership. For example, assess the risks for each post-it note (in your Risk Workshop that follows your Planning Workshop) should mean you have considered all possible areas of the project for risk, and so on.

How About a Scope Document?

If you then combine this approach with a document that can then be reviewed and signed-off, what format should this document take? For those not rushing straight for a formal PID template one practical solution could be to use the headers from the Project Brief as defined by PRINCE2. These are:

• Background
• Project definition, explaining what the project needs to achieve:
• Project objectives
• Project scope and exclusions
• Outline project deliverables and/or desired outcomes
• Constraints
• Dependencies (interfaces)
• Outline Business Case
• Description of how the project supports business strategy, plans or programmes
• Reasons why the project is needed
• Project tolerances
• Customers quality expectations
• Acceptance criteria
• Any known risks

So if you want to ensure you, and everyone else, are fully aware of what you are letting yourself in for when you agree to be the Project Manager make sure you have a well defined scope. Don’t get approval to delivery xyz for £x to then be put in a situation where expectation is that you are going to delivery xyz AND abc for the same budget.

Note from the editor:

Of course what better way to create this essential project documentation and keep track of the changes to it than by using PROJECT in a box, either the free Community Edition or the full professional platform.

Notes on Wellingtone Project Management

Please visit http://www.wellingtone.co.uk/project_management_recruitment.htm to learn more about our specialist project management recruitment expertise.

Please visit http://www.wellingtone.co.uk/vacancies.php to look through our current permanent and contract project management job opportunities