Pitfalls of context diagrams

- I like to believe that context diagrams take us from the initial unconscious incompetence, "I don't know what I don't know," through conscious incompetence, "I now know that I don't know," to conscious competence, "I now know and it starts to show." Investigating how organizations come together becomes easier once all the pieces fit into place. As always with diagrams, there are risks in subverting too much from reality by leaving important things out or focusing so much on trying to include everything that the diagram loses part of its value by being too complex. I want to share a few pitfalls that you can easily fall into when creating context diagrams. The most common is getting too detailed. Rather than having a flow for each interaction, you can simplify your diagram by listing all types of interactions on a single flow. These are called processes. These processes can each be analyzed separately and drilled down to in more detail when we create the next level of detail in the functional flow diagram. Let's take an example of an organization that has the bulk of its IT operations done overseas. If we were to mention every single overseas partner, the diagram would be difficult to read and would not create an easy at-a-glance view. Let's take a closer look at this example. Here, the organization has partnered with multiple external offshore businesses responsible for all the IT operational support for the organization. They have partnerships in Manila, India, Philippines, just to mention a few. As the information that needs to flow to the external provider, the delivered outcome from the external provider is the same. All entities can be grouped together and simply labeled offshore IT operations. If there are differences between how the interactions occur, these differences will come to light when you drill down into the next level, when you create your functional flow diagram for each entity's interactions. Context diagrams do have their limitations and weaknesses, as they do not indicate the internal functionality of the organization, indicate timing or system interaction with its external entities, and do not capture all the modes that relationships are undertaken. It is possible to create many different models of any one system. This may well be necessary at some point, but when initiating a modeling exercise, it is a best practice to start with the operational view and the way the system has been designed and installed to deliver on the day to day operations. Constructing a context diagram might also require several build review iterations. It is unlikely that a fully populated context diagram can be drawn first up. Be careful and be sure to always validate your information as you go. Even if the context diagram you're analyzing is not going to be socialized, you need to ensure that your foundation is accurate as possible before you delve into the next level of detail. By keeping the diagram simple, your stakeholders can be easily walked through each of the relationships without being distracted or losing focus. Once you've worked through a few context diagrams, you'll be thankful that you've always had the big picture reference to refer back to when you start drilling down into the other business process modeling. Hopefully you will then end up in an enviable place of unconscious competence, "I simply do because of what I know," and become the best and most informed modeler in your organization.