Information Technology Reference
In-Depth Information
“Raise Purchase Order,” “Release Test Plan,” “Get Approval for Change
Control 21.”
What should be their granularity? Because action items must be
assigned to individuals (or teams) and tracked separately, they must be
sufficiently granular to be understood by the receiver. Our recommenda-
tion is that an action item list should be quite granular and specific. For
example, “Tim to forward John's e-mail to Mary” is a unit of work that
can be verified in the next meeting. This is not a high-level document
mapping to a software life cycle. It is lower and more detailed than the
Project Plan. To the extent possible, all action items should map to some
entry in the Project Plan. (Tim's forwarding the e-mail to Mary is part of
the “finalize design specifications” activity in the Project Plan.)
Action item lists should be as uncluttered as possible. The list should
be limited to the item, the person taking the action, the date that is
expected, and some remarks. The item should, because of its very nature,
be action oriented. The name of the person in the “Person” column is
the person doing the task, who may or may not be the person “responsible”
for the task. Managers may, in the end, be responsible — having their
names in the columns does not serve much purpose, unless they will do
the task themselves. The date is often specified at a degree of granularity
that is not appropriate. Use flexible terms such as “Next Week,” “ASAP,”
“On receipt of approval,” whichever might be most suitable. They will be
taken more seriously. Often, “Remarks” columns double as minutes of
meetings and become longer and longer until the entire column is just
ignored. It is not necessary to record every remark made about the action
item in this column. Keep it short so that people read it.
Does one need an action item list when one has a Project Plan (in
MS-Project or some other PERT based tool)? Yes, one does. They serve
slightly different purposes. A good, easy-to-read action item list is key to
day-to-day monitoring and management of projects.
Demos
Software seems to be working well until it goes into demos. Something
always seems to go wrong. This may be one of the many errors popping
up at an inopportune time, although many suspect that arranging a demo
is itself a cause for triggering misbehavior. We do not subscribe to such
superstitious ideas although we would like to draw attention to Bill Joy's
observation that the word “demonstrate” has embedded in its etymology
the same roots as the word “monster.” So maybe there is something to it
after all.
