Task slippage isn't the point
Matt Harmer developed a High-falutin task slippage metricproject management metric:
I have a rule of thumb for determining how much undetected slippage will occur for any task. Its pretty high-tech and may challenge those of you who don't have high-falutin university degrees.
The amount of undetected slippage that can occur on a task that was scheduled to take X, where X is in the range of one hour to one week, is X.
Pretty great eh? In other words if something is supposed to take a day and something goes wrong that causes the task to blow-out then, taking into account the realities of people and project dynamics, its likely that it won't be until one day after the task was due to finish that it will be detected by "management".
I have to say that I agree with his observations. Projects that operate with a date focus invariably have tasks that are not so critical that they MUST finish on the date that was promised when the plan was built (or even if it has been statused recently).
This is yet another argument in my mind to the value of managing the project, rather than managing the tasks. What should be of primary importance is the impact of those tasks on the project, not whether an individual task was completed "on time." One way that Critical Chain Project Management helps with this is to ask for "how much more time do you need" to complete a task, rather than "are you going to be done on time." This lets you have conversations like, "if you are able to finish a day earlier, we can get started on the subsequent activities and bring in the project sooner." Or, "that's fine, there is another set of tasks that we are focussed on completing in the next two weeks to bring the project in early."
3 Comment(s)
A recent post over at Knowledge Jolt with Jack discussed the importance of keeping your eye on the big picture and not becoming consumed with any particular task. This is a lesson that can be learned from chess as well, and was described in The Book ... Read More
said:
Isn't this great? Your idea of "due date-less" tasks is very much in line with the Theory of Constraints idea of Critical Chain Project Management. This is a method for managing projects where you don't ask "when will you be done," but "how much longer until you are done." This implicitly acknowledges the fact that individual task timing estimates can never be 100% correct. Rather than load all the uncertainty into each task, pull it out to the project as a whole. And when you are managing the project, don't look to the individual dates but to the status of the project overall.
Leave a comment
KJolt Memberships
Heureka!
My experience is that often the key is simply in keeping the tasks flowing and making sure nobody drops the ball.
A due-date driven system almost guarantees that any given task will only be started at its due date, minus an optimistic minimum time that the task performer thinks it will take. There is an increasing probability of task level failure depending on both physical and logical distance from the task source.
To counter that I have been tinkering with a concept of "due date-less" tasks, primarily driven by task flow and "task landing time", rather than individual due dates.
If you as a process owner can maintain an overall view of the status of all tasks, and if you have the means to re-direct tasks on the fly, you will have substantially improved your chances for better on-time performance.