Week 6 - Scope Creep

I was on a project a few years ago (the same project I wrote about in Week 2 and posted on this blog) as an employee of a major defense contractor.  Our team was tasked to develop and deliver a satellite communication time scheduling system that would allow the users (Air Force organizations around the world) to schedule “time” on satellites so they could use them to communicate.  Their current system was old and antiquated and they were having a very difficult time getting parts when it broke.  When the contract was awarded, the original project team members and the customer did a poor job of capturing the full system requirements and instead the PWS (performance work statement) was full of requirement statements that were open-ended, fuzzy, and left to interpretation by both our project team and by the customer.  We seemed to spend more time arguing about the meaning of requirement statements than actually getting the job done.

When it comes to government contracts, this is typically how scope creep starts, with poorly crafted requirements.  The second reason scope creep is common is due to the daily interaction and familiarity of the project team members and the customer.  From our reading this week “A major source of trouble with changes is typically that the project manager, in an attempts to avoid bureaucracy, adopts an in formal process of handling requests for change.  Such a process leads to misunderstanding on the part of the party requesting the change, and before the project manager can undo the damage, the organization is committed to extending the scope of the project but without the additional resources and time to do it”  (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer. (2008), pg 346).  I would add that this is not confined to just the PM.  Certain team members and project leaders contribute to this as well, and it almost always goes bad for the team. 

In our case, this did occur on a frequent basis.  After a year or two into the project the actual work was probably 50% more complicated than what the government asked for in the first place, meaning approximately half of the work to be accomplished was due to scope creep.  For instance, the hardware solution (racks of servers, thin clients, etc.) was over engineered and turned out to be a nightmare to configure and maintain.  Also, the software was also over engineered due to the constant input from the customer changing this button to that and, more importantly, the software team not developed coding standards from the very beginning.  You should have seen how lost they were trying to troubleshoot problems with their team’s code.  Each had his or her own way of writing code that no one else on the team could decipher.  I’m no software developer, but I still remember “coding standards” as a critical aspect whenever software is involved. 

            All of this churn and scope creep resulted in a really big mess, both on the project team and (more importantly) in our relationship with our customer.  The project had changed hands early on due to the former prime contractor being called to the carpet by the customer, so there was already animosity to begin with.  When the problems I described here (and in my week 2 post) started to pop up, the customer/project team relationship was already strained.  This made it even more difficult to get past each milestone, and every time the PM had to announce a project slip it was like going to a funeral.  Team members were blaming each other, the next “drastic change” had to be implemented to show we were serious about getting back on track, and there just didn’t seem to be much control at all.  I left the team after two years.  I blame a lot of this on the PM who, while he was a nice guy, was not a very hands-on leader and left a lot of us needing direction and focus. 

If I were the PM I would have ensured the project’s requirements were fully developed, vetted, and agreed to by all parties prior to the project beginning.  Further, I would have ensured that each of the project’s teams attended weekly meetings where milestones would be covered and dependencies would be discussed.  Lastly, I would empower each team lead to run their team how the saw fit while ensuring they were held accountable for milestones that were not met due to their team’s actions (or inactions). 

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.