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:
- Communications with stakeholders all but ceased 4-5 weeks ago, and
- 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:
- Can you tell me what you believe is the current status of the project?
- 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.