In project management, evaluating the work load that insists over the resources shoulders plays a fundamental role for the project Happy Ending.
In an ideal world where you work with infinite resources, projects are always in-time.
In the real world, on the other hand, we often have to deal with teams simultaneously involved in multiple projects, which have to manage daily activities and several emergencies.
In this case, an indication on “sustainability” is essential to understand who and when will be able to positively bring our project to completion.
Duration and effort: which is the difference?
At the beginning, I was surprised by the difficulties that some of our customers face to understand the difference between duration and effort. For many of them the ratio was one to one.
This type of approach is not only wrong in management terms (a phase that lasts 30 days could require an effort of one hour e.g.: waiting for material from a supplier), but implies a total and exclusive allocation of the resource on that one activity.
If this approach works well in the analysis and budgeting phase, it cannot work in the planning phase.
A good question to ask yourself at this point is: “How many hours can a resource work on his project per day?”
To answer correctly, several parameters must be considered:
- the obvious working hours (full-time, horizontal or vertical part-time)
- holidays, illnesses, permits etc.
- what has already been allocated to other projects
- routine activities
- spot activities already planned
The first two points are intuitive and partly out of the PM’s control, so we will analyze the others and we will see how they contribute to generating the “work load” of a resource.
Project activities
A project, or rather a phase, always has a start date, an end date (therefore a duration, usually expressed in working days), and some resources assigned on it.
Each resource must perform the estimated activities for a total of days / hours (effort).
Without going into too much detail, we can evaluate the load on a resource by dividing the estimated hours by the project/phase duration.
For example: a 10 days phase with an effort of 20h generates an average load of 2h per day or 25% (assuming 8 hours a day).
Easy, at least before the project starts.
But once it get started, what happens if for the first 5 days I have not been able to work on this project?
It happens that I will have to work 20h on 5 remaining days, with a load of 50%.
Therefore in the project activities the hours “not yet done” give an incremental feedback to the load, accumulating in the remaining days.
Having the opportunity to compare the “ideal” situation (the one planned by the PM, without taking into account the done/ not done), with the “real” one (which takes into account the feedback) gives many food for thought and possible corrections.
It is interesting to note that the failure to work on the planned project can be read from the worklog records.
The worklog is an excellent indicator from this point of view, it is a sort of “heartbeat of the project“; if the heart doesn’t beat the project is dead!
What said above consider the “average load”.
Twproject allows you to plan all the hours or just a part by assigning them directly on the calendar (there are various tools to do this), but the substance does not change; 20h needs to be done in the 10 days of the phase.
If a resource works on several projects at the same time, the calculations can become complicated and for this Twproject helps us by presenting this information in an optimal way.
Balance your resource as we do!
with Twproject you can manage your resource allocation, insert worklog and resolve peaks.
Try Twproject now!Routine Activities: Do you work eight hours a day?
They are the Cinderella of activities.
Many of us, despite being in the office for 8 hours (at best :-)) can only dedicate a percentage of their time to “real projects”.
We spend a lot of time (note: I didn’t say “we lose it”) in activities not attributable to a project.
In my case: reading incoming emails, department meetings, phone calls, supporting colleagues.
In addition to these generic ones, there can be other more specific ones such as updating, training, document archiving, backup verification, maintenance etc.
How much time do I spend on these activities? Almost 3 hours a day!
I know this with some confidence because, with the help of Twproject, I recorded daily , for years, the hours spent and I know that, on average, the 38% of my time goes like this.
If I were planning a project that involves me 100% for a period longer than a few days, it would definitely go out of dates.
The funniest part is that if someone asked me how many hours I can work on one thing every day by instinct I would say “eight hours“. To avoid these errors it is important to have objective data on which to base our choices and analysis.
The worklog recording is the basis for good planning, not just for good cost control.
I know very well that this is an additional effort and in fact when I tell our clients to record the “lost” hours, the first reaction I get is of the “reluctant / snorting / I get up and walk away” type.
This is why it is important that the worklog registration activity is as “painless” as possible.
On this point Twproject is unbeatable; you can record the worklog at the close of the To-do, with the start-stop buttons, on one / two / three weeks, on the whole month day-by-day, etc .. The overhead is minimal!
With the aim of “measuring” routine activities, having a “cauldron” available where you can put everything that cannot be traced back to a project greatly lightens the recording by helping us to “reach 8“.
We always advise our customers to create a non-project “cauldron” (or “basket” or “BAU” Business As Usual for the more chic ones) which starts on 1/1 and ends on 12/31 for the recording of non-project activities .
After a few months of recordings, you can better understand how long our resources can really devote to their projects.
It also happens that it is necessary to take a look at what went into the “cauldron”; perhaps it could be structured to better “classify” routine activities.
For example this is what we use in Twproject:
We understand how to use the worklog to measure the hours we can devote to “real projects”, but how do routine “projects” behave from a work-load point of view?
More or less like real projects. The effort is “spread” evenly over the period.
There is a small difference: they do not have incremental feedback.
Let’s take an example: my support activity to the development team takes me “on average” one hour a day.
If I don’t get support requests today, it’s not necessarily true that I will receive twice as much tomorrow.
In practice, the effort is considered constant over the entire period.
Its graphical representation is a constant bar:
Spot activities
These are activities that take place within a “contract” without knowing first how much and when.
The best example is the interventions to be made on request as part of an annual maintenance contract.
In this case, you can create a “project” that has the same dates as the “contract” and assign resources if necessary.
Since it is difficult to predict the overall effort first, for simplicity we can not specify it and leave it at zero.
If, on the other hand, you want to track it, because a package of hours has been sold to the customer, you can enter them, these will not be considered by the load anyway.
Therefore, unlike projects and routine activities, spot activities do not generate a “spread” load over the duration of the project / contract, but only on that days in which the activities are planned.
With Twproject this can be done directly by assigning ToDo’s or by using the work plan.
A practical example: Giorgio’s workload
Giorgio works in a production company and has been dealing with a specific product for many years, he supports customers who buy it and participates in the development of his customizations.
Giorgio’s daily work is therefore composed of projects of a different types, let’s create them in Twproject and see how his workload looks.
Giorgio has a general customer support project that lasts all year and takes up more or less a couple of hours a day. This project is routine:
And this is how the workload will look like:
Giorgio is then involved in a project for a custom product of one of his customers. The phase in which he is involved lasts only 10 days and his effort is estimated at 40 hours.
This is the new assignment:
And the new workload evaluated:
Finally, Giorgio has an active support contract with a specific customer, with a 40-hour pay-as-you-go package. Giorgio does not work on this project unless the customer calls him. This activity is spot and even if we insert the effort, the load does not change.
But what happens to Giorgio’s load if the customer calls him and they schedule an intervention on the product? Giorgio will create a scheduled ToDo and this will modify his load.
As can be seen from the image, the commercial activity has stolen some time from the Analysis project and in fact the hours that Giorgio will have to dedicate to it in the remaining days have increased.
These are just 3 simple examples managed by Twproject but which give a good idea of how to map the different types of business activities. With Twproject 7 we have worked a lot on these aspects and introduced a tool, which using the information of the load “suggests” a “sustainable” project end date for the team.
We have also introduced a tool to quickly solve load peaks and overlaps, because not always everything goes smoothly like our Giorgio, we will see this tool in a dedicated post.
