Scope management is something that we struggle with - at least I do on most of my projects. Tracking the small (and big) things that fall outside of our agreed upon requirements...it's difficult and never fun to go back to the client for change orders on work that is outside what is perceived to be the set scope for the project.
What are some of your best practices for managing project scope? How do you engage team members to help manage scope?
Brad
What are some of your best practices for managing project scope
Hi Brad,
I equate project scope to an iceberg. There's the bit you can see (what the customer asks for) and the bit you can't see (the customer's assumptions about what the project will deliver that have not been articulated). As we know icebergs are a danger to shipping, and scope icebergs are equally dangerous to projects.
The first step is a good set of requirements. I find several iterations and customer interviews are needed to arrive at a full and agreed set of requirements from which you can define the scope. Always look at what the project will deliver when agreeing scope, not how it will deliver.
I start by asking the customer these questions:
It took a while to stop members of the project team 'gold plating' solutions, but eventually they fell in line and now are custodians of the change control process. They have developed this mantra, "if it's not in JIRA it doesn't exist."
I'm interested to hear about others experiences and tips for managing scope.
Duncan
I equate project scope to an iceberg. There's the bit you can see (what the customer asks for) and the bit you can't see (the customer's assumptions about what the project will deliver that have not been articulated). As we know icebergs are a danger to shipping, and scope icebergs are equally dangerous to projects.
The first step is a good set of requirements. I find several iterations and customer interviews are needed to arrive at a full and agreed set of requirements from which you can define the scope. Always look at what the project will deliver when agreeing scope, not how it will deliver.
I start by asking the customer these questions:
- What is covered in the project?
- What is not covered in the project?
- How does the project look when it's finished?
- What are the benefits from running this project?
It took a while to stop members of the project team 'gold plating' solutions, but eventually they fell in line and now are custodians of the change control process. They have developed this mantra, "if it's not in JIRA it doesn't exist."
I'm interested to hear about others experiences and tips for managing scope.
Duncan
I love Duncan’s comment about the Iceberg.
I often think of Scope as being within the box (included in the project) or outside the box (not included in the project)
I think a good point with managing Scope is to include what is not included in the project. By stipulating what is outside the scope of the project, the customer is given that extra clarification on what they should expect, and also what they will not be getting.
I often think of Scope as being within the box (included in the project) or outside the box (not included in the project)
I think a good point with managing Scope is to include what is not included in the project. By stipulating what is outside the scope of the project, the customer is given that extra clarification on what they should expect, and also what they will not be getting.
-
begeland
kwalford-
I like that concept you mentioned - document in general what is not included in the box. Of course you can't document everything that isn't included, but you can certainly document those grey areas that probably come up as you were discussing and finalizing requirements. That documentation will serve as a great reminder later that those things are NOT included (as inevitably one or more of those items will be requested by the project customer).
Brad
I like that concept you mentioned - document in general what is not included in the box. Of course you can't document everything that isn't included, but you can certainly document those grey areas that probably come up as you were discussing and finalizing requirements. That documentation will serve as a great reminder later that those things are NOT included (as inevitably one or more of those items will be requested by the project customer).
Brad