This video discusses some of the issues that can surface when you create the context diagram, as well as common mistakes that can be made when developing the diagram and how you can avoid them.
- I like to believe that context diagrams take us from 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 averting 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 drug down to a 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're drug down into the next level when you create your functional flow diagram for each entity's interactions. Context diagrams do have their limitations of 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 correct 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 in the way the system has be designed and installed to deliver on the day-to-day operations. Constructing a context diagram may also require several build review iterations. It is unlikely that a fully populated context diagram can be drawn first up. Be sure to understand the purpose of a context diagram.
If this is the case, be careful and be sure to always validate your information as you go. Even if the context diagram you are analyzing is not going to be socialized, you need to ensure that your foundation is accurate as possible before you dove 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 model.
Hopefully, you will then end up in enviable place of unconscious competence, I simply do because of what I know, and become the best and most informed modeler in your organization.
- Using common modeling tools
- Determining when to use a particular modeling diagram
- Avoiding the pitfalls associated with each diagram
- Creating diagrams
- Leveraging key stakeholders