Red Flags, Blue Lessons

Watch for these warning signs, so you don’t end up twisting in the wind!

As a project manager (PM) for an international consulting firm, I was once assigned to a very large account that taught online classes through the internet. The company was called the High Intensity Teaching Corporation or HIT. This is the pseudonym used throughout, and for reasons that will soon be obvious, I found it managed to fly into some of the most dangerous red flags that warn of project trouble: a virtual office, an excess of PMs, overlapping projects, and risk aversion. Let’s examine these one by one. I’ll attempt to transform my agony into your benefit.

 

1. A Virtual Office Can Sometimes Be a Drawback

In the past, I had set up shop Monday through Friday. This usually entailed flying to the client’s location early Monday morning and flying back home Friday afternoon or evening. However, as telecommuting opportunities advanced, I began to spend less time at on site with clients. I could show up Monday through Thursday, sometimes every other week. It all was dependent on the project’s progress, and my physical presence was my choice. This was great for me! I got more work done from my home office because I was spending less time traveling. Likewise, it seemed ideal for my company at first, but you know what they say about the transient nature of happiness?! Things quickly turn upside down!

Red Flag: The first month I was assigned to HIT, I was “allowed” to travel to its headquarters on two consequent weeks. The plan was then for me to use my home as a “virtual office.” The bottom line was that HIT didn’t want to pay for my traveling expenses. It seemed reasonable enough, but this was truly a classic case of being penny-wise and dollar-foolish, and a show of how little regard they had for the value of PMs.

As it turned out, my virtual office meant that my mirror image was physically at HIT’s headquarters as I had a phone, email, and getting plugged into their system was supposed to be a snap. I soon learned; however, that working for this account, my virtual office really meant working with handcuffs. In one situation, I advised that we should hold a one day workshop at HIT to brainstorm, review the many project requirements, and work on some initial solutions. The client thought this was an excellent idea because all vested parties were located at headquarters and we would accomplish more, but I soon learned I had to facilitate the workshop from my home using Skype. The time-zone difference caused headaches in this and other cases. I was two hours ahead of HIT, and I usually started work at 7 a.m. Since most HIT employees started between 8 and 9 a.m., I was really three to four work hours ahead, but had to take many evening conference calls, too. On numerous occasions, I wasn’t invited to key meetings, which made me feel out of the business’s mainstream. Of course, this made it difficult to manage priorities effectively.

Blue Lesson: The virtual office makes you more flexible if you are working on multiple accounts as a PM, instead of a single one like I was assigned at HIT. In this case, I would have been more much more effective if I could have traveled to the client’s headquarters once every two to three weeks. If you are offered a remote PM role that doesn’t allow for much travel, take pause before you accept the assignment. Travel restrictions could be a red flag that signals not only the client’s reluctance to invest in you, but their view of your role as unimportant. If you must take the assignment, forewarn management about the extra hurdles you will encounter due to your stationary status. You may suggest that they use local people or contractors on the premises at no extra cost.

 

2. Too Many PMs Involved Can Cause Chaos

I was originally brought in to work on one project, on a worldwide basis, replacing about 1,400 outdated servers with a lesser number of new powerful servers. This alone was a fulltime job; however, in today’s workplace, one fulltime job is often just the beginning.

Red Flag: Periodically during my time with HIT, a new project would be thrown “over the fence” and hit me on the head. Figure 1 depicts how I felt. When I reviewed the histories of these “new” projects, I realized I was the second or third PM to take over each one, and all had been in existence for between 6 – 12 months. Furthermore, I realized some of these “projects” where really programs – usually a group of related projects working toward the completion of a single deliverable. I ended up with these unannounced projects because the group that owned them “reorganized” or felt they no longer fit in. I was very alarmed to see how many PMs (and client owners) had previously worked on them, and I quickly understood why these short-term endeavors were turning into long-term exercises. Working from my virtual office, it took me two to three weeks to get up to speed on these projects. Of course, this was all while working on my original fulltime assignment. Other red flags included the fact that no up-to-date project plans were in place, and there was too much dependency on a small number of key resources.

Figure 1: Bang Head Here

 

Blue Lesson: Because it extends project length and cost, and disenchants the client, group reorganizations shouldn’t be used as an excuse for unloading projects. In my experience, if a project is thrown over the fence, so to speak, it should have a clean bill of health, updated project plan, and a good transition from the outgoing PM to new one.

 

3. Too Many Overlapping Projects Creates Unnecessary Work

I went into my HIT role expecting most colleagues to understand the importance of an entire team or business unit having awareness of a project’s “big picture.” To me, this meant that the people involved or affected needed to know the project’s goals, objectives, master schedule, system architecture, and major milestones. When you are juggling too many overlapping projects, it’s tough (and vital) to keep track of all the details. It should come as no surprise at this point that HIT had many team members without knowledge of and consensus on the big picture, and much time was wasted defining details that ended up as throwaways anyway.

Red Flag: Since I was working on a number of inherited projects, I realized that many projects lacked a big picture because they overlapped with one or more concurrent projects, mainly in the area of doing work on servers. HIT had over a hundred of active projects covering many different business areas, so it was extremely difficult to know if one project overlapped with others.  For example, on one project, the application releases of a series of servers were being updated by one support group, and in another project, the Window’s operating system was being upgraded for the same servers by a different support group. These two project schedules weren’t coordinated, and efforts became duplicated, unknown dependent activities occurred, work tasks were done out of sequence, and payment confusions became the consequence.

Blue Lesson:  I advised HIT to find ways of eliminating unnecessary work and misunderstandings about who was doing what. In the case of the servers, if any new project involved servers, I realized that the server addresses should have been queried against the project administrative database to find possible matches to other projects. The PMs assigned to those projects should have been notified and work efforts coordinated. If the server addresses from the new project could have been validated against HIT’s server database to make sure the server’s description within the project matches what’s on the database, any information that didn’t match could have been corrected.

 

4. Risk Aversions Decrease Your Chances of Success

On two of the additional projects I was assigned, HIT was always changing the scope and priorities at the last minute. These projects had been stumbling along for about a year and should have been finished by the end of 2017, but ended up being completed at the end of 2018. What does all this mean? Well, most people view risks in a negative manner, but risks can be positive in that they open the door for a better approach, creating new opportunities that may not have been available when the project began.

Red Flag: The HIT projects were adrift because of constant changes, which hurt the team’s overall morale and effectiveness. HIT didn’t want to spend any extra money and instead expected my consulting company to take all the risk. In the short run, HIT would be saving money, but ended up spending more in long-run because of the necessity of providing additional support for outdated products that were no longer supported by their vendors. This kind of penny-wise and dollar-foolish thinking is a real impediment to progress. Furthermore, HIT lacked the discipline to meet its own schedule commitments, even though they expected me to meet mine.

Blue Lesson: Management’s actions always speak louder than words. It is obvious that HIT and my company did not have a good working relationship. Senior management has to come together to overcome this type of adverse environment. The biggest factor that can make or break a project is the degree that leadership exercises effort at this.

HIT had to learn that risk management is proactive management—and this includes the need to replace inadequate or outdated risk assessments. Risk management enables you to minimize future threats, seize opportunities, and achieve optimum results. All projects have risks, and if they go unacknowledged, the project is looking at failure. Numerous studies have shown that IT projects share some common sources of risk. One of these studies comes from the Standish Group, which shows a project’s success criteria and its’ relative importance. Using this criteria can help a PM look for areas of success by finding and reducing risks. Table 1 shows the scoring sheet. Notice the first three items account for 50% of relative importance for success. These are key areas to find and reduce risks.

Table 1: IT Success Potential Scoring Sheet

 

Summary

As a PM, my time at HIT was fraught with frustration. Although at times these red flags left me twisting in the wind, I learned a lot from the blue lessons they produced—and I hope you did too!

 

Next Webinar

Avoiding Death by PowerPoint (and other Presentation Arts)

Ronald Smith has over four decades of experience as Senior PM/Program Manager. He retired from IBM having written four books and over four dozen articles (for example, PMI’s PM Network magazine and MPUG) on project management, and the systems development life cycle (SDLC). He’s been a member of PMI since 1998 and evaluates articles submitted to PMI’s Knowledge Shelf Library for potential publication. From 2011 - 2017, Ronald had been an Adjunct Professor for a Master of Science in Technology and taught PM courses at the University of Houston’s College of Technology. Teaching from his own book, Project Management Tools and Techniques – A Practical Guide, Ronald offers a perspective on project management that reflects his many years of experience. Lastly in the Houston area, he has started up two Toastmasters clubs and does voluntary work at various food banks.
Share This Post
Have your say!
00
1 Comment
  1. Ronald, thank you for this really excellent Red/ Blue retrospective. I’ve experienced these at different times and De degrees, but your observations are spot on. I’ll be sharing with our project office. While we may learn the lessons again, drawings on the Blue perspective will help find the better way to the right solution!

Leave a Reply