Analysis Tips and Practices

There is a wide range of skills that professional analysts must possess, but the truly effective individuals are also aware they need something more to quickly understand the problem, stay organized and communicate smarter. This chapter is going to provide several tips that may positively influence the analyst's day-to-day routines and make the analysis efforts more effective.

Learning the Domain

A business analyst is expected to serve as a partner for the stakeholders, help them find solutions to their needs, and drive the organizational changes. To achieve this, business analysts must know the domains in which the company operates. Even though some analysts specialize in only one domain, it is more common they change domains, either by changing the company or within a single company. Big organizations operate in multiple areas, and it is not exceptional that analysts must be ready to start working on projects in different domains or projects which span across various domains. For example, in a bank, an analyst may be assigned a project dealing with mortgages and then could be asked to help find a solution in credit cards once the mortgages are done.

Of course, it is not expected of analysts to know everything from day 1 as long as they can learn along the way. However, stakeholders are not going to have patience. They know the processes and systems from A to Z, and they cannot look at it with the eyes of the newcomer. They will be using their terminology, referring to the processes and systems they know and will be unconsciously talking about the problems as if they were talking to their peers. It is not that they would not want to slow down and explain it the simple way, but they simply cannot. For this reason, the analyst needs to catch up fast and prepare in advance to gain the required knowledge and self-confidence. The analyst must be on track from the first minute not to miss any vital fact and to establish good relationships with stakeholders. It is not simply possible to build respect and trust with the stakeholders without knowing the basics of their work. One approach is to ask for business training and software demonstrations before the actual analysis starts to get into the problematics and learn the terminology. Meeting all stakeholders face to face beforehand is also a great benefit, yet not always feasible.

Understanding the Context

Although "the devil is in the details", to avoid the devil, we need to first learn how the hell works. An analyst must understand the high-level context before diving into the details. Is it clear what the real need behind the requirement is? Was it clarified what is the business purpose of the application to be built? If a part of the process should be changed, do we know how the whole process looks like? Looking at the problem from the level, which is one or two levels above it, could pop up interesting consequences which may more or less influence the final design of the solution.

a) Forget the IT Side

As mentioned in the previous tip, it is very hard for stakeholders not to dive into details, which complicates attempts to understand the context of the problem. One way to prevent this is to ask the stakeholders to describe what they need to do without involving IT systems. This way, they will focus just on the business steps without thinking about the implementation details. The goal is not to ignore this information, but just to postpone its elicitation after the overall context of the problem is clarified.

b) Start With the Process

The context of the problem strongly depends on its nature. If it requests to change the flow of steps in the application, the context is very likely to be a use case. If the problem is the wrong data is being saved into the database, the whole route of the data must be mapped to identify the application which might have corrupted it. And for most business-level problems, the context is a process. All mentioned examples share one attribute. The context is basically a sequence of steps which represent a "process", yet each is at a different level of abstraction.
The process is the best way of defining the context of the problem. Knowing what precedes the modified step and what follows it, comprises a big picture which gives analyst certainty that no part of the chain has been ignored and all impacts have been discovered. A process is a great starting point when learning the current state and also a very effective way of capturing the future state.

Example

The following diagram depicts the process of assessing incoming CVs. After the CV is received, the HR officer converts it to PDF and uploads it to the Document Management System (DMS), where it is reviewed by the reviewer. In the old version of the process, the reviewer is automatically assigned by the DMS, which has shown not to be the best solution, so the analyst is asked to change the process so that HR officer will be able to manually assign the best reviewer for each CV:

Knowing the context of the required change enables analysts to look at the problem from a broader perspective and identify more complete solutions. What is more, having such a high-level model also has additional advantages:

• It streamlines the presentation of the changes to the stakeholders. The model clearly demonstrates what is going to be changed and how each party is going to be affected.
• It enables presenting the changes to multiple parties at the same time and still keeping the meeting organized as each party could focus only at the specific part of the process
• Current and future state could be easily compared by presenting them side by side

Hands-on

We sometimes see analysts have a solid knowledge of the process, they know who and when performs the individual steps, but they know it just theoretically. They were told how the process works, but they actually have never tried it themselves. They have never talked to the people who really carry out the tasks, and they blindly rely on the high-level information from managers. Seeing the real screens and "touching" the system with the actual users usually changes the game for them. Analysts instantly start to look at the problem differently; everything is suddenly more concrete and clear, and they become more productive.

Does it sound silly that somebody would start analyzing a system without even seeing it? In business analysis, this is more common than one would think. When analyzing the impacts of changes to a complex business process, which involves five or six different systems, it is simply not possible to simulate all scenarios of the process in a reasonable time. It might not even be possible to see all parts of the process in the real applications as the process may be so complicated that just simulating it end to end in all systems would take more time than the actual analysis. On the other hand, it is not necessary to simulate everything in the process, and the advice here is to insist on seeing at least the main parts of it live. The best approach is to team up with somebody who knows the systems such as testers or system specialists, who can also simulate the basic scenarios to help the analyst grasp the idea of how it all really works together. Another way is to ask the end-users directly to show how they use the systems in production. This is great as it enables analysts to see how the real users perform the process steps, yet unlike testers, users cannot simulate all scenarios. The ideal situation is to combine both ways.

Mapping Both the Future State and the Current State

Analysts always look ahead, because even though they first need to understand the current need, their main job is to find the future solution to that need. The solution is basically a specification of what will be created or changed in the future, be it the system, process, or even the whole part of the enterprise. It is the future state, which is essential since project managers and developers are not interested in how it works now, they need to know what they are expected to deliver in the future.

Stakeholders look at it slightly differently, though. They first need to select the best solution to be implemented by assessing the alternatives provided by an analyst. This involves understanding what exactly each solution alternative will change, how it will affect the way they work now, and what value it will deliver. For this reason, it is also crucial for them to understand the current state. Comparing the solution alternatives with the current state helps understand the context, learn the main modifications, and justify the decisions.

Learning to be Structured

One of the biggest values of a business analyst is the ability to take a big tangled ball of information, untangle it and give back several smaller balls ordered by color. It is a well-known fact that humans struggle with analyzing big problems. We should keep in mind that our brain is far more effective in processing smaller chunks of information comparing to the big amount of data, so every analyst must learn to break down complex problems into smaller pieces. When being introduced to a complex issue, the best way of splitting it into smaller ones must be first identified, which helps analyze it piece by piece. There is never only one way of slicing the problem. What is more, there is also no rule what size the pieces should have. This all depends on the problem, purpose of the analysis, and recipients of the analyzed information.

The following example demonstrates breaking down a big entity to smaller subcomponents which helps understand the complex system by analyzing its individual parts:

Having a High-level Picture

After the problem is identified and successfully broken down into smaller pieces, another piece of advice is to visualize it. During the project, it is going to be necessary to introduce the problem to various people, both from the business and IT. Stakeholders and the development team, they all will have to learn the basics and understand the context of what they are going to build and why, which is best described using a visual overview. The picture can depict impacted business areas, the future version of the business process, a comparison of the current state and the future state, a project timeline, or a context diagram. Having such an initial picture is very handy for introducing the problem to people and for highlighting the boundaries and scope of the problem or project. It is such an elevator pitch of your analysis effort.

The following example represents an overview of monitoring payments and clients in the bank. It provides a high-level summary of what checks are in scope, what is the purpose of each check, and which systems are responsible for the checks.
Such a picture will help the analyst introduce the domain to people very effectively, ensuring that all of them have the same starting knowledge. This picture should be put visible publicly (on a project home page, for instance) so that anyone can refresh the basics anytime they want.

Having a Map

The concept of creating an overview of the problem or solution, as mentioned in the previous section, could also be applied to the analysis process or the whole project. The typical project contains a lot of information stored in various tools. Some information is stored in the documentation, some could be found in the issue tracking, communication log, or in a business case, for example. It is then complicated to compose an overall high-level picture of the current status of the analysis or project to recall the critical decision, current deadlines, or the most vital open points. Although it is somewhere, it is very uncomfortable to list through 40 pages of text and diagrams every time you need to refresh something. For this purpose, a mind map has proven to be a great tool. It can present key facts such as crucial deadlines, contacts, or open points in one place and in a very convenient form.

However, this approach requires duplicating information between the primary storage and the map, so it must be used wisely, and the duplication must be justifiable.

Having Communication Log and Task List

On bigger projects, sooner or later, the amount of overhead information exceeds the level, which is possible to keep in head. One could simply can't remember everything that has been promised to stakeholders, what the stakeholders have pledged to, and where is the communication supporting the key decisions. So it is better to have a communication log and a task list right from the beginning.

Communication log includes all important communication, incoming or outgoing. Not all information goes to an official document, and even if it is somewhere in the email, it is more convenient to have a distilled hierarchical audit. It may include what somebody required from me or from the project, including our reply or how somebody replied to our request.

Task list contains the status of the partial tasks which are not suitable to be included in some tracking software.

Preferring Face-to-face Communication

Analyzing systems, processes, or business needs is a complex task itself, and the complexity should not be increased by using non-face-to-face communication, which magnifies the risk of misunderstanding. Email or instant messaging is slow, and the written form may lead to misinterpretation, so the face-to-face or phone communication should be by any means preferred. Another important aspect is that analysts need to work hard to get the trust of the stakeholders. This cannot be achieved via email, as it is not strong enough to deepen relationships. To become an equal partner, stakeholders must know the analyst personally. This also applies to environments, where everything needs to be recorded in order to prove that it was really negotiated, the only difference is that analysts should always make a short summary of what was mutually agreed on during the face-to-face meeting.

Avoiding Offline Documents

The times of writing documents, sending them via email for review, and then copying the stakeholders' comments back to the original document are gone. We are living in the time of modern collaboration tools like online office suits or wikis, so it is no longer necessary to send whole documents when it is enough to send just a link. It might not always be easy or even possible to accomplish, but analyst should at least try to set up a common single place to store information which enables collaboration and sharing.