1. Download the add-on from SourceForge
2. Using Freeplane 1.2.x, select Tools -> Add-ons
3. Click the Search and Install tab then use the Search button to navigate to the downloaded add-on
4. Click Install
5. Restart Freeplane

Uncovering Conflicts with a Current Reality Mind Map

One of the techniques introduced in Goldratt’s Thinking Process is constructing a Current Reality Tree (CRT), which shows how a goal depends on necessary requirements which may have their own prerequisites. As an example, consider the following (simplified) CRT for profitable products:

Since we’re using a mind map as a drawing tool, the usual CRT arrows are missing, but the interpretation is the same: child nodes are conditions that if met then result in the parent node. For example, if our “design is flexible” and we have “rapid customer feedback” then we will achieve “fast time-to-market”.  A full-blown analysis would, no doubt, have other necessary requirements (like “good execution”).

In the above example the contradiction of a flexible and frozen design is highlighted. This is a source of conflict that can impede progress towards the goal.

Check Your Premises

The next step is to extract the Evaporating Cloud and list the underlying assumptions. The contradiction exists because at least one of the assumptions is wrong.

Here’s the new mind map:

Some further thought will uncover more assumptions, but all we need now is to find a few bad ones. Some questionable assumptions are:

• “Changing designs cause havoc in the supply chain”- What’s missing that can alleviate this problem?
• “Need to scale the supply chain now”- Really? Are we sure we have a product customers want?

Inject New Requirements

The above questions lead to adding (“injecting” in TOC-speak) two new requirements to fix the bad assumptions:

• Supply chain disruption can be minimized with a good change control process that clarifies effective dates, disposition of inventory, and build schedules.
• Don’t scale the supply chain until the demand for the product is validated

Once these requirements have been added, you should go back a see if they create any new conflicts that need resolving.

But That Was Obvious, Right?

Well, maybe- but notice that many organizations have exactly this conflict of missions between product development (want maximum variation) and manufacturing (want no variation). If even this simplified example raised this, there is plenty of room for (continuous) improvement in real life!

I’m interested to see any applications you may care to share…

This two part post explores resolving conflict that impedes progress. We’ll use mind maps to diagram the Evaporating Cloud technique introduced by Eliyahu Goldratt as part of his Thinking Process in the Theory of Constraints. Part I will give an overview of the technique, which will then be applied to an example in Part II.

The Necessary Requirements to Reach a Goal

Let’s use a mind map to show the requirements that are necessary to achieve a goal (keeping the descriptions generic for the purpose of overiew only):

These are necessary requirements, meaning that all must be present to achieve the goal. Each of these requirements will typically have their own requirements, cascading down the tree structure to the preconditions at the end of each branch.

Sources of Conflict That Prevent Progress

When constructing a diagram showing the hierarchy of requirements needed to achieve a goal, you may find that some of the preconditions are in conflict with each other (as indicated by the red arrow between Preconditions 1.1.2 and 3.2):

For example, your goal might have a precondition that requires buying an expensive piece of equipment while another precondition requires minimizing spending. These kinds of conflicts cause a ‘friction’ in the system that slows (or even stops) progress towards the goal.

The Conflict Resolution Diagram (Evaporating Cloud)

For the purpose of resolving the apparent conflict, the above diagram can be simplified to show just the key elements in what is called a Conflict Resolution Diagram (or Evaporating Cloud):

Since Requirements 1.1 and 3 are assumed necessary, the contradiction or conflict rests between Preconditions 1.1.2 and 3.2. Note that each connecting line in the diagram implies a number of assumptions, like Precondition 1.1.2 is necessary for Requirement 1.1. Echoing the Ayn Rand quote above, Goldratt maintains that the problem is not the conflict or contradition, but actually due to bad underlying assumptions. Once the bad assumptions are invalidated, the conflict evaporates like a dark cloud (hence Evaporating Cloud).

Challenging Assumptions

The first step is to make the assumptions explicit by listing them:

Each of these assumptions then needs to be reviewed to see if it is really valid. Suppose Assumption 8 is found to be invalid. This usually leads to some ideas about the actual precondition needed. This new precondition is called an Injection by Goldratt, as depicted below:

Note that Precondition 3.2 can now be removed from the original diagram of the goal and replaced by the Injection. Most importantly, note that the red arrow depicting the conflict has been removed, indicating a self-consistent system of requirements necessary to achieve a goal:

The discussion to this point has focused on an overview of the mechanics involved in creating and solving a Conflict Resolution Diagram- admittedly a bit dry (unless the logic stirs your inner Vulcan).  So Part II will walk through an example.

GTD systems have a solution for capturing the tasks others are doing for you: the “Waiting For” list. These are the tasks that you have delegated to someone else on a project (and now you are waiting for them to finish).

There are two ways to handle this in a FreeMind|GTD mind map:

1. Treat the individual as a context
2. Use a hack on the date field to list the individual under a project

Treating ‘Waiting For’ as a Context

In previous posts, I described how to use the @ symbol notation to denote a context such as @phone (a next action to take when on the phone). You could also use this to denote a next action as being assigned to an individual (for example: @Jeff B).

When a FreeMind mind map with next action markup is processed by FreeMind|GTD, the all the next actions for Jeff B will be grouped together as a context with due dates (when assigned). This is can be useful to make sure you check on Jeff’s status when you sit down together- all the things you need from him are under one heading on the Next Actions list.

Using a Hack to Include ‘Waiting For’ in Projects

Sometimes, it is more convenient to use a project as the context for grouping next actions. This allows you to consider both your own and other’s next actions when you are reviewing a project- there are often natural inter-dependencies that need to be thought about.

In order to do this, use the @ symbol to make your project the context. If you have a deadline for your own next actions, add them with the usual [date] notation. If the next action has been delegated, instead put the individual’s name in the brackets (for example, [Jeff B]). When you run your next action list in FreeMind|GTD, the “waiting for” next actions will have a name associated with them. Here’s an example of a mind map configured this way:

This gives you a next action list like this:

The key thing is to use whichever method helps you get things done! Note that the above example is actually a hybrid between the two (the 1:1 meeting with Jim is treated as a context).

Luckily, FreeMind has a simple search function that can be used to find your Next Action. It searches from the current node down the hierarchy, so it can be easiest to just start at the root node of the mindmap. The shortcut for selecting the root node is the ‘Esc’ key. After selecting the root node, press ‘Ctrl+F’ to open the search dialog box, as illustrated below.

Click on the ‘OK’ button to go to the first instance matching the search string. The search function looks for an exact match within the node text string, so use the FreeMind|GTD Next Action list to help you make up the search string. A typical place where the simple search can trip you up is searching for ‘reports’ when the node text might be something like ‘Draft report’- the exact match will fail since report is singular rather than plural. Here’s the result for the above search:

So use the sequence ESC Ctrl-F to quickly find a Next Actions in large mindmaps.

Download

ProdDev_Template.zip

David Allen’s GTD methodology is a highly effective way to handle event driven work. At its core is creating a “trusted system” for collecting stuff, processing it, and organizing the decisions into the actions needed to get things done. Since it is a generic methodology, you can implement it in a variety of ways, from fully paper-based to all-digital. This article will focus on an implementation that uses mindmaps as a core tool for organizing the stuff you collect and process.

Collecting Stuff

The key goal of GTD is to get “stuff” out of your head and into a system you trust. This frees attention that is wasted mentally cycling through everything on your plate. My collection system is shown below:

Email can appear across laptops, desktops, and my smartphone. I tend to convert voicemails and audio notes from the recorder into written notes, rather than processing them directly. The recorder (Olympus VN-5200PC) is perfect for the car- it is a device designed for a single purpose so there is much less distraction than trying to fumble through smartphone functions or leave voicemails to yourself. Often something like an NPR story will trigger some idea you want to remember which is then easy to do with the recorder. The Note Jotter (M by Staples) holds 3″x5″ cards and a pen- essentially a Hipster PDA that works really well for capturing ideas and tasks. The In Basket holds the usual pile of papers, clippings, Post-It notes, etc. Taken together, these tools collectively form my GTD InBox. I trust that “stuff” I need to deal with will get captured by one of my InBox tools- a necessary condition for getting things out of your head.

Processing

Processing the “stuff” in the above InBox follows the standard GTD methodology:

As you process each item in the InBox (from whichever collection tool it resides), the first decision to make is whether it is actionable. Non-actionable items are either tossed, saved for future reference, or “incubated”. For example, you might store the datasheet for a new component in your reference file system and put a note on your Someday list about how it could be used.

If an item is actionable, you need to gauge whether this is really a multi-step project. You can add it to your project list if it is not there already. In either case, the key thing is to decide on the next action required. This is the heart of GTD- it is what breaks procrastination and keeps things moving forward. If the Next Action can be accomplished in a couple of minutes, then just do it! If it really belongs on someone else’s plate, then delegate it to them (even if it is your boss). Otherwise, the item must be deferred until you can work on at a specific time (schedule it on your calendar) or specific place (place it on a Next Action list sorted by place or context).

Organizing

OK, so where does the Mindmap come in?? Mindmaps are excellent organizing tools because they are hierarchal structures. Using FreeMind|GTD with a FreeMind mindmap allows you to combine all four lists (Projects, Waiting For, Next Actions, and Someday) into one place. This makes it easier to review and manage.

Begin by creating your GTD mindmap organized by your areas of focus (or roles):

Note that a Someday node was added for capturing non-actionable items that you may want to think about (incubate). For example:

The Someday category gives you a place to collect stuff that you are not going to deal with right now. It is important that you periodically review these items to decide on whether they will acted upon or dropped.

You may want to further breakdown areas of focus before including projects. For example, under Home a sub-category of Improvements holds the project to remodel the kitchen:

From this simple example, you can get a sense of how Project and Someday lists are capable of being captured in a mindmap. Next Actions are then captured under projects, for example:

Next Actions should be written as a complete, stand-alone actionable task. Note that the format includes the elements required for FreeMind|GTD to parse and compile a Next Action list.

Reviewing

During the course of the week, I periodically run FreeMind|GTD to generate a Next Action list from my GTD mindmap. I find it useful to print the Next Action list so it can be consulted in different contexts to help decide which item to work on next. In the above example, the Next Action list would have a task to contact contractors for quotes when you are working on your email. The Next Action list (and Calendar) are reviewed many times daily.

The mindmap is a really useful for weekly reviews- you can look across several levels of hierarchy to determine if there are any other “stuff” that needs to be captured or removed. These things may come from longer term goals, for example.

Executing

At the end of the day, nothing happens unless you actually execute on your next actions. There is a definite satisfaction crossing off a completed next action from the printed list (I use a Sharpie marker to really cross it off!). When you are “in flow” and moving forward rapidly on next actions, it is better to physically cross of completed items on the printed list- you should use a review to update the mindmap, rather than trying to do it real-time. Often completing a next action will put the ball in someone else’s court. In these cases, just make a note of what you are waiting for this person to do right on the printed Next Action list. Later, during a review, you can update the mindmap to reflect that the context for the new next action is with someone else. In the remodeling example, after you solicit quotes via email, the next actions will be to review quotes you are waiting for from contractors. The mindmap becomes:

Running FreeMind|GTD will then list these next actions under the contractor context- which is a Waiting For list. Thus, the mindmap has also combined the Waiting For and Next Action lists.

Conclusion

I have found the above system very helpful for getting things done- hopefully you will too.

Building the Mind Map

Start by creating a mind map that has the transformational goal on the left side and each involved functional group on the right:

You’ll spend most of the time working with the nodes representing the functional groups, but it can be handy to have a reminder of the goals right in the mind map.

Next, add the immediate projects (i.e., tasks requiring multiple steps to complete) for each functional group:

Use your overall project plan (typically a Gantt chart) to determine which current projects to include- there is no need to add projects that won’t start for the next few weeks. Remember that the point of the mind map is to link current projects in the overall plan to their next actions.

Once you have captured all the current projects (and perhaps relevant supporting tasks), add the next actions required for each of these:

Note that each next action starts with ‘*’ and has it’s owning functional group name after the ‘@’, following FreeMind|GTD conventions. Capture all the next actions for each group and then run FreeMind|GTD to generate the list of next actions sorted by functional group:

This table can form the basis for group reviews. In the above example, due date were not assigned, but would be in practice by adding ‘[<date due>]‘ to the next action text. You should also identify an owner for each next action within a functional group. Normally, this would come after the ‘@’, but since functional groups are using this already, simply add the owner’s name in parenthesis (don’t use square brackets which are reserved for due date).

Over the course of the overall transformational project, functional projects will dropped off the mind map as they are completed and new ones added as required. The mind map helps you to translate the timeline-driven Gantt chart plan into next actions that can be reviewed for follow-up.

Here is an example mind map. Give it a try!