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 Truth about Getting Your Point Across…and Nothing But the Truth 

What we learned was more than what we had anticipated; not necessarily about their purchases, but about how they worked and the importance of urgency versus importance in their jobs.

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. 

Pat hated giving board updates. As the head of integration of a recent acquisition, Pat was required to provide monthly updates on the integration to the board. There was one board member, Cary, who focused on how the integration project was being done, questioning Pat on initiative processes, minor deliverables, and detailed assignments. Cary was experienced in acquisition integration and spoke from a position of authority, but Pat was also an experienced professional with six successful integration projects completed. Because of Cary’s experience and strong personality, the board chair permitted Cary to deep-dive on minutiae. Pat’s frustration with being micro-managed boiled over to the rest of the executive team, creating a tone of distrust between the board and executive team. Pat’s updates became less and less transparent, with Pat reasoning that more information was only fodder for Cary’s drilling. The integration project ultimately was completed, but the trust relationship between the board and executive team was significantly eroded.

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.