This website covers knowledge management, personal effectiveness, theory of constraints, amongst other topics. Opinions expressed here are strictly those of the owner, Jack Vinson, and those of the commenters.

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."

Repairing MT after db corruption

Can blogging replace communities of practice