Project RIsk and Mitigations
What You Learn From Rescue the Problem Project
Rescue the Problem Project
by Todd C. Williams
Todd's first book delivers twenty-five years of project rescue experience. Unlike other books on the subject, Rescue the Problem Project focuses on the process to rescue the project. This is the critical few weeks that transform a failing project to a successful project. Other processes blindly layer processes on top of a project without finding the cause of the failure. Rescue the Problem Project focuses on root cause analysis to determine the source of problems and solve them once and for all.
The book starts by discussing the biggest hurdle in rescuing a project—realization that there is a problem—and proceeds through detailed discussion of the four-step process to recover them—audit, analysis, negotiate, and execute. In addition, it includes a complete discussion of four key processes to prevent failure.
Risk is in everything we do in life, from going to the store to managing our projects. If we understand the risks associated with something we are doing, we can address the risks better and in many cases avoid them all together. Unfortunately, risk often scares us and as a result, we ignore it. This course identifies types of risks on projects and ways to lessen their effects. What you will cover:
A few years ago, we had a run in with the healthcare industry. I think of it this way since is sounds like a run in with the law. Doctors are the law, or so they think. Do as they say, or else. The problem was that my wife, at 46, was having a heart attack and had a hidden... oops... I almost spoiled the story. Unbeknownst to me, Doctors rarely think about two things being wrong; they only work on one issue at a time. Those of us who live in project work realize this assumption can have grave consequences. What the doctors in this case needed was an anal-retentive, tenacious, asshole of a Project Manager whose objective was a successful project. As Gene Kranz so aptly said, "Failure is not an option," the product, service or end result of this project was a life—my wife's. However, I am getting ahead of myself. Let me take a few minutes to set the stage to show my mistakes and how years of project recovery experience helped. I will keep it brief.
Red project recovery is a four-step process. One must, however, determine a short-term plan for the project. It takes time to get to a resolution and it is nonsensical to continue spending money at the current rate. Other than doing nothing, there are two remaining options:
Trust relationships, certifications, and standards sound like such a safe harbor. These sound like such great words in a proposal or statement of work. How could you possibly go wrong building a trusted relationship with a customer by committing to follow a standard? In fact, this can burn you… in court.
No one ever starts a project with the goal of ending up in court. In fact, litigation may never cross your mind; after all, you have built a trusted partner relationship. Taking a few cautionary steps, however, will make your life easier if you end up in that ill-fated litigious position. Your best chances for success come long before you enter the courtroom—even before the project starts.
Months ago, maybe over a year, now, I was blasted for talking about innovation in the context of information technology (IT) projects. The gist of the complaint was that all IT folks think they are building some new groundbreaking, revolutionary application that requires the latest in technology's tools. I agreed with his argument, qualifying that although this seems to be a pervasive theme, IT is a discipline that needs to keep one-foot in the pioneering frontier. Regardless, I had to concede that many innovative initiatives are more about a technician playing with some new toy. Jobs like implementing ERP interfaces to manufacturing execution systems (MES) only sound new. Unfortunately, I must say, "been there done that." Most IT is neither new of innovative. To avoid squandering funds, executives must understand and direct what needs to be innovative and permeate the company's culture with that knowledge. Otherwise, the wasted time and expense will suck a company dry.
Friday brought news of another company outsourcing part of their IT. The details are sketchy, but it appears that all the COBOL programmers (many counting days until retirement) are going to have their jobs moved half way around the world. Soon after, it sounds like the IT infrastructure and operations will follow. Friends lamented about more jobs going overseas. I had to ask what other options management had. I did not hear any alternatives.
To the dismay of my cohorts and their potential pink slips, I am less concerned about outsourcing the administration of servers, networks, and base applications. For most companies, those are not the systems unique to their mission. These days, those functions are utilities. However, outsourcing customized systems that are at the heart of how a company does its business and distinguishes itself to its customer, is very risky. It may be the only option now; however, it could have been avoided.
The other day, while playing with my nine-month old Granddaughter, I counted the number of times she tried to do something and failed. If I had that much trouble, I would give up. Then I reflected on how many successes she has ever hour. Day by day, she changes—in a marked way. Making new sounds, crawling, climbing, signing, putting toys together, they are all big steps. She repeatedly tries until she gets it right, resulting in more successes in a day than I have in a week... maybe a month, even though she fails at more things in an hour than I do in a year. Maybe, if I were to increase my number of failures, successes would skyrocket.
The other day a Latvian student contacted me for my views the connection between culture and success criteria—an important and intriguing topic. After working in Taiwan, Singapore, Korea, Japan, Israel, United States, and Canada, I wear many scars of both blatant and subtle cultural violations. I also know that within a culture one person's success is often another person's failure. So, after dispelling concerns about clicking on some random email link, I completed her survey (please feel free to take it yourself). In the process, I struck up a friendship with the student, Kristine Briežkalne, who is studying at Riga International School of Economics and Business Administration . She has some interesting views and presented me with a Venn diagram showing four frames to a project (business, client, project management, and growth perspectives) and how they intersected. As the diagram is part of her Master's thesis, I will let you ponder the how to label the overlapping areas (an eye-opening exercise).
|Author:||Todd C. Williams|
|Released:||March 20, 2011|
Amazon #1 Bestseller in Business and Technical Project Management!
Back from the brink... the first fail-safe recovery plan for turning around troubled projects and keeping the problems from reoccurring.
When budgets are dwindling, deadlines passing, and tempers flaring, the usual response is to browbeat the project team and point fingers of blame. Not helpful. For these situations, what is needed is an objective process for accurately assessing what is wrong and a clear plan of action for fixing the problem.
In Rescue the Problem Project, Todd Williams, President of eCameron, describes how projects go wrong and what to do to fix them. It focuses first on people, then process, and finally technology. By doing this it helps you find the root cause of the failure and helps you prevent it from happening again.