Tuesday 8 July 2008

The art of The Big Picture

For me getting a good Big Picture up front is key to the success of any project involving new or significant change to Information Systems. The Big Picture comes in to parts. First there is the picture, the document that we would call The Big Picture. This document need not be a rigorous diagram, although a UML context diagram would be a good start.

Key properties of a good Big Picture document
  • The principal systems should be present
    These should be described in business terms.
  • Where it is customer facing the key channels to market should be represented
  • Key points of interaction between humans (staff, customers) and the Systems
  • Each stakeholders interests should be represented
    If a key stakeholder looks after a call centre - make sure the call centre is represented. If a key stakeholder is responsible for leads sourced via email - have this in the diagram.
  • Communication between items on the diagram should be represented.
  • Some narrative should be given where the purpose of a system or communication isn't immediately obvious.
  • Any phasing or early deliverables should be highlighted.

This probably provides 60% of the value of the Big Picture. The other 40% is derived from the story line surrounding the document. The document is intended as a mnemonic and point of conversation. It is the conversation around the picture that fills in the gaps.

So the Big Picture say this:
  • I've covered all the angles
  • Your specific concerns are addressed and you can see them here, here and here mr. stakeholder (for each stakeholder)
  • Here's the names of everything involved and how they fit together

The surrounding storyline says this:
  • Here's how it will all work when we're done
  • Here's how we're going to address all your concerns and what we'll use to do it mr. stakeholder (for each stakeholder)
  • This is how the general case will be addressed in this model
  • Here's the storyline on how exceptions will be handled

This conversation is typically much harder to capture in a document. Typically it is formed in the mind of the Information Systems Architect as they capture the requirements, examine the existing systems and draw on personal experience to build the big picture document. Frequently, they challenge themselves with exception cases to test their model but never get exactly the exception case offered in the presentation. As a result many of the story lines around exception cases are answered on the fly - with a good knowledge of the domain and a good Big Picture this should be bread and butter to the IS Architect.

So the Big Picture is a document which acts as a mnemonic and provides comfort to stakeholders that they are being cared for. The Big Picture is also the storyline that accompanies the document that sells the concept and brings to life what it means for the stakeholders.