Procedures to measure project progress (I)

The purpose of this post is to start a set of blog entries to share my thoughts about ways to measure progress in project planning and to explain methods about how to do it.

Delimiting the problem

The field I want to talk about is the progress measurement in projects which are represented by Gantt charts. These projects consist of a set of activities with logical dependencies among them  and which are done by resources, that can be people or machines. Besides, resources can be over-allocatable.

The aim of the planning is to fulfill the project deadline, to have a cost lower than the budgeted money and assess if it is possible to carry out the project with the available company resources. This job is complex and is usually aided by the use of planning, monitoring and controlling project management tools.

In my opinion, on measuring progress it is important to distinguish two levels:

  • Task level. It is the most common analysis scope and consists of measuring the progress inside tasks. Although there are several possibilities, to put it simple, it will be supposed that it consists of specifying the work already finished in the task in which the measure is being taken.
  • Project level. In this level the project is taken into account as a whole, with all its tasks, to know how it globally goes. It is a scope which is not as studied as the task level one and, therefore, is less known by people too. I will use the term global progress to call to this type of progress as well.

Having said that, I will focus on the measurement of progress at project level. In this area, the key is to answer the next two questions: is the project delayed or ahead of its planning at the present time? how much?

The project manager needs to know the answers to those questions because they allow him to make decisions. For instance, if there is a certain accumulated delay in a project, the project manager could order to devote more resources in order to recover the delay and arrive on time.

Progress at project level by doing a weighted addition of tasks

This is the method I will explain in this post and is one of the methods that maybe first comes to your mind if you think about this problem. I will explain it by answering two questions which are mandatory if you define a method to measure progress at project level.

Which tasks contribute to calculate the project progress?

In the method I propose all the tasks are considered. The rationale of this answer is that all the tasks which make up a project  are important and, therefore, all of them must contribute to the global progress.

How is the contribution of each task ?

The thing here is to make the decision about the way in which each task influence the global progress. Two strategies can be thought:

To use the average

The principle which supports this option is equality. It sets that contribution is the same for all tasks.

To use a weighted average.

It implies to break the equality principle and to set that contribution to the global progress is not the same for each activity. There are many ways to establish equality and, regarding to the global progress calculation, the point is to identify the task feature(s) that makes them different. So, which are these features ? Well, from my point of view, the feature which distinguishes them concerning to progress is the amount of work a task consists of. This is so because, having tasks with different amount of hours causes that, for the same progress value at task level, the amount of remaining work to be completed per task was different.

The bad effect of ignoring the different amount of remaining work of each task can be seen in the next example easily: If we have a two tasks project, one having 100 work hours and another 10 work hours and we receive a progress of 10% in the firs task and 90% in the second one, we get the following global progress value using average: ( 10 + 90 ) / 2 = 50%. Half of the project is already done according to the global progress, but, however, the remaining work to finish is much more than 50%.

To correct the behavior described, the method I propose is to add progresses per task weighing the progress value of each task by the hours percentage the task represents with regard to the  project total hours. With the average calculation the project manager thinks that project goes very well when reality is not so good but, however, using the weighted average, he sees a value which approaches project state better, he gets a global progress value of 10*(100/110) + 90*(10/110) =  17,27%.

Finally,  I would not like to end up without stressing that  in NavalPlan users can  measure global progress choosing among several options and the method explained here is one of the alternatives.

A taxonomy problem in project management

Project management according to PMI is the application of knowledge, skills, tools and techniques to project tasks to meet the project requirements. It is made up of a set of activities which can be grouped in five areas:

  1. Initiating
  2. Planning
  3. Executing
  4. Monitoring and Controlling
  5. Closing

Different applications can be used to help to carry out the activities above and they are usually called project management applications.

Throughout my experience, however, the previous name is not the most suitable one because it causes two undesirable situations.

The first one relates to the fact that the inclusion level is too broad. It is too general to say that a program is a project management application.

The second situation happens when the use of the term causes confusion. Maybe people taking part in the communication attribute different meaning to that software category. There are two reasons which explain this fact from my point of view:

  • I do not know programs which cover all the process areas and, in case they exist, they are a minority and are not widely spread.
  • Project managers use a set of programs which cover just some of the mentioned areas (but not all of them).

Therefore, if we take into account both things, we find scenarios where people use the term project management to mean qualitatively different applications and that is the cause of the confusion.

The solution I suggest to avoid these problems is to use the process area name(s) to categorize applications and add this prefix to the project management term. Besides, many times this last part will be implicit and not necessary. As an example, we can say that NavalPlan covers (2) and (4) areas and, thus, would be a planning, monitoring and control tool.

Finally, I would like to end up with a last perception about applications which have among their features:

  • Bug tracking.
  • Time tracking.
  • Wiki
  • Calendar
  • Document management
  • etc

These applications are very common and I do not know a specific term for them, apart from project management. They are used for coordination, for resource collaboration, etc during the execution of certain type of projects.

Having said that, the idea I want to share, is that, according to my proposal, I would call them executing project tools, (3) area.

I will go in depth about project management tools categorization in a later blog entry.