Macro-Micro Roll-up

Micro Macro Roll-up is a planning philosophy based on the best practices of fast teams

We start planning top-down using a macro plan. This is typically 50 high-level tasks framed by about 5 major customer focused milestones or project integration points. It's a best practices to plan top-down, slow teams plan from the bottom-up and get lost in the forest for the trees. It never works. The macro plan sets the architecture of the detail planning; a framework or structuring the problem.

The micro plans decompose these macro tasks into their composite detail; thus verifying the macro-level assumptions or challenging them for further refinement. The micro plans are develop by the people that have to do the work, while the macro plan is done by the core team that own and manage the program.

The trick is to reconcile these estimates and reach agreement between the top-down goals, which is the reality of the customer or market with the bottom-up reality of the team’s ability and capacity to get the job done. Failure on most projects starts here, before the project starts, when these two different views are not reconciled and expectations are misaligned.

In this example, we have a macro plan, which are high-level tasks that are typically 60+ days in duration.

We break these down into micro plans.

We then reconcile the micro with the macro. In this case, the micro team needed to accelerate their schedule and find a way to do their project faster. They determined that some of the work could be done concurrently.

This micro information can automatically be rolled up to the macro plan in order to reflect the accelerated schedule at the macro level. The process creates the network logic at the macro level to reflect the micro project’s detail.

As the project progresses, the actual schedule performance information can be rolled up from the micro to the macro in the same way. Here I’m illustrating actual performance being recorded at the micro level and this information being automatically rolled-up.

Example using fastProject

Lets take a look at a simple example using fastProject.

I’m going to show you two roll-up scenarios; one where I roll-up a micro schedule to refine the macro schedule during the planning phase, and the second where I will roll-up a micro schedule that is in-progress to illustrate how "actuals" are transferred to the summary macro schedule. I’ve simplified the model to illustrate the process, but it gets more interesting with more complex schedules.

This is my macro schedule. There is a requirements phase, creation of a prototype, field tests, and the start of manufacturing.

This is the next level of detail in the macro. We’re going to concentrate of the prototype project.

In the bottom pane you see the prototype team’s micro schedule. Notice the top level of their schedule is the bottom level of my macro schedule.

The micro team has broken down the first two macro tasks; the hardware and software development work. We only breakdown the near-term schedule. This breakdown process rolls forward with time—when more is known, that work will be decomposed. Notice that the macro schedule shows the hardware and software tasks in serial, while the micro schedule shows them overlapping. When we did the macro we were conservative and wanted to reduce risk, but we were late. The micro team’s job was to find a way to compress the schedule and do it faster. Notice their schedule is done in 220 days while the macro task is 260 days long.

In this project, getting the requirements is what drives the micro schedule start. We call this a touch-point.

This is the hardware breakdown in the micro schedule. And this is the software breakdown.

This is the finish to start relationship at the macro level, which causes the software to start after the hardware is completed. The micro team thinks they can start the software after they develop the preliminary hardware. They’ve expressed this dependency as a finish to start relationship between these two micro tasks.

Now lets roll-up the micro schedule into the macro schedule in order to reflect the more aggressive micro schedule at the macro level.

The overlap between hardware and software development is expressed in the macro now, automatically from the micro schedule. The micro-macro roll-up in fastProject will determine the correct network logic at the macro level along with the correct lags in order to reconstruct the macro schedule so it reflects the micro detail. This works on a multi-level network as well, but I’m showing a simple model now to illustrate the concept.

You can see the macro on the top and the micro on the bottom. We use the macro schedule to drive the project at the core team level, while the milestone teams use the micro schedules to drive their work locally. We plan from the top and roll-up from the bottom to see the gap.

My macro schedule is still late, but the micro schedule roll-up did improve the gap to my target.

In the next example, I’ll update the micro, roll-up the updated micro to the macro, and then update the macro schedule.

We’ll update the micro to the 23rd. The micro team didn’t get the requirements, so they respond “no” to this question, the milestone is not complete. However, like all good engineering teams they didn’t wait for the requirements, they just started working. But they ran into some trouble and predict that the preliminary hardware development will take 21 days, instead of the 19 remaining. This cased a 7 day slip in the micro schedule.

The result of the update is that they started the preliminary development task early. The green line indicates the progress.

Later in the day the core team updates their macro schedule. But before they update their macro tasks they’ll grab the detail from the already updated micro schedule. It is hard to see, but macro task number 3.1 has a green bar on it reflected the micro roll-up. The remaining duration is also correct to reflect the 21 days remaining that was input by the micro team.

Now we’ll update the macro schedule. The first task is to get those requirements. This started, but is not finished. It should have finished by now. We’ll say it has 2 days remaining.

Notice what happened at the macro level. The red line on the left side of the requirements task is “negative float.” This means that the requirements task should have started two days earlier in order to be on schedule, based on the finish to start relationship between the requirement task and the prototype hardware development task.

The bottom pane shows the micro schedule. The “actual” information was rolled-up to the macro schedule automatically. The roll-up reconstructs network logic at the macro level so that it reflects the schedule at the micro level. It also figures out the correct durations and lags to synchronize the macro and micro schedules. Finally, it rolls-up actual information so you can see the micro progress reflected that the macro level. This permits multi-level schedule to be developed and the macro planning process to be implemented on large scale programs.