Analysis Traps and Antipatterns

Just as there are tips and practices, which could improve analysis effectivity, there are traps and antipatterns that may affect it negatively, and it is better to be aware of them and try to avoid them.

Stakeholders Predetermine Solution

When stakeholders describe their problems, they very often tend to include also their idea of the solution. So instead of stating "We need to solve this ", they often tell analyst "We want you to implement this ". This is dangerous because stakeholders do not have the whole context of the problem, they cannot foresee all possible impacts of the change they propose and cannot discover all alternative solutions. This is why the solution should always be the result of the analysis. Even though stakeholders may look convincingly ensuring that it has already been thought out carefully, the analyst should not fall into this trap, apply critical thinking, and double-check the solution proposal.

EXAMPLE

Head of Customer support emails analyst with the following request:

Each customer inquiry has one of the 5 predefined states. We need a report showing us a number of inquiries in each state for the current date/week/month and also the average time the inquiries stay in each state. It is required by the member of the board to measure the effectiveness of our department.

We have a similar report already in place, please see it attached. We want it exactly like this. It was developed by Mark Brown from Operations, a very nice guy, he understands the domain and can do it fast. Just please create a short specification and send it to him. He will get data from the data warehouse.

Thank you

Alice

It is soundly based, Alice very nicely expressed the need, she even recommended an IT guy who knows the domain, so what is the trap here? The problem is that what at first sight looks like a timesaver is actually a timebomb. What if we tell you that the report created by Mark was developed ad hoc because of some critical deadline and it was considered only a short-term solution. What if Operations, according to the company policy, are not supposed to create reports, even though they have a very good relationship with Customer support. There is a dedicated team managing all reports in the company, which has standardized tools and procedures for creating reports, and all reports should be consulted with them. Also, the data warehouse is by no means the primary data source for data reports. Data might be inaccurate in the time of report generating, and the company has introduced a dedicated analytical database for that purpose.

The analyst should always first understand the goal stakeholders need to achieve and why it is crucial for them. Only then could the analyst come up with possible solutions - in this particular case, customer support needs to know "the number of inquiries in each state for the current date, week and month and also the average time of inquiries in each state." Based on the need thus specified, the solution alternatives are:

1. Enhance the existing report
   • There is a similar report used by another department which includes 90% of the required information and which could be reused
2. Create a simple Excel report
   • Stakeholders need just a one-time report to quickly check the data, so such a simple solution will work for them
3. Create a dedicated report
   • A fully-fledged report supported by the Reporting team

These alternatives will be introduced to stakeholders who must select the final solution by assessing the value of each solution, evaluating how the solution supports business goals, and considering its cost/benefit ratio.

REMEMBER

Business analyst is the person in the organization whose responsibility is to connect the dots and see around the corner.

Unverified Information

Everybody lies.
— House MD

Stakeholders do not lie intentionally, but from time to time, they simply think they tell the truth, but they do not. They may not have the most up-to-date information, or they cannot see the whole picture, which causes that they provide misleading information. It happens, and it is the analyst's responsibility to apply the critical thinking and confirm each important information no matter from whom the information comes from. Of course, it would be annoying and time-consuming to double-check every information, but analyst should be sure at least about the most critical facts which might impact the project strongly. In the end, it is always the analyst bearing the responsibility, not the author of the misleading information.

Meeting Without Meaning

Analysts spend a lot of time facilitating different kinds of meetings, and it is crucial for them to be as effective at it as possible. Organizing a meeting that does not bring any real value does not only cost the time of the participants but if the attendees are important and very busy people, it is also a missed opportunity. Analysts should, therefore, be prepared for every single meeting to ensure the time is well spent.

REMEMBER

Meeting facilitation means leading or moderating the meeting

Organizing a quality meeting is not an easy task, and it requires training and skills. An appropriate meeting room must be booked, the right people who could contribute to the discussion must be identified, and an agenda along with the definition of the meeting goals must be prepared. This sounds easy in theory, but the following can ruin your meeting in minutes, leaving you with nothing but a burnt hour of time: inviting wrong people, not the following agenda, not keeping attendees on track, and not focusing on meeting the goals.

So how to avoid such a catastrophic scenario?

1. Invite the Right People

Composition of the meeting participants depends on the goal of the meeting. Does it aim to reach a strategic decision or the goal is to just find out how something works? Is it necessary to invite a manager or an officer will be sufficient? Or both will be needed? Do we want to discuss the topic from the business point of view or is it going to be more IT-oriented? All these questions are important to be answered to select the right participants.

2. Let the Participants Prepare in Advance

If the attendees could read the agenda and supporting materials before the meeting, the meeting will be more effective as it will not be necessary to waste time introducing the topic. What is more, the topic could also be discussed in more detail since the participants could learn the details in advance, and the basics could be skipped.

1. Create an agenda, attach supporting materials like meeting minutes from the previous meeting, diagrams or sketches and send it to attendees before the meeting
2. Optionally prepare an introductory high-level picture of the problem which will be used at the beginning of the meeting to synchronize the view of all attendees; depending on the topic this may be a high-level process, a problem decomposition or a wireframe of the screen

3. Introduce Agenda and Meeting Goals

At the beginning of the meeting, nobody should be allowed to discuss stuff, before the facilitator welcomes everybody and clearly states the purpose and the expected goals of the meeting. The facilitator should first confirm the purpose of the meeting and define each attendee's contribution. Before discussing the future solution, the facilitator should make sure everybody understands the current state - how the process, system, or other organizational component works at the moment. There is nothing worse than having the group discussing the future state while everybody has a different opinion on how it currently works.

4. Go Top-down

To avoid participants to lose track of the meeting, keep the meeting flow top-down, discussing the general topics first, and elaborating details afterward.

5. Stick to the Topic

Some participants will try to use the meeting as an opportunity to talk to people whom they otherwise would not have a chance to talk to. This means there might be attempts to inject unrelated topics into the meeting. In this case, the facilitator should stop the conversation politely and ask the participants to discuss only the topics included in the agenda. The facilitator is responsible for reaching the goals of the meeting, which may not happen if the valuable time is wasted on topics that do not support the goals.

6. Take Notes

Most facilitators cannot remember everything that was told in the meeting, so the notes should be taken. If it is not possible to facilitate a big meeting and take notes at the same time, the facilitator should ask somebody to help by making a scribe.

7. Close-up the Meeting Correctly

Each meeting should be closed by summarizing the points where the agreement was reached, the topics which will require a follow-up meeting, and the main tasks generated during the meeting. This information should also be sent to the participants in the form of meeting minutes.

Overloading With Details

The significant part of the analysis is learning the current state - discovering how a specific system or process works. One of the possible approaches is asking people who know the particular part of the enterprise to provide the details. Paradoxically, the more people know, the bigger trap the elicitation may represent. These people try to tell everything they know in goodwill the more information they provide, the better. So they start a fast and unorganized stream of information, jumping from one topic to another, from very high-level topics to complete details. This approach usually leads to overloading analyst with information which is not necessary at this early stage, moving the activity away from discovering the main goals and rapidly decreasing analysis effectivity. Analyst must be prepared for this and facilitate the elicitation properly.

1. Before starting the elicitation, the analyst should know the domain. If not, the first step should be letting the expert introduce the business area, independent of the specifics of the current organization.
2. Then the elicitation could continue with the description of the organizational component which is subject to change:
   • If it is a process, the analyst should ask for a map of the process steps that form the happy path without considering exceptions or error flows. The description should be just business without mentioning any concrete systems.
   • If the subject to change is a system, the first step is to identify the most important use cases. The analyst should understand how the users work with the system. Such a description includes just basic flows without mentioning concrete screens without calling external systems or data manipulation and without considering exception or error flows, which would distract from understanding the main goal.
3. Once the analyst understands the domain and the high-level purpose of the process or system, the elicitation could move to more detailed topics such as mapping the process to concrete systems or screens, describing the concrete steps performed by the user in the application or describing exceptions and variations to the main path.

Neverending Projects

Regardless of the used software development approach, be it a rigid waterfall, a flexible agile or anything in between, the analyst is always responsible for pinpointing the boundaries of the project scope and for defending the area from intruders - the unrelated features or changes of the scope. True agilists may now shake their heads because one of the main agile principles is "Welcome changing requirements," right? Yes and no. Even agile projects have a scope, requirements must be aligned with the business goals, and the requirements must be prioritized so that it is possible to say which are the most important. It is not possible to endlessly inflate the project or to start including requirements that do not support business goals. Therefore, some rules must be applied to avoid falling into the scope creep.

SCOPE CREEP

Refers to changes, continuous or uncontrolled growth in a project's scope, at any point after the project begins. This can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered harmful. (source: Wikipedia)

Stakeholders sometimes try to smuggle unrelated requirements to the project, and despite being open to changing requirements, the analyst should always assess their relevance and verify whether the requirements support the business goals stated by the project. Very often, requirements are added to the scope just because the project has the necessary budget, and it is more convenient for anybody to implement it this way than to ask for starting a new project. Such requirements horse-trading cannot be effectively avoided, especially if the decision power is held in someone else's hands, but the aim should be to focus primarily on requirements that solve the identified business problem.

Fixed Scope, Fixed Time

There are projects, which are expected to deliver a fixed set of "must-have" requirements, and at the same time, the requirements must be delivered by a strict deadline. We all know it is a big trap that should be avoided in the first place, but if this happens, the only thing analyst could do is define, what is the minimal set of requirements that deliver value to stakeholders. In most cases, some requirements are must-haves, but in an emergency, they may be replaced with some backup solution, such as a manual calculation or storing information in Excel instead of the system for a limited time. It does not really matter whether the project is waterfall or agile, if there is a fixed deadline, every project can go behind schedule, and an emergency plan should be prepared.

RED LINE

In case everything does not go according to the plan, the analyst in cooperation with stakeholders should identify the minimum requirements which must be delivered by any means. It will serve as a safety net, which ensures the delivered solution will be usable even without being complete, and it will also show to the development team what the priorities are so they will not spend time on below-red-line features.

Project Manager Performing Analysis Tasks

The project manager's responsibility is to track if the project is on track, if it has the right people available and whether it is committing to the agreed deadlines. They also manage the project scope, which is where analysts should be careful. In terms of scope, PM almost fully depends on the analyst. PM knows the very high-level boundaries, but it is the analyst who elicit the requirements and who understands them. On the other hand, the PM is the one who puts the head on the block regarding the scope, so PM often tries to influence the requirements or sometimes even tends to substitute analyst during the elicitation. The analyst should not allow for that. Project managers do not have the required skills to elicit, analyze, and manage requirements, and they do not know how to describe and structure them. PM has to manage the scope but only in terms of controlling that all activities are done according to the scope marked out by the analyst.