Business Analysis

Business Analysis is about shaping out a concrete solution from abstract ideas and objectives that different stakeholders usually have in a project. The way to go from high-level objectives to concrete solutions is to understand the objectives and their background: Where do they come from? Which concrete solutions would be acceptable to which stakeholders? Which options do we have at all, and what impact do they have on technical feasibility, risks, costs and time.

Top-Down vs. Bottom-Up

Putting emphasis on a sound concept does not mean that we live in an abstract world; on the contrary, it is about concrete details. Business value is created by delivering solutions to concrete problems. On the other hand, dealing with details without having a conceptual and strategic guideline inevitably leads to the dissipation of resources. This is why we constantly change our «flight level» from low altitude to high altitude and vice versa: knowing all the important details, while having the big picture and overall objectives clearly in mind enables us to check reality against the plan.

Think Short Term and Long Term

Make sure that short-term solutions do not become long-term problems

We know we cannot predict the future, and therefore it is impossible to cater to every possible requirement or circumstance that may potentially be relevant at some point down the road.

Nonetheless it is crucial to assess whether a specific design will be able to support the most likely scenarios and developments of the near and mid-term future. We make sure that short-term solutions don’t become long-term problems.

We love to write concepts

A concept, latin concipere, present active infinitive of concipiō ("to take in, collect, grasp"), puts thoughts to paper and holds them together

Concepts (as suggested by etymology) are a way to formulate and hold together thoughts. Therefore, they are our preferred tool to capture, organize and visualize the heterogeneous opinions and expectations of the stakeholders.

We typically write a high-level concept right at the start of the project: It establishes the big picture. At first, it is mainly a communication tool and serves as an indicator as to how well the solution will be supported by the stakeholders and users. It also helps us to get to a thorough understanding of the problem. There will even be early input from the developers regarding technical considerations or constraints that will have to be respected or overcome on the way to delivery.

Concepts are the first traces we leave behind in the virtual space of a project. We say: Go for the beautiful, make a difference. Be thrilled about describing something as succinctly and clearly as possible.

Better to meet the nasty details on paper than during implementation

It is much cheaper to deal with a nasty little (or even bigger) snag or trap during the conceptual phase than during implementation. Inconsistencies, contradictory requirements, assumptions yet to be verified – all these things are common in the beginning of a project and it is much better to discuss them prior to development or early in the implementation phase.

We strive to specify in detail early in the process. It is the job of the business analyst to put the concept down to paper.

The Data Model is the holy grail

If you mess up the data model, you mess up the project

Shortly after beginning the high-level concept, we start data modelling. If you mess up the data model, you mess up the project. Remember that we are building information systems: whatever happens in the system will be reflected in the data. The structure of the data represents our conception of the outside world. If this conception is incomplete, contradictory or fuzzy, then you will not be able to build a proper database model. If this is the case, it is better to rethink it. Sort this out at the beginning.

Analysing: Destroy it and Rebuild it!

We aim at creating an atmosphere where analysts and developers alike think out loud, oppose if necessary and come up with alternative solutions to a problem. If you build something up and destroy it for some good reason, then rebuild with the knowledge gained from the previous deconstruction, then you will ultimately achieve something better.

This is why we have the courage to destroy and rebuild over and over again – the only thing is: we do it on paper and in our thoughts. If you do it in reality, be prepared to bear astronomical costs! If you don’t do it at all, be prepared to bear astronomical costs.

Of course, the conceptual refinement cannot go on forever. Being a perfectionist on paper will not help you deliver. We know when it is time to start implementation.