Saturday, December 8, 2012

Analyzing Scope Creep

My company was hired as part of a contract bid to conduct an audit and network security assessment of a federal agency, which was part of an audit of federal agencies at multiple sites across the U.S.  The project was initiated by the headquarters for this particular agency (at Washington DC), but the work was to be conducted at a number of local sites in Hawaii.  My role was Project Technical Lead as well as the Lead Security Control Assessor for federal government sites in Hawaii. 

What specific scope creep issues occurred?

During the initial kick-off meeting to discuss the audit of the network, the local client stated that they were aware they had not implemented a number of the required controls for their network and asked to make a change to the scope in order to help them better understand the mandated federal security control requirements for their network.  In the project charter, the exclusion statement specifically stated that controls identified as “Not Implemented, but planned”  would be considered as “Not Satisfied”  and would be validated, but not assessed.  The client asked if we asked if we could take the time to assess the controls to provide the client with feedback on how to implement the control.   Wanting to assist the client (and gain favor for future projects), we agreed to this change.

How did you or other stakeholders deal with those issues at the time?

As noted by Greer (2010), the project team followed some of the steps for dealing with project scope changes, but not all.  Our project team did the following:

1.       Made note of the specific change and discussed it among the team

2.       Notified the government sponsor of the change.  The sponsor neither agreed nor disagreed with our decision to provide more assessment; however, they simply said that they were not doing an assessment of these controls at other sites.  We indicated that if we didn’t provide assessment for controls that were “Not implemented, but planned,” there wouldn’t be much for us to assess since the site had not implemented the majority of the required security controls for their network.

Looking back on the experience now, had you been in the position of managing the project, what could you have done to better manage these issues and control the scope of the project?

What we failed to do was the remaining steps recommended by Greer (2010), which was to update the project scope statement and overall plan as well as obtain written approval. This was important because this change in scope ended up adding too much time to a project that already had major time constraints (it was a six week project that needed three to four months and/or more personnel to conduct assessments).  We finished the project on-time, but all team members had to work long hours to get it done.


Greer, M. (2010). The project management minimalist: Just enough PM to rock your projects! (laureate custom ed.). Baltimore: Laureate Education, Inc.

1 comment:

  1. Ah Dawn, I am very familiar with similar scenarios, especially with clients whom I've done work with and who know me personally. In such a situation, the request made to expand the scope has often been made with the best intentions or very politely. And often, I've agreed to accommodate such a request out of courtesy and a need to prove to the client that we could "do the job, no matter what it took." From that experience, as you learned, I now make sure I have change documentation reflecting the acceptance of the inclusion, exclusion or expansion of the scope and require signatures. In a few instances even, when presented with the change documentation and viewing how the perceived "small changes" would subsequently inflate the project schedule, budget or resources, I've had clients who just as politely backed down, and some who indignantly expected me to complete the work without the change documentation because "I said I would make accommodations." In other words, little changes often suggested somehow seem to have very large impacts in the long run, and like you, I feel that without following progressive steps as illustrated by Greer, we as Project Managers or team members are often eating the costs in hours, budget and time to please the primary stakeholders without any accountability on their part in presenting the change in the first place.