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.      

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.

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. 

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.

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:

So okay, Microsoft Project is a super flexible tool in helping you as a project manager define your project tasks, dependencies, and resources.  Quite frankly, though, the workplan you define in MS Project is only as good as the thought that goes into it.  Too often I've seen savvy MS Project users completely bungle a project because, while the tool was being used appropriately, the workplan didn't make sense to the project team and didn't reflect what really needed to be done.  The team consistently expressed confusion about what needed to be done by when because the project workplan wasn't reflective of the actual work which needed to be done.  Great exercise in using MS Project, but poor execution of the project.  Blech.