Difference between revisions of "Project planning with mind maps"

From WikIT
Jump to navigation Jump to search
imported>WikITSysop
imported>WikITSysop
Line 41: Line 41:
 
My take is that with abstractions like grids and tables of information, we are forced to build mental models if we are to extract meaning from them.  I think this is borne out by the fact that graphs tell most people more than spreadsheets of numbers.  (I have known auditors who were happier with columns of raw numbers, but that's surely an acquired occupational skill.)
 
My take is that with abstractions like grids and tables of information, we are forced to build mental models if we are to extract meaning from them.  I think this is borne out by the fact that graphs tell most people more than spreadsheets of numbers.  (I have known auditors who were happier with columns of raw numbers, but that's surely an acquired occupational skill.)
  
Conversely, if we are say, planning a project, we visualize the areas of activity and then to use most project-management software, we have to squeeze that into the tabular structure so that a Gantt chart can once again represent it visually (to an extent and rather rigidly).  Software supporting the direct drawing by the user of CPM or PERT diagrams does help us work closer to the way we think.
+
Conversely, if we are say, planning a project, we visualize the areas of activity and then to use most project-management software, we have to squeeze that into the tabular structure. That's just so that a Gantt chart can once again represent it visually (to some extent and rather rigidly).  Software supporting the direct drawing by the user of CPM or PERT diagrams does help us work closer to the way we think.
  
 
Information maps like mind maps seem to reduce the gap between what we look at and what we see - reducing the abstraction and getting us to the nub of the planning quickly.   
 
Information maps like mind maps seem to reduce the gap between what we look at and what we see - reducing the abstraction and getting us to the nub of the planning quickly.   

Revision as of 22:55, 23 July 2009

You can’t start a project without thinking, “What do I do first?” but starting there is premature.

Even with small projects you must have a clear understanding of the following:

  • The project aims,
  • how completion will be judged (what tells you that you’ve really finished? Who decides?)
  • how success will be judged,
  • what the scope of the project will be,
  • what resources it can draw upon,
  • who will be involved,

but that’s just the beginning. Next, you must decide, task by task, what has to be done when and by whom and when each step must be finished.

Planning preliminaries[edit]

Start a mindmap as you think about what the project aims to produce, what it covers, what resources you will need and then draft the first ideas for a timetable:

Preliminary project planning thoughts (Click for larger version)

Scope may be a problem. It should mention what’s included, but it’s a good idea also to try to write what is not included. Try to catch the exclusions that other players in the project might expect to be included.

You may not have decided much of what you write about aims, scope and resources yourself – maybe your boss told you – but whether you define them and then go seeking agreement, or they are handed down, make sure they have been thought through, written down and circulated. Either way if you are managing the project, the next part is down to you. And this is where the mindmap gets really useful.

Mind mapping encourages structured capture of unstructured thoughts. You could do some of this with a checklist, but a mindmap lets you move quickly, skip from one area to another when you foresee consequences there, and remain open and unconstrained when planning. There will be a time for formal and detailed planning, but this is not it – you need a broad view and the mindmap approach gives that.

Filling out the details[edit]

Next, develop the mindmap to a more detailed level. You have aims, now you need a statement of requirements, and an informal agreement with the sponsors of the project, or more likely a formal agreement, and even a legal contract in some cases. Depending on how formal your sponsors are, there may be penalties to agree at this stage and you will need to consider contingencies in cases of failure to obtain all the resources or meet certain requirements – delivery dates especially.

Project planning outline (Click for larger version)

The problem with linear planning is clear, now. Here the description, as is the nature of prose, is linear, but at this point in the project planning, there will actually be movement on many fronts – timetable planning; consideration of constraints; negotiation about completion dates and penalties; factoring in the need for approvals and whether these will be available in a timely manner; and considering internal controls imposed by, say, quality processes or regulatory requirements, if these apply.

Such multiple and parallel activities are better supported by a mindmap than a linear outline, a checklist or a purely text-based planning document.

This mindmap continues to grow though the planning process as more and more detail is filled in, and detailed budgeting, formal timetable preparations and resource allocation get under way.

Taking regular snapshots of the mindmap and keeping these intermediate stages is a good idea. It can help with future projects. Once you have found the right form of project-planning mindmap for your work, you will be able to use its general structure for project after project, and tune it as your projects grow.

An afterthought[edit]

On Twitter, @rabenfeder posted a thought that “mindmapping projects with task is much more intuitive in a visual way than working in MS Project”. I agree with that most strongly, so re-tweeted it. And that brought in academic Brian Friedlander (@assistivetek), which got me thinking about it some more.

My take is that with abstractions like grids and tables of information, we are forced to build mental models if we are to extract meaning from them. I think this is borne out by the fact that graphs tell most people more than spreadsheets of numbers. (I have known auditors who were happier with columns of raw numbers, but that’s surely an acquired occupational skill.)

Conversely, if we are say, planning a project, we visualize the areas of activity and then to use most project-management software, we have to squeeze that into the tabular structure. That’s just so that a Gantt chart can once again represent it visually (to some extent and rather rigidly). Software supporting the direct drawing by the user of CPM or PERT diagrams does help us work closer to the way we think.

Information maps like mind maps seem to reduce the gap between what we look at and what we see – reducing the abstraction and getting us to the nub of the planning quickly.

I would like to see academic research that supported this nebulous abstraction/model hypothesis, which is based on a subjective and not at all rigorous assessment of my own experience.