How do you prevent scope creep on a complicated IT project?

I think it’s first very important to differentiate between scope creep and change. Change itself is inevitable but scope creep is avoidable.

The interdependencies that Mark pointed out are often called the project management “triple constraint”. Generally scope, schedule, and budget are the three components in this triangle and a change in one area requires adjustment of the other two.

Scope creep is not simply an increase in the scope of a project. Scope creep is when changes to the scope of a project are not identified as such and the other constraints are not adjusted accordingly. The main reason this occurs is because scope has not been explicitly and clearly stated during project planning.

Project managers can eliminate scope creep form their projects by taking the following steps:

1) Clearly state and document project scope and have the customer/client sign off. The statement of work (SOW) should be very clear and as detailed as possible. Ambiguity and obscurity in this area leads to misalignment between deliverables and expectations.

2) Strictly and consistently apply the change management process. All change requests should be documented, reviewed for accuracy by all parties, and approved by all parties. Due diligence in this area is crucial.

Change does not have to equal scope creep.

Preventing scope creep is not always possible often times one needs to be satisfied with limiting it. My experience has found that scope typically increases because:

• business processes change
• customer expectations change
• inadequate requirements gathering
• IT project process

You’d notice that the first two have an element of time. Projects that drag on will increase the like hood of scope creep. This is why I like agile development and lean business process methodologies. It addresses all the above issues. This is optimal where the customer comes with the budget. Tight iterations insure customer validation/alignment with expectations. The project is considered “done” when the solution has the feature/functions at a quality they desire. The agile approach does have some risk when the project is funded by IT but directed by the business – as the business will never consider it done. In these instances IT should solicit inputted from the business subject matter experts (SMEs), but own the project scope.

Denouncing scope creep at a project kickoff meeting is fine...but may not help people grasp *why* it's something to be so aware of.

I've found that spending a little bit of time up front with a project team around understanding the 'three project levers' can do wonders for keeping things contained.

The concept is quite simple:

1) there are three project levers: scope, resources, and time
2) as one lever is adjusted (or proposed to be adjusted) it has impact on the others

For example, if you ask for more scope, don't expect the project resources and calendar to remain static. If you want to cut project resources, don't expect scope to remain static. If you need to bring in the calendar....you get the picture.

While it seems quite elementary, I'm always surprised by how few people remember these basic principles.

If your team understands these basics and knows how scope, resources, and time are ranked in order of importance on the project in question, you will face a lot less chatter about 'hey, let's add x, y, and z' to the mix.

There is no such thing as scope creep in Agile methodologies. There are only new iterations. It might be the driving factor to switch to Agile. I embrace what you refer to as scope creep because it means there are constant cycles of features being developed and enhanced and the idea of a big release date and then slipping into maintenance mode is dead. Time to market is faster, more features get implemented faster, and you are not late to market because the first 6 weeks of a project was spent in requirements and specs and arguing about creep.

I think the key here is that it is a 'complicated' IT project. In a simple IT project the two techniques Mark and John outline would be effective in handling most scope creep challenges.

To recap:

1. Mark outlines the project management “triple constraint” methodology. Certainly it’s worth understanding that changing one ‘lever’ effects or impacts the others.

2. John outlines the importance of properly setting expectations from a SOW or sign off process and ensuring the process is handled in a professional manner.

My answer:
The single biggest reason for scope creep is ‘unknowns’ and lack of understanding from the beginning. In IT especially this is a challenge. Most requirements aren’t well defined and there is no such thing as a truly ‘complete’ requirement set on project initiation (where scope expectations are often defined).

In ‘complicated’ IT projects you are dealing with more unknowns and significantly more complexity. As a result of this if you really want to PREVENT scope creep from happening then you have to use a methodology that encourages and embraces an extremely iterative approach to IT projects. The more iterative you are (and the shorter your iterations) the more effective you will be at preventing or reducing scope creep.

There are tons of resources out there that introduce PM techniques that allow for an extremely iterative process (the simplest one would be a 100% time and materials contract). Here are a few methods I use in practice for SharePoint projects.

1. Never provide a single estimate (also in my mind a ‘single point of failure to meet expectations’).
In EVERY SOW I write I provide both a low and a high estimate on each aspect of the work. In many situations a client requires a single number so I do simple math to provide it (or many clients choose the higher number) and it ensures that from the beginning the client (or involved parties) understand where my numbers come from. If you give a single number it gives no information on how ‘confident’ you are with that number. If I give a range of 1-100 hours on a task it means I am pretty uncertain as to what the task is, or the dependencies of that task. If instead an estimate of 8-16 hours is given you can see a greater level of confidence in the estimate. (I use many other techniques as well. In the past 23 projects I have delivered ‘under budget’ or under my estimates.)

2. Don’t rely on a single SOW or ‘all encompassing’ expectation setting document.
Often even for small Intranet projects I will break the work into many SOWs and provide a summary of the SOWs to the client. This way when we get into any confusion as to what should be in scope I don’t have to negotiate or go back to a giant vague SOW (or complex one) and instead can just target the SOW that relates to the work we are doing. Making the process of redefining expectations or handling change requests much easier. It also often encourages a “don’t write this yet if it isn’t ready” mindset compared to the guesstimating that people do with larger SOWs. (The smaller collected ‘requirements’ and tasks are – the more iterative you can be – the chance of scope creep is lessened.)

3.Don’t forget cost and alternatives.
If it’s a 1 dollar requirement who cares? If it’s a 1 million dollar requirement throw up the stop sign and explain why. A big ‘issue’ with scope creep is cost. So if you can give a lower cost alternative (that isn’t quite what they want, but satisfies the underlying requirement) offer that instead. Often this might still be a change in scope, but it may be so minor that it is a non-issue.

These are all obvious, but it never hurts to give extra examples. I do honestly believe though that the only way to really prevent it is to have extremely small scopes with short iterations. This way the interval is short enough they won’t mind waiting for the next one, and the scope is small enough that setting and managing expectations is not complicated or challenging.

Scope creep is inevitable because in business change is constant, pervasive and often permanent. Regulations, compliance, productivity need, accuracy needs, margin pressure, new products, new markets, and global economic conditions all fluxuate and demand a change in how business operates. Complicated IT projects are more susceptible to scope creep because of their complexity.

Our own projects, delivered in a matter of hours, have scope creep. Fortunately, the creep happens after the implementation and use. The Operations group is refining their needs and able to find faster and more accurate ways of performing the transaction. Changes in process, data and technology always keep the scope creeping along. Complicated IT projects take longer than a matter of hours and over the course of the months requirements change.

It would seem the best strategy to address scope creep isn't to attempt to prevent it but rather to align with it.

Scope creep isn't evil and in many occasions should be encouraged. Just because you couldn't define all the requirements upfront and find they are starting to emerge as you mature through the lifecycle is something that should be embraced.