I’ve written a fair number of requirement documents in my business analyst lifetime, and I’m still not sure what took longer – gathering and documenting the requirements, or trying to get the business to read and approve them.

Let me know if this sounds familiar…

You spend weeks, maybe months, eliciting requirements, reviewing requirements, and documenting requirements in a nicely formatted word document with the title Business Requirements Document (or something similar) slapped on the front. You are proud of the work you have done, the diagrams you have drawn, the requirements you have logically ordered and laid out for your stakeholders to read – and you’re sure that you have made it down right simple for anybody to just open it up and review it.

You happily click send on the email, sure that your stakeholders will read it and send back their input within the requested time frame—after all, who wants to risk the project deadline, right?

Problem is, usually stakeholders don’t have the time, or the space, to review a long—and let’s be honest—often boring, requirements document.  Your priority as the BA to get the requirements document reviewed and approved is unfortunately often not their priority—and it’s extremely hard to make it so. Or even when you do get their input, what you receive is often not as meaningful as you were hoping—I remember on more than one occasion receiving a requirements document back with fewer comments about the requirements themselves than about the spelling or grammar style I chose to write it in.

In today’s projects, where the dynamics of the solution is constantly shifting, the complexities increasing, and our stakeholders’ attention spans are ever so quickly decreasing (whose isn’t really?)—the inefficiencies of using a document to record, manage, review, and gain stakeholder approval for requirements needs to be questioned.

If it’s not, projects will continue to be negatively impacted by:

• Incomplete and inaccurate sets of requirements
• Delayed implementation schedules
• Lack of stakeholder engagement
• High levels of change requests during the test phase
• Lack of user adoption once the solution is implemented
• High levels of rework resulting from requirement misunderstandings 

And, I’m sure you can probably name a few more that affect you as well.

We need to start acknowledging, and managing, the fact that stakeholders simply don’t have the time, or the desire, to read the stodgy documents we tend to throw at them in projects. We also need to acknowledge that much like the projects we are working on, requirements also need to be able to easily adjust and pivot with the changing dynamics of a project landscape.  Business objectives can change, stakeholder needs can change, the market can change, the priorities of what we are building can change—and with those changes, the requirements need to change as well.

As business analysts, we need to be able to effectively manage them. Assessing change requests can be one of the largest challenges any project manager or business analyst faces on a project—and attempting to do it from within a large document, can make it all that much more worse. In fact, doing so poses a risk to the entire project.  How can you tell what the impact of a change request will be when the traceability and context of a requirement is spread confusingly throughout a document? Wouldn’t it be easier to just see all those impacts in one place? And really that is just one small example of how managing requirements within a document can be so inefficient.

So what’s the answer?

Well, at Enfocus Solutions, we think: enough with managing the documents, time to start focusing on managing the data instead.

To effectively manage requirements means that as business analysts, we need to stop spending our time on managing the document the requirements are in, and instead focus on managing the requirements themselves.

We need a better way to:

• Review requirements with stakeholders and receive meaningful feedback to ensure the accuracy and completeness of their requirements as we move through the project.
• Establish a visible and accessible location to document the requirements for a project.
• Control the changes made to the requirements once initial approval has been achieved, and control the resulting versions of requirements that result.
• Effectively communicate changes to requirements to the right stakeholders throughout the lifetime of a project.
• Capture the context and traceability of the requirements we define—where they came from, why they are being developed, and what value they will ultimately deliver.

So what does managing data instead of documents look like?

Instead of documents, and the multiple versions that usually result…

Use a requirements management tool to establish your single source of documenting, reviewing, validating, and managing requirements throughout the lifetime of your project.

Instead of gathering stakeholder feedback in isolation of one another…

Establish transparency and generate conversation with and amongst your stakeholders using a tool that allows you to capture stakeholder comments and needs in one location on the requirements themselves, keeping the conversation visible and accessible to everyone else on the project.

Instead of validating and approving requirements all at once, after you’ve completed the document…

Validate and gain stakeholder approval as you go—eliminating the need for stakeholders to navigate their own way through a large requirements document, and enabling them to easily navigate their way to only the requirements that impact them.

Instead of limiting the participation of your project team by making them wait for a completed and approved requirements document….

Enable collaboration with them by providing visibility and access to the validated requirements as you go through the project. If you start to review with your stakeholders as you go, then developers and testers can start to work in parallel with you too. Keeping your team actively involved in the conversation from the start, is just as important as keeping your business stakeholders involved.

Instead of wanting to pull your hair out trying to manage changes to requirements after review and approval…

Manage the change requests through a defined process built into your requirements management tool, so you can easily assess the impact each change will make and control the changes that are included in each release.

And the list can really go on.

Documenting requirements is an important part of any successful project, but at the end of the day if we are spending our time and energy on managing the vehicle we are communicating them instead of the requirements themselves, there is a large risk that requirements will be overlooked, be incomplete, and ultimately not clearly define what it is the business needs to be successful.

Once the shift starts to move away from building and managing the documents that hold the requirements themselves, and more towards managing the data within them, then the opportunity for improved collaboration, requirements quality, requirements development, testing, and ultimately, project success is what results.