This is a guest article by Dr Mike Clayton from OnlinePMCourses.com.
We all know that defining your project well is the foundation of good project management. Without it, you’re managing a mess.
And there’s one thing I’ve learned in training many thousands of project managers. This one topic seems to hold the biggest light-bulb moments.
Because for some people, getting a clear project definition is like sculpting a heap of jelly. That’s jello to my US cousins.
You often have an amorphous set of wants and desires, hopes, dreams and needs. Each subset is championed by a different stakeholder. Each stakeholder has their own style and way of expressing their priorities. And, it gets more complicated still. Your stakeholders have different levels of authority and influence.
And there is one more complicating factor. Terminology.
There’s a lot of jargon around project definition. In fact, this is the stage in the project lifecycle with the most different names:
Let’s Cut Through the Clutter
The core of a solid project definition is three things:
If you can understand these and can elicit each one clearly from your stakeholders, you’ll be in great shape.
By the way, that’s not always easy. In fact, I consider scoping to be the hardest part of project management. Which is all the more reason to understand it well.
The First Problem is Goals and Objectives
This is a problem, because distinguishing them is not always easy. Indeed, some people talk of ‘goalsandobjectives’ almost as one word.
So let me make it very easy to separate the two ideas.
A goal is what you want. It answers the first question you should put to your boss, your project sponsor, or your client:
‘What do you want?’
When you have achieved a consensus about your project goal is, it’s time to move onto their objectives.
Objectives set out what’s important about how you achieve your goal. They articulate what your stakeholders care about, and their criteria for total success. Again, start with your leading stakeholder: your boss, your project sponsor, or your client. Then consult others. Ask them:
‘How do you want the goal delivered?’
Typically, people will answer in terms of the triple constraint of:
- Time – they will have preferred deadlines. They may have required deadlines.
- Cost – they may want you to keep within a certain budget.
- Quality – they may set you specific quality standards to meet.
Again, it’s typical to find that most stakeholders try to tie you down to fixing all three. The common project manager’s refrain is:
‘Time, cost, quality: pick two’
That’s not strictly necessary. As long as the three are consistent, it’s fine in principle. To be OK in practice, you also need to have enough contingency in each of them, to accommodate the level of risk in your project.
As a proxy for risk at this stage, consider a combination of:
Your project scope sets out the breadth and depth of your ambition for your project. Or, more correctly, your stakeholders’ ambitions.
It answers the question:
‘How much of it do you want?’
There are two approaches to scoping. They depend on whether your project management is rooted in the UK or US. Neither is better, but I guess we all have a preference.
In the US, the scope of your project is the amount and range of products your project will deliver. Once you have defined that, the secondary step is to work out the activities you’ll need, to deliver them.
In the UK, project managers talk of the scope of work for your project. The scope is thus the range of activities the project will encompass. Then, the secondary step is to list the deliverables those activities will produce.
The Biggest Mistake in Scoping a Project
Whichever approach you take, there is one further thing you must do. The common mistake is to set out your scope clearly and stop.
What happens then is stakeholders see that scope, interpret the words liberally, and assume they mean more than they do. The phrase you’ll hear is:
‘While you’re doing that, could you just… ?’
You must counter this tendency towards scope creep. If you don’t, it’s a recipe for delay, cost over-runs, errors and defects, and stress. And the way you do it is to look at the boundary around your scope.
Consider every edge case. And then explicitly document what is not included in each scope item. This is your list of project exclusions.
Get your scope exclusions signed-off as part of your full statement of scope.
That way, when someone asks: ‘could you just…?’ You can answer:
‘I really wish I could. But I can’t. See here… It’s on the list of things my boss, sponsor, client says are excluded from the project. Sorry.’
Of course, there’s lots more to project definition.
But here’s one thing I’ve learned. Goal, Objectives, and Scope are the 20 per cent of project definition that deliver 80 per cent of value.
These three key elements are about accuracy. Everything else is about precision. Get these three right, and you’ll be hitting the centre of your project target. Everything else just clusters your aim more tightly.