When the usual economic constraints are combined with strategies of environmental frugality, it’s natural to look at the rational use of resources, and in particular human resources, in project management. But could indiscriminate tightening of the screws reduce our chances of success? Or of harming the people involved in the project, who are certainly capable, but above all individuals with their own desires and needs. In these times of great change, we project management professionals are all looking for meaning. This can be found in the project’s purpose; it can also be found in the way projects are managed: efficiently and with respect for people. Resource management has a major influence on these two parameters. It’s a subject that often goes beyond the project itself, requiring a thorough understanding of the issues and a certain amount of technical expertise. I’d like to take a closer look at this question together, first by clarifying the concepts of workload and needs to be satisfied, and then by looking at a concrete case study and the best practices to be implemented.
What is a workload?
Much more than an accumulation of figures supported by endless databases, workload is first and foremost a living entity over time. At the level of an organization, it is classically broken down into firm workload, corresponding to projects in progress and contracts won; probable workload measuring projects and contracts with a certain probability of completion (50%, for example); and projected workload, representing future tenders or those estimated on the basis of market analysis, and potential in-house projects. The mesh used to break down this stack is not constant. Coarse in the long term, when it serves the interests of corporate strategy (HR, sales, etc.), it becomes finer as time progresses, until it reaches a level of detail compatible with operational management imperatives. The “mesh” changes described in business processes are often referred to as “rolling wave planning”. This concept is often illustrated in the middle of the year, when the budget for the coming year is prepared. Anyone who hasn’t experienced this great moment of business decomposition should raise their hand!
Humans we are…
“What’s left to do?
– I estimate 100 hours to complete the activity.
– 100h?! But last month there were also 100 hours left, it’s not going anywhere!”
We’ve all been in a situation like this, and some of us have experienced it from both sides of the fence. What should we remember?
- Measuring progress is subjective; it may lack precision or be marked by the 90% syndrome, or in other words, the task that never ends,
- The workload is not stable over time, but becomes more precise as we learn more about the project,
- The one who does is not always the one that estimates!
- Caught up in the objectives to be met, it’s easy to fall into the trap of pressurizing and accusing.
Discussions about workloads and resources therefore inevitably include a human aspect.
Center of gravity of needs
Three fundamental needs will determine the center of gravity of the needs to be considered. This prism, a function of corporate culture, impacts the way resources are managed.
- The need of the project manager is to ensure the ability to complete project tasks on time. The project manager wants to know that “make or buy” strategy is being implemented, because of its influence on development costs.
- The business needs to adapt production capacity to the incoming project workload. This activity requires anticipation, as the actions it implies (training, recruitment) last from 6 months to a year, and sometimes longer. Intrinsically unstable, this management requires constant attention.
- Management’s need is for a complete, synthetic and longer-term vision of the company’s project portfolio, to support its strategic orientations (sales, organization, purchasing, HR, etc.), as well as arbitration between projects when lower-priority ones must be postponed or cancelled.
Individual needs
An essential but often overlooked cog in this engineering machinery: humans and their needs. Let’s use Maslow’s pyramid as an analytical tool. Let’s skip the levels relating to “physiological needs” and “need for fulfillment”, which are of little relevance to our study, and focus on the intermediate levels:
- The need for security refers to the need to know the project schedule and priorities, for the purposes of personal organization. It calls for respect for transition phases, as we are less effective at the start of a project when knowledge is still being built up. The same difficulty arises when we are involved in several projects, and our personal ratio of “production time”/”information acquisition time” sinks into deep water. Finally, it brings us back to the obvious need to have sufficient time to carry out the planned tasks, which militates in favor of involving the “implementers” in the estimation of project tasks.
- In a professional context, the need for belonging is often to support the company, its image and its values. So, let’s extend the “employer brand” with the “project brand” associated with the desired goals and with the “professional brand” focused on competence and continuous improvement.
- The need for esteem brings us back to the recognition of what makes up each person’s personal contribution. Over and above hours and skills, experience, involvement and affects are revealed. Let us know how to recognize them, we are not numbers, we are free men!
In practice
Let’s take the simplified case of an SME running several tooling projects in parallel. It has skills in mechanical design, automation, manufacturing and testing. Its ranks include project managers and even professional planners, profiles that are hard to find in certain sectors. Schedules are drawn up correctly, but there is no provision for consolidating the workload. Under these conditions, it’s difficult to answer the manager’s questions:
- Am I able to keep up the schedules?
- Am I optimizing the use of resources?
- Do I need to adjust the capacity?
Let’s help this manager by setting up a company-wide RBS (Resources Breakdown Structure), to harmonize the categories of resources assigned to tasks. Let’s set up the calendars, indicating at the very least the company’s holidays (typically May, August and December).
For nominative management of workloads, let’s inject information on the actual availability of workers into the schedules. Finally, let’s consolidate this information at regular intervals in a data visualization tool. And that’s it! We are now able to compare the workload and capacity, by project and by skill, at the different levels of the RBS. Decisions are then taken from this: smoothing, prioritization and reinforcement to cope with peaks. These decisions are then fed back into the schedules, and the life of the projects continues as usual… until the next exercise, which will inevitably take a week or two. Easy, right? Nothing could be furthermore from the truth, and numerous pitfalls lurk in the shadows, waiting in the background for even the most discerning manager.
Bringing reference systems into dialog
The first obstacle often encountered is the poor dialogue between reference systems. Or more clearly, the difficulty in understanding each other’s works and projects. Let’s take the example of a project requiring the development of embedded software. The project team will issue a requirement for the “software developer” skill and move on to the next task. On the business side, it’s not that simple. If a software developer gets the job off to a good start, he or she is followed by a unit tester and then an integration tester. Finally, an expert checks the results and validates the development. One skill on one side, four on the other! Worse still, the “expert” resource can be critical, and the workload associated with tests are highly variable. The project is simply unaware of this. As you can see, taking the time to establish a dialogue between repositories is essential for effective communication around requirements and the shared identification of risks.
Analyzing a project request
Another classic situation involves a project where the demand for resources has risen sharply in relation to the consumption of hours observed up to now. This kind of break in demand typically falls into two categories, which you need to know how to spot. In the first case, a change in the project phase, such as the contracting and parallel start-up of numerous work packages, justifies this sudden increase in demand. There’s nothing wrong with this, and we must keep up with it to keep the project on schedule.
In the second case, the project falls behind schedule but does not change its planned completion date. In this case, the project’s remaining work is potentially excessively parallelized, compressing a spring that is likely to relax later. It is important for the business manager, concerned with efficiency and fairness in the mobilization of resources, not to stop at the raw demand of the project, but to understand and challenge it. When in doubt, looking at the schedule, the physical progress and its evolution sheds light on many situations.
Best pratices
Let’s summarize the best practices we’ve gone through together:
- Maturity and centralization of the scheduling
- Long-term project planning
- Shared calendars and defined capacities
- Dialogue between business and project repositories
- Deployment of the resource management process across all projects
- Analysis at each RBS aggregation level
Two final recommendations are worth mentioning to conclude the overview:
- Tolerance in the workload-capacity balance
Bringing the workload-capacity gap below a certain threshold requires an effort incompatible with the cyclical nature of the resource management process. The last few meters of the adjustment exercise will therefore be based on exchanges and coordination, rather than on the utopian and pointless quest for perfect balancing.
- Catalogs or workload charts for repetitive projects
The benefits are twofold: getting teams involved in a project to capitalize on operational REX and providing a powerful estimation tool for the project initiation phases.
In conclusion
Whatever the organization and size of the structure, it is necessary to manage resources to ensure that projects progress as smoothly as possible. The context of the company and its projects must be carefully analyzed to model and equip this management. Aspects of change management, which are not developed in this article, must be considered, otherwise potentially harsh opposition will emerge because of assimilating resource management with an abusive policy of surveillance and control. On the strength of its benchmark, setec eocen supports the implementation of resource management solutions to meet a wide variety of needs. A forthcoming article will focus on the implementation of PPM solutions – Project Portfolio Management – a specific and expert aspect of our service offering.
