What are some of your best practices for managing project scope

This forum is for members to share and gain knowledge of Project Management. Got a question about project management? Need help with a problem? Wish to offer tips and advice? Post here.
Post Reply
User avatar
begeland
Expert Member
Expert Member
Posts: 173
Joined: Sat 09 Mar 2013 11:46 pm
Location: Las Vegas, NV
Contact:

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
User avatar
dhaughey
Site Admin
Site Admin
Posts: 462
Joined: Sat 19 Dec 2009 4:39 pm
Location: London

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:
  1. What is covered in the project?
  2. What is not covered in the project?
  3. How does the project look when it's finished?
  4. What are the benefits from running this project?
Once the project starts all changes are logged in our JIRA ticketing system and reviewed by senior stakeholders before any scope change is made. This makes sure there is senior stakeholder recognition and agreement of the impact each change will have on the 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
User avatar
kwalford
Global Moderator
Global Moderator
Posts: 301
Joined: Thu 08 Dec 2011 1:34 pm

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.
User avatar
dhaughey
Site Admin
Site Admin
Posts: 462
Joined: Sat 19 Dec 2009 4:39 pm
Location: London

Thanks Kit,

The box analogy is another good way of thinking about scope.

Duncan
User avatar
begeland
Expert Member
Expert Member
Posts: 173
Joined: Sat 09 Mar 2013 11:46 pm
Location: Las Vegas, NV
Contact:

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
Post Reply