Carl here. ProjHugger is for Microsoft Office Project newbies, enthusiasts, and zealots. I publish new posts every Monday morning, but you can add comments any time. This week’s ProjHugger post continues the “Top 10 problems new (and not so new) Project users have, and what you can do to ease the pain” series, which started like this: #10, #9, #8, #7, #6, #5, and #4.

Problem #3: Put far too much detail in a schedule

Using Project effectively is sometimes an exercise in restraint. Just because you can plan out work to a fantastic level of detail does not mean you should. Knowing when enough detail is just right is a fine art of project management.

The Devil is (in) the Details

This is a problem many of us have experienced first-hand, and some of us have likely caused (I for one am guilty as charged). It's a familiar scenario: you're responsible for building the project plan for a complex project that involves many different activities and resources. You run a rigorous top-down planning process to define broad phases of the project, and work with the team members in bottom-up fashion to flesh out the task list. And what a task list it is! Hundreds of tasks grouped into dozens of summary tasks. Many task durations are measured in hours. Task relationships are many and complex. Intermediate milestones have been flagged with deadline dates. Resources are assigned and leveled. And so on.

Plan the Work, Work the Plan

This is all goodness, right? Well, maybe. In my experience, very complex plans require a great deal of effort to keep up-to-date and accurate once work starts. That's true whether the project goes more or less as planned, or if for whatever reason (and there are many) the project veers off course into unexpected territory.

Consider the day in the life of the project manager after the project does has veered off course. Tracking progress and updating a project plan in the best case takes effort. When the team's in what I like to call fire drill mode--when promises that have been made to important people and partners are now in jeopardy, when reputations and even careers are at stake--keeping that detailed project plan accurate may fall by the wayside.

But wait! Isn't the whole point to use the project plan as our guiding light? You know: Plan the work, work the plan. Isn't it exactly when a project gets off track that we should invest even more time and effort into updating the plan? Maybe so, but that's just not human nature.

Who Plans This Stuff?

Part of the reason this is so is that complex project plans, are, well, complex. A Gantt chart with hundreds of tasks, relationships, and assignments is an awesome thing. It makes for an impressive poster to print on large format and hang on the wall. But have you noticed what happens to many such Gantt chart posters that are hung on walls? Scribbles start appearing; move this here, cut the duration of that, add this whole new phase of work we just discovered. In short, it becomes a maintenance nightmare. If the project manager is able to keep the details flowing into Project, what started as a complex plan just grows in complexity. The team that initially found some comfort in the weight of schedule details now finds it frustrating at best. Sooner or later some calm but disgruntled voice (never the project manager) on the team proclaims something along the lines of:

This schedule stuff is crazy. We're professionals. Let's just do what's right for the ________ (fill in the blank with: customer; partner; boss).

The frazzled team quickly lines up their support behind this calming and seemingly reasonable pronouncement. After all, they gave some input into the planning but the schedule monstrosity in front of them was never their schedule. It was the project manager's schedule. Said project manager may put up a fight for a while, but eventually gives in, shrugs his shoulders, and quietly abandons the project plan. The project however continues in perpetual fire-drill mode, following its own unpredictable course to who-knows-what resolution. The team members revert to whatever communication channels and issue-tracking tools they know best and feel most comfortable with (note: it's not Project).

Continue reading at projhugger.