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.

Week 3 - Communicating Effectively: Different Modalities

         In this week’s multimedia program “The Art of Effective Communication”, we were exposed to the same message in three formats: written, verbal, and face-to-face (or video).  After reviewing each one I took notes on the message, the content, the delivery, and what I interpreted as the meaning of the message.  First, I would say the email was the least effective form of communication.  I understood that Jane needed a report from Mark and that she needed it right away, but her reference to the “data” she would accept as an interim piece of information was unclear.  She did not effectively convey what data she needed and was rather wordy in her email. 

         The voicemail was effective, especially when compared to the email.  The inflection in Jane’s voice helped drive the point home that she really needed the report and her work was suffering as a result of not receiving it by now.  Again, the definition of “data” is unclear, but this was a much more successful communication than the email. 

         Finally, in the video Jane conveyed the same message to Mark, only this time it was supposed to be a face-to-face conversation.  While I appreciate this is meant as a learning tool, I didn’t really buy the fact that Jane would talk like this to Mark and was instead expecting a conversation between the two.  This artificiality made it hard for me to truly judge the quality of the message, and in fact I would say the voicemail was still the most effective of the three.  However, in general I believe face-to-face is almost always the best communication method.  

         What this tells me is we should always “choose the best communication approach” (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, (2008). pg 357) when talking to colleagues.  If the message (or question) is succinct, then an email may do.  But the old adage that nothing can take the place of a verbal conversation still holds true.  We should reserve email for correspondence that is simplistic in nature and that isn’t on a timeline.  Voicemails are better, but only when the person cannot be contacted.  Finally, face-to-face is always best (even though I didn’t care for our video example) as a two-way conversation should solve most issues and allow both parties to continue their work without any further delays. 

References:

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 2 - My Project Post-Mortem Story

The project I am writing about this week based on my experience on a government contractor team from 2006-2008.  I started on the project as an IT instructor/instructional designer where my role was to write the training material for the IT staff that would be taking over that role upon system delivery.  After spending about a year developing the material (in cooperation with our IT SMEs), I was promoted to be our team’s lead (ILS or logistics lead).  As the lead, the trainers and technical documentation writers fell under me and I became the interface between our team and the PM.  It was in this role that I quickly realized how disjointed our project team really was and how many factors contributed to both the internal and external impression of our team.

From the time I was hired, it only took about six months to realize that our team of approximately 50-60 contractors was woefully behind schedule.  This was solidified when our PM delivered the news of our first project “slip” to the customer.  Unfortunately this is where things started to unravel, and our team quickly realized that we were much farther behind schedule than we had initially estimated (or had been told, depending on your perspective).  What ensued was a confusing, confrontational, and frustrating period within our project, not to mention with our customer, where many people questioned their contribution to the team and, more importantly, our team’s leadership and ability to even complete the project (regardless of the time frame).  When I left the team in 2008 we were three years behind schedule and the system we were supposed to install in 2007 is just now in the initial phases of install and turnover to the customer.  There are many reasons for the delays, and I will attempt to go over as many as possible while keeping this as brief as possible.

            The majority of the issues our project team encountered are captured in section 4.7 of our book, “Examining Why Plans and Project Fail” (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, (2008). pg 104).  Since I joined the team about two or three years into the project, I cannot speak intelligently on how it was actually started and whether the phases were accomplished according to our reading.  What I can say is that, through many conversations with coworkers, it was obvious to me the project did not get off to a very efficient start.  The system requirements specifically were something our team kept going back to, even years into the project, and we found ourselves (us and our customer) disagreeing with the verbiage and questioning whether all of the actual system requirements were documented or mapped properly.  It is quite possible this is the number one reason why the project was so far behind schedule.  But again, that was the prevailing opinion of many team members (system engineers, software developers, etc.). 

           

            On page 107 of our text there is a section on “Detecting Potential Pitfalls Early” (Portny, et. al. (2008). pg 106).  I am not exaggerating when I say that virtually every one of these causes affected our team:  “not involving all key project stakeholders”, “vague objectives” (read requirements), “vague or nonexistent role and responsibility definitions”, “not identifying and sharing key project assumptions”, “not writing down key information”, “not holding people accountable for performance”, and the biggest one of all “poor team communication” (Portny, et. al. (2008). pg 107).  I blame most of this on our PM, as it was his primary reasonability to ensure we stayed on schedule and to avoid these circumstances when they arose.  However, the entire team seemed to have this dysfunctional dynamic that we just couldn’t shake.  It was in the ways we talked to each other in meetings, how teams didn’t share information, milestones weren’t given the proper amount of importance.  Again, I was hired years into the team being formed so I walked into this situation.  It didn’t take long to figure out that, while there were some very smart and talented people on the team, there were some that were obviously part of the problem yet no one seemed to be doing anything about it.  It was as if everyone knew this was good way to earn a paycheck and there wasn’t really a compelling reason to turn it around. 

            Well, after reading back over this post I don’t particularly care for how negative it sounds, but that is how the project “flowed” and some of the issues that I believe contributed to the setbacks.  As for me, after about two years I just didn’t have the patience so I moved on to a better opportunity.  But I have always remembered the lessons I learned on that team and have tried to put that knowledge to use since. 

References:

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.