Questions - Defining Project Scope
From the Project Management 2.0 Blog
by Dave Garrett
New technologies, concepts, and Web 2.0 tools are popping up everywhere. How can you use them to help your project team collaborate, communicate - or just give your project an extra boost? [Contact Dave]
Recent Posts
Are You Prepping For The PMP 24/7?
Are You Just Too Darn Busy?
Eliciting Requirements... Creatively!
What To Expect When Your Stakeholders Are Expecting
8 More Templates to Save You Time
Categories
Advice,
Certification,
Collaboration Tools,
Decision Making,
Estimating,
Interviews,
Learning,
Management Approaches,
New Templates,
Personal Productivity,
PM Software,
PPM Software,
Presentation Tools,
Reporting Tools,
Requirements Management,
Research,
Risk Management,
Scheduling Software,
Security,
shameless self promotion,
Techie Tools,
Time Killers,
Time Tracking Software,
Training,
Virtual Team Tools,
Web-based Tools,
workshops
Date
Situation: You want to ask the right questions when defining your project scope.Last week I posted a set of questions from Project HEADWAY related to selecting and enrolling a sponsor. Here is a similar question set from the Plan stage of the process, Define Project Scope. What do you think? Are these the right questions to ask yourself and others during this task?
To determine the scope of the project, ask yourself the following questions:
- What is out of scope on the project? What work won’t you do?
- What is in scope? What work will the project do?
- Do you know the boundaries of the project? Into what areas will you not venture?
- Have the requirements for the project and the product been clearly defined?
- Do you know which stakeholder requirements will not be delivered on by the project?
- Do you know how you will document the project scope?
- On a 1-10 scale, do you know how set in the stone the scope of the project is with 1 being not at all and 10 being carved in stone?
Ask your sponsor or a trusted colleague the same questions. Also, consider asking them:
- Based on what you know about the project to date, what do you think it is going to do?
- What do you want this project to do?
- What should the project not do?
Posted on: April 24, 2008 01:18 PM |
Permalink
Comments (8)
Please login or join to subscribe to this item
The key question I ask myself, and the sponsor, is; "How will I know when I am done?". All of the other questions have easier answers if you can define, picture or describe the last delivered item. Of course, if you can define "done", you can then create the WBS structure needed to achieve "done". If you are able to create the project's WBS, you've defined the scope of the work and you've created one piece of the work product you need to get started.
Rob Martin
Consulting (Contract)| Microsoft (Thailand)
Lam Luk Ka, Pathum Thani, Thailand
Norman hits the nail on the head. Without a vision of success, there is no vision. This is one of the fist scoping questions to be asked. It's the "Why" question. I am sure many PMs here could describe projects they have done where the business didn't really know why they were doing it.
When I am scoping I have three areas I detail for management:-
1. In Scope
2. Out of Scope
3. Undecided scope
By doing this you can expedite decisions on the "Undecided" portions and have them as part of every status update you give to your sponsors.
One cannot execute the project without resolving "undecided" scope.
There will always be some level of scope creep, but by framing it correctly, everyone need not be under any misconception as to what is being delivered.
Rob
I would like to add another perspective. You need to deal with scope long before you get to developing a WBS. My definition of scope is "what you want to do and how will you do it", answered from a business perspective. I will develop a scope document, with input from the project sponsor, to define the following areas:
1. Executive Summary - 2. Project Description , 2.1 Business Objectives, 2.2 Solution Approach - 3. Risks, Assumptions, & Constraints - 4. Project Deliverables, 4.1 Includes, 4.2 Does Not Include - 5. Project Schedule - 6. Project Control, 6.1 Project Plans, 6.2 Issue Management, 6.3 Change Control, 6.4 Communications and Reporting - 7. Project Scope Signatures.
All I am doing at this point in the project is to 'frame' the project, get concurrence on the "is / is not" list, identify all known assumptions, and get signatures that I can later use as rationale for the boundaries. Then comes the task of drilling down to the level that you need in order to develop your WBS.
I think the questions initially posted will help you assess how well the scope is defined.
As a matter of test I always ask the question: if the project is ready and I have done the things mentioned in scope: "will it work, did I meet the objective? The business case is leading as far as I'm concerned. And what if all things have been done, will I meet the business case prognoses? The questions should act as a failsave. The project, as such, should never be a goal in itself.
You also might want to add constraints as part of the scope (e.g budgettairy constraints, time frames).
Other questions that might be useful:
a) What is the priority of each of the requirements? This will help differentiate between actual requirements, and wish-lists.
b) Any specific deliverables other than the implicit project deliverables? (Examples: technical documentation, user guides, etc).
c) What is the scope of activities of the project team? Does it include user training, Knowledge transfer to support teams, etc.
Does anyone of a sample scope document that I can use as a framework that they are willing to share.
There are some excellent points here. Like Norman, I also like to ask "how will I know when I''m done?". In addition, I like to ask the sponsor and key stakeholders: "in your view, what are the key factors that would make this project successful?" or "what is your vision of a successful outcome of this project?". In my experience, these questions usually spark some excellent and lively discussion about the project. It''s interesting how many different answers I get depending on who I talk to.
I would add that often times during the course of the project, stakeholders tend to forget the original scope, and success factors, if not defined by them. This situation occurs especially if the PM team is internal.
The "vision" of success tends to get clouded up with minutaie.
In my experience, its critical to allow the business to develop/drive the scope and requirements such that ultimately, the project team has a straightforward goal to which solution methodology can be proposed and accepted by stakeholders.
Please Login/Register to leave a comment.
|
"Great souls have wills; feeble ones have only wishes."
- Chinese Proverb
|
