Fundamental principle being forgotten . . .

Task Status is Binary (and written)
by Conrad Weisert, January, 2007

© Information Disciplines, Inc., Chicago. This article may be circulated freely as long as this copyright notice is included.

QUESTION:
What does each of these reports tell us about the status of an assigned task?

50% done

95% complete

Finished (except for a couple of minor loose ends that we'll take care of this weekend)

We pose that question in our project-management courses. Most participants who've had any experience at all with non-trivial projects respond without hesitating:

"Nothing!"

Sometimes the response is accompanied by pained laughter, as participants recall the futility of squeezing those final loose ends from a task assignment that was already checked off as virtually done.

So, how should we report task status?

Successful project managers know that there are only two possibilities for an assigned task:

complete
The reporting team member asserts that the task deliverables called for by the corresponding task specification in the project plan are on file and are available for use or examination.

incomplete
The reporting team member provides (or reaffirms) the following information:
  1. the date when the task will be complete.
  2. the number of remaining person-hours or other resources required to complete the task.
  3. an explanation of the causes of any new slippage, overrun, or remaining obstacles.

Doesn't everyone already know how to report task status?

Apparently not.

During 2006 I came upon several articles in mainstream trade journals that actually poked ridicule at rigorous project planning and status reporting. In February I reported on the movement to do away with project planning altogether ( Have We Lost Our Minds?). It also turns out that some radical methodologists are just as vigorously opposed to rigorous and honest status reporting.

"While short, daily stand-up meetings are a far more effective way of communicating status than written reports, many traditional managers still insist on documentation. These reports take valuable time—time that could be better spent developing working software."

Scott Ambler, Software Development magazine, April, 2006, p. 45.

Fortunately, Mr. Ambler meant the above only as part of an April Fool article, but similar assertions are being made in all seriousness by many self-appointed "experts" who ought to know better. You can find them in trade journals and web logs.

Status reporting in an unplanned project

Why would anyone claim that submitting a written (paper or on-line) status report is a waste of "valuable time"? What could be quicker than going down one's list of assigned tasks checking off those that have become complete in the current reporting period, reaffirming unchanged target dates for tasks in progress, and noting any unusual setbacks, obstacles, or problems? With suitable project management software to prompt one, the typical time to complete a status report is less than the time to walk down the hall to a conference room before a meeting even starts.

So under what conditions would it take a long time to prepare a status report? When there's no project plan! A well-structured project plan includes a network1 of task specifications. Each team member's workload consists of a subset of the tasks on the plan.

In the absence of such a structured workload, a team member must improvise vague and selectively optimistic descriptions of what happened in the current reporting period or what's planned for the next period:

That's the sort of thing that Ambler may have had in mind in claiming that it takes valuable time to prepare a status report. But note that those assertions are exactly the same kind of reporting that's done orally in a typical "stand up meeting". It's almost always possible to say something positive about the status of one's assignments, and it's just human nature to do so. But such vague comments convey even less information than the worthless "95 percent done" report.

Such quasi-status-reports may make everyone feel good. We made progress this week. Good things happened. We successfully dealt with the few bad things that happened. But all of that is divorced from the context of what was supposed to happen. I've had the sad experience more than once of reviewing two years' worth of rosy status reports for a project that turned out to be unfinishable within an acceptable cost! Substituting oral reporting for vague written reports will merely make the true status even more obscure.

On the other hand, a binary status report forces each team member to confront reality. An assigned task is either complete or it isn't, and if it isn't then the approaching (or past) target date renders vague hopeful comments futile. Neither the individual project team member nor the project manager can bluff the funding authority about the real status of the project.

Should we also have team meetings?

While project team meetings are inappropriate for collecting status reports, they can serve some positive and valuable functions:

Regardless of the size of the team, a daily meeting is much too frequent and will be seen as burdensome. Nor should the format include "round robin" calling upon each participant. Attendees should be free to raise issues and make comments, but shouldn't have to listen to empty recitations by colleagues who have nothing to contribute.

Most important of all, the project manager mustn't use a meeting to update his or her own knowledge of the project status. I've witnessed with extreme discomfort sessions where the project manager looked embarrassingly weak in front of the whole team and lost their respect. And never, never ask in your own meeting " Who's taking care of . . .?" or "Does anyone know about . . . ".

Coming soon

More related articles:


1 -- Sometimes called a "work breakdown structure" (WBS) by project management specialists.

Last modified January 7, 2007

Return to IDI home page
Management articles
Project management links