How to Avoid Scope Creep in Project Management

Just over 10 years ago, I had considered leaving the banking industry. A friend had suggested that I consider programming as a career, as it seemed that my strengths and way that I preferred to operate would make a good programmer.

After careful planning, I resigned and enrolled on a 4-month full time programming course. The final of those 4 months was the practical element, where you actually had to deliver a programme that could function properly for a particular industry. The programme itself would be written in Java, and set up on an Access database.

As we would be working in a team of 4, the team met and agreed on different duties. Only one member of the team had Access experience, so part of his remit was to set up the database so that it could work with the rest of the programme that was to make an off the shelf package for independent retail stores. It had to have a built-in stock and till system, so that everything for the store would be linked. In order to ensure that everything worked properly, although only one of us would be working on the database, careful requirements needed to be set up so that it could work with the rest of the system.

The actual project was monitored throughout, and on the day that we finally presented our complete system for marking, the monitors mentioned that when it came to scope creep, they had never seen a project involving programming that included so little, and that everything was designed exactly according to plan.

For me, that was the first time that I had ever heard the term scope creep. While I could guess what it meant, I did ask just to clarify. Basically, it means how the scope of a project changes as the project is in development, away from the original goals set. The invigilator that answered explained that although other projects also fulfilled their requirements very often, because our group had chosen to add to the original assignment so that we could better display our skills, the actual scope we gave ourselves was not identical to the original assignment. As it turned out, the only thing that we had added was an extra log in screen. We had finished ahead of schedule, and so thought to see what else we could add in a few short days.

What was mentioned as being particularly impressive was the way that the database was so carefully planned, and designing it according to the plan meant that we never once had to meet about changing things. This we were told, is extremely rare. Too often projects - and IT development projects in particular - go over budget and over time frame because of scope creep.

So what causes scope creep, and how can you either avoid or manage it?

There are a number of different things that cause scope creep.

1. Poor requirements analysis is top of the list. What is the Project Vision? How well was that put together? Who all were involved in determining the vision? I worked at a company years ago that was using one system for the sales staff as a CRM system. They chose to internally add features and change the way that it worked. The owners of the company were delighted to present it to the sales staff when it was ready. Within one day it was found to be totally inefficient. It slowed the salespeople down so much that they were not able to make anywhere near as many calls as before. Not one person from the sales team had actually been involved in how it should work, what they would really like added etc., it was all done by the sales director who never used the old system. You need all the stakeholders involved in this, and users must get involved early on. Spending more time on this at the beginning will save lots of time and money later on.
2. Already mentioned above is getting users involved early. If they are not, you will later see where the flaws in the system are, and have spent time and money on needless things.
3. Ensure that the complexity of the project is not underestimated. I have seen projects where the individual programmers knew how difficult something was going to be for specific aspects, but nothing was conveyed to other people that those "fiddly bits" were so difficult. I have also seen people provide quotations to clients on behalf of their company without talking to those programmers and then both the time constraints and pricing were both incorrect.
4. Is there a lack of change control management? If you do not implement a system to control requirement changes, and this is being done by people all over the project, it can spiral out of control.
5. Are people needlessly adding value to the system? The project might have been brought in with one goal in mind. People might then see that it could add separate value elsewhere. This might well be the case, but is the extra effort and expenditure going to be worth the tiny amount extra that it offers in value?
6. Sometimes you can get stakeholders who will try to get something for nothing, asking for things that they know are not in the original scope.
7. Poor communication. Are people working on things without realising that another part of the project has already started looking at that item but not told anybody?

So there are a number of things that cause scope creep. What can you do to avoid it, or manage it?

• Do not be too hasty in setting the original requirements. Be thorough. As the old adage goes, "Measure twice, cut once." Even if this stage feels like it is taking longer than it should, it will save time and money later on.
• Get users involved early on, all the way through the project.
• Document the original requirements. All stakeholders should be involved in the sign off of the plan. If there are differences in needs, can you arbitrate now to identify either a compromise, or one chosen goal?
• Work out a process for change management. If a change is required, do you have a plan that allows it to be suggested, then revised and either given approval or rejected? If not, that is when things get done without approval etc., because of poor communication. Have you also identified who the people are that can authorise these changes? If the suggestion is from a stakeholder at the client, are they at a level authorised to spend extra?
• Set up a project schedule. Once you know what the project is to provide, you need to sort out what needs to be done in order to accomplish that, and then assign tasks. This schedule should link tasks to activities.
• Create both major and minor milestones. Allow and build in some flexibility, usually building in an extra 40-60% of time that people can predict tasks being done. This will accommodate any possible eventualities that delay things, whether it be weather, illness or any other hindrance.
• At this point, confirm the scope with all stakeholders. As misunderstandings can happen, it is better to go through what will be done and by when. Ask the stakeholders if it looks like anything they might have expected to see does not appear. That way, any misunderstandings are picked up early.
• When working with your own team, find out if all of their needs have been met. Do you need to provide anything for them to get the job done? This can be resources that they need, or new skills to be learnt.
• Within your own team, do you have a wide variety of experience? If working on an IT project, do not just have programmers. Do you have people who would understand how call centres actually work that could see how the software would be used, for example? Have specialists, certainly, but covering different things.

The Standish Group's CHAOS Summary 2009 stated that only 32% of all projects commissioned were successful, which means that they were delivered on time, in budget and with all the required features. If you want to avoid your projects being part of the 68% that miss in some way, put these tips into play, and you are going a long way to ensure that. That would look good for you and your business, and would keep earning you even more projects to work on. Finishing projects successfully is one very good way to ensure that you get more to work on!