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.

Week 5 - Budget Web Sites

I found a couple of web sites via a listserv that would be useful in estimating the costs, effort, and/or activity durations associated with ID projects.   The first is from the University at Buffalo (The State University of New York, http://www.research.buffalo.edu/sps/about/guide/chapter5.cfm).  This site covers virtually everything a PM would need to consider when creating a budget for an ID project.  It discusses many of the topics covered in our reading this week, but also touches on some important expenditures that the PM needs to consider, like travel, fringe benefits, consultants, and sub-contracts (to be used if your company cannot accomplish all of the work).  These are useful because omitting just a couple of these items from the budget could mean the difference between staying close to your project cost estimates and blowing right past them mid-way through the work. 

Another resource I came across was published by Northwestern University (http://www.nucats.northwestern.edu/funding/seed-grants/arcc-seed-grants/pdfs/CCPHGrantWritingResources.pdf).  This too discussed the cursory budget considerations every PM should include as they are planning the project, but again includes a lot of expenditures that can easily be overlooked by an inexperienced PM.  The examples given are payments or incentives for participants, stipends for meetings outside of the project’s local area (usually associated with travel), training workshops, meeting room rentals and food for meetings (if applicable), and protocol reviewer or lawyer expenses (again, if applicable).  Depending on the type of ID project, there can me many of these “hidden costs” that again can add up quickly and will cause the PM a lot of sleepless nights as he/she tries to figure out why the team is so far off-budget after just a few week’s worth of work.  The old add 20% padding rule might assist in softening the blow to leadership, but if the PM does not accurately account for some of these costs AND something catastrophic happens on the project, then the budget and the overall success of the project is at risk. 

I have had the opportunity to be part of a rather large proposal team with Northrop Grumman a few years ago.  While I only had the logistics piece of the pie, there were at least 10-15 other people estimating their own costs plus management oversight).  Throughout the process I was in awe as our team sat in the proposal room, each pitching their labor and cost requirements.  To see the business development folks add all of the numbers up plus the many factors we were not tracking was incredible (and not in the least enviable).  When everything was included, the overall budget for our proposal was rather large, but then again so was the work we were bidding on; a major re-design on our current project requested by our customer.  It taught me a lot about the so-called hidden costs within projects and gave me a new appreciation for the amount of time and effort that goes into project budgets and proposals.