Preventing Scope Creeping

While discussing scope creep during class I began thinking of a project that I was part of where the vary issue became the downfall of a relationship with one of our biggest clients. My company, an investment operations outsourcer agreed to take on a process (and the tool that went with it) in order to win a client relationship. I wanted to better understand what could have been done in order to prevent the disaster that we ended up with. I began researching scope creeping and I found a blog (http://blog.bidsketch.com/clients/preventing-scope-creep/) that contains what seems to be an easy 5 step process. I decided to go through each of the steps and see if we would have acted differently regarding each step.

Step 1 is to understand the outcome. This seems like an area we just dropped the ball on. For this process we understood what the client wanted as a result, but we didn’t understand why. If we understood the reason they were in need of this process we could have been able to offer up other solutions that would have been a much easier deliverable. At the time we already had a product that was comparable to what we took on from the client and would only require implementation to the platform rather than development of and integration of the client’s tool.

Step 2 is to be critical of your client’s Ideas. This is another area we did not perform well on. We simply took the client documentation of their process and began emulating it. What we should have done was to analyze their process and determine if that best fits our model. From there should have discussed changes to the process. Our clients come to us because we have standard procedure across that board that work well, in this case we lost sight of that.

Step 3 is to clearly define the scope of the project. For our scenario I think we did a good job of outlining what the scope of the project was. The issue is that the client decided to change the scope. The amendment to the scope was the lingering factor of whether we would continue the relationship or not. Having already invested significant resources to the relationship, we didn’t have a choice and agreed to change the scope. Because of the change we had to integrate manual procedures and caused errors and financial losses that ended up straining the relationship with the client.

Step 4 is to Price the project correctly. This would seem to be a good deterrent for scope creep, but in this case the project was one of those “Price in no object” situations. The client required the change due to regulatory requirements for expanding business.

Step 5 is to get it in writing. As part of projects, the client is required to fill out a project initiation form that details what they are for in terms of deliverables. This form would capture the scope of the projects. I think we could improve upon the form by addressing scope creep specifically in the document stating that we would require any changes in scope once the coding is complete to be addressed as a new project initiation form.

I think the 5 steps are helpful in addressing and mitigating scope creep risks. I think by using these steps in most cases we can avoid scope creeping all together, but it’s not the case in all situations. As we saw in step 3, even if your following certain rules scope creeping can’t always be prevented.

12 thoughts on “Preventing Scope Creeping

  1. Larry,

    I think these 5 steps would help eliminate many of your problems. Most of the times problems that occur during a project come from a lack of communication between PM and client. It seems as if communication should be simple, but there are usually so many variables that it makes it almost impossible to cover every point. The best run projects are those that take a deep look at all aspects of the project and really understand how they relate to each other. There will always be hiccups in any project, but effective communication prior to starting can help eliminate some of those issues.

  2. Scope creep is a very common issue during the phase of a project. It occurs more frequently when the project management team is dealing with a newer client that they are trying to satisfy and/or build a relationship with and when there is not a solid project manager that does not give in to out of scope tasks. During my time as a consultant, I worked on a few supply chain projects that involved newer clients and inexperienced project managers. Although it is important to exceed client expectations, it is also very important that the project remains on task with the SOW in order to meet the project timeline. Newer inexperienced project managers are less likely to control scope creeping as efficiently since they do not have the proper communication measures in place. Scope creep can be costly because it can result in the project manager bringing additional team support at their own cost to meet the project deliverables on time. It is essential that the initial agreed upon contract is followed and that the project manager is able to control any potential out of scope tasks by addressing them immediately with the client and/or creating an additional SOW to reflect the new scope changes. We had a few instances where additional work was signed off on through a contract and we were able to successfully complete the tasks at an additional cost. I think this systematic 5 step approach is a great guideline to have in mitigating scope creep.

  3. These 5 steps are helpful in avoiding a scope-creep. In some cases, you cannot completely eliminate scope-creep. The R&D projects are good examples of where the requirements are uncertain and risk of scope growth is really high. In those case, you simply have to use your best judgement and identify all the risks/opportunities upfront to avoid any downfalls later down the road.

  4. Great example Larry. I think I always end up paying the bills on the other end of the scoop creep! NU normally works with very experienced consultants and project teams. As Maks notes, the vendors we normally work with generally issue additional SOW to reflect the new scope changes. As NU groups change and adjust the requirements the bills grow. I work in the area that pays the bills on these projects. I see the expanding project bills less when there is a PM on our end also working on the project. Having an in house PM also working on project and implementations means projects tend to start with a well defined scope and keep things in line.

  5. I have experienced scope creep in projects within my organization. Ideas seem to lead to other ideas and it takes real discipline to avoid scope creep that can derail the original product. I believe part of the struggle is that the world moves so fast that new ideas and options make their way into many projects. The key to me seems to be differentiating between changes that add value to the project from those that change the scope; it is a small but important distinction. Steps 1 and 2 remind me of the importance of offering clients solutions to their problem versus simply doing what they ask you to do. They are hiring you for a reason; they may not have the expertise to do it themselves. Listening early in the project and understanding their true needs will save time and money at the end of the project. In step 3, it is important to communicate the impact of the requested changes to the client so they can make an informed decision. Step 5 ties into this in that you want to confirm understanding in writing. I

  6. I find myself having problems with Step 2 ‘being critical of clients ideas’. Especially in sales, so much energy goes into closing new clients. When you finally get a new client to assign you to a project, you do not want to kill the fire. I do not know how many times I have told a client ‘no’ on something and then they refute, “If this is not what you are able to provide, we will go elsewhere.” Usually this is just an empty threat but it is this kind of push and pull that hinders open honest communication with clients. Even if the suggestion is to the clients benefit, saying ‘no’ or being critical needs to be handled with finesse.

  7. I have witnessed scope creep for different reasons. Sometimes you get clients that just want more and more as you come back with each deliverable. And most of the time you just don’t get step 1 and step 2 exactly right which of course turns into a domino effect to all other downstream steps.

    I have found that extra time spent in steps 1 and 2 have paid big dividends in future steps. In my case, we have exhausted the prototype / mock processes early and often in order to nail down exact requirements for all of the client’s needs and wants that we both feel should be inclusive.

  8. Scope creeping is one of the major issues I have come across. Your 5 steps are a great summary of how to prevent scope creeping. In line with your 5 steps, it is critical to really understand the final outcome. In my experience, it is important to have final understanding of the deliverable. We often find that the requirements are not finalized properly meaning not every little detail is considered. If the requirements are not captured from the beginning as further analysis is done along the way, scope tends to get bigger. Another common scope issue is that the more people learn about the project the more they want to drive their own agenda. Therefore, new scope is introduced with sometimes the expectation of the same deliverable date. In order to prevent scope creep, it is critical to ensure everything is captured up front, stakeholders are all involved from the beginning and correct costs are captured. As one of the points you bring up, it is important to have it in “writing” because somehow people tend to forget things 🙂

  9. I agree with a lot of the responses to this post, scope creeping is something that a project manager has to be mindful of going into a project. The team, as well as the third party client in this case, has to be proactively cognizant of this as well in order to stay on track. It might be because my background doesn’t relate to the industry in the given scenario, but I found it hard to follow where the scope creep happened. However, the 5 steps that were touched on were really useful points. Steps 1 and 3 are critical to the project at hand. Both sides of the party needs to be clear and concise on the mission in order for both to have the same direction and outcome desired. Step 2 is important in that, in order to be fair, professionals have to understand that change is expected and adjusting and adapting to it is just part of the program to be successful. The last 2 steps to me go hand in hand and should be critically routine in consultative circumstances like this. Great post Larry, and great discussions all around.

  10. I work in IT. In IT there are two popular projects styles- waterfall and agile. I have noticed that scope creep is more common in waterfall style projects and less in agile projects. Waterfall projects have long implementation cycles compared to agile which have usually 3-4 week sprints or deliverables. The advantage of agile is that the feedback to the customer is constant and the task is broken into smaller and manageable chunks. What doesn’t fit in one sprint gets taken into the next one. So there is almost negligible chance of scope creep. In waterfall approach, the feedback to the customer is less frequent , hence the client might point out missed requirements or new functionality that client feels is required to catch up to their competition.

  11. Scope creep is definitely an issue of major concern at the company I work for. I think that Step 3 is by far the most important out of the 5 steps when it comes to scope creep. Nothing defeats scope creep like an extremely detailed, well thought and defined scope. It is very important that a project scope is shared and analyze with all parties involved on the project as well. Understanding of the scope, not only yourself but also for, yours client, a manager, another company, your fellow co workers, etc.

    Another good point when it comes to scope creep is when you are working for a new client or trying to impress your manager, etc. You want to go above and beyond the call of duty to create a deliverable that “wows”, but in the process ruin your schedule and budget. Scope creep should always be at the forefront of concern when it comes to any project.

  12. In my experience, these 5 steps are exactly what should be done to avoid changing scope, but sometimes it’s unavoidable. The needs of the client may change in the middle of the project, either due to a changing business landscape within the client’s organization, due to regulatory changes, or something else. For that reason, it’s difficult to completely avoid having scope changes, but as you mention Larry, it’s critical to have a Changes Management process which will be used when a requirement is identified that is different than the original agreement or project charter.

    We use a formal Change Order process at my organization. The key to the success of that process is to have a clearly documented scope (with specific deliverables) and outcomes to begin with. From there, it’s more simple to identify when a change has come up and the Change Order process should be applied.

    The challenge I have seen in the Changes Management space is that often a project team member will come across a change, but if they are not familiar enough with the original agreement or with the Change Order process, they may simply commit to the change and proceed forward with it (i.e., scope creep). For this reason, I’ve found it’s important for the Project Manager and entire team to be well-versed in the scope of the project, how to identify a change, and what process to use after a change in scope is identified.

Leave a Reply to jitesh598sum14 Cancel reply

Your email address will not be published. Required fields are marked *