The idea that a map represents your relationship with a subject (rather than the subject itself) is worth a whole posting by itself, but before sending everyone to sleep with the theory, it might be more useful to first present a practical application. It leads to a clearer variation of the project map template that captures a simpler view of the relationship between an event and its stakeholders.
Many business people are primarily concerned with events that change the status quo. This could be launching a product or service, commissioning a process, solving a problem, delivering a physical event (such as a seminar), or establishing a new behaviour. Learning, information and knowledge all play a role within that context, either before (in skills and training required) or afterwards (in lessons learned and experience gained). The relationship between an individual or team and a finite event includes responsibilities, actions, expectations, outcomes and consequences for the individual or team.
One of the differences between software maps and pencil & paper maps is that the majority of software tools only support horizontal text. Today, many of the software maps that you look at are not truly "radiant" but are horizontally banded and lead the eye left and right - like scanning the horizon for interesting features rather than looking in the sky or sea. This is a restriction that we can also exploit as a feature. If we also adopt a left-to-right convention, we have a convenient way of visualising concepts that naturally converge to a single critical point before diverging again.
I suspect you're already way ahead of me here. If we make the centre of a map represent an event, then on the left we can write down the converging factors that lead to the event, and on the right we can show the divergent consequences of that event occurring. This gives us a flexible graphic depicting the whole of our relationship with an event:
(Click for larger image)
For example, let's suppose that you are the director of a mail order company, and you are getting feedback from customers receiving parcels that appear to have been delivered by Ace Ventura. Readers in the UK will know which delivery service I mean. So changing your courier is a promising long term solution. The Event template structure helps us to think about and organise our ideas in several areas:
- The "defining moment" at which the changeover can be described as complete - how this point is characterised
- The conditions that describe that point, which are drawn on the left
- The resources and actions that lead to those conditions, also drawn on the left
- The implications that arise from completion, which are drawn on the right. Not all of them need to be positive, provided they are not unanticipated
- How the outcomes contribute to other strategies, also drawn on the right
(Click for a larger image)
This also gives us simple way to correlate the consequences listed on the right with the actions and decisions on the left, to ensure that we will deliver on expectations. This is hardly a new idea, but formal statement and verification of requirements is not often used in general business. All we want is a simple visual device that can easily be explained to almost anyone and conveys a real sense of the consequences of decisions and actions.
The beauty of using an expansible tree diagram is that there is a place for all the detail you could ever need, without losing the birds-eye view of the most important factors for discussion and presentation purposes. It creates space for some of the more intangible results of completing a project, especially where they lie outside the direct remit of the project team (i.e. are not actions on the left).
An "event" could be a project outcome, problem situation, hypothetical opportunity, educational achievement or anything that has a sense of completion or a point at which a change occurs. The same basic visualisation can be used to communicate, negotiate and deliver anything from buying a new printer to reorganising a department.
