Excerpted from Six-Word Lessons to Avoid Project Disaster

As a young hot-shot information technology (IT) project manager I was convinced that I had it all together. I was bound and determined to show all those more senior to me how to deliver successful projects. It wasn’t until I messed up not one, not two, but three projects simultaneously that I grew up and recognized I wasn’t all that I thought I was. While that period in my professional career was particularly painful, it was also some of the best learnings I could have gone through. Since then I’ve had successes and failures, but the failures became less frequent because I learned to get comfortable with others providing a critical eye on my work and helping with the necessary precision questioning to keep me out of hot water. This is the genesis behind Six-Word Lessons to Avoid Project Disaster.

​“I’m in!” Lori, the department general manager said to Caleb.

Caleb had just joined Lori’s department from a competitor where he had worked for two years after college. This was his first one-on-one meeting with Lori. Lori had a strong reputation as a people cultivator and looked for opportunities to grow her staff with in-the-moment learning opportunities. She was about to get that opportunity with Caleb.

“Great to hear. I can get going on the plan right away,” Caleb said.

“That’s great, now what do you need from me?”

Caleb stopped. “Um, I’m sorry?”

“What do you need from me?”

“Uh, nothing.”

“Nothing? Do you have the support you need from my management team?”

“Well, I was going to talk with them about it.”

Seeing the teachable moment opportunity, Lori decided to help Caleb think things through.

One of my column readers recently sent in this question: One of our senior project managers left abruptly in the middle of a 3 year million $ contract. What experience and education would you consider in promoting a replacement? 

Ooh, good meaty problem.  Not so simple a solution.

A sad tale of a how a sponsor/PM relationship killed a project...

Exec identifies a need for a project and nominates self as sponsor.  PM gets assigned to project and assembles project team.  Sponsor is vague about problem to be solved other than "we need a new system".  PM can't communicate problem to be solved to the team because he doesn't understand what the problem is.  Sponsor continues to ask for more and more things to be included in project, PM doesn't have courage to say no.  PM treats sponsor as "that person in the corner office" and doesn't know how to ask for help, so he escalates everything.  Sponsor has to make some tough decisions but is unwilling to do so because of the political fallout.  PM provides bad information about decision alternatives so sponsor ignores him.  Due to changing priorities project no longer makes sense to do, but PM lobbies to keep the project going.  Sponsor loses interest because there are bigger fish to fry.  PM and team are disillusioned because sponsor doesn't care.  Project dies a slow death.  R.I.P.

While this is a fictional story, you can undoubtedly relate to most of these things happening on one project or another in your career.  The sponsor/PM partnership on a project is one of those "soft skill" factors that gets frequently overlooked when assessing a PM's skills but is a key determinant in the success or failure of a project.  Under a healthy partnership, the sponsor and PM work as a singular unit to ensure the project gets what it needs to be as successful as possible using only as many resources as absolutely necessary to secure success.  Under a less than healthy relationship the project will undoubtedly cost more in time and money assuming it even gets completed at all. 

Throughout my career I've been both a sponsor and a PM and have first-hand experience in how this relationship needs to work from both sides of the desk. Through my experience, I've locked down on ten truths which I feel are crucial to securing a healthy sponsor/PM partnership.  See if these resonate with you:

On the 1980s HBO show Not Necessarily the News, comedian Rich Hall created Sniglets, which dictionary.com defines as “any word coined for something that has no specific name. Words like Jokesult (When someone insults you, you call them on it, and they say, "It was just a joke.”) and Chwads (discarded gum found beneath tables and countertops) were born to humorously explain commonplace things or actions. I’ve created 20 of my own project management and leadership sniglets; some made up words, others repurposed words or phrases. I hope they resonate with you and put a bit of humor in your day.

Some time back I was in a meeting with a project manager who presented the status on his troubled project to the project sponsor and other executive stakeholders. This project was of high interest to the sponsor and stakeholders as they were depending on its successful completion to make some major changes in their respective organizations. The project sponsor asked the project manager a very straightforward question:

Why is the project slipping?

The project manager went into a long, meandering monologue. The sponsor interrupted and asked the question again. More meandering from the project manager. Seeing the sponsor and other stakeholders’ growing frustration, the project manager’s boss stepped in and said they needed to do more homework and would come back the next day better prepared. The next day, the project manager’s boss presented the status and answered questions--along with a new project manager.

Bill was a newly appointed project manager over a mission-critical systems development initiative. Ann, Bill’s boss, trusted Bill to lead the initiative and gave him the latitude he needed to execute without getting in his way. While the two worked well together, they did struggle in one area: decision-making. They had several instances where Ann was surprised by key decisions Bill made but didn’t inform Ann. Bill also didn’t benefit from Ann’s experience on several issues and made uninformed decisions that hurt the project. Ann asked Bill to include her more on decisions, but Bill took that as him needing to come to her on decisions he could have made on his own. Bill grew frustrated with his perception of Ann micromanaging him, whereas Ann just wanted to ensure she was in the loop on key decisions. The project ultimately got done, but not without a lot of friction between the two.

Friction that could have been avoided.

Project screw-ups mean wasted time and money and can irreparably damage your relationship with business partners if they perceive that you are at fault—in any way. If you’ve been through a post-mortem for a project that failed, you’ve likely heard one or more of these “we didn’t” excuses:

“We didn’t define the problem we were trying to solve.”

“We didn’t communicate what we were doing.”

“We didn’t manage our project risks and issues.”

“We didn’t create a good project plan.”

“We didn’t have the right sponsorship.”

“We didn’t work well together.”