How to align stakeholders around project scope without a requirements review and sign-off process

A few months ago I posted about how requirements walk-throughs are a necessity in any good requirements development process. I’m here today to tell you I’ve changed my opinion.  It’s not that walk-throughs lack value. They definitely do. But the timing, scope, and methods of these reviews might need to be reconsidered. A structured requirements walk-through is not always appropriate.

So let’s take a step back and think about what problem we’re trying to solve with requirements reviews.  In my opinion, reviews seek to align stakeholders around scope, either of an entire project or a subset of a project that directly impacts them.  We want them to understand what is changing and how this change will impact them. We want to reduce (or even eliminate) unnecessary rework by validating our assumptions, getting meaningful feedback, and working through options before we invest valuable development time in building the solution. Why would we assume that walking through a document is the best way to achieve these objectives?

I don’t know. But I did and so do many other business analysts out there.  I’m here today to say I’ve jumped off of this particular Ivory Tower and landed on a plush cushion full of contextual insights about how to achieve these objectives.  By eliminating a “best practice” and replacing it with an open-minded acknowledgment that there are multiple paths toward achieving alignment, I feel confident my work on future projects will result in more meaningful approvals and scope sign-offs.

Instead of developing a new best practice to replace an out-dated one, consider some characteristics of your stakeholders and be clear about what you are trying to achieve. Factor these into your approach to requirements reviews.

Who are your stakeholders? Do your stakeholders know how to read requirements?  Seriously. Do they? Many of your most important stakeholders won’t give a lick about your beloved requirements and it’s self-centered of us to think they can and should.  It’s easy to lay blame when these individuals don’t provide the feedback we’re looking for.  I say that it’s our job to get meaningful feedback despite whatever short-comings our stakeholders might have. If they need pictures, draw pictures. If they are good at reading lists, create them. If they want a story, tell it.  It’s our job to keep all the various ways of communicating requirements in sync. It’s their job to meet you half way and provide meaningful feedback.  Here are just a few ideas for communicating scope across your organization:

1. Create high-level documents, even slide decks for engaging presentations, for executive-level stakeholders.
2. Consider one-on-one meetings for your most important stakeholders, such as the CEO, who hold the funds but probably don’t want the details.
3. Compartmentalize the details that are important to each individual or functional group. Schedule separate meetings, unless their concerns overlap and you need to facilitate collaboration.
4. Visuals speak louder than words, especially words that encompass requirements lists.  Use diagrams to talk through complex processes and wireframes to simulate new software experiences.
5. Save the details for the people who care and have something to say about them.

What feedback are you looking for? Before scheduling a requirements review meeting, take some time to consider your desired outcome.  What do you want to achieve? What do you want to learn?  What input do you need make the project more successful? Here are some useful tips for getting the feedback you are looking for in requirements discussions:

1. If your purpose is discovery, list out your unknowns in a list of discussion points for the meeting. Organize them in a logical manner than aligns with a visual you can talk through.
2. If your purpose is to validate and flesh out hidden assumptions, have a list of talking points to ensure the attendees are “thinking through” the process in the same level of detail you are. Maybe this can be accomplished through a use case review, but maybe you are just as well off talking through a diagram and keeping the use case to yourself.
3. If your purpose is to facilitate collaboration where there is conflict, have a preliminary understanding of each individual’s point of view and some ideas for resolving the issue.
4. What are the uncertain parts of the process you want to validate?
5. What pieces do you know you know and can be skirted over or avoided in a review altogether?

None of this above should be read to say that requirements don’t matter or that the deliverables are unnecessary.  I’ve analyzed many a problem by writing a use case that no one ever saw except the developer–the content of the use case was fully validated while the “use case” itself was not.  So yes, requirements matter for many, many reasons…but consider separating how you document your requirements and how you communicate your requirements for the sake of getting meaningful, targeted feedback that will make your software projects more successful.

I’m new at this. Jumping off an ivory tower of a “perfect process” is never easy, but it’s almost always rewarding. What are some interesting ways you’ve used to get the input you need?

By Laura (Brandau) Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura (Brandau) Brandenburg

Related posts:

1. Reverse Engineering Requirements: Select a Business Owner and Identify Scope
2. Help your stakeholders discover technical possibilities to define new project concepts
3. Can we elevate constraints in the requirements process to encourage creativity?