Simplicity

Analyzing business or IT problems is an inherently complex task, and it should not be made even more complicated by introducing meaningless processes or producing outputs that are not needed or that nobody can understand. Effective analysts keep things organized and consistent, but they must also strive to keep things as simple as possible. Simplifying itself is not difficult. The real challenge lies in finding the right balance—keeping things simple but not oversimplified. In other words, the goal is to find the simplest solution that still delivers full value.

Simplification Tips

1. Create Simple Outputs

When creating an output, whether it is a document or a model, it should be in the simplest possible form that still clearly communicates the message. The author should always keep in mind that the artifact might be used or read by someone with limited knowledge of the area and very little time. Therefore, the consumer must be able to understand it instantly without needing to search for additional information or ask for explanations.

2. Don’t Polish Details Too Early

A famous idiom states: “The devil is in the detail.” However, fine details are usually not needed right at the start, and it is practically impossible to capture all of them anyway. The more details you document during the initial analysis, the more effort is required to maintain them later. Detailed analysis costs time twice: the time required to create it, and the time required to keep it up to date. Analysis and documentation outputs must be kept as simple as possible, and details should be added only when the current level proves to be insufficient. The necessary level of detail must be continuously evaluated, finding a balance between documenting everything and spending time wisely.

3. Formal Is Not Always Best

Every output can be an informal description, or its format can be prescribed by a strict set of formal rules. Formal outputs have the benefit of being readable to anyone who knows the rules, and they all look highly consistent. However, as always, reality is not just black and white.

Let’s look at modeling standards, which define how to graphically describe a specific aspect of reality; in other words, they define the semantics of the symbols used in a model. Modeling standards such as UML and BPMN are certainly beneficial because they enable different people to speak the same language. But using them comes at a price. First, creating these models takes time, as it will always be more time-consuming to build a formal model than to sketch a free-hand diagram. Second, for the model to be readable, all recipients must understand the notation, which can be a limiting factor.

Ultimately, before delivering an artifact, you must carefully consider who the target audience is and whether the model is a one-time sketch or a permanent piece of documentation. The final format should then be selected based on that purpose.