Top Ten Problems, #3: Put far too much detail in a schedule

This blog post is one in a series of 10 based on a presentation I developed, “Top 10 problems new (and not so new) Project users have, and what you can do to ease the pain.” I first gave this talk at a Puget Sound PMI chapter meeting. I later gave an updated version of the talk to my local chapter of the MPUG Project User Group. As you might expect, at the PMI meeting the discussion tended more towards the broader project management issues, while at the MPUG meeting more towards specific features in Project. In fact at the MPUG meeting I had my computer projecting and we played around with Project features that related to some of the issues I brought up.

Top Ten List

In the process of writing the Project Step by Step books (starting with the 2000 edition and continuing through the current edition) with my co-author Tim Johnson, I observed first-hand some of the problems Project users encounter. Some of these problems are straight-forward gotchas in the software, but many common problems were really about how people define, understand and practice project management. In this and the other posts in this series, I’ll guide you through each of the top ten problems new or inexperienced project managers encounter, and what you can do to help identify and address these problems.

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).

Let's consider one example and then an alternative. In my world of technical communication, I do on occasion develop schedules for new content deliverables. One truth of technical communication is that it is for the most part a well-understood domain; we who practice it have pretty clear and well-defined activities, and shared understanding of intermediate and final completeness of our tasks and deliverables. Say my team is assigned to develop a technical whitepaper about a new technology or product, Foobar. My rigorous, metrics-driven and detailed project plan might look something like this:

TIP  Click the screenshot image to see a larger view.

This plan is 20 working days in duration and involves just two resources. My plan lays out a clear sequence of activities; I've left nothing to chance. Is this an appropriate level of detail for this work? Maybe, maybe not. That depends on a number of factors, including but not limited to:

Do I personally know the writer and editor resources? Do I know their capabilities, strengths and weaknesses? Can they work together well?

Besides the publishing task what are the key intermediate tasks if any that I as the project manager absolutely need to know were completed and when? (As we sometimes say in the project management vernacular, what's the level of control I need in the project plan?)

Now consider this alternate schedule for the same deliverable. Same overall duration and same resources:

It's clearly simpler, but is it better? Again, that depends. If the resources in question wanted a lot of prescriptive guidance about how to complete their work, this schedule probably isn't going to answer their questions. That doesn't make it a bad schedule, however. Let's make a distinction here between workflow definition and task management. My complex schedule illustrates in great detail the workflow to be followed. The simpler plan does not. The workflow definition (in this case creating a whitepaper) need not be captured in the project plan, however. It can live elsewhere. A workflow definition is really just an elaboration on what needs to be done, by who, and in what order to produce some desired end result. The project plan puts time boundaries around that workflow: follow the workflow to create a whitepaper, but scale it to fit this specific timeframe.

Another consideration is which version of the plan are the resources more likely to feel accountable for? I have found that more often when not, with the small teams of knowledge workers I work with as a project manager, I get better results when our discussion focuses more on what the deliverable should be, and what factor most drive the project (time, or scope, in my world), and leave it to the resources themselves to work out the detailed workflow that they think will best meet the end result we all want.

Hands-on with Project Step by Step

To read more about this blog entry's subjects in the two most recent editions of Tim Johnson's and my Project Step by Step books, see the following cross-references.

Managing a Simple project

• Project 2007 Step by Step: "Managing a Simple Project," pg. 2.

• Project 2003 Step by Step: "Managing a Simple Project," pg. 2.

Understanding what drives your project

• Project 2007 Step by Step: "A Short Course in Project Management," pg. 475.

• Project 2003 Step by Step: "A Short Course in Project Management," pg. 475.

###

Comments

[Kyler]

I am used to writing articles for the journals which might be found at http://www.pdfqueen.com the pdf search engine on periodical and ebooks. Now I'd like to write for blogs, how can I do that?

[PMP]

Hey Kyler don't worry. You just need to get an account. Try wordpress.com or blogger.com. Good Luck!