First of all, I have to clarify that this blog post is not(!) about progress bars as we all know well from installing software or from downloading files. But this post is about the visualization of progress as we are used to see for instance in production planning or project management software systems.
I want to demonstrate the difference between a "classic" progress bar and a forecast oriented visualizaton of progress. The second is a new approach that has been currently implemented in our latest Gantt chart application we developed with our NETRONIC Web Application Framework and the feedback from the users was enthusiastic.
Usually, the progress of an activity – like an operation in the production planning field or like a task in the project management field – is expressed by a percentage value. This value is calculated based on the feedback posted by machines or the staff and establishes a relation between a schedule on the one side and the reality on the other side. This way a planner or controller will be able to recognize deviations of the actual data from the original planned data.
The measurement units of the feedback values may be time based (e.g. 5 hours of the total work time needed have been processed) or volume based (e.g. 100 pieces have been produced). But for the following discussion it does not matter whether we are considering progress based on time or on volume.
Now, let’s have a look at some simple samples, which we see very often during our daily work. The following figures are showing samples of three activity bars enriched by additional progress bars:
The length of each progress bar is determined by multiplying the length of the corresponding task bar by the percentage of the progress.
I guess you agree with me that in each of the three cases above we can roughly estimate the progress percentages by relating the lengths of the progress bars to the length of the corresponding activity bars. Of course, we cannot rate the exact values – for instance, if it is 31%, 33%, or 35% with the first activity –, but we could enhance the display by adding text labels:
Now – even when assuming a linear progress –, things are becoming more difficult, if we are faced with bars that are overlapping working periods as well as non-working periods (the latter symbolized in the following figures by the gray rectangles):
In this case, text labels are essential, because without them the user will not be able to get even a rough idea of the real progress percentages.
So far, we have considered the issues a user faces when trying to determine the progress percentages by studying graphical representations. With the latest proposed visualization you could be satisfied now. But now a serious and essential problem arises: What will you do with these progress percentages? Do they really help in any way to realize the state of your project or the production process you are responsible for? No, they don’t! Can you tell me if 33 % is good or bad? No, you cannot! Because the "what should I have reached" figure is missing. Maybe instead of 33% I should have reached 50% instead. So, are you able to estimate whether a task is in time or behind schedule? No, you are not!
Hence, this kind of visualization does not really help you! The problem with those percentages lies in the missing target values. Hence, there is no way to compare an actual value with the corresponding planned one and there is no way to determine the deviation.
Let’s have a look at some outstanding phases of progress and the corresponding possible visualizations:
As you can see in phase III (just in time), the progress bar ends exactly at the time now line if the activity is on time. But please note, this is only feasible if we presume the following:
These are essential restrictions to which we shall return later on.
Now, let us focus on phase II (too early) and phase IV (too late). Instead of showing “normal” progress bars only, we have added bars with different colors to mark an exceeding progress (green bar) or a delay (red bar). Both additional bars have one end at the time now line and the other end at the progress bar. This way they indicate activities that are too early or too late. And it is a first step to enable the user to quantify the amount of the deviation of the current progress from the planned one, because we have related the planned progress to the actual value.
Very often it makes sense to have a forecast end date for an activity instead of a progress percentage, because such an information can be more meaningful. If there is “only” a percentage value, then it is up to the user to interpret this value and to determine the new expected end of the activity.
Now, if we have a forecast end date for an activity, we can show precisely the impact of the progress deviation. An alternative graphical representation of phase II and phase IV could be as follows:
This is a more direct and intuitive way to show the effects of for instance a progress delay. And if we enrich this kind of diagram by additional load or capacity curves (see for example our DemoApp for the NETRONIC Web Application Framework), then we have a great tool to recognize additional capacity needs or free capacities for the resources.
One question remains unsolved: What will be the best way to determine the forecast values?
Let’s have a look at phase IV (too late). As long as we can accept the restrictions mentioned above (continuous progress feedback and linear work progress), we can calculate a forecast end date (fe) by simply adding the work time between the end of the progress bar (tp) and the “time now” date (tn) to the planned end (pe) of an activity:
In the same manner, we can handle phase II (too early):
As we all know, the above restrictions are unrealistic. In practice, a continuous reporting of progress only exists in fully automated systems where the machines have sensors that are connected to the data processing system. And in production systems with a high degree of human resources involvement ad hoc feedback is hard to implement.
Especially in situations where due to some exceptional interrupts the progress has been reduced or even stopped it may be critical to suppose that the rest of an activity will continue with the same speed as planned; i.e. the progress will not be linear.
Therefore, we should leave the calculation of the forecast end dates to the business logic that has to be provided for instance by the connected planning system. Or it may also be possible that the planner and his experience will be needed to decide what the impact of an altered progress will be. This approach has been proved in practice as we know from some of our customers. They gained a positive feedback from their users after they had replaced the “classic” progress representation in their Gantt charts by a forecast oriented view.
We first enhanced the graphic by inserting additional texts to make it easier for the user to quantify the progress percentages. Then we established a relation between the planned and the actual progress. At the end, we changed our focus from the visualization of the progress percentage values towards the presentation of forecast end dates.
Of course, it depends on the specific circumstances you are facing, which solution and which kind of presentation fits the needs of your customers best. But I hope you have an idea now of how critical the visualization of progress itself by a simple bar can be.
Are you interested in more visualization tips for Gantt charts? Read these blog posts:
Position Nodes in Gantt Charts with a Snap
Visual Production Scheduling with Multiple Resources
9 Basic Design Tips for User Friendly Gantts
For more than 20 years, NETRONIC has been engaging in the development of intelligent graphical planning boards, based on our Gantt components for .NET, ActiveX and ASP.NET (VARCHART XGantt) and for Java (VARCHART JGantt), as well as on HTML5 and JavaScript (see the NETRONIC Web Application Framework, NWAF for short).
Want to learn more about visual scheduling with Gantt charts? Contact us.