The Project Whisperer: How to Spot a Troubled Project Before…

by PH Lohnes, PMP

Dealing with troubled projects is indeed a noble and necessary pursuit in the project management discipline; however, more important is the ability to spot the precursors that a project exhibits that may lead to the eventuality of it becoming distressed. Can one review a project and discover these markers? Are there markers in the first place?

The resounding answer is YES! Speaking with many trouble project managers as well as drawing on personal experience, there are four common characteristics that most of the “off the track” projects seem to exhibit. These four tracers, as they can be considered, are:

  1. Lack of objectivity
  2. Lack of discipline
  3. Lack of transparency, and
  4. Lack of experience

A most significant point to understand is a combinatorial principle, paraphrased for our purposes, that the existence of one of the above tracers in a project does not mean the project will become problematic. However, a significant number of troubled projects exhibit most if not all of the tracers. So if we know the markers that show up in projects that are troubled, can we derive useful managerial information from these markers appearing in yet to be troubled projects?

Again, the resounding answer is YES! The whole purpose of project management is to manage the future activities of a coordinated network of interrelated tasks oriented towards a common goal. So if as a project manager, one begins to see the emergence of tracers that distressed projects exhibit, the logical course of action would be to determine the root cause of the tracer and prune it.

What are these precursors? Do they have physical manifestations? How can they be identified? Let’s take these questions in order, briefly in this article, and in more detail in subsequent issues.

Precursor #1: Lack of Objectivity

This can also be referred to as “project personalization.” This precursor occurs when team members, and most importantly, component managers such as leads and subject matter experts (SME) become personally or emotionally invested in the success of the project. This begins the process of project protection which usually leads to the blurring of objectivity.

Precursor #2: Lack of Discipline

One of the most common characteristics of failed projects was an exhibition of a low level of professionalism or discipline to adherence of industries standard practices. Inconsistent behavior in dealing with risks, issues, and problems is a manifestation of this precursor. This is referred to as “professional lethargy.” There are others which will be discussed in more detail.

Precursor #3: Lack of Transparency

By definition projects need to be open, forthcoming, and accurate about their status, performance, and progress. The hiding or obfuscation of project data cannot be tolerated for long since every project has a finite lifetime upon which its conclusion will reveal all problems and issues. Problems cannot be masked forever. As project team members become less transparent, the full data needed to make decisions on the project’s future cannot be considered reliable. This is referred to as “project fog.”

Precursor #4: Lack of Experience

In a previous issue of the Project Post-Gazette, this concept of siphoning off project management experience in order staff program and portfolio levels has been addressed. The reader is directly to the February 2013 Issue <link here>, The PPPM Roadmap column, to read about this precursor in more detail; however, suffice it to say, that most troubled projects are not staffed by highly experienced, well-skilled practitioners. These professionals or sometimes the sources of the project’s problems have left well before the project deteriorated being replaced with less experienced less well-healed individuals. This is NOT an indictment of all projects or programs or their mangers, just a simple observation.

Each of the next four articles in this series will deal with the four precursors, their sources, manifestations, and some solutions to their occurrences. While knowing how to handle troubled projects, an aggressive project whisperer should also know how to prevent them from becoming problematic initially. Remember, the old adage – “a risk in time, saves $2 million in public relations.”

The Project Whisperer Approaching a Troubled Project

By PH Lohnes, PMP

Let’s begin with a story…

This conversation occurred several years ago between a client and a project rescuer concerning a troubled project for which the consultant was being asked to service.

“Glad you could make it, today. We really need to get cracking on this project issue,” he said quite matter-of-factly.

“Happy to help, Mr. Blamet, my schedule was open when you called,” I said.

There was more small talk for another 30 seconds or so, and then I asked the big question:

“So tell me why you think you need my services on this particular project?”

The VP of R&D’s face fell immediately, and he swallowed hard and long,

“I believe this one is in trouble, and I can’t seem to get answers on its status,” he said.

“All right, let’s begin with this task — can you assign me an IT person that is skilled in the workings of your communications systems: email, file archives, reporting system?”

“Yes, but I do not understand, why communications?” he stammered.

I paused, looking thoughtfully before answering,

“I have usually found that the quickest method to discovering what is going on with a project is to review its actual communications between the project manager, the project team, and the project’s stakeholders.

Projects that are doing well compared to plan usually have up to date and accurate reports and communications to stakeholders while those that are suffering in silence, do not. It’s just a commonality I have found over the years in helping to rehabilitate troubled projects.”

Mr. Blame picked up the phone and asked his assistant to tell Mr. Pickering in IT to send up his best company communications tech, someone that knows how to retrieve emails, reports, and documents from the archives.

He hung up the phone, and turned to me, and said,

“How long do you think it will take to figure something out? Can we at least expect something by next week or so?”

Looking him in the eye, I told him, “Brad, I can tell you this afternoon once I review the communications dump. It is not brain surgery. Give me about 2 hours with your comm tech, and I should be able to have at least a preliminary report.

Does that work for your schedule?”

He simply muttered, “Unbelievable, I should have called you in sooner,” and then almost under his breath, “if you can deliver…” trailing off as he lowered his head back to the papers littering his massive, oak desk, indicating to me the interview was over.

From this point on in facing a troubled project, it is important to review only what has a minimal probability of being altered, faked, or reported in error. While you would hope that fakery is not an issue, troubled projects may involve a need to obscure reality, and this usually manifests itself in problem communications.

 

In reviewing the communications dump, I was able to discover two items that needed further investigation:

 

  1. Communications with stakeholders all but ceased 4-5 weeks ago, and
  2. project emails between the team members dropped almost 72% during the same period.

Once I had an idea about where to begin my review, I asked the comm tech for access to the project archives particularly the stakeholders register and the risk register. Upon completing the archive search, only one of the two registers was available: the stakeholders. It was evident that risk management was not a part of this project’s planning.

I made some calls to the key stakeholders, and asked two questions:

  1. Can you tell me what you believe is the current status of the project?
  2. When was the last time you received any communications (reports, emails, etc) about the project?

From the answers to these questions, I was quickly able to determine that something major had occurred about 5 weeks in the past for which the project manager had stopped all stakeholder communiques, and severely limited his contact with the project team. Again, the communications, or lack of it, led me to the issues that needed to be addressed with this troubled project.

Armed with the communications and answers from the stakeholders, it was time to meet with the project manager. However, before confronting a sitting project manager, I would suggest that you obtain his/her background/bio or organizational HR dossier so that you understand his/her history, experience, and skills for project management.

In this case, it was quite evident that while Todd was an excellent optical engineer, he was not trained in project management and the management skills and capabilities he might need to run a project successfully.

I spoke with Todd, and asked him what happened 5 weeks ago. His head almost snapped off his neck as the realization that someone else knew something about the problems with his project. I mentioned that one of the main functions of a project manager is to communicate truthfully, accurately, and timely all status and performance issues related to his project. Keeping bad information to himself was only delaying the inevitable since the project could not be carried forward in this manner indefinitely.

He seemed relieved that he no longer had to carry his secret, he told the story:

Five weeks ago, the sole supplier of the photonic phase-tuning circuit (PPTC) for the laser based interferometer deliverable of his project had gone out of business due to bad management. He had not completed a risk identification or risk management plan so using a sole-sourced component was not considered a risk event nor planned for with a risk response. When he found out that this critical component was not going to be provided, and there was not enough time to find, procure and deliver a suitable replacement, he panicked and tried to hide the fact by cutting off communications hoping he could fix it somehow.

 

In writing up the report for Mr. Blamet, I mentioned that had the project manager come to him, as the project sponsor, with the problem when it occurred, there may have been enough time to repair the issue without dramatically altering the schedule or budget of the project. Now, it seemed that unless Mr. Blamet was willing to allow the project the time and cost of second-sourcing the PPTC, it would be best to close down the project or roll it into next year’s R&D portfolio.

Using the best numbers from both the severely out-of-date project financials, Todd’s project notes, the organization’s best optical engineers, the cost of rolling the project forward would be roughly $420,000 vs. $485,000 to find, contract, and obtain a new source of the PPTC plus allowing another 6 weeks for the effort.

Since it would have past the time for the industry conference at which the organization was going to announce the new product (the laser interferometer), Mr. Blame decided that he would roll the project forward to next year’s R&D portfolio. Todd, the excellent optical engineer, but under-trained project manager, was released back to the engineering staff for re-assignment after the normal “dressing-down” for trying to hide the project’s problems from the stakeholders.

As the project rescuer, I used something I have discovered over the many years and many troubled projects:

Do not assume that what you read, see, or hear about a project from the standpoint of reports, EVM/EVT analysis, or performance measurements is accurate as to the honest status of the project especially if it is in trouble. Many project manager’s do not like nor want to deliver bad news, and are sometimes likely to try and stall or hide it while they search for a “workaround” that will get them out of their predicament.

 

I use the communications inspection as a very quick, but excellent methodology for finding out what is going on with a trouble project since it is very hard if not impossible to alter or mask communications given the networking and security technologies and applications that support the communications infrastructure used in most organizations today.

As a trouble project rescuer, be diligent and fair, but be skeptical until proven otherwise — use the project’s communications or lack of it to lead you in the right direction rather than being taken in by wonderfully prepared reports, excellent analysis profiles, or nicely purported presentations.