The art of The "Big Picture"

Getting a good Big Picture up front is one of the keys to the success of any project involving new or significant change to Information Systems. The Big Picture comes in two parts: The picture itself and the story that goes with it. First there is the picture, the document that we would call The Big Picture. This document need not be a rigorous diagram, although for those familiar with the Unified Modelling Language, the UML context diagram would be a good start. For those familiar with TOGAF, this would be the Architecture Vision document summarised into a single picture or diagram. The principal systems should be present and should be described in business terms. Where the system is customer facing the key channels to market should be represented and the key points of interaction between humans (staff, customers) and the systems should always be present. Each stakeholders interests should be represented - so, 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 and some short narrative should be given where the purpose of a system or communication isn't immediately obvious. If possible 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 a tool to drive conversation. It is the conversation around the picture that fills in the gaps. So the Big Picture says "I have covered all the angles," "Your specific concerns are addressed and you can see them here, here and here" (for each stakeholder) and finally, "here's the names of everything involved and how they fit together." The surrounding storyline needs to fill in the gaps. The storyline comes from enterprise architect and needs to describe how it will all work when we're done, how the solution will address all the stakeholder concerns, how the general case will be addressed in this model and finally how exceptions will be handled. This conversation comes from the discussion of the big picture with key stakeholders and weaves the storyline to their particular concerns. It is typically much harder to capture the conversation in a document. It is formed in the mind of the enterprise 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 queried during a 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 relatively easy for the enterprise 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. Finally a good Big Picture acts as a flag for a project, a reference point to follow. Do you have a project that has no clear end game, no commonly held vision? Or for which your key stakeholders are worried that their particular concerns are not being addressed? Perhaps something as simple as an A0 diagram capturing the salient points of the project for each stakeholder would give all participants the boost in confidence and direction they need.