A picture of a project action log with dates in the 'Target date' column repeatedly crossed out and replaced with new dates.

It’s an entirely natural tendency.  A default even.  We create an action log, or a template for meeting minutes.  We think about all the things we’d want to track – what’s the action?; who owns the action?; what’s the status?

And then we add another column.  Target date.  It makes perfect sense – if we’re giving people actions, shouldn’t we include a date by which we’d like to have that thing done?

Well, it certainly makes intuitive sense.  And if you only ever run one or two projects, it might not be obvious why this column is a complete waste of time.

There are three reasons why tracking target dates doesn’t really work:

  1. It’s the wrong thing to track
  2. It’s the wrong message to send
  3. It’s the wrong behaviour in the first place

Let’s take a look at each one in turn.

It’s the wrong thing to track

The items that we track in the action log are really just tasks that need to get done. Very often they don’t actually have a hard deadline driving them. There’s no imperative date by which they must be done. They’re just activities which need to get done in the general course of things and need to be tracked.

So they don’t necessarily have a real deadline driving the activity.  But the Target Date column suggests we need to put a date, so what do we do?  We pick an arbitrary date; a random date, or most typically the date of the next project meeting, and just say we’ll have an update on that activity at the next meeting. All the dates end up defaulting to become the date of the next project meeting (or the one after that). It’s not a really useful date to be tracking.

This leads to our next point…

It’s the wrong message to send

This leads to a further problem in the meeting itself, which is that every week we ask for an update on the task itself. Of course, perhaps there isn’t an update because there was no real deadline driving it and the update becomes, “Oh I haven’t got round to it yet.”  This is usually for a perfectly good reason (higher priority activities, day-job commitments, etc.) Because the target date is a false deadline, we feel no problem pushing it out.

All the target date column really does is demonstrate the project manager’s ability to add 7 to the last number that was in there

So, we push it out a week and the target date moves back by 7 days. This happens week after week: every meeting the project manager pushes the target date back by 7 days.  You may be familiar with this: project managers week after week just pushing back the target date by 7 days. All the target date column really does is demonstrate the project manager’s ability to add 7 to the last number that was in there.

This sends terrible message: it doesn’t really matter when the action gets done.

If you just keep on moving the date back, the message this implicitly sends is that the target date doesn’t actually matter. It doesn’t matter if you get it done by the target date because if you don’t, I’ll just push the date back by a week. The whole purpose of the action log is to make sure actions get completed. But the way the Target Date column is commonly used creates precisely the opposite behaviour.

It’s the wrong behaviour in the first place

And this is all because it’s the wrong behaviour in the first place. Rather than assign an arbitrary deadline, we should be asking people to make us a commitment to complete an activity.

Of course, if there really is a hard deadline driving a task or an activity, then put that in the task description. If there isn’t, then we don’t need to track a date.

BUT! What we can do is track the age of the activity: how long has that been sitting there undone?  This is a much better and more interesting metric to track as it does two things.  First, it implicitly tracks the date by showing how long it has been on the action log.  This can even create a bit of competition within teams to keep the age of their actions low. Second, over time, it helps to understand the true priority of the activity.  An activity that has been sitting on the action log for 26 weeks possibly wasn’t that important in the first place.

It’s often better to see the age of a task and understand how long it’s been hanging around, than it is to arbitrarily move some target date that has no effective meaning to the project. And far better to ask people when things need to be done and, if there’s a really hard deadline driving it, track the deadline in the description.

But don’t use a target date. It’s an exercise in futility.

The solution – a better Action Log template

Our action log template gets around this by removing the target date column and replacing it with the age of the activity. That’s based on the date that the activity got raised. From week to week you’ll be able to see how long that activity has been hanging around.

More often than not, sheer embarrassment will drive people to get the activity done because they don’t want to see that this is the 25th week that this task has been on the activity log. It’s much better to track the age of the task and the age will just tick up automatically week by week, rather than you having to move out a task visibly and show everyone that you don’t really care when the task gets done by.

Happy action tracking!  And if you have any tips and tricks for tracking actions (and making sure they get done), please share them in the comments.

Leave a Reply

Your email address will not be published. Required fields are marked *