It was one of my earlier projects as a project manager.

I spent a lot of time planning the work out, calculating the critical path through the project, and getting everything ticked and tied prior to kickoff. The kickoff meeting went well with the exec sponsors. I set high expectations on my ability to deliver. The team was largely silent during the kickoff meeting, letting me do my thing.

The first few weeks in, I reported that we were on schedule and budget, and within scope; we were on our way to a stellar delivery.

At week four, a few of the tasks started slipping. “No problem, we can make it up,” I thought to myself. I reported that we were still on schedule.

The next few weeks saw more slippage, and some team members began expressing concern about our ability to meet dates. I reported that things were still okay, and we were working through a couple of minor issues.

After a couple more weeks, the concerns continued to crescendo, and one of the exec sponsors caught wind that there might be some problems on the project. He set up a meeting with me and some of my leads to deep-dive on what was going on. It was one of my most uncomfortable meetings at that point in my young career. I was the last one in the room to acknowledge there were problems.

Read more at ProjectManagement.com.

Mr. Creosote.

Some of you may know the name. He was a character in Monty Python’s The Meaning of Life. Portrayed by Terry Jones, Mr. Creosote ate and drank massive quantities in a French restaurant. At the end of the meal, the server (played by John Cleese) offered Mr. Creosote a wafer-thin mint. After some objection, Mr. Creosote agreed to eat the mint, which caused an unfortunate reaction.

Those of you who know the skit (or just searched for it) know my description cleaned things up quite a bit. While most could have easily eaten the small mint without any adverse consequence, for Mr. Creosote it was just too much to handle. He had hit a saturation point.

This analogy applies directly to how much newness an organization can absorb before things start breaking. It’s the organization’s saturation point.

Read more at ProjectManagement.com.

Recently, my wife and I were watching a college football game between two highly ranked teams. Deep into the third quarter, only a few points separated the two teams. The quarterback took the snap, scrambled while looking for someone to pass to, and let the ball fly. The ball was intercepted by a linebacker and, with three teammates as an escort to block opposing players, made his way to the end zone.

The linebacker, thinking he was in the end zone, dropped the ball to celebrate with his teammates. Upon replay, the linebacker dropped the ball at the 1-yard line—and a quick-thinking opposing team player pounced on the ball while the linebacker and his teammates reveled in what they thought was a touchdown.

Then the referee signaled “fumble with recovery by the defense” at the 1-yard line. The look on the linebacker’s face was one of “Oh, $*&$!” after he learned his all-but-guaranteed touchdown would now go down as a fumble with a recovery by the opposing team. Even worse was the fact that two of the linebacker’s teammates ran by the ball bouncing at the 1-yard line, more focused on the celebration than the ball. Fortunately for the linebacker, his team still went on to win the game.

Afterward, the head coach was being interviewed. He stressed the importance of doing the little things right—including not dropping the ball before hitting the end zone. I can only imagine the conversations that the linebacker had with his coaches after the game.

Read more at ProjectManagement.com.

No show, third in a row.

Anna, a PM, holds a weekly Zoom status meeting with Jade, the project sponsor. At the beginning of the project, Jade was a great partner and a strong supporter for Anna.

As the project went on, Jade’s involvement became more and more sporadic. Sometimes she responded to emails, other times she didn’t. Anna sent Jade status reports and rarely got responses. The rest of the project team noticed Jade’s declining involvement and was growing concerned. “Does Jade still care?” Anna would hear from the team.

Anna, a professional, did her best to keep the team motivated and engaged, but she too was wondering what to make of Jade’s disappearing act.

*** *** ***

I’ve been a sponsor, worked as a PM with sponsors, and advised both sponsors and PMs. By and large, sponsors and PMs are both trying to do the right thing—understand a problem, figure out how to solve it, and work together to implement a solution that addresses the problem.

Even with the best of intentions of all concerned, the sponsor/PM dance can feel more like one is doing a jitterbug and the other a waltz. Often, it’s the PM who sees the difference and has trouble getting the sponsor to take the same steps. This is not only frustrating, but can materially impact—if not completely tank—the project.
Before we get too far down the road on this topic, I’d like to lock down a number of assumptions regarding the sponsor:

Read more at ProjectManagement.com

While searching for a job online, Manesh found a listing that caught his eye. “Wow, this looks perfect!” he thought as he read through the position requirements. Then those three dreaded words reared their ugly head:

“Leadership experience required.”

“Dang,” Manesh thought as he closed his laptop. “This is so frustrating. How do I get experience when everyone is expecting me to already have the experience?”

You’ve likely experienced this earlier in your career, or may be going through it now: Potential employers want leadership experience that you don’t have, and you don’t have a clear path on how to get that experience.

When looking to grow leadership skills, this can be a frustrating dilemma. How do you get the experience you need and build great leadership skills when your paths are limited? Here's a potential path...

Read more at ProjectManagement.com.

As project managers, we’ve likely been faced with getting a one-line explanation of what a sponsor needs—along with a deadline. Depending on the organization, there could be a range of responses—from doing a back-of-the-envelope calculation, getting people in a room to estimate the work, or using a comparative initiative to assess feasibility.

Now, I’m not here to criticize your organization’s approach, but I have found that having something that enables the PM to rough-cut an initiative using some standards can be helpful in providing a lens on whether a date is even remotely achievable. This is where the work-back timebox model comes in.

Read more at ProjectManagement.com.

Dean, a project manager, was conducting a project post-mortem with Tania, his VP.
“Why the month slip, Dean?” Tania asked.
“Well,” Dean started, “we didn’t get on the vendor’s calendar early enough for integration testing. They couldn’t schedule us in when they needed us, so we had to slip.”
Tania shook her head. “Hold on, Dean. The vendor is Conset, right?”
“That’s right.”
“If I remember correctly, we did a project with them last year and the same thing happened; we didn’t get on their calendar early enough and it caused a slip. Were you aware of that?”
“I wasn’t.”
“I specifically asked the project team to include that in the lessons learned. If I recall, Tarun was the PM. Did you talk with Tarun or look at his lessons learned?”
Dean looked down. “Um, no.”
Tania kept her gaze. “Honestly, what good are lessons learned if we don’t bother to use them? This was clearly avoidable.”
“I’ll make sure to document this for the next time, Tania,” Dean said.
“Do you look at lessons learned from other projects?” Tania asked.
“Well, not really, they’re all over the place and in different formats. It’s kind of like finding a needle in a haystack.”
“Unbelievable. We’re willing to make the same mistake over and over and not bother to learn from past mistakes. What a waste.”

Read more at ProjectManagement.com.

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.