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.