Dependencies and Rate of Accomplishment
Review of Rate of Accomplishment
From our earlier blog post, we discussed task dependencies and how understanding these connections improve our probability of project success as it pertains to schedule. Additional information on dependencies can be found in our book Project Management of Complex and Embedded Systems.
Monitoring Rate of Accomplishment means Measuring
So what does it look like to monitor progress? We can start by sufficiently decomposing our project task via the WBS and provided description information in the WBS dictionary to the smallest level. This smallest level would make answering the question, are you finished with the task either a yes or a no. This is a binary (yes, no – 1, 0) easily understandable assessment of the state of completion.
Accomplishment, Team Behavior – Saving Face
If you are a project manager or a project team member with any significant experience, you will not doubt have witnessed instances where our team members may over inflate the state of progress for a task. This inflation is not known immediately, or when we periodically ask for assessment of state of completion. We find out just before delivery. Sometimes it is difficult for a team member to say they are not able to keep up. If a specific progress metric is established, we can make the measurement more progress assessment more objective and less subjective. That is, we report we have accomplished x amount per t time, rather than I believe I am on track or my gut says all is well.
Understanding this curve or rate of progress allows us to predict where we should be at a given time on the curve. We then need to measure the actual progress and compare those two to see if we are on track, ahead of schedule or running behind schedule. Below we provide a number of curves that our activities or rate of completion may follow. We essentially use this as a road map, then measure the actual progress, and respond as needed adjusting the schedule or method of achieving the objective when we encounter deviation from this planned or ideal performance.
The agile approach relies less on an atomic decomposition and more on a continuous monitoring of the actions underway to meet the immediate objective. This progress is measured though as a collection of progress via the very simple burn down chart. This chart meets the same sort of requirements as afore mentioned rate of accomplishment charts. We monitoring closely the rate of accomplishment this is recorded in the burn down chart. We can see if our sprint is likely to achieve the objectives or if we are likely to not. This chart will be updated and reviewed daily providing clear feedback allowing us to assess the probability of success and perhaps take some other actions rather than wait until hopelessly late.
Check Lists and Accomplishment
Check lists can help, but check lists show what is missing, not what may not happen within the expected time. Check lists are better as a summary or review. For example, just prior to the gate to see if what is expected has been done. To predict we need to measure
Summary of Rate of Accomplishment
Estimates have a bad reputation for being inaccurate. That is bound to happen when people are estimating things they may not have much experience. The word is, after all, estimate. Some refer to it as guess-timates. To ascertain the validity of the estimates, were we even close, requires monitoring the actual performance (EVM, Burn Down Chart or some specific metric) to the planned performance. This helps with the prediction, are we going to deliver this task, this objective within the time we planned. Correctly done, this comparison puts us in the position to “predict” the progress. We will know ahead of the delivery date, transition time, that we are probably going to be late in advance of the date. We can work to find other ways, and we can begin managing expectations.