Scope Creep

A few posts ago, I shared a project from hell titled Change Fail, where nothing seemed to go right.  This week I've been asked to write about scope creep and that same project on waste contains elements of what I've been asked to share.  If you recall, one of the issues involved with customers adding more requirements to the project after a charter and project deliverables had been defined.  Unfortunately, it was a project I was "in charge" of, but my manager retained the project manager, sponsor AND champion positions.  In essence I was only executing what he told me to and arguing or offering a different point of view was looked down upon.  He went as far to tell me that he knows best and if I didn't do as he asked, my performance review would be affected.  What a nice guy, eh?

Background

As part of the project, one of the deliverables was a report to categorize and summarize the waste by product run.  A report was designed with input from the stakeholders and agreed to.  The proof-of-concept showed the same view and data fields the final product would show.  The only difference was the data displayed on the report was fictitious at the time since automated data capture was not available.  Even with fictitious data, we kept the numbers in a reasonable and realistic range to mimic reality.  However, once the report was approximately halfway completed, the stakeholders decided it was no longer good enough for them and wanted additional capabilities in the report such as report by individual operator.  They went as far as to tell us that they would not trust the report until it contained the information they requested and I would be personally running the reports by hand until they could get the report they wanted.  To run each report manually, it took approximately 5 hours per product per piece of equipment.  There were five winders included in the report, and each winder could potentially change product once a day.

Reasons for Creep

A 1994 article in Computerworld lists the top five reasons for scope creep:  poor initial requirements definition, new applications (technology) were unfamiliar to users, projects take too long, failure to manage user expectations, and failure to involve users in early stages.  Unfortunately, I do not feel that any of these reasons were the reasons why the scope kept changing.  At the very start of the project, the people requesting the changes were involved in bi-weekly meetings.  They were provided with an example report that would be automated for them.  The report contained the exact format and data they would receive on a monthly basis and they were given an opportunity to make changes as needed.  After they signed off on the full-scale development of the report, they began changing the requirements and questioning the usefulness of the report.  I honestly and full-heartedly believe we involved the users at the start of the project (every report and data field was approved by them), managed user expectations and provided specific requirements definition by providing an exact replica of the report.  When asked why they wanted to change to report, they were unable to state a clear reason why it was necessary and were not able to provide proof the new requirements were being reported or utilized at present.  The stakeholders were also not able to state how the newly defined requirements would be used to monitor performance of the department.

The reason I believe the stakeholders kept changing the requirements and providing unclear and unrealistic demands was due to change resistance.  They were dragging their feet and delaying the project to avoid being monitored and measured on waste.  Portny et al (2008) point out that upset clients are a common result of creep due to the additional time or cost associated with the project.   Since the report was being provided free of charge to them, the only item they could complain about was the delay.  Never once did they mention the delay or ask when the project would be complete, which supports my feeling that they did not want to implement the waste tracking system.  Beach’s book, Leadership and the Art of Change (2006) also substantiated my belief that it was a resistance to change that caused scope creep and additional requirements.  Unfortunately, the project manager/champion/sponsor never used any method or process to control the project changes or attitudes.  Every suggestion I made to help control the scope and provide realistic reports and time-lines was ignored by him.  By ignoring the requests and not offering any acknowledgment of the requested changes, frustration levels grew between the stakeholders and myself since it appeared that no one was listening to anyone.

Methods for Controlling Creep

Had I been allowed to proceed in my proposed way, I feel the frustration could have been reduced.  Some suggestions to managing scope creep included:

• Referring back to the original project time-line and agreements 
• Explaining the impact of the changes
• Requiring the stakeholders to demonstrate how the information would be used
• Demonstrating how the requirement was currently being met in a separate report (which was one of the claims)
• Maintaining a change log or scope creep document
• Speaking with the stakeholders’ management team 
• Just saying "NO" and backing it with a valid reason 

Each of these suggestions can be backed in literature including Portny et al (2008), Anthes (1994), and Gurlen (2003).  In the end, the stakeholders agreed to a spiral development approach where we improved the report at distinct intervals once we proved the basic report was accurate.  However, they would not agree to using the report until it was 100% complete according to their opinion.

End Result

The project had a happy end for me after all!  I decided to leave the company, partly due to my management and the way the company managed this project.  OK, who am I kidding? That was a major part of my decision.  On a serious note, a year after the project started, it is still on-going and is not much further along than 6 months ago, even though I've only been gone for 3 months.  I occasionally receive phone calls from my replacement asking for my help or trying to understand the people, attitudes, and agreements in place.  In reality, a project like this should have taken 3 months to complete.  I have worked much more complex projects in shorter time, including dealing with people resistant to change.  The lack of support and direction from the project manager/sponsor/champion was a major cause of the delay and frustrations.  Had he stepped in and been more firm regarding the changes, the project would have progressed faster.

The types of problems encountered in this project was typical of many other projects at the site.  I believe the resistance to change and inability to properly manage projects has already had a large negative impact on the site.  Just the other week they announced additional layoffs and a potential sale of the facility.  In the event they don't find a buyer, they stated they will close the facility.

               

References

Anthes, Gary H.  (1994, May). No more creeps! Computerworld, 28(18), 107.  Retrieved February 10, 2011, from ABI/INFORM Global. (Document ID: 311539).

Beach, L.R. (2006). Leadership and the Art of Change. Thousand Oaks, CA: Sage Publications, Inc.

Gurlen, S. (2003)  Scope Creep.  Retrieved February 10, 2011 from http://www.umsl.edu/~sauterv/analysis/6840_f03_papers/gurlen/

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.