Please login or join to subscribe to this thread
The problem is showing a percentage of progress. This is a clasic mistake in software for example. What does mean 80% of progress in a program? How you are meassure it? What does mean 80% completed in a document? So, it is better to meassure how far or how close to the objective you are and compare it with the remainder amount of effort that is needed to reach it. I mean. Supposse you have to walk 100 meters and you calculate you will do that into 1 hour. If after half an hour you walk 30 meters then is something you have to do to recover. It is not "good" or "bad" just there is something to do to recover and get the objective of walking 100 meters in 1 hour.
To build on Sergio's feedback, when you have these long drawn out activities, you will need to find a way to break them into smaller chunks to report objectively on their status.
For higher resolution monitoring, you need higher resolution plans.
Often the deliverables tracked have a number of internal steps and interactions prior to completion. When I have issues where we need to monitor them closely like an item on the critical path which his a high schedule risk, I track the lower level activities.
Some groups are good at planning their own work and when I ask them for the details, they show me their detailed plan in a tool such as Project. When they do, that is goodness because I know they're proactively planning and not just reacting.
Otherwise I create a network diagram of the detailed plan. Each activity/box in the network will show planned and actual start and finish dates, and % complete. While you still have the uncertainty of % complete, the activity durations are short and where I get the real information on progress is reviewing that detail level plan with the performing team to know what's going on, rather than just some dubious KPI.
If I understand Kiron's and Keith's approaches correctly then it mean to have more granularity in scheduling and it makes sense. However, what happens if task can't be split and it's progress is non-linear? In that case I would go with Sergio's approach of effort driven metrics. For example, the program I am currently working with has lost of activities with highly non-linearised progress and I use the comment from the team about the effort left or other appropriate context to report to the program board.
Thank you for your answers !!
The best solution that i found is to split the deliverables according to their common points and, obviously, two major group come; the first is generated documents and the second is certificates (for example after proceeding to a test (supression system, valve check... a certificate have to be generated)). I figured out that all engineering documents (generated documents: Drawing, maintenance plan, design note...) have been done. But the certificates no one has ever been done. So, i present once prgress for engineering document mentionning 100% and another progress for certificates mentionning 0%. Next challenge for me is to figure out the weight of each group and make a correlation by a formula to reflect real prgress...
I do agree with Sergio.
I've found it useful sometimes to define what specific degree of completion means. For example, you could define in your project management plan that a document's degree of completion will be as follows:
70% complete draft
80% draft reviewed
90% draft edited
100% document completed
Please note that using percentage is one way to measure the degree of completion. Also note that you want to apply it to the smallest unit of work. Maybe you want to track your document at the chapter or section level?
As Sergio explained, there is great value in focusing on what's left to to do, rather than what's done.
In many cases when working a tight critical path problem, they are non-linear with multiple activities proceeding in parallel. This is why I use the network diagram. They easily allow showing how the multiple parallel paths come together. In that case,% complete for the entire activity may be somewhat meaningless, but it is not difficult to tell if the plan is on schedule, and the resulting variance if not. On fast moving plans with near term deliverables, I would update the network diagrams daily to evaluate progress and plan any needed mitigation actions.
Please login or join to reply