Avoiding Project Scope Creep

If you are managing a software project, one of the most difficult things you are asked to do is manage the timeline of the project so it is finished on time. This task is often made more difficult by people who make requests that would normally impact the project timeline, but they require you to change the project requirements without changing the timeline. As a nice person, you try to allow as many changes as possible, but you have to remember who gets blamed if the project is late.

What are 5 simple ways to keep control of your project?

1. Requirements Documentation

You must document the project requirements to prevent scope creep. Interview the project stakeholders and the users to determine what they want from the project, as specifically as possible. Write everything and prioritize the requirements. Even if you can’t complete them all, document the requests and indicate why the are included or not in the project. It can take a long time to record everything the stakeholders request, but once you have captured all the requirements in a document you can share share that document so everyone can easily see read and understand what is (or isn’t) included in the project.

2. Change Control Process

So you have the requirements documented and published. As with anything in life, things change and the business may change how they want the project to proceed. You need a process for allowing stakeholders to make changes. It is unrealistic to believe that nothing will change. What a formal change process will allow is a controlled and managed process for people to request changes to your project.

A change control process is very straightforward. It starts with someone suggesting a change, it is then reviewed and approved or rejected. If it is approved it is incorporated into the project plan. Creating this process for your project means identifying  who is going to review and approve proposed changes, who will communicate the process to the stakeholders, etc. There isn’t usually a need for a formal change meeting unless you have a large number of proposed changes.

3. Create a Project Schedule

Use your requirements to create a detailed task list, and it should show all the requirements and how they will be achieved, in the form of tasks and activities. You should cross-reference your schedule against your current requirements document to verify you have not forgotten anything. Even after you have outlined the schedule, make sure you have planned for contingencies by knowing that things will always change and that means if you haven’t planned for change your timeline will be negatively impacted.

4. Stakeholder Scope Review

Never make assumptions with the company’s budget. You should always verify that the project you have documented contains all the correct requirements before you start spending development resources. What you think the project sponsor intended might not be what he or she meant, and you will know for sure if you are headed in the correct direction until they have read the requirements. Take the time to go back to your sponsor and share the written requirements documentation with them. You should also share with them your written project schedule and verify that all the elements they expected to see are represented in the task list.

Once the sponsor approves the project, schedule some time with each stakeholder and talk them through exactly what the project is going to deliver for them or their team. Show them the written plan and give them the chance to make comments. It is better for them to start listing changes now than weeks or months from now. This will be a good time to discuss the change control process, making sure they understand they can always request changes, what process they will be required to use, and what impact a change could have on the overall project.

Even if the stakeholder is too busy to review the documentation, make sure they understand what stage of the process you have finished and what happens next.

5. Project Team Engagement

After everything ha been documented and the stakeholders have approved the project, you still need a motivated team to make the project successful.Make sure you explain to the team what you have gone through to get them the documented project. Make sure hey know the change review process, and are comfortable with the assigned timeline.

Sometimes members of you project team will attempt to be helpful and will agree to minor changes without applying the formal process. You must explain to them that all changes must go through the formal change review process before they change can be approved.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.