Measuring Project Progress

There comes a time in the life of a project in which the PM will find himself having to answer the fateful question: “where are we?”

At the dawn of my activity in this field, many years ago, the main purpose of the PM’s job was summed up by the creation of a huge Gantt (the more detailed it was the better ), which was punctually printed, or at the time “plotted” and hung in the office behind the PM’s desk.

Then the project started and ….

Unfortunately, the reality had not been informed on the path traced by the PM and despite good intentions they could be separated.

But here unexpectedly the atrocious question fell from above on the head of the unsuspecting PM: “WHERE ARE WE AT?”

Following days were generally full of excited phone calls, rounds of emails, exchanges of Excel, screams and anxieties to be able to collect data and update the evil Gantt (which was the more detailed and the more difficult to update).

The idea of Twproject was born in that troubled era (we are talking about the distant 2001) precisely to solve this situation.

Twproject should:

• be a tool for the whole company
• being able to collect information where the activities are carried out, i.e. at the operational level
• provide updated data and management tools to the PM
• present aggregate data and statistics for top management

Without the aid of a project management software such as Twproject, the PM, once the data was collected and the Gantt updated, had to make a manual estimate of the project’s progress percentage, the extreme synthesis.

66.6%

I consider it “diabolical” to synthesize an infinite number of parameters in a single figure, but basically this is what is required of us.
A good PM will still be able to extrapolate a plausible datum, but how useful can a software be to helps us with this evaluation?

Manual progress estimation

Twproject provides you with a view of the main parameters, so that the PM can base their considerations and then manually enter the progress.

Let’s see an example: the data of the development project of Twproject 7.0.007.

Without going into too much detail, the project is managed in Scrum-like mode; we have a backlog where we collect all the ideas, improvements, bugs in the form of ToDo. Sprints, lasting 20 days, represent the Twproject releases.

For each sprint / release we move the ToDo’s that we are going to develop from the Backlog.

This is the structure we currently use:

On each sprint resources (Scrum team) are assigned with the estimated hours to close the ToDo’s.

Here is how Twproject summarizes the data useful for determining the progress.

Looking at the figures, I see that 69% of the time has passed for this project, 82% of the to-do’s have been closed, 84% of the hours worked.

Surely a project in good health that could be estimated at 80% of completion.

Leaving this task in the hands of the PM, however, has two negative implications:

• top management does not have this information available in real time and therefore the PM must update the assessment when necessary
• the subjectivity of the assessment is a harbinger of discussions and requests for clarification

Automatic progress calculation

To solve these two problems, the solution was to introduce an automatic mechanism for calculating the progress of the project.

To do this, we have identified the most common situations and combined them to allow you to easily model the behavior of even complex projects.

Let’s see in detail the other types of calculation besides the manual one:

Worklog done on estimated

I estimated to work 100 hours I worked 45, I’m 45%.
Optimistic. It models well both the hourly package support contracts and the budgeting and study phases.

Completed phases over totals

The project consists of 3 phases; after the first two they are at 66%.
A rather brutal calculation, but easy to understand.
It can be useful for projects consisting of many repetitive phases.
Eg: installation of 200 identical appliances.

ToDo closed over total

I have 100 ToDo’s on the project / phase, I have closed 50, I’m at 50%.
Suitable when the project activities can be summarized in lists (see ToDO lists in Twproject).
This calculation is particularly fitting with Agile methodologies.

ToDo weighed closed over total

It is a refinement of the previous one with which the “severity” of the ToDo is considered.
If I have the same 80 ToDo’s as before, including 40 “Blockers” and 40 “low priority”, if I close the 40 blockers I will have a higher advancement than closing the low priority ones.
It is a stimulus to induce to follow good practices

Encountered costs over estimated or budget

You have an expenditure (or budget) forecast of 100, if you have spent 30, you are at 30%.
Model different types of contracts related to SALs.
It also works for some no-estimate iterative Agile methodologies
Not my favorite algorithms 🙂

By dates

90% of the expected time has passed we are at 90%
Everything is always fine; by far my favorite!
Unfortunately, it cannot be applied often in real projects. Typical is the use in construction in some “waiting” phases such as settling, drying and the like.
However, it is very useful for modeling annual support contracts and similar situations

By phases weighed

I have deliberately left this type of calculation for last because it is the most flexible and “refined”.

It is based on the percentage of progress of the phases that make up the project, weighed on the importance of each of them.

Suppose we have a project consisting of three phases that can proceed in parallel, the first of relevance 60, the second 30 and the third 10.

If the progress of the first stage is 20%, the second 50% and 100% the third, the result will be

60 * 20% + 30 * 50% + 10 * 100% = 37%

When a phase advances, the project will automatically advance as well.

If it seems complicated to give relevance, don’t worry, Twproject levels all the values even if the total does not make 100.

Conclusion

Returning to our example of the sprint Twproject 7.0.007, the most suitable automatic formula is the ” ToDo weighed closed over total “, because the sprint is completely determined by the set of ToDo’s that compose it.

If we edit the project and change the type of calculation we will immediately see the effect:

So slightly better than the 80% expected per sensation.

Twproject allows you to use progress calculation rules not only on the project, but also on each phase, sub-phase, sub-sub-phase and so on.
In this way it will be possible to easily model even complex and heterogeneous behaviors.

For the Twproject 7.0 project we have development partners; in their case we have purchased packages of days and for the progress we use the “done / estimated worklog”

I could therefore have a phase of study progressing with the work done, an Agile development phase progressing by completed ToDo and a maintenance phase progressing by time.

Easy, powerful, intuitive, automatic, objective and above all without too much effort for the PM!

The information relating to the progress is then visible in Twproject not only in the summary lists but also in specific dashboards that high-level users can independently verify without disturbing the team.

Of course, all progress changes will also be tracked in the project’s statistical data, but we’ll talk about this in another post as well.