Demand Driven: innovar para ser eficientes
28 febrero, 2017
COASA (Aernnova), más facturación y menos stock con Demand Driven DDMRP
20 marzo, 2017

MULTIPROJECT MANAGEMENT: A Disruptive Model For Optimizing Processes


Manuel Rodríguez, Managing Partner at CMG Consultores, and José Luis Portela, Professor and Director of the Strategic Project Management Program at IE Business School


Many companies are still working with an old-fashioned mentality even though their very nature has changed. A different approach is needed because the model of working at a single company for eight hours a day for a gross salary is destined to disappear: workers will perform their duties at various companies on a project-by-project basis.


Read more in IE website


Most organizations now find themselves in a multiproject scenario, even though they were created to handle only a single-project scenario. The critical-chain project-management methodology, developed by Israeli physicist Eliyahu M. Goldratt, proposes a solution for operations management in multiproject scenarios. This solution acknowledges the existence of uncertainty and manages it by sharing—not distributing—resources. It is better to have many people working on just a few projects than to have many projects with few people, but this is the opposite of what has always been done. To address this problem, Goldratt introduced buffers and time sharing, concepts derived from his theory of constraints.

With critical-chain project management, Goldratt proposed an approach that downplays planning in favor of execution. This approach abandons the classical static planning model that manages and justifies deviations in favor of a new model in which plans are revisited every day in light of the remaining task duration, i.e. the time needed to finish the project. Under this methodology, you don’t start tasks just for the sake of starting them or being busy. Instead, you start them when you must. The idea is to start later in order to finish earlier. This disruptive concept contradicts all the classical theories that have always been applied.


The only thing that matters is the remaining duration, not the progress made so far.


Upgrading from map to GPS

What determines how long it takes you to drive somewhere? Not your skills behind the wheel, not your car, and not the traffic on the road. In a project, the traffic is all the tasks that are currently open. For a given journey, you might take ten minutes or an hour, because the amount of traffic varies depending on the time of day. The difference in travel time is due to the number of waits you encounter, which has to do with the number of open tasks or, in our example, the number of cars on the road. This is the opposite of what most companies do. Many companies want there to be lots of traffic, because otherwise it seems like people aren’t working. But the more tasks you have open, the worse things get.

Buffers and critical-chain project management are like a GPS that can recalculate your route and priorities every day. When it comes time to make a decision, your buffers can tell you whether one task is more important than another. The idea is to base your planning not on intermediate milestones but on buffers. This allows you to recalculate your plans on a daily basis as a function of the actual remaining duration of the tasks in progress.

Planning with intermediate milestones is like printing out a map before you need to drive somewhere: once you make a wrong turn, the map becomes useless and you get lost. Buffers, in contrast, are a mechanism that allows you to manage an entire project and see at a glance the impact of any deviation on the project as a whole.

The solution, therefore, is to implement ideas or mechanisms for managing the execution, not planning and control. You still have to do some planning, but it’s just 10% of the work; 90% of your effort goes into ideas and rules for managing the execution, not into detailed plans.

The only thing that matters is the remaining duration, not the progress made so far. The amount of work left to finish will be different tomorrow than it is today, and this is the only real fact: at the end of each day, the people working on each task must declare how much is left to do. That is more real than any plan. The recommended buffer length is one third of the turnaround time.


Work in progress

The fundamental measurement is work in progress (WIP)—the number of projects underway and tasks open. Here’s the trick: the fewer the items in progress, the clearer the organization’s priorities will be, and the easier it will be to work on the right things. Just by making a decision about when to start a project, the organization is able to increase its productive capacity and reduce delivery times.

Often, however, this decision is not consciously made. People tend to try to seize business opportunities as quickly as possible. The truth is that you have to start things, but you also have to finish what you’ve started, so it’s important to have a mechanism for determining exactly when to start.


The weakest link

According to Goldratt’s theory of constraints, a project or organization is like a chain made up of various links. If you subject it to a tensile test, it will break at the weakest link. If you strengthen any other link besides the weakest one, you will achieve no improvement whatsoever.

Translated into multiproject terms, the weakest link is a department. Generally speaking, when the work being done is intellectual in nature, the weakest link is problem-solving capacity, not a resource. The important thing about the chain is the relationship between the links. Your aim is to synchronize the various links; all links are equal, except the weakest one.

There are many models—for example, cost reduction. Costs are like the weight of a chain. If you reduce the cost of several departments, you reduce the organization’s overall costs, because in this case the sum rule works. But when it comes to speed or synchronization, the sum rule doesn’t apply because there’s only one link you need to improve: the weakest one.

The problem is precisely how to synchronize. A project takes at least a month, and there are tasks in various departments that must be aligned. Somehow, you have to shake them all up and arrange them in a way that results in synchronization. The critical-chain method applies to each individual project. When you have multiple projects, you have to identify the synchronizing resource: the drum.


When it comes to speed or synchronization, the sum rule doesn’t apply because there’s only one link you need to improve: the weakest one.


Changes and conflicts of interest

Even if a project is well defined, some change in scope always comes about at the behest of either an internal department or a customer. At the same time, interactions are continuous and unexpected new tasks crop up. There are changes in sequence, things that take longer than expected, delays, changes in resource requirements, and so on.

Resource leveling is more difficult in a multiproject scenario because many projects are underway at the same time. Some people argue that you need to have a clear idea of the demand, balance it with the load, and make decisions on that basis. But nobody really knows the demand, and in any case it changes constantly. Many companies try to forecast sales with great precision so that they can get the right product to the right place, but this is difficult or impossible to do. What’s more, there is a cascading effect among projects: if you have experts working on several projects and one is delayed, the others will be delayed as well. Replanning is also constant: you try to stick to the plan, but the plan ends up changing as you go along.

Well-leveled multiproject planning is possible, but any deviation leads to load spikes and conflicts. There can also be multitasking—individual or organizational—which means starting one thing and not finishing it before starting another. The task that has been started consumes resources even though no one is working on it, and meanwhile the turnaround time for that task grows ever longer. People tend to start projects as soon as possible. However, starting earlier leads to more multitasking, which slows everything down and is worse for the organization.

Many companies choose to hire more people, make them work more hours, and use a sophisticated system to micromanage everyone’s efforts. Some companies assume that greater detail can decrease uncertainty, but this is false: the uncertainty remains the same.

Other companies decide to put all their effort into planning and invest in the most innovative planning methodologies. But after all that, everything can still change in a matter of days.


You try to stick to the plan, but the plan ends up changing as you go along.



Goldratt understood that project synchronization involves two types of waits: either the resource waits for the task—because it hasn’t arrived yet—or the task waits for the resource. Waits and interruptions account for nearly half the duration of a project.

Projects can be sped up by reducing wait times. Because of uncertainty and dependencies, some waits are natural and can never be reduced. Others can be prevented through better synchronization. In these cases, Goldratt’s parameters can be applied to improve synchronization. You must realize, however, that uncertainty exists and detailed planning doesn’t work for synchronization, as far as we know.

Waits can also occur when projects or tasks start without adequate preparation, which is what tends to happen 100% of the time. Measurements are another reason. Estimations of measurements and intermediate milestones end up becoming targets. Let’s say you’ve negotiated a five-day turnaround with a customer or department. The chances of the task being completed in four days are very low. In the end, you only see delays, never advances, even though, statistically speaking, 50% of projects should finish ahead of schedule and 50% behind schedule.


A good multiproject management methodology has to take Murphy’s Law into account.


Multiproject scenarios

A new product launch is a multiproject scenario. One example could be the introduction of new products at a brewing company. The company launches about three hundred projects each year. If the container, the type of packaging, or any other aspect is different, it counts as a new project, even if the beer is the same. Each project takes an average of three months and involves several departments, which must be synchronized in order to deliver the product.

Engineering is another example. Variability is present from the moment an engineer working on a plan is asked how long he needs to finish the job. He doesn’t know; the best he can do is give an estimate. Curiously, whatever figure the engineer provides ends up being added to someone’s spreadsheet or plan. Suddenly it becomes the evil number that gives the engineer recurring nightmares about what will happen if he doesn’t meet the deadline.

The same is true of equipment maintenance and repair. Iberia uses this methodology for aircraft maintenance, which entails a lot of variability. When a plane arrives, you have to open it up and take it apart… and you don’t know what you’ll find. Then you have to repair it, have parts shipped, put everything back together, and test it. And you have to do all this in 20 days: as long as the aircraft is in the hangar, it’s not flying and not generating revenue.

A good multiproject management methodology has to take Murphy’s Law into account. Planning is not the solution: no matter how much you plan, you can’t escape Murphy. And the more detail you put into your plans, the more resources they eat up. That’s why I propose doing away with planning in favor of buffers.

If you implement the ideas of the theory of constraints and critical-chain project management, you are quite certain to get results. The challenge is to keep it up and improve year after year.


Manuel Rodríguez, Managing Partner at CMG Consultores, and José Luis Portela, Professor and Director of the Strategic Project Management Program at IE Business School.

© IE Insights.