DEFINING SCOPE WHEN NO ONE UNDERSTANDS WHAT SCOPE EVEN IS
A project’s success or failure usually hinges on scope management – how well scope was defined, understood, agreed, monitored, controlled, communicated about and delivered. This (along with risk management, in my opinion) is one of the biggies in project management.
So, what happens when you’re a project manager and you’re the only one who knows or understands what scope actually means? Ask any lay person and you’ll get several, varied, sometimes conflicting definitions of scope.
Time to get out your coach-consultant-trainer-facilitator hats on to help progress the project towards gaining a common understanding of what scope is, what it means to project success and how it should be/is going to be managed. Only when everyone (Sponsor, project board, project team and project stakeholders) understands what scope is, can scoping discussions, workshops and consultations begin in earnest.
DEFINING SCOPE WHEN NO ONE HAS TIME TO DEFINE SCOPE
Quick question: “I don’t have time right now, there are other more important/urgent things going on. Can’t you just do it? When you’re done, I’ll just review it really quick and sign it off. You know what I want better than me, anyway!”
Short answer: “NO!”
Longer answer: “I may have done similar projects in the past and can guess fairly close to a scope definition that would meet a lot of your needs, but I don’t do what you do, I don’t think what you think, nor do I mind-read to understand what you need. If you don’t dedicate the time, you’re not going to get what you want, you’re going to get what I want and I am not you. I will not be an end user. At the end of this project, I will be on to my next and you will be stuck using something that I wanted, but will never use. Make time…please!”
Shorter than the longer answer, but longer than the short answer: “Clarifying objectives and defining scope are imperative to successful project management. Either you will not get exactly what you want or you will have to have significantly more resources available for all the extra re-work that will be required. If you can’t find the time to dedicate to the project (a major expenditure and risk increasing endeavour), then maybe we shouldn’t be doing it.”
DEFINING SCOPE WHEN TWO OR MORE PARTIES DEFINE CONFLICTING THINGS
Be prepared because this is not an ‘if’ situation, it’s a ‘when’ situation on every project.
- Understand who has the authority to decide
- Sponsor? Technical Senior Manager? User Advocate? Change Board? Combination? Or other?
- Understand the escalation route
- discussion-> conflict resolution-> negotiation-> arbitration-> mediation
- Understand how conflicts will be resolved
- Consensus? Democracy? Official Arbitrator? Official Scope Decider (see above)?
- Understand that the ‘losing’ party will not (initially, at least) be happy
- employ extra stakeholder engagement with that stakeholder, especially in clarifying benefits of the official decision. Recognise the loss, but stay focussed on the benefits and the part(s) they play to achieve them
DEFINING SCOPE WHEN EVERYTHING IS URGENT/IMPORTANT/CRITICAL
Sanity check: Is this a matter of life and death? Will the world end if not all 100% of scope is delivered? How and why is this project so special?
- Ensure enough user consultations have occurred to determine what the essential criteria/features will be used and if there are any workarounds available or possible.
- Ensure enough supplier consultations have occurred to determine the best delivery options are chosen and employed to meet the user requirements.
- Ensure enough business consultations have occurred to truly understand the value of each item of scope, its connection to meeting the business objectives and its contribution to the business benefits.
If everything really is of equal importance, then cost and time will be sacrificed in order to accommodate any minor or major hiccup, delay, mis-estimate, change request, etc. How much money and or time does the Sponsor/customer actually have? The old “cheap-fast-good – pick any two” conversation will have to be had here.
And when they finally come around, make sure that there is a workable prioritisation strategy (see below) in place to help reach consensus and/or take a decision about what’s in and what’s out and the relative weighting of importance.
Common strategies to help define what’s in and what’s out
- Needs-based analysis
- Buy a feature
- Pain ranking
- Limited voting
- Limited weighted voting
- Agile – timeboxing
DEFINING SCOPE WHEN NO ONE KNOWS, NO ONE IS WILLING TO KNOW, NO ONE IS WILLING TO ACKNOWLEDGE THAT THEY DON’T KNOW, NO ONE IS WILLING TO ACKNOWLEDGE THAT NO ONE IS WILLING TO ACKNOWLEDGE THAT THEY DON’T KNOW
Not everyone is lucky enough to work with a client who knows exactly what they want or need, much less be able to explain what they want or need. Sometimes the best a customer can do is explain what they don’t want and even then, they can only do that when they see something they don’t want. So, until there is something to see, the project is working in the dark, guessing, surmising, working in opposites (e.g., if he doesn’t want “up”, then does that mean he wants “down”?).
Build it into the plan to discover scope in the early stage(s). Or consider using a more Agile project management approach to build incrementally in short, iterative bursts. Utilise discovery tools and techniques such as: prototypes, mock ups, stories, scenarios, user stories, a day in the life narratives, illustrations, wireframes, models, simulations, moulds, casts, displays, walkthroughs, replicas.
Once clarified and refined, gain acceptance and agreement, yet still build in a substantial change budget (trust me!).
- It’s not impossible to do this well, though some days it feels like it.
- Not everyone will agree all the time, just make sure you understand the authority roles and decision making rules and stick to them.
- You can be uber-, ultra-, totally and completely clear in defining your scope and there will still be some mis-understandings, somewhere along the line.
- Upfront effort pays dividends over rework or last-minute-scrambling efforts.
- Good luck!