The Scope Creep Thief

Managing Scope Creep

Photo from Dailybhaskar.com

Like a thief in the night, scope creep will come in through the window when least expected and steal your time, resources and project budget.  Being prepared to manage the aftermath of the thief’s visit is important for every project manager.  I have experienced the scope creep thief and managed it through it with the help of my design team mate; however, I have also learned that we could have been better prepared and done at least one thing that could have minimize the effects of the thief.

Project Overview

The original scope of the project was to design and develop tools for Chef’s to cost their recipes, determine yields for ingredients and the summarized analysis of the overall costs of menus that would be part of a lesson that was also under development.  The expected outcome was to provide a methodical approach for Chef’s to more accurately cost their recipes and menus.

Scope Creep

Three months into a six month project the tools had been designed, developed, reviewed, tested and approved by three subject matter experts and two sponsors.  Changes had been made during this time period before what was thought to be the final was approved.  When the final tools were reviewed with key stakeholders, a red flag was raised with reference to an existing tool that had similar information and had been previously approved by the same sponsors and was supposed to be used by the same subject matter experts.  

The stakeholder determined that the lessons should include instructions for the using the existing tools and then what parts of the tool are used by the Chefs.  The target audience for the existing tool was mid-level management; while the Chef’s were not included in this target audience.  So, it would require a separate lesson that was not part of the original scope because the tools was for a different target audience and the Chef only had a small portion to complete.

Due to the red flag and stakeholder’s requested change in direction, the tools design project had to be put on hold.  Because of the size of the existing tool and since it included other elements that weren’t required to be completed by the Chef, but higher levels of management, the tool was massive and most of it did not pertain to the Chef.  In addition to the focus of the tool, the needs analysis and subject matter experts, provided evidence that the tool was not useful to Chef’s and not being used by Chef’s. 

Over a period of two weeks, design resources focused on the feasibility of meeting the request of the stakeholder versus the original project scope and expected outcome.  Both tools were reviewed and analyzed against the expected outcome.  It was found that request would not meet the expected outcome and broadened the scope.  It took another week of meetings, discussion, and negotiation to get the project back on track and have the new tools accepted.  The project was three weeks behind and required extreme focus and long hours for the design team to make up some of the time on the project.  This increased the time and money charged against the project.

Managing Scope Creep

In handling the changes to this project, the team managed to turn things around and meet the identified needs of the learner.  However, the change took place with much distress on the parts of the design team because there was no change control system in place (Portny, Mantel, Meredith, Shafer, Sutton, Kramer, 2008).  The problem of scope creep was handled with gut instinct, a lot of starts, stops and misses. 

Though gut instinct won the day, there were a couple of things that the design team could have done differently to minimize the risk which includes staying in close contact with stakeholders.  If the design team had of included the stakeholders in the initial review of the tool before it was finalized, the potential problems could have been addressed early on. It still may have caused a delay, but the level of stress could have been decreased because it was part of the analysis of tools.

In addition to more frequent contact with stakeholders, project managers should have a change control system in place and ensure all stakeholders, sponsors, subject matter experts and other members of the design team are aware of the process that will take place.  Having a change control process reduces confusion and stress associated with changes.  It also ensures that changes are reviewed by all parties and the impact of the change is clearly identified on how it will affect performance, cost and the schedule (Portny, Mantel, et al, 2008).  By identifying the change, capturing it in writing and sharing it among all members of the team; everyone is clear on expectations, risks and outcomes.  Having it in writing also helps to ensure everyone receives the same information and has an opportunity to ask questions in meetings and there are no surprises.

So, be prepared for the thief and put your own insurance policy in place by having a plan in place to try and minimize your losses.

Reference:

Portny, S. E., Mantel, S. J., Meredith, J. R., Shafer, S. M., Sutton, M. M., & Kramer, B. E. (2008). Project management: Planning, scheduling, and controlling projects. Hoboken, NJ: John Wiley & Sons, Inc. pp 377-399