Any Project Manager who has had engineers on his team, especially software engineers, will be all too familiar with over estimates of task completeness. The following scenario is how it usually goes:
PM: “How far through the Comms Manager are you?”
SE: “It’s going well, I would estimate that I am about 50% done.”
PM: “How is the work on the Comms Manager Going?”
SE: “I am almost done, about 75% complete.”
PM: “Is the Comms Manager completed?”
SE: “Yes, it’s pretty much done, 90% there.”
PM: “Have you started work on the User Request Factory yet?”
SE: “Not yet, still finishing off the Comms Manager, I am about 95% done.”
PM: “How the Comms Manager going?”
SE: “It’s progressing, 98% there.”
PM: “How is it going?”
SE: “I would say it’s about 90% complete….”
This is a classic problem within task management. The task was 50% complete after one week, which would lead the project planner to expect the project to be complete at the end of two weeks. But after 6 weeks, it has still not been completed. This situation makes planning the project very tricky, dependant tasks will become affected, the critical path could become affected and the whole program could slip. The Software Engineer was due to start the User Request Factory after they had completed the Comms Manager, this task could have been reassigned after week 2 if it was believed the Comms Manager task has slipped. More resources could also have been assigned to the Comms Manager task if the team working on it were struggling to complete the task within the required time.
So, what is the solution to this problem? At Zircon we have taken the following approach to mitigate against this:
1. Ensure that everyone on the team understands project management! Why the project manager is interested in project progress, and how it can affect the projects programme. All of our engineers are trained up to the APM’s Introductory Certificate, this course leaves the engineer with the ability to run a single disciplined small project so they will be able to put themselves in the position of the project manager and understand what he/she is doing.
2. Asking “When do you think the work will be complete?”, can give a better judge of when the task will be completed, rather than using percentage complete. Though this can often lead to a similar problem of being told “by close of play on Friday” each Monday morning, and lead to planning headaches when filling out the tracking Gantt chart!
3. A customer will often like to know how complete the project is. After all, the project being undertaken is often part of a larger programme of work which needs to be planned and managed. In order to achieve this, and have greater confidence in the value we are giving the customer, we regularly use Software Readiness for Production (SRfP) metrics. This is a MISRA (The Motor Industry Software Reliability Association) standard to measure project progress. Tasks in this method are only ever marked as:
0%: Not Started, No Progress
25%: Work Started
50%: 1/2 Work Complete
75%: Work Complete, but not signed off.
100%: Work Complete and signed off.
The engineer estimating progress is only using the subjective values of 25%, 50%, or 75%. This value is combined with a re-work factor (which is a measure of the amount of potential re-work that may occur, this is adjusted throughout the life of the task and will approach 1 as the task completes) and a block size factor (which is a measure of the scale of the task in relation to the other tasks in the project). The values for individual tasks are combined to give an overall project percentage complete. This method still relies on some subjectiveness on the part of the engineer estimating progress, but we have found that it allows for far more consistent results and reduce the embarrassment of telling the customer the work is 99.9999% complete!