Tasks and Time

Tasks are always associated with time... Tasks are started at some point in time and they are completed at some point in time.  We're almost always interested in the duration (how long it takes) from the Start Time to the Completion Time.

Start Time and Completion Time are the biggies, but there are a few more timestamps that we're often interested in capturing (especially when tasks are performed by humans).  Here's my list:

• Assignment Time - the point in time when the task is assigned to a person (or group).  In most of the process applications I've implemented we don't assign a task to a person until that task is ready to start... but sometimes we do know who should work on a task long before the task should start. If we relate this in terms of an appointment on your calendar, this would be the time when you made the appointment.

• Scheduled/Estimated Start Time - the point in time when the human should (ideally) start working on the task.  In many process applications we don't predict when a task should start - it simply starts when the process flow reaches the task.  Explicitly scheduling or estimating start times can be very useful if you need to determine whether or not a specific process is "on track" to complete on time.
• Ready To Start Time - the point in time when everything is ready for work to begin on the task.  
• Start Time (aka Actual Start Time) - the point in time when the human starts working the task. It's our fondest hope that the Scheduled Start Time, Start Time and Ready To Start Time are all the same - but when dealing with humans they seldom are.

• Scheduled/Estimated Completion Time - the point in time when the task should be completed.  This is really an expression of "how long the task should take".  In most cases I've seen this set by adding the expected duration of the task to the Start Time - but there are cases where a hard and fast completion time is critical if you need to know whether or not the process can complete on time.
• Completion Time (aka Actual Completion Time) - the point in time when the human completes the task.

There are also some optional timestamps we need from time to time that you may encounter:

• Reassignment Time - It happens... and there can be multiple of these for a single task instance.
• Task Cancelled Time - Often good to know - not every task gets executed to completion.
• Task Escalated Time - This might possibly be redundant, since reassignment and cancellation are very common elements of task escalation.
• Task Suspended Time - Sometimes things come up and work on a task just has to stop. As with reassignment, this can happen multiple times per task.
• Task Resumed Time - If a task was suspended, you will almost certainly want to know how long it was suspended.

Analysis of all of these timestamps can help you figure out whether or not your process is running smoothly.  For example, whenever the actual Start Time is later than the Scheduled/Estimated Start Time you may have a problem... but to determine where the problems lies you'll need to take a look at the Ready To Start Time.  Was the human slow in starting the work, or was there a delay that prevented the human from starting the work?

In all honesty, I've never worked with a client who captured all of these timestamps for every task... and I am certainly not advocating that you should complicate your solutions by capturing this information unless you really need to.  Just don't be surprised in those rare instances that you encounter a process analyst who needs this level of detail.

If you've encountered requirements for capturing additional task oriented timestamps (or you have better descriptions/names for these timestamps), I'd love to hear about them.