Effective Analysis and Documentation

Analysis Traps and Antipatterns

Just as there are tips and practices that can improve analytical efficiency, there are also traps and antipatterns that can degrade it. It is vital to be aware of these pitfalls and actively avoid them.

Stakeholders Predetermine Solution

When stakeholders describe their problems, they very often tend to bundle in their own ideas for a solution. Instead of stating, "We need to solve this," they often tell the analyst, "We want you to implement this." This is dangerous because stakeholders rarely have the full technical context, cannot foresee all the downstream impacts of their proposed change, and often overlook alternative solutions. This is why the solution should always be the result of the analysis, not its starting point. Even when stakeholders sound incredibly convincing and assure you that everything has been thoroughly thought out, the analyst must not fall into this trap. Apply critical thinking and double-check the proposed solution.

EXAMPLE

The Head of Customer Support emails an analyst with the following request:

Each customer inquiry is in one of 5 predefined states. We need a report showing the number of inquiries in each state for the current date/week/month, as well as the average time inquiries spend in each state. A board member requested this to measure our department's effectiveness.

We already have a similar report in place—please see the attached file. We want it exactly like this. It was developed by Mark Brown from Operations, a great guy who really understands the domain and can build it quickly. Please just write up a short specification and send it to him. He will pull the data from the data warehouse.

Thank you,

Alice

On the surface, this looks solid. Alice clearly expressed the need and even recommended an IT professional who knows the domain. So, where is the trap? What looks like a timesaver is actually a time bomb. What if Mark's original report was hacked together ad hoc to meet a critical deadline and was only meant to be a short-term workaround? What if Operations, according to company policy, isn't supposed to build reports at all—regardless of their great relationship with Customer Support? There is a dedicated Reporting team that uses standardized tools and procedures, and all new reports must be routed through them. Furthermore, the data warehouse is not the appropriate primary data source for real-time operational reports. The data could be inaccurate at the time the report runs, which is precisely why the company introduced a dedicated analytical database.

An analyst should always first focus on the goal stakeholders need to achieve and why it is crucial for them. Only then should the analyst explore potential solutions. In this specific case, Customer Support needs to know "the number of inquiries in each state for the current date, week, and month, and the average time inquiries spend in each state." Based on that core need, the actual alternatives are:

  1. Enhance the existing report
    • A similar report used by another department already contains 90% of the required information and could be repurposed.
  2. Create a simple Excel report
    • If stakeholders just need a one-time snapshot to quickly check data, a simple, low-cost solution like this will work.
  3. Build a dedicated report
    • A fully fledged, sustainable report built and supported by the official Reporting team.

These alternatives should be presented to stakeholders, who can then choose the final path by assessing the value of each option, how well it supports business goals, and its overall cost-benefit ratio.

REMEMBER

A business analyst is the person responsible for connecting the dots and seeing around the corner.

Unverified Information

Everybody lies.
— House M.D.

Stakeholders rarely lie intentionally, but they often share information they sincerely believe is true, even when it isn't. They might be working with outdated information or lack a complete view of the organization, leading them to provide misleading details. This happens, and it is the analyst's job to apply critical thinking and verify key pieces of information, no matter who provides them. Of course, it would be exhausting and counterproductive to double-check every minor detail, but an analyst must be absolutely certain about the critical facts that could make or break a project. In the end, the analyst bears the responsibility for the requirements, not the person who supplied the inaccurate data.

Meetings Without Meaning

Analysts spend a massive amount of time facilitating various types of meetings, so it is crucial to make them as efficient as possible. Running a meeting that yields no real value doesn't just waste participants' time—if the attendees are busy, high-profile stakeholders, it is also a massive missed opportunity. Analysts must prepare meticulously for every single meeting to ensure that time is well spent.

REMEMBER

Meeting facilitation means actively leading and moderating the discussion.

Organizing a productive meeting requires deliberate effort and skill. You need to book an appropriate room, identify the right people who can actually contribute to the discussion, draft an agenda, and clearly define the meeting's goals. This sounds simple in theory, but a meeting can fall apart in minutes if you invite the wrong people, fail to follow the agenda, let attendees drift off-track, or fail to focus on the goals.

How can you avoid such a catastrophic scenario?

1. Invite the Right People The participant list depends entirely on the goal of the meeting. Are you trying to reach a strategic decision, or are you just trying to understand how a specific process works? Do you need a manager, an frontline worker, or both? Will the discussion be purely business-focused, or will it tilt toward IT? Answering these questions upfront ensures you have the right brains in the room.

2. Let Participants Prepare in Advance

If attendees can review the agenda and supporting materials before they walk into the room, the meeting becomes far more efficient because you won't waste time introducing basic concepts. Instead, you can jump straight into the details.

  1. Create an agenda, attach supporting materials (like minutes from a previous meeting, diagrams, or wireframes), and send them out well in advance.
  2. Consider preparing an introductory, high-level visual overview of the problem to quickly align everyone at the start of the session—such as a high-level process map, a problem breakdown, or a screen mockup.

3. State the Agenda and Meeting Goals Clearly

At the start of the meeting, the facilitator should welcome everyone and explicitly state the purpose and expected outcomes before opening the floor to discussion. Confirm the meeting's objective and clarify what each attendee is expected to contribute. Before diving into future solutions, ensure everyone aligns on the current state—how the process or system works today. There is nothing worse than a group debating a future solution when everyone has a different assumption about how things currently operate.

4. Go Top-Down

To keep participants from losing the thread, structure the meeting top-down. Address general, high-level topics first, and dive into specific details later.

5. Stick to the Topic

Some participants will view a meeting as a rare opportunity to pitch unrelated pet projects or chat with colleagues they don't see often. If attendees try to introduce unrelated topics, the facilitator must politely intervene and steer the conversation back to the agenda. The facilitator is responsible for hitting the meeting's goals, which is impossible if valuable time is squandered on side discussions.

6. Take Notes

No facilitator can remember everything said in a dynamic meeting, so taking notes is mandatory. If you are leading a large, intense session and cannot facilitate and type at the same time, appoint a dedicated scribe to assist you.

7. Close the Meeting Properly

Always wrap up a meeting by summarizing the points of agreement, identifying topics that require a follow-up session, and reviewing the action items generated. This summary should be distributed to all participants shortly afterward as formal meeting minutes.

Overloading with Details

A significant part of analysis involves learning the current state—discovering how a specific system or process works. A common approach is to interview subject matter experts (SMEs). Paradoxically, the more these experts know, the easier it is to fall into a trap. In their eagerness to help, SMEs often try to share everything they know all at once. They launch into a fast, unorganized stream of information, bouncing erratically between high-level concepts and hyper-specific details. This firehose of data overloads the analyst with irrelevant details too early in the game, distracts from the core goals, and derails analytical efficiency. The analyst must actively manage and facilitate these sessions.

  1. Before starting elicitation, the analyst should learn the domain. If the domain is unfamiliar, the first step should be asking the expert for a general introduction to the business area, independent of the company's specific setups.
  2. Next, transition to eliciting details about the specific organizational component slated for change:
    • If it is a process, ask for a map of the "happy path" first, completely ignoring exceptions, errors, or specific IT systems. Focus purely on the business steps.
    • If it is a system, start by identifying the primary use cases to understand how users interact with it. This description should outline basic flows without getting bogged down in specific screens, external system calls, database manipulations, or edge-case errors.
  3. Once you grasp the domain and the high-level purpose of the process or system, you can safely drill down into detailed topics, such as mapping process steps to specific screens, detailing user actions within an application, or mapping out exceptions and alternative paths.

Neverending Projects

Regardless of the software development methodology used—whether rigid waterfall, flexible agile, or anything in between—the analyst is always responsible for defining the project scope and defending it against scope creep. Strict agile practitioners might disagree, citing the principle: "Welcome changing requirements." Yes, but even agile projects require boundaries. Requirements must always align with business goals and be rigorously prioritized. You cannot endlessly inflate a project or accept requirements that fail to support the core business objectives.

SCOPE CREEP

Refers to the continuous or uncontrolled growth of a project's scope at any point after the project begins. This occurs when the project scope is not properly defined, documented, or controlled, and it is generally harmful to project success. (Source: Wikipedia)

Stakeholders will frequently try to smuggle unrelated requirements into an active project. While maintaining openness to change, an analyst must evaluate the relevance of every single request and verify whether it supports the project's original business goals. All too often, features are tacked onto a scope simply because a project has a remaining budget, and stakeholders find it easier to hide a feature there than to fund a new initiative. While you cannot always stop this horse-trading—especially when senior management forces it—your primary focus must remain on requirements that directly solve the core business problem.

Fixed Scope, Fixed Time

Some projects are expected to deliver a rigid, fixed set of "must-have" requirements by an unyielding deadline. Everyone knows this is a dangerous trap that should be avoided from the outset. If you find yourself in this situation, the best move is to define the Absolute Minimum Viable Product (MVP) that still delivers baseline value. In a pinch, even a "must-have" requirement can often be replaced by a temporary manual workaround, such as manual calculations or tracking data in Excel for a limited time. It doesn't matter if the project is waterfall or agile: when a deadline is fixed, slippage is a real risk, and a contingency plan is mandatory.

RED LINE

When things do not go according to plan, the analyst, in cooperation with stakeholders, must identify the bare minimum requirements that must be delivered no matter what. This acts as a safety net, ensuring the delivered solution is usable even if incomplete. It also signals clear priorities to the development team, keeping them from wasting time on nice-to-have features that fall below the red line.

aa

Project Manager Performing Analysis Tasks

The project manager's job is to ensure the project stays on track, has the right resources, and hits its agreed deadlines. They also manage the project scope, which is where analysts need to establish clear boundaries. When it comes to detailed scope, the PM relies almost entirely on the analyst. While the PM understands the high-level boundaries, the analyst is the one eliciting and truly understanding the granular requirements. However, because the PM is the one answering to leadership for the project's delivery, they often try to influence requirements or even attempt to take over elicitation sessions. The analyst should not permit this. Project managers generally lack the specialized skills to elicit, analyze, structure, and manage requirements. The PM should manage scope exclusively from a tracking perspective, ensuring that project activities stay within the boundaries established by the analyst.