In my last post, I outlined “10 Ways to Manage Project Scope”. Those weren’t, of course, the only 10 ways to manage scope and just to substantiate this argument, here are 10 MORE ways to manage project scope. I hope you will find them helpful.
- Have a good customer. Ok, we’ll this might not be something completely within your control*, but if you’re fortunate enough to have a ‘good’ customer, this will go a far to help you manage scope on your project. How? By having the customer work with you and your team to do their part to help manage the scope of the project, rather than having them (at least seem like) they are working against you in this pursuit. Why would they do this? Because they understand that managing scope is a key tenant of project management/solution delivery that is very much interrelated with time, (schedule), cost (budget) and quality so it is in their best interest to do so. How would they know this? You will educate them on these sorts of things in the early stages of the project (if not in pre-project discussions). *So, maybe having a ‘good’ customer is in your control after all!
- Have a good support system. The only thing better than having a good customer is having a good support system. This could include having a team that supports the scope management process by doing a good job when collecting requirements and documenting assumptions to define the scope baseline that the scope will be verified against, and to understand the dangers of things like scope creep and gold plating. It could also include having the support of program managers, functional managers and PMOs that will support you in your efforts to manage scope – which could mean ‘pushing back’ with the customer when they want to add scope without being willing to accept adjustments to those interrelated items as noted above (time, cost, quality).
- Manage the requirements. In my last post I noted a few points related to capturing and agreeing upon some requirements as a best practice for managing scope, but that’s not where it stops. The management of the requirements is (or should be) a process that extends beyond the initial ‘requirements’ phase. While this process may differ across methodologies, having a process to ensure that requirements are updated as more details become known is vital to ensure that the team is working from a set of blueprints that reflect the current scope of the project. Further to this, the requirements management process should also ensure that the updated requirements are reviewed and signed off by all necessary parties – from the clients and stakeholders to the teams and individuals on the implementation team.
- Define success criteria. As part of the process to define the scope of the project, you should also define success criteria. Basically, define – in as detailed terms as you can – how you will know when you are done. Review this with team and the customer and ensure everyone agrees on it. Ideally, you will be able to define success criteria at not only the project level, but at the requirement level as well.
- Acknowledge milestones. Following on the point on definition of success criteria above, you can manage scope by acknowledging milestones. Acknowledging – along with the execution of other related processes and deliverables such as phase-end/toll-gate or deliverable (i.e. requirements document) reviews – can serve to ensure that any further effort related to a now complete phase will cease (assuming the scope for the phase has been verified). While most projects will have phase level milestones such as those noted above to transition from one phase (i.e. Planning) into another (i.e. Development), you can also build in mini-milestones along the way within the phases as a way to ensure that once a feature has been completed (based on defined success criteria) no further effort is put toward it.
- Don’t swap resources. While the ideal resourcing scenario is that you have team members that are dedicated (only allocated to one project) and are able to focus all of their time and energy toward your project (assuming the budget can support it) – working on multiple, concurrent projects is often the reality in the consulting world. As this much is understood, it’s not really a concern from a project management perspective. Where you do end up getting into trouble is when resources end up having to get swapped out, when other projects run late or other commitments take priority. While on paper, switching a developer/designer/’insert other role here’ with a similar skill set with another when a conflict arises seems easily done, doing so adds risk to the project in the form of additional ramp up that may be required, inadequate knowledge transfer and a lack of understanding of the project vision and objectives that would have been obtained having spent time taking part and contributing to earlier phases and deliverables.
- Watch the Burn. Over the course of the project, the project manager will be tracking the ‘burn rate’ on the project, to track how quickly the budget is being consumed and on which phases, work packages, tasks etc. While this relates more to cost management than scope management, if tracking has been set up so that you’re able to track at a work package or task level, keeping an eye on the burn rate can provide visibility into where additional scope may have been added where it shouldn’t have been. An example might be where a feature has already be completed yet there is still being time logged against it (perhaps by a resource that has been recently added).
- Educate the client on how to properly verify requirements. As part of your efforts to ensure the client is educated on the processes that will be used to plan and execute the project, it is important to ensure they understand the role they will be playing. One aspect of this role – and an important one if you want to ensure your project gets completed – is the expectations around how they will verify that the requirements have been met. Depending on the methodology, this may be an iterative process that happens several times over the course of the project, or it may happen at the end in a final UAT phase. Either way, it will be important that the client resources assigned to verifying the requirements, fully understand the requirements so that the time allocated to this phase(s) is used wisely. Further to this, they should understand the objectives of the requirements verification process which is, as the name would suggest, verify that the requirements have been met – not write new ones. That said, if an objective of having the client review and/or test the solution to verify the requirements is to look for ways to further enhance the solution, that is ok too, as long as it has been agreed upon as an objective and that you have a process in place to handle changes.
- Illustrate the impacts of scope changes. A major part of managing scope is having a process for managing change. It’s not about eliminating changes, since quite often at the beginning of a project, ‘you don’t know what you don’t know’ and as such changes are expected. That said, as a precursor to outlining the actual change control process, and the execution of it for every change that comes up, you should educate your customer on the concept of the ‘triple constraint’ (also referred to as the ‘iron triangle of project management’) (stay tuned for a future blog post on this) that explains the interconnected nature of scope, time, cost and quality. You can do this using tools and applications you are probably already using on your project such as MS Project or Excel, where you can illustrate (visually, in a status report, meeting or screen-share session) how the addition of a new feature or extra complexity in a previously scoped feature can push out the schedule or increase the budget beyond what might be is acceptable.
- Go Agile. In my earlier post, I noted that developing and validating iteratively was a great way to manage scope and build trust. Well if you think this is the way you want to go, why not try an Agile project?! While this is definitely easier said than done, since there are a lot of factors that need to be in place for an Agile project to be agreed to and to succeed (outlining all of these would certainly be ‘out of scope’ for this post), using an Agile methodology is certainly a good way to go when the requirements (that will drive the scope) of the project are largely unknown, due to the manner in which Agile handles the balance between requirements and development and responding to change.
So, there you go – 10 more ways to manage scope. Many of them relate closely to one another as well as to the original 10 strategies I posted [here], and of course not all of them will be possible to implement on every project. That said, hopefully they will give you an idea or two that you could use on your projects.