Scope creep, which is according to Business Dictionary.com is the all too common tendency where “small changes in a plan or project that necessitate other changes which lead to still more changes … and so on.” The term scope creep itself reminds me of a similar term – “mission creep” that is associated originally with military operations – think of the Vietnam conflict, which began in the late 1950s with only a few hundred U.S. military advisors to bolster the South Vietnamese Army, but in a decade expanded to the scale of a major “hot” war. Mission creep is now used to describe the slow, even cancerous like growth of government programs and their attending bureaucracies in the political domain.
Though I have experienced both mission creep and scope creep firsthand, the topic of this post is the latter. About five years ago, I was part of a team to develop online asynchronous courseware for a Department of Defense client in California. At the start of the project, I was not the project manager (PM) and was not involved with the initial stakeholder and client meetings or the planning phase of the delivery. However, at the six-month mark of the two year project timeline, the original PM was promoted and I was put into the position of de facto or “accidental” PM responsible for the execution of the delivery ranging from monitoring the schedule, quality assurance and quality control, supervising production and even drafting team member evaluations.
However, there was one wrinkle, the former PM, now a Program Manager (PgM) retained his role as the focal point of contact between our firm and the client and the reason for this arrangement was he was to engage the client for future business development. In other words, as the PM, my communication with a key stakeholder was limited and filtered through a go between whose agenda was different from mine as the PM for a delivery.
This arrangement as you can imagine became the source of issues that manifested themselves later on in the form of scope creep. For example, in order to foster good will with the client the PgM was reluctant to say no to the client when they requested modifications to the delivery in the form of enhancements that naturally caused production delays, yet we were still bound to the terms of the original statement of work (SOW) when it came to the timeline.
I could go on with more examples of how the PgM’s inability to say no created additional problems, but I think you get the gist of the situation and may have experience a similar fate, so I will end here with the following from Michael Greers’ Project Management Minimalist on the necessity of sometimes saying no:
Make sure everyone on the project team has deep knowledge and respect for the boundaries of the project. Make sure they know, and are willing to defend, the finite nature of the project deliverables as specified in the contract or the work plan. If you haven’t already done so, make sure there is a method in place for handling add-ons, wishes, and other requests for expanding the project scope. For example: Keep a list of items marked “Version 2” or “Enhancements for Future Projects” when you’re in those meetings with stakeholders. These items can be rolled into another, subsequent project that is separately funded and has its own schedule. That way stakeholders are assured that their ideas are captured. Back up your team members and be there to help them say “No” when they are faced with scope creep. (Greer, 2010).
If I only could have left a copy of Greer’s treatise of project management on the PgM’s desk back five years ago it might have gone differently. Well maybe not, because as things go it probably would not have mattered given the organizational culture.
Business Directory.com Definition of scope creep. Retrieved from http://www.businessdictionary.com/definition/scope-creep.html#ixzz3FgExneBe
Greer, M. (2010). The project management minimalist: Just enough PM to rock your projects! (Laureate custom ed.). Baltimore: Laureate Education, Inc.