In the series of activities that make-up the basics of Project Management, Scope Management is a subject that gets alot of attention when things go wrong. With all of the “flavors” of Project Management these days (Scrum, Agile, traditional, waterfall, RUP, CMMI, etc) the basic tenets of any PM methodology are the same – help remove risk, ensure optimal performance and deliver the project you’re chartered with managing. The PM is accountable for ensuring the project’s scope is accurately accounted for and where changes occur the proper steps are taken to manage the scope.
Scope Management is the practice of defining what the project is supposed to deliver and what areas the project will not attempt to address. This is the fundamental component that separates projects from operational work. The reason that projects can fall behind schedule or miss the expectations of their customers primarily lies with inaccurate scope development or management. This uncertainty doesn’t just lead to project impacts with schedule, budget or team – if left unchecked this uncertainty can impact the client’s confidence in the team, or impact the team’s morale.
Properly managing the scope of a project begins with defining the scope in the beginning stages of the effort. The Customer and Executive Sponsor come to some agreement as to what the project will look like. At this point, the PM is accountable for working with the Customer and the various stakeholders involved to validate the scope is indeed achievable, and whether it is achievable within the time, money and resource constraints that were initially conceived.
After the scope has been defined and validated, scope management takes on the monitoring the tasks and activities of the project. That process seeks to confirm the project is focused on the scope, just the scope and nothing but the scope. Whether you are in a traditional or agile track at this point isn’t a concern – you’ll just focus on different constraints. In a predictive/waterfall approach, there is only so much money and resource time to go around – the task at hand is to make sure of the following:
- The Project is working on the scope defined
- That the Project isn’t working on other elements that are relavent and even important, but outside of the scope of this effort.
- When scope elements are being worked on (from item #1) we watch to make sure that enhancements or things that the team feels are critical but aren’t in the scope are guarded against without amending the scope of work (scope creep or gold-plating).
In an agile/adaptive approach, you approach the question of scope as a matter of timing. Because the project (or feature roadmap) is constantly in flux, you and your team are focused on what’s coming up on the radar next. The client representative makes decisions based on the current needs of the business/customer and changes the priorities/scope as they need to. Here, scope management is based on the process of asking questions about priorities and working with the team to ensure that infrastructure components (keep-the-bits-flowing code) are factored into the scope.
When scope changes (and it always does) the response should consist of a brief analysis of what change is requested and what impact it will have on the overall project. The customer (whether the end client, a business customer or other project “customer”) should be the one who determines whether the change should be pulled into the project, slated for a future release or shelved for future consideration.
The scope of a project is the heart of why some projects are in trouble from the start and why some defy issues and risks while they quietly move toward a successful delivery. Give the Scope Management aspect of your project a second look – see where some extra attention defining, managing or amending the scope of your project could enhance your results.