5 Ways to Avoid Scope Creep
A project manager was working on a small, three-month project to deliver a new piece of software. After a couple of weeks, the project sponsor decided to add some new requirements. The project manager included them. A bit later on, the sponsor made some more changes, and asked for some new functionality. Again, the project manager said that it was no problem. The changes were made. Towards the end of the three months, the sponsor went to the project manager and complained that the project was behind schedule. The project manager tried to explain that all the changes meant that there was no way that the software could be completed to the original timescales. The sponsor was not happy and the project manager was taken off that project because he was “too slow”.
Sound familiar? I hope not! Scope creep is what happens when changes are made to the scope of a project without any control. Of course, changes happen to projects all the time, and it is very rare for a project to end up delivering exactly what was asked for on Day 1. However, changes without control mean that the project manager has very little chance of being able to keep on top of the project work and manage the project effectively.
Scope creep generally takes the form of new requirements being added once the project has started. Typically, these are not properly reviewed and the project team are expected to deliver them with the same resources and in the same time as the original scope. On the other hand, you could end up with a project with lots of approved, considered changes, that never ends because every time you think you have finished a new requirement arrives in your inbox and you have to make more changes.
Here are 5 ways to stop scope creep from crippling your project.
1. Document the Requirements
The single most important thing to do on your project when it comes to scope creep is to document your requirements. Talk to all the project stakeholders and work out exactly what it is that they want the project to achieve. Write their requirements down. You may have to manage some conflicts – if one stakeholder wants their new website to be blue and another stakeholder wants it to be green you will need someone to arbitrate and make a final decision. Equally, you may have to prioritize some of the requirements as it may not be possible to do them all.
It can be quite time-consuming to get round all the stakeholders and record everything they say. Once you have done so, capture all the requirements in a document. Then you can share this in your online file storage so that everyone can see it easily.
2. Set up Change Control Processes
Your requirements document is the starting point, but what happens when someone wants to change something? It is unrealistic to think that nothing will change. What you are aiming for is managed, controlled change on your project and for that you need a change control process.
A change control process is very straightforward. Your project management software may have change management functionality, so you can always use that. Essentially, someone suggests a change, it is reviewed, approved or rejected and if it is approved, then incorporated into the project plan.
Setting up the process for your project really means thinking about who is going to review and approve changes. You could discuss them with your project sponsor or at a team meeting. You don’t need to arrange a formal change meeting unless you think you will have a lot of changes and that it will be easier to sit with your colleagues to review them all at the same time.
3. Create a Clear Project Schedule
Use your requirements to create a detailed task list. The project schedule is the result of knowing what your project will deliver, so it should show all the requirements and how they will be achieved, in the form of tasks and activities.
You can cross-reference your schedule against your requirements document, just to be sure that you have not forgotten to include anything.
4. Verify the Scope with the Stakeholders
It’s also important to check that you have properly understood the requirements. What you think the project sponsor means might not actually be what he or she means. Often people talk at cross purposes without realizing it, so take the time to go back to your sponsor and share the requirements documentation with them. You can also show them your project schedule and ensure that all the elements they expected to see are represented in the task list.
You can do this with all the other stakeholders too. Schedule some time with each stakeholder and talk them through exactly what the project is going to deliver. Show them the plan and give them the chance to comment. You may find that they change their mind, even at this stage, but it is better to know now than to carry on with your project and find that they bring you different requirements in a couple of months.
You can also use these discussions to talk to your sponsor and stakeholders about the change control process. Explain how you will manage changes on the project and what approval you will need from them in order to proceed. This is a useful moment to remind them that they can have pretty much whatever they want – if they are prepared to pay for it and for the project to take longer if they include new requirements!
5. Talk to the Project Team
When your project stakeholders are happy, you should also make sure that your project team is as well. They need to know about the change control process and how it will affect them. Sometimes project team members will want to be really helpful and they will agree to changing something without using the formal process. Use your conversation with them to explain that they cannot say yes to changes without the change being approved. If they want to help a stakeholder, the best thing that they can do is to explain the process and offer to help with documenting the change.
Scope creep can be a real problem on projects, especially when the team and the stakeholders don’t understand the impact that changes can have on the resources, the budget and the schedule. Fortunately, it doesn’t have to be a major issue if you are clear about the initial project scope and you carefully manage changes during the lifecycle of your project.
Here are some ways of applying good PMO governance to some of these 5 ways:
1. Use a short concise document. NO ONE will read a 30-100 page Project Plan. Be clear on In Scope and just as importantly Out of Scope items. Lay out In Scope items on a spreadsheet like a WBS with milestones, dates, durations and times. Identify if any or NO slack time in case of run over or possibility to allow controlled changes.
2. An effective Change Control process also must focus on impact, added time to schedule, added resources and funding, possible capital costs for hardware, software, software licences, effects to other softwares or programs, Have change evaluated by all stakeholders and discuss impacts, Risks and overall project jeopardy of the added change. If approved communicate to all stakeholders and sponsor of added Risk or possible jeopardy(s).
3. Do a face to face working session with all stakeholders and perform a WBS work shop to shell out all the milestones and all tasks. Especially ones that require a delivery and then a hand off to and from other stakeholders. Define work durations, what can be worked on simultaneously, what must wait for input or hand off. Make sure each stakeholder is happy with their deliverables and start and finish dates and EVERYONE knows the Final delivery date and agrees and buys in.
4. Good governance above I agree. Also ensure everyone is on board with In Scope and OUT of Scope items and the governance to be used for ALL Changes.
5. Communicate regularly and consistently right to the Final Due Date. Make sure your stakeholders/team mates participate in these meetings. Then weekly or bi-weekly advise primes and sponsor of status, any Risks in RED status, any changes that affect delivery date, funding , resourcing.