Macro Mind-Mapping

In this screencast I’ll discuss Macro Mapping, which is a planning technique we use to organize a top-level macro plan.

This mind-mapping approach causes a team to look holistically at a program from beginning to end... from a macro perspective. This way of looking at a program from the top-down is a key characteristic of fast teams we’ve worked with over the years.

It drives a lateral or process focus. The alternative perspective is from the functional bias, which is common when the program is viewed through one function like marketing or engineering for example. Further, the macro map is structured from the major integration points which are designed to mean something to a customer or an external party, rather than from the inward looking perspective of the functional organizations. This builds in customer focus and cross-functional integration from the top and drives this down to the detailed schedules to come.

In normal environments, we see lots of time spent and detail created and then roll-up from the functional silos. The bigger the program the more detail there is and the more confused people get by it all. There is an attempt to reconcile and integrate it, but usually this fails and just a few people understand it and it loses its value as a management tool.

Macro mapping creates the information architecture around which the detail can be organized. “Detail is the devil” on large programs, unless you first have a top-down macro plan around which the detail can be organized.

Lets look at an example macro map of a new product program called x-Phone.

We start with the program mission statement which typically has “what, when, and how much” clearly articulated. Simple, yet in most programs we see, this is not clear nor is it commonly agreed to by all the stakeholders. This simple statement has taken us hours to facilitate with some core teams.

We look at what is driving the completion date for the program in order to understand the reason for urgency and what the potential costs of delay might be if late.

Then we ask what criteria would be used to measure the “doneness” of the program. This is a short check list that determines when the program is complete. This delimits the boundaries of the program, yet another thing that is typically not reconciled within a core team. Without this, you can’t measure success or failure, something the former President found out when he made a famous speech on the deck of an Aircraft Carrier with the words “Mission Accomplished” displayed on a big banner behind him. Clearly, they had not articulated the doneness criteria of that endeavor and eight years later people are still trying to determine what “done” means.

You can see the four high level groups of work on this program, from “identifying the requirements” to getting it to the point of “volume manufacturing.”

We started by identifying the four major milestones on this program. These are displayed in blue. For each milestone we defined the doneness criteria for each. This is the next level down of completion criteria. Using Covey’s “start with the end in mind” concept we determined the four major points of integration of the x-Phone, not from our functional perspectives like engineering, software, hardware, operations, etc., but rather the four points in time where we could measure or see the idea coming together as an integrated thing. This is an example of a process focus versus a functional focus, again a key best-practice characteristic.

For each macro group we then proceeded to define the macro activities that preceded each customer focused milestone. Using the doneness criteria, we then did this for each group.

Then we assigned ownership, first to the milestones and then to each macro activity. The ownership of each milestone means by default you are placing a person in change of a cross-functional deliverable. Each owner was asked to estimate duration for their macro task. We are not too worried about the quality of this estimate at this point, just an order of magnitude as it would be refined later in the macro schedule and still further when the next level of detail was developed.

The final step was to transfer the completed macro mind-map to fastProject where we engaged the core team in modeling the schedule to determine how close or far away they were to hitting their target completion dates.

We went through a process of linking tasks within each major cluster of macro activities, and then across macro clusters until we had an overall critical path that ran through the entire program. Remember, we were only looking at the forest at this level, not individual trees! That is the definition of macro thinking. We’re looking for the big interface points or strategic issues at this level, there’ll be plenty of time for drilling into detail later.

During the modeling process we are trying to understand the cause of the gaps between the real schedule and the target dates. Notice the targets are indicated as red stars and our x-Phone is about 2 months late. The idea with the modeling process is to get a team to experience the project together, like being in a flight simulator for project teams. This is always done in group facilitated workshops with the core team during 1-2 days of time. We are trying to find out what is driving the critical path and to make the strategic decisions to accelerate the schedule. This is the advantage of the macro.

You can see the comparison between the macro map and the macro schedule. The map served its purpose to create the broad architecture of the plan, the schedule is the tool to drive it. The next step is to breakdown the near term schedule and start the refresh planning process.