Blog: Fixing Problem and High-Risk Projects
It happens hundreds of times a day around the world, the CIO calls an urgent IT Management Committee meeting. She has heard that one of the projects in the portfolio, a seemingly simple project doing a routine upgrade, is projecting a 20 percent cost overrun and will be three months late. How can a project go that far off track since the last week's executive team meeting? Managers scramble to get their stories straight, determine who to blame, form opinions and alibis, and pummel the project manager for failing to manage the project correctly, even though he has been saying the project is in trouble for months. The project has drifted from its initial intent and now the ultimate goal is to find someone to blame.
As mentioned last week, alignment is of the utmost importance. Achieving alignment, at first glance, is easier when the supplier works for the same company as the customer, say an IT organization delivering a new application to a business unit. However, from my experience there is little difference. In fact, exploring a vendor's world, where access to the customer is inhibited, sheds significant light on techniques to improve the customer-supplier relationship. Classically, vendors must wait for a request (RFP or RFQ) before they can get access to the customer. Exploring ways of "fishing up stream," as an eloquent account manager friend of mine says, is critical in improving project success. To understand this we need to review a couple of case studies on vendor success and failure.
I have always enjoyed cooking and rarely thought of it as a chore, let alone a project; however, when my wife became ill, I became the household chef and had to learn a new way to cook. Every evening was a project with varying degrees of success. Eventually making multi-course meals from scratch became easier. I used to joke that cooking Chinese food was two hours of chopping fresh vegetables and ten minutes with three blazing woks.
Risk is a risk in itself. It is risk for you if you dare bring it up. Have you ever identified the risk, in writing, that your boss' inherent inability to make decisions is going to sink the project? How about the company loss of market share will require laying off half the project team? Or, that the project manager has never had a successful project? These are CLMs (career limiting moves). Even mentioning such common risks as a company's inexperience in the project's domain is too risky to put in the risk register. It is as if management enjoys blissful ignorance and relishes the firefight that ensues. Cowboy mentality. Identifying risk, modeling mitigation plans, and compiling contingency are too boring compared to the thrill of disaster recovery.
Loyalty. I have heard a lot about loyalty lately. It focuses on a company's loyalty to their employees. The current stormy economic condition means layoffs and employees on both sides of the pink slip are unsettled. Albeit, conditions today bare a stronger semblance to a hurricane stalled over the employment sector, while Wall Street seems to be holding its own, when the floodwaters subside both employees and employers will be on more fertile ground. As opposed to straining loyalty to its breaking point, it is only taking on a new form.
Estimates are wrong if you cannot beat them half of the time; they are also wrong if you are not late half the time. Neither condition is one that should make management upset. In fact, matching that score is a great accomplishment. So how can people get so emotional about the statement? The answer is that people do not understand estimates and how they work. Through years of estimates being treated as quotes, we have been brainwashed into thinking our best effort is to meet the date, not better it. Heaven forbid if you are late. This lack of understanding is very evident by the number of blogs on the subject and some of their bewildering comments. The comments point out wildly different views. Some people think that Monte Carlo analysis gives you an estimate that has a 95% chance of being right and others believe that using Agile relieves people from having to make estimates entirely. Both of which are plainly not true.
Why is it that tasks always seem to be late? No matter how much time we allot, there never seems to be enough to complete a task on time. There is one overreaching reason pervasive throughout the enterprise—poor time management. To accommodate the continual barrage of supposedly urgent tasks, we heavily pad estimates. Excessive padding triggers numerous negative work patterns. The extra time and over confidence in estimates allows people to accept other unrelated tasks, introduce low priority features, and strive for perfection. It is unfair, however, to saddle the individual with the entire problem; the work-place culture reinforces and rewards the behavior.
The policy reads, "Before you can proceed, the PMO needs to approve the design gate." So, you begrudgingly wind down the project so the slowest members of the design team can catch up. A week, maybe two, sometimes even more flash by. The rest of the project team starts finding work on other projects. Once the PMO finally gives the project the green light, you will need to wait for people to complete those other tasks before they can focus on your project. Precious time is lost.
Estimates are a pain in the... er... butt. Everyone hates doing them. The reason? They are always wrong. They are either too optimistic, when we think we know more than we do, or they are overly padded, trying to account for the unexpected. Other times it is much more subconscious. Some little voice in the back of our heads is working on our conscience to change the perception of the work required. We can be our own worst enemies when it comes to creating estimates and do even more harm when we go to work the task. For now, let us look at a couple factors that influence how we determine the length of time it takes to do simple tasks and save the effects of that estimate for another article. With a little audience cooperation, we will produce a fun answer from a simple mental exercise.
People, who know me, are aware I am less than enamored of certifications and titles. Therefore, when I got my PMP many were taken aback, some laughed aloud, and, since I seemed to get it overnight, all asked why and how I got it. However, it is not just my situation, this is a perennial question in online forums and groups and it is a common topic at local project management meetings. In many of those discussions, people try to analogize the PMP to a CPA or MBA; without question, the requirements to get a PMP have none of the independent educational rigor of college level degrees. The PMP's worth is visceral and personal—it depends on each individual's goals and their project management experience.
Filling Execution Gaps
Rescue The Problem Project
- New PM Articles for the Week of November 9 – 15, The Practicing IT Project Manager, November 9, 2015
- The Argument for Disbanding Your PMO, Accellerated IT Success, Nov 13, 2015
- New PM Articles for the Week of September 28 – October 4, The Practicing IT Project Manager, October 4, 2015
- Episode 332: Project Sponsor Challenges and Solutions, PM Podcast, Cornelius Fichtner, September, 2015
- New PM Articles for the Week of December 1 – 7, The Practicing IT Project Manager, December 7, 2014
- How to buy Project Management Consulting Services: Service as a Product (SaaP), Guerrilla Project Management, Samad Aidane, December 2, 2014
- Episode 275: Your Project Statement of Work is Missing a Comma!, PM Podcast, Cornelius Fichtner, June 14, 2014
- State Invites 10 Firms To Shift Cover Oregon To The Federal Health Insurance Exchange, Oregonian, Portland, Nick Budnick, May 28, 2014
- Decision To Scrap Or Salvage Cover Oregon Health Insurance Exchange Poses Risks Either Way, Oregonian, Nick Budnick, Portland, April 9, 2014
- Cover Oregon Consultant: Fix For Health Insurance Exchange Could Take $40 Million, 21 Months, Oregonian, Nick Budnick, Portland, April 4, 2014
- Episode 205: Rescue The Problem Project, PM Podcast, Cornelius Fichtner, June, 2013
- Episode 206: How to Keep your Project out of Trouble, PM Podcast, Cornelius Fichtner, May, 2013
- How to identify, prevent, and recover from project failure, Accellerated IT Success,April 2, 2013
- Episode 260: The Seven Steps to Rescuing the Problem Project, PM Podcast, Cornelius Fichtner, January. 2014
- New PM Articles for the Week of August 6 – 12, The Practicing IT Project Manager, August 12, 2012
- New PM Articles for the Week of June 11 – 17, The Practicing IT Project Manager, June 17, 2012