As a child and young adult I was very independent.  Regardless of the situation, if I was doing something I was determined to do it myself and not ask for anyone's help.  In my eyes asking for someone's help was akin to admitting defeat or somehow showing others that I was weak or incompetent.   My attitude was "If someone else can do it, I can do it".   How Naive.

 A couple of years back I was engaged on a project to help recover an agile project run amok.  The project was one of the first in the organization to use an agile development methodology and consisted of eight four-week sprints with six capability development teams.  The project manager was a very theoretical scrum master who was more concerned with having an agile "design win" than he was with ensuring the business sponsor was satisfied with the project result.  After about the third sprint there were significant issues with capabilities not working together, interfaces with external systems breaking, and problems with meeting sprint dates for committed capabilities.  To save the project, we had to take a number of steps that violated the purist agile model but were necessary if we were going to keep moving forward on the project.  Our implementation looked like a mishmash of agile and waterfall.  It wasn't pretty, but we eventually got the project done.

Since Microsoft Project's initial release in 1984 it has evolved  into an incredibly powerful and sophisticated project management tool.  One of those sophisticated features is calendars.  As one of my heroes  Spiderman says, "with great power comes great responsibility".  As a project manager, you can exploit some of the cool capabilities with Microsoft Project calendars, but beware, you could really tie your shorts up in a knot if you start getting too fancy with project calendars.  In addressing this topic, I want to start off by telling you what Microsoft Project help says about calendars then give you a few tips to help you avoid Project Manager hell when trying to develop a meaningful and realistic project schedule.      

Begin rant.

Recently I've noticed a trend which frankly really ticks me off.  My observation is that more and more project managers are becoming hyper risk-averse and demonstrating an unwillingness to accept accountability for the projects they manage.  One tell-tale sign which I've noticed is the usage of "matrixed" organization charts.  In matrixed organization charts, the project team is depicted using different types of team leads shown vertically and horizontally on the organization chart.  With a matrixed organization, team members may have a "solid line" reporting relationship to one manager and a "dotted line" reporting relationship to one or more managers.  Now, I fundamentally don't have a problem with the collaboration aspect that a matrixed organization enables; where I do have a problem is when the matrixed organization makes it difficult to pinpoint who has accountability for the project. 

Excerpted from The Project Management Advisor - 18 Major Project Screw-Ups And How To Cut Them Off At The Pass (Prentice Hall, 2004)

Virtually every (rational) project has at its core a need to solve some problem that is perceived by someone.  Problems can manifest themselves as barriers to getting something done (“we can’t possibly ship 10,000 units/week with our existing systems”) or as opportunity to doing something better (“we need to reduce the cost of processing purchase orders by 20%”).

In any event, there is a desire to do something tomorrow that can’t be done acceptably today. Admittedly, some of the most fun projects that I have worked on have been the “omigosh, we need to get this done or else” projects.   I have seen the greatest clarity of purpose on projects where there was a very real and tangible consequence to not completing the project successfully.  One outstanding example of this that affected virtually every business on earth was the Y2K computer scare.  One of my jobs was in ensuring that our mission-critical vendors were adequately prepared for Y2K and that there would not be any business interruption to our company as a result of a vendor’s failure to perform.

Tom looked at the clock.

“Midnight,” he said to himself as he took a sip of coffee. The milestone review for the second phase of the project was the next day. As he updated the project plan, he came across the organizational change management tasks that were supposed to be done in phase one that got pushed to phase two. He saw that the tasks were still zero percent complete.

“We’ll pick them up later,” he said to himself as he added the tasks to the phase three workplan.

During the milestone review the next day, Tom’s manager, Gayle, asked about the incomplete organizational change management tasks.

“Ran out of time,” Tom said. “We’ll get them done in phase three.”

“Isn’t that what you told me three months ago during our phase one review?” Gayle asked.

Tom looked down. “Um, yeah,” he said.

“Phase three is even more intense than phase two, what makes you think you’ll get the OCM tasks done in phase three if you didn’t get them done in phase one or two?”

“Gayle, we’ll get them done,” Tom said.

“OK, I’m holding you to it, Tom.”

Three months later, at the phase three milestone review, Tom walked through the workplan, then got to the OCM tasks. Tom knew what was coming.
​
“Still not done,” Gayle said as Tom avoided her gaze.

On a recent project my company was working with a frozen seafood manufacturer to help them bring a specialty frozen seafood product to market.

A huge component of getting this project done was the packaging; it had to be eye-popping and appealing while protecting the frozen seafood pieces inside.  After a number of design sessions with the packaging manufacturer, we received the finished packaging.  What was initially exuberance during the design session turned into disappointment when we saw the finished product.  Some of the graphics were a bit blurry, a re-sealable zipper wasn't included, and a clear window to view the contents inside was missing.  Our emotions went from disappointment to anger as the manufacturer told us it would be a number of weeks before a new delivery of the packaging could be done.  If we took this route, a key delivery to a very important customer of ours wouldn't be met.  What a pickle.

When I screw up, I have one way that I have found effective at helping me get through it and learn from it.

I write about it.

This is one of those royal jerk screw-up times.

Patty and I stayed at a hotel where we paid about $300/night. The room was clean and the location good, but the service and amenities were definitely substandard, certainly not something we’d expect from a $300/night room. The night before we checked out, we put together a number of issues and I sent it to the hotel’s customer service site, requesting a reduction in our room rate. The next morning, I talked with the hotel sales director about some of our issues. She was pleasant and empathic and said she would talk with the general manager.  A couple of hours later while driving we got a call from the sales director informing us that the hotel would not make any adjustment.
​
This is where the jerk part comes in.