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.

 References:

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