The single biggest problem for a project during the execution phase of the project is staying on track. Despite all the best planning, having the best team and anticipating all the possible pitfalls projects have a knack of developing unforeseen problems.
There is a common falsehood about tasks which is promoted by project tools such as Microsoft Project. The myth is that tasks can be partially complete, i.e. a task can be 10% or 20% done.
If a task is thought of as a goal then the lie becomes obvious – either you have achieved your goal or you have not. It’s a black-and-white, binary proposition. If your goal is a vague and imprecise statement of intent, like “write some instructional documentation”, then it is complete the moment you start. As soon as you put pen to paper you have “written some instructional documentation”.
On the other hand if the task is well defined and has a measurable deliverable then the goal is not achieved until it is delivered. For example: “complete a user guide and a technical manual”. This task definition is much more useful because it has a clear measure of success. The only time the task is complete is when the documents are written, have been reviewed and edited and are ready for publication. You are finished when there are no more changes to be made.
The danger in believing that tasks can be partially completed is that it gives you a false sense of security. Because 50% of a task can be such a hard thing to define, people will tell you they have completed 50% of the task when they are 50% of the way through the time allocated to it. It might be the case that 90% of the task remains but they will insist that since there is 50% of the time left there must be only half of the work left, too.
This misconception is particular entertained by those people who believe that time is elastic. That is that you can cram any amount of work into a particular length of time, it just depends on how hard you work.
These are the people that will tell you one of two things:
- After working 10 days on a 20-day task they announce that they have only done 10% (i.e. nothing but 10% sounds better) and that they will make up the time. This is despite the fact that they fought tooth-and-nail in the first place to get 20 days allocated to the task. Truth be told they are simply rolling their delays from one task into the next and picking up speed as they accelerate through the project towards non-delivery.
The second case is that they report good progress all the way through the first 15 days of a 20 day task and then their progress slows down so that on successive days they go from 95% complete to 96%. They will certainly overrun their task and be claiming three weeks later that the last 1% of the task is nearly done. The old adage of the “first half of a task takes 90% of the time and the other half of the task takes the remaining 90% of the time” is all too often true.
It is much better to break tasks down into smaller steps and to simply report on their completion. Then if a particular task misses its completion date it automatically triggers an adjustment to the schedule. There is no ambiguity, there is no confusion.
Nick Jenkins is an IT manager with 10 years experience in software development, project management and software testing. He’s worked in various fields of IT development in Australia, Britain and the USA and occasionally he learned something along the way. Now he lives on the banks of the Swan River in Perth, Western Australia, and he publishes the odd guide to help aspiring IT professionals. Nick’s website can be found at www.nickjenkins.net.