Let’s talk about scope.
Not that kind of scope. Project scope! The “what’s in”, the “what’s out” and “how you are going to manage it” kind.
In my previous post, I outlined the 10 Project Management Knowledge areas, one of which was ‘Project Scope Management’, which the PMBoK (5th Edition) defines as,“includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully”.
Well that sounds easy enough, right? So, what are these processes you speak of? They are:
- Plan Scope Management – the process of creating a scope management plan that documents how the project scope will be defined, validated and controlled.
- Collect Requirements – the process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives.
- Define Scope – the process of developing a detailed description of the project and product.
- Create WBS (Work Breakdown Structure) – the process of sub-dividing project deliverables and project work into smaller, more manageable components.
- Validate Scope – the process of formalizing acceptance of the completed project deliverables.
- Control Scope – the process of monitoring the status of the project and product scope and managing changes to the baseline.
While all of the above processes are important when it comes to scope, the one that seems to get discussed the most in one form or another is the ‘control scope’ process. In fact, while ‘controlling scope’ is the context in which the conversation is often framed, the processes – as you’d expect – relate very closely to one another, so doing a good job in one area will often yield dividends further downstream. For example, if you do a good job of collecting requirements to establish what the scope actually is, this will help you when evaluating potential changes to the scope during the project, and when validating that the scope was met before you finish.
Also, still on the subject of ‘controlling scope’, depending on your chosen methodology, the process for collecting, documenting and managing the requirements that will largely drive your scope may not be following a traditional waterfall type of process where all requirements are known and documented prior to development. Understanding this, the notion of ‘controlling scope’ should be something that is balanced with having processes in place that will allow more detailed requirements to become clear as the project evolves, to ensure that the developed solution is addressing current and relevant requirements for your customer.
So while processes should always be tailored to the project, as no two are every completely alike, here are 10 ways that you can manage scope on your projects.
- Understand the business drivers, pain points and customer objectives for the project. Establish a shared vision. Getting everyone on the same page for what is it you’re building and why will be the foundation for all of the decisions you make on the project.
- Take the time to define and agree upon requirements. It’s always tempting to want to jump directly into building the solution, but take the time (regardless of your methodology) to agree on some requirements first.
- Establish a scope baseline. Acknowledge that changes may need to occur but agree to evaluate them against the agreed upon baseline.
- Ensure all key stakeholders, users and SMEs were involved in the requirements process. If any key stakeholders were left out, they could emerge later and add scope that could have impacts on the project.
- Ensure that due diligence was performed when defining scope and associated estimates and timelines. Make sure the team understands the complexities and effort for what you’re now on the hook for delivering. Ask questions. Document assumptions. Review with the client to get on the same page for whether you’re building a ‘Cadillac’ or a ‘Pinto’.
- Break the work into manageable pieces. If your WBS has a task that reads something like – ‘Feature 1-development: 80 hours’; this is a WAG, not a proper estimate, so you should take the time and energy to figure out how to decompose this work package into smaller tasks that can be properly estimated, otherwise accept that there is some risk in this ‘estimate’.
- Acknowledge that scope creep can kill a project (and beware of Gold Plating). Get agreement from the team from the client that sliding in even seemingly small changes has the potential to impact your project. This could include things that the client is asking you to add in, as well as little things that project team members might try and add in, in hopes to add some extra value (‘gold plating’). In the latter scenario, while these types of things are often well intended, it’s often the additional little item that will be the thing that results in an issue down the road.
- Develop and validate iteratively. While this may depend on your chosen methodology, showing progress will go far to allow the custom to validate parts of the solution along the way (thus reducing risk) and will also establish trust.
- Maintain a ‘wish list’. As change requests are raised and evaluated, maintain a ‘future enhancements’ list of items that weren’t able to be added to scope for the current release, as candidates for a subsequent release.
- Have a change control process. Last but certainly not least, establish a process for addressing changes. How to raise a change, how to evaluate/assess impact and who is responsible for approving or rejecting it. The change control process should allow time for the impact analysis itself, since even the process of performing the assessments (particularly if there are many changes being requested) can have impacts on the project, as team members need to shift focus from delivery of in scope features to assessment of changes.