5 Steps to Manage Scope Creep in Projects, especially SharePoint Projects

While defining requirements for any project, you will run into scope creep. You get talked into adding little bits of functionality because “It shouldn’t take anytime.” Then you end up with an additional 900 requirements that “shouldn’t take anytime.” This happens A LOT in SharePoint projects, because SharePoint is so easy (according to some). If you don’t get a grip on this early in the process, you will run into this….

SCOPE

You are hired to build this within a specific timeline and budget

SCOPE CREEP

While defining requirements, the project morphs into this, but has the same timeline and budget

SCOPE SPRAWL

As you build, the requirements keep rolling in. Now people want this within the same timeline and budget

Here are 5 steps to manage scope creep before it becomes scope sprawl…

1.  Figure out what you want to accomplish

• Clearly define what you want to see at the end of the project
• If you want to save time or money, figure out how much time and money you are spending now
• How much do you want to save? Pick a number or percentage. Example: We want to save 30 minutes per transaction. We want to reduce repair costs by 3%.
• If this is a new process or solution, figure out what the CEO wants to see
• All requirements need to map back to these decisions

2.  Rate requirements

• All requirements should map back to what you want to see at the end of the project
• Rate requirements on three things:

1. Relevance to project end state – Is this requirement needed to reach the end state? Would this requirement make the end state better? Would this requirement make the end state perfect?
2. Effort – How much time and money with this take? Which resources do we need to complete this requirement?
3. Other Systems – Will meeting this requirement make changes to systems not currently involved in the project? The more systems we touch the more challenging it will be to meet the requirement. Was changing these systems part of the original scope?

3.  Next Version

• If a requirement is not integral to the end state, the effort would be too great, or would touch too many systems, consider making it part of the next version or update to the end state

4.  Sign Off

• Get sign off from the sponsor before the build. Very surprised at how often this doesn’t happen in SharePoint projects
• Understand that even though you have sign off, there will be changes

5. Share

• When there are changes requested, share with the rest of the team
• Run the request by the sponsor after clearly defining relevance, effort and effect on other systems

What steps do you use to manage scope creep? Add them to the comments below.