Skip to main content

Get your Requirements Off to the Right Start with these 5 Steps!

It’s project kick-off time! February, more than any other month, tends to be the time when organizations transition from planning to action. New initiatives have been prioritized, dollars have been allocated and teams are being formed—everyone is ready to get to work.

BAs being assigned to these projects often working with new PMs or new leaders and sometimes leaders expect BAs to jump in and start detailed requirements, like NOW! BAs are often asked to begin gathering requirements before solution scope and context are defined. The project scope might be defined, but that does not mean the solution scope is defined.

Most leaders I talk to would say they expect that BA start with scope and context activities and some planning, yet BAs don’t feel that is what leaders are asking of them. BAs feel they are expected to jump into specification level of detail based on expectations from leaders and business stakeholders, coupled with unrealistic deadlines.

BAs might be tempted to go with the flow and jump right into detailed requirements. Instead, we need to rock the boat a bit, think strategically, and advocate for the time needed to properly get requirements right and avoid the rework. After all no matter if we are working on agile or traditional projects, rewriting and reworking requirements because we jump to writing details vs. aligning on the big picture spells waste and disaster. Our leaders DO want context and the big picture defined, even if they seem focused on details and deadlines. Here are 5 things BAs should do to build a solid foundation for their requirements:

  1. Create a Scope/Context Diagram: A high-level scope/context diagram helps the project team understand the boundaries of the solution. Agile and traditional teams benefit from this critical visual of the solution. It helps the team identify stakeholders, processes, products and systems that will be affected by the solution. The diagram offers a great starting point for dialogue when BAs begin their work. Even when assigned to a project late in the game, I start with this as a critical tool to build credibility with the team that I understand the scope of the solution, its impact. Stakeholders and I have alignment to where the details fit into the bigger picture, and this makes planning easier. I find leaders LOVE these diagrams and teams can rally around all the details once everyone has the same big picture visual to understand where the various details fit in.
  2. Document The As-Is and the To-Be: The as-is and to-be models, often presented in the form of a diagram rather than text, are a valuable tool for defining gaps between the current state and the future state. These models can model the process (current and new), the product (current and new) or the system (current and new). They are really great at showing the changes that will be taking place and that we are eliciting requirements for. These don’t need to be at a detailed level, they should be high level to start, adding detail if needed. Agile and traditional teams will rally around full understanding of what details impact what parts of the bigger process with the proposed changes.

    Most BAs see the value in this information, but they get caught up in details. We need to put our reading glasses and microscopes away and look at the big things. Outline the major differences between the current state and future state before beginning with the details.

  3. Identify Stakeholders: Who are your primary stakeholders and how will the solution impact their team, processes, and/or systems? This step seems so obvious. We know our stakeholders, right? We always have a list of key leaders and SMEs before a project begins. Have we taken it to the level of what user roles are impacted and how? And communicated/reviewed this with all project stakeholders.

    A key analysis at the beginning is to identify all user roles impacted by the solution and how they are impacted. This gets elaborated as we discover more, and a high level to start can really help the team move forward with very positive results.

    In truth, projects rarely start with exactly the right stakeholders. They either start with an unnecessarily large group (everyone), that we help refine and manage based on impact, or with small group that expands with the scope.

    When we leap into requirement details too quickly without solution scope, context, as-is and to-be, we miss stakeholders, which means we miss requirements. We use extra time to get these stakeholders up to speed on the project and they often miss the very important collaborative processes in the initial phases of elicitation.

  4. Outline Acceptance Criteria: Similar to the future state, acceptance criteria outlines the minimum criteria that will make the solution a success, and gives BAs and stakeholders a glimpse of the future. BAs begin to understand what success looks like and this picture keeps us focused on value. The strategic focus on value helps us make good choices along the way. On agile teams acceptance criteria is often paired with User Stories; here I am discussing the entire solution, so a comparable term in agile is MVP (minimum viable product) and its criteria.

  5. Tailor the BA Approach: For every new project BAs should consider what is new or different about the project. Which techniques will work best in the project environment to best define the solution? Is there more or less risk? In what areas? How can we use techniques to mitigate them? Custom development projects have a very different approach then package software, and process improvement projects are different as well. The same approach, techniques, and templates will not work, we need to tailor the approach for the unique project and solution characteristics.

    Even if the deliverable list remains the same for every project from a governance perspective, we always have flexibility in how we elicit the information and how to use the templates. For example, a package software project might require us to dig into and understand the vendor capabilities and functions and do a gap analysis, then user demos and prototyping with the vendor package. Whereas a project to build a new in-house system, with team members scattered across the world might require a series of virtual requirement workshops focused on the users, what they need, and why. Prepare for these differences and prepare the team for them.

When we consider these activities carefully, we quickly realize they are interdependent. BAs need to work through them iteratively, circling back through each task multiple times as the project evolves. For example, we can’t really develop a high-level scope diagram without the help of some stakeholders, and we can’t identify all stakeholders before you define the scope.

Because of this spiral effect, BAs need to be very aware of “good enough.” We need to be efficient in order to be effective. Don’t worry about perfect or complete. Focus on the main components and the quality of dialog, engagement, and relationship building with your stakeholders. We need to focus on what we need to generate and maintain your focus on value throughout the project.

Don’t forget to leave your comments below.

Comment