Eight to Late

Sensemaking and Analytics for Organizations

Capturing decision rationale on projects

with 3 comments


Most knowledge  management efforts on projects focus on capturing what or how rather than why. That is, they focus on documenting approaches and procedures rather than the reasons behind them. This often leads to a situation where folks working on subsequent projects (or even the same project!) are left wondering why a particular technique or approach was favoured over others.  How often have you as a project manager asked yourself questions like the following when browsing through a project archive?

  1. Why did project decision-makers choose to co-develop the system rather than build it in-house or outsource it?
  2. Why did the developer responsible for a module use this approach rather than that one?

More often than not, project archives are silent on such matters because the reasoning behind decisions isn’t documented. In this post I discuss how the Issue Based Information System (IBIS) notation can be used to fill this “rationale gap” by capturing the reasoning behind project decisions.

Note: Those unfamiliar with IBIS may want to have a browse of my post on entitled what and whence of issue-based information systems for a quick introduction to the notation and its uses. I also recommend downloading and installing Compendium, a free software tool that can be used to create IBIS maps.

Example 1: Build or outsource?

In a post entitled The Approach: A dialogue mapping story, I presented a fictitious account of  how a project team member constructed an IBIS map of a project discussion (Note: dialogue mapping refers to the art of mapping conversations as they occur). The issue under discussion was the approach that should be used to build a system.

The options discussed by the team were:

  1. Build the system in-house.
  2. Outsource system development.
  3. Co-develop using a mix of external and internal staff.

Additionally, the selected approach had to satisfy the following criteria:

  1. Must be within a specified budget.
  2. Must implement all features that have been marked as top priority.
  3. Must be completed within a specified time

The post details how the discussion was mapped in real-time.  Here I’ll simply show the final map of  the discussion (see  Figure 1).

Figure 1: IBIS map for Example 1

Although the option chosen by the group is not marked (they chose to co-develop), the figure describes the pros and cons of each approach (and elaborations of these) in a clear and easy-to-understand manner.  In other words, it maps the rationale behind the decision – a  person looking at the map can get a sense for why the team chose to co-develop rather than use any of the other approaches.

Example 2: Real-time updates of a data mart

In another post on dialogue mapping I described how IBIS was used to map a technical discussion about the best way to update selected tables in a data mart during business hours.  For readers who are unfamiliar with the term: data marts are databases that are (generally) used purely for reporting and analysis.  They are typically updated via batch processes that are run outside of normal business hours.   The requirement to do real-time updates arose from a business need to see up-to-the-minute reports at specified times during the financial year.

Again, I’ll refer the reader to the post for details, and simply present the final map (see Figure 2).

Figure 2: IBIS Map for Example 2.

Since there are a few technical terms involved, here’s a brief rundown of the options, lifted straight from my earlier post (Note: feel free skip this detail  – it is incidental to the main point of this post) :

  1. Use our messaging infrastructure to carry out the update.
  2. Write database triggers on transaction tables. These triggers would update the data mart tables directly or indirectly.
  3. Write custom T-SQL procedures (or an SSIS package) to carry out the update (the database is SQL Server 2005).
  4. Run the relevant (already existing) Extract, Transform, Load (ETL) procedures at more frequent intervals – possibly several times during the day.

In this map the option chosen by the group decision is marked out – it was decided that no additional development was needed; the “real-time” requirement could be satisfied simply by running existing update procedures during business hours (option 4 listed above).

Once again, the reasoning behind the decision is easy to see:  the option chosen offered the simplest and quickest way to satisfy the business requirement, even though the update was not really done in real-time.


The above examples illustrate how IBIS captures the reasoning behind project decisions.  It does so  by:

  1. Making explicit all the options considered.
  2. Describing the pros and cons of each option (and elaborations thereof).
  3. Providing a means to explicitly tag an option as a decision.
  4. Optionally, providing a means to link out to external source (documents, spreadsheets, urls). In the second example I could have added clickable references to documents elaborating on technical detail using the external link capability of Compendium.

Issue maps (as IBIS maps are sometimes called)  lay out the reasoning behind decisions in a visual, easy-to-understand way.  The visual aspect is important –  see this post for more on why visual representations of reasoning are more effective than prose.

I’ve used IBIS to map discussions ranging from project approaches to mathematical model building, and have found them to be invaluable when asked questions about why things were done in a certain way. Just last week, I was able to answer a question about variables used in a  market segmentation model that I built almost two years ago – simply by referring back to the issue map of the discussion and the notes I had made in it.

In summary: IBIS provides a means to capture decision rationale in a visual and easy-to-understand way,  something that is hard to do using other means.

3 Responses

Subscribe to comments with RSS.

  1. Hi Kailash, what a great post. This has served for me as a first introduction to the IBIS concept. Having read now through your previous posts I can see the opportunities it raised for capturing knowledge.

    Great article mate.


    Shim Marom

    March 21, 2011 at 12:36 pm

  2. Shim,

    Many thanks for the feedback. I continue to be amazed at the power of such a simple notation: it is incredibly useful for capturing the essential points of a dialogue in real-time as well as working through written arguments.

    Thanks again, your comments are greatly appreciated!





    March 21, 2011 at 7:07 pm

  3. […] practical level there are computer supported deliberative techniques such as argument mapping and dialogue mapping which can assist in structuring and capturing such […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: