Effective resource management in projects

Resource shortages are one of the most common problems I encounter when analyzing a project business. This is also the easiest problem to solve. Not only is it simple, the solution is also largely free. All businesses have a hidden resource pool that is just waiting to be put to use.

If you are a line manager or a project manager in a business that runs projects, you have already met the hidden resource pool. You actually meet them every day. Of course, it is your employees and project participants. The reason why resource shortages are so common is that most of the employees’ worktime is lost on tasks that are not adding value. This waste can be as much as 90% of the time. This may sound impossible, but I’ll give some examples.

Waiting times because of high workload

The existing doctrine for resource management is that everyone should have tasks that fill up 100% of their working time. Often, employees’ working time are spread over various projects and tasks: 25% in project A, 15% in project B and so on until 100% is achieved. This means that everyone is fully occupied with jobs, that is, the total workload is 100%. For many companies and managers, this is a goal. The problem is that 100% workload is the same as 100% waste. Here is the explanation.

Credit: A study of highway capacity (1935), by Bruce Greenshields.

It’s all about queues. The understanding of how queues work primarily grew from the communication sector, starting with the telegraph and developed to today’s internet. But queues and flows have also been studied in a number of other areas. The figure above shows traffic flows on a major road. The red line shows the traffic density measured as vehicles per km. The green line shows the vehicles speed measured as km per hour. The brown line shows the throughput for the traffic system measured as vehicles per hour.

When the traffic is low the vehicles can travel at 100 km per hour without problems. But as traffic increases, speed drops. The interesting thing about the throughput is that it forms a parabola with a peak, in this example at just over 5000 vehicles per hour. This peak occurs at a traffic density of about 100 vehicles per km which maintains a speed around 50 km per hour. As the number of vehicles per km increases, throughput decreases.

But what does this have to do with my projects? It shows that there is a relationship between how much works is going on, the throughput and the lead time (speed), called Little’s law. And the diagram also shows that when the road is full of vehicles the traffic stands completely still. A workload at 100% means that nothing comes through. This is also consistent with queuing theory.

Fortunately, a business rarely achieves full occupancy. Therefore, after all, some results will come out. But as the diagram shows, if we have a throughput of 1,000 vehicles per hour we can say that we have a waste of 80% in relation to the full potential of the road. Travel time will be long for everyone, fuel consumption will be high and the society will be forced to build more roads than would actually be needed. Today there is a simple and cheap solution. Traffic can be regulated with traffic lights on the accesses so that the traffic volume is not too high. Density can be monitored automatically with cameras. Then more cars can travel faster.

Translated into a project business with 100 employees, 80 people are trapped in “traffic jams” (they are waiting) caused by too much ongoing work. That is what I have seen in a large number of companies, it is common for project members to find themselves waiting because their colleagues are overloaded with work.

The solution is similar to that for regulating the amount of traffic. In pulse we impose limits to the number of permitted projects and (importantly) other type of work. The latter we call assignments. In a Pulse room, we set up pulse boards (whiteboards) for the permitted number of projects and a corresponding solution for the assignments. Therefore, more work than is permitted cannot be started. By limiting the number of projects and assignments, these can be executed much faster and at a lower cost with higher quality.

For many years we have had the slogan to “cut the lead times in projects by half”. The above shows how easy this is. Businesses who have implemented Pulse with our help get a throughput of several times more projects and assignment per year with significantly shorter lead times than before.

Long-term forecasts in large-scale production vs. real-time control in lean

What will the weather be like on Wednesday at 13:00 in 12 weeks? Today we know that such a forecast is not possible and it never will be in the future. It depends on the built-in sensitivity of complex systems. The fluttering of a butterfly may be enough for the weather to develop in a different direction.

The same goes for a business. Small events can have a big impact. I call this uncertainty. It is not possible to make reliable long-term forecasts for what is to be produced or detailed plans for projects. Instead, lean production uses kanban and “just-in-time” mechanisms to control the current consumption. Similarly, in Pulse we use visual control on projects at daily pulse meetings. Work is divided into smaller parts and thus we get less material and information in circulation.

An example of uncertainty and how this can be managed is given by Donald Reinertsen in the book The Principles of Product Development Flow. He uses the internet as an example. To deal with the uncertainty the Internet is based on a protocol that divides the information to be transmitted into smaller packages. When transmitting information over a cable, information will be lost due to the noise that is always present. If we are to transfer a 10 megabytes file as one large package over a connection where we can statically get 1 error per megabyte, we will get 10 errors in the file. Thus, we have 1 chance out of 22,026 of receiving the file without errors. If we instead use 10,000 small packages at 1,000 bytes, we will have to resend 10 small packages. This gives us an overhead cost of 0.1%. This means that if we did not split into smaller packages, we would have had an overhead cost that was 22 million times larger.

This is an example. Subdividing will not make such an enormous difference in a project. But still you will get a significant reduction in uncertainty. In Pulse, we will split a project of 10,000 hours into 1,000 – 1,500 packages (activities), instead of having maybe 5 – 25 main deliverables as in a Stage Gate model or Scrum. This will give you a 90% reduction in overhead costs.

It is sometimes said that projects with an estimated budget of 10,000 hours in the end will rather be three times larger. But that rarely happens in Pulse, we generally end up at about the estimated worktime. This may be a result of dividing up the work into considerably smaller and more numerous packages, and that uncertainty thereby is reduced. As a result, fewer resources are spent on overhead costs associated with uncertainty.

Detail command vs. Mission command

For many people, project management has become synonymous with planning the project, handing out tasks to the project participants and having meetings once or twice a month where progress is followed up. This type of project management is called detail command.

Another way of managing a business is called mission command. This means that the project group has a shared understanding of what to achieve so that they together within the team can plan and direct the project forward. Mission command was developed by the army to achieve higher speed in their operations. We want to achieve the same thing, get more done with less administration.

The problem with detail command is that it takes a long time and requires a lot of effort to deal with deviations between plan and reality. Product development involves taking risks when developing new solutions. Trying to plan long term in detail will lead to a lot of deviations. These deviations must then be communicated back to the project manager who in turn will have to re-plan in order to deal with the situations that arise. The new plan will then be communicated to the parties concerned. All this takes a long time and requires a considerable effort.

If the project team understands the purpose of the project, what effects we wish to achieve, they can do detailed planning themselves in small steps as they advance forward. And when deviations and problems occur, they can handle the situation at their daily pulse meetings themselves. Thanks to mission command, we can save a lot of calendar time, and also a lot of working time.

Effective resource management in projects

I have pointed out three areas where it is possible to free employees from tasks that add no value. There are still several things I have not discussed, such as co-locating the project team in a project room and having an agile decision-making process to support the project with strategic decisions.

My main point has been to show the hidden resource pool that exists in every R&D department. But hidden resources can’t just be found in R&D, they are everywhere where knowledge work is being done and where the old fashion principles are used to lead and organize the work.

It is not a resource shortage that projects and companies suffer from; it is a waste of resources.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.