Having trouble getting your requirements approved after they’re ready for review? Chances are your process is missing one or more of the following:
1) Have you established and clearly communicated the value to be delivered by the project to the people in charge of approving the requirements?
If a requirements document is taking a long time to approve, I’m willing to bet that the value to be delivered by the project is not crystal clear for the people in charge.
While a lengthy and difficult to read document can be an obstacle for a quick sign-off process, I guarantee you that if a project is going to solve an important problem or address a big opportunity for the company, the decision-makers responsible for the approval will find a way to get around this issue. Stakeholders might ask the business analyst to repackage or split the requirements into smaller chunks so that they become easier to review. Or decision-makers might just ignore your requirements and start working directly with the developers to get the ball rolling. But in real-life nobody is going to delay the implementation of an important project just because of the size or format of the requirements document is in the way of achieving sign-off.
Imagine that your organization uses a CRM system that is causing the sales team to waste 30% of their time entering information that could be easily automated (e.g., logging customer calls, updating contact information that could be easily extracted from the email system, etc.). The sales team complains, and the IT department approves a project to implement enhancements. You work with the end-users to clarify the need and send the requirements to the VP of Sales, who “owns” the CRM system and is supposed to approve the requirements before the project can proceed. The document sits in the VP’s inbox for weeks, and when you contact her to ask for an update, she repeats that “it’s on her to-do list”.
How to fix this issue: Make sure the decision-makers in charge of requirements approval understand who the solution is for, what problem it’s meant to solve, and why it matters for the organization and for their individual goals. Your stakeholders will inevitably get busy with all sorts of demands for their time. In order to have an incentive to make your project a priority, they’ll need a clear picture of the “glory” that will result for them from putting aside time to review the requirements for this initiative.
Put yourself in the shoes of the VP of Sales. She may be busy creating sales projections for the next quarter or discussing the new territory division with the CEO. The CRM enhancement will not make her job easier (the exact same information that exists today in the system will continue to exist after the integrations and automations are in place). Why would she make it a priority to review and approve your requirements?
Now, compare with this scenario. Once the project is initiated, you contact the VP of Sales to let her know what you’re working on, and explain what’s in it for her: freeing up 30% of the time of her sales team so they can spend more time on the phone generating and closing deals rather than on repetitive tasks that could be automated. The VP of Sales might not even care about making the lives of her subordinates better by removing this repetitive work, but she will certainly care about the potential increase in revenue caused by having the sales team spend more time in deal-making activities. By clearly communicating the value the project can deliver for the business and the stakeholders, you’ll be setting up the stage for a quick approval process when it’s time to get the requirements ready for the development team.
2) Have you mapped out the people who need to approve different subsets of the requirements at their various levels of granularity?
It’s highly unlikely that the same set of people need to approve the whole collection of requirements you’re working on. I recently worked in a project in the healthcare industry. Senior management needed to review and approve the security requirements for the project, but they only cared about ensuring that the solution complied with the federal rules in place to safeguard electronic protected health information (PHI) so the organization didn’t run into any financial or reputation risk. These executives didn’t care about details such as “all data storage will use AES 256-bit encryption in order to safeguard electronic PHI” as long as PHI was handled according to the federal rules. This means that for that group of stakeholders, the requirements should be kept at a higher level, without all the details about the technology used to secure the data that the development team needed to obtain. Checks and balances were put in place to ensure that each high-level requirement approved by a senior executive was accounted for in the more detailed requirements submitted to the approval of the program manager and solution architect.
Going back to the example of the CRM enhancement, the VP of Sales is probably not interested in reviewing all the detailed requirements the solution will encompass. She might only need a high-level description of the changes to confirm that there would be no degradation of the quality of the reports being extracted from the CRM as a result of the changes to be ready to delegate the approval of more granular requirement to a sales manager. The approval of highly detailed requirements such as a function to flag family and friends in the email application as non-customers (so the interactions users have with these people are kept out of the CRM) could be even further delegated to a group of end-user representatives. If you don’t do your due diligence to identify the various stakeholder groups and what matters to them, you’ll face much more resistance during the review and approval process, in particularly if stakeholders are being asked to sign off in the entire solution requirements as opposed to just the portion they care about or can fully understand.
How to fix this issue: As part of stakeholder analysis, make sure you identify not only who needs no to be involved in the requirements review and approval process, but also to what extent. Speak to the project manager about the different needs and interests of each stakeholder group, and come up with a plan that allows different artifacts to be delivered to each group based upon the role it’s playing in validating and approving the requirements. Then, rather than waiting until the full set of requirements is ready for review, start sharing the artifacts as they become available. This not only addresses the matter of smaller artifacts being easier to approve, but ensures faster feedback from approvers who may be reviewing a subset of requirements while you’re working on the next set.
3) Have you gained buy-in for the plan to get the requirements reviewed and approved in each stage of the requirements process?
Just because you and the project team came up with a good “divide and conquer” plan to accelerate requirements sign-off (item #2), it doesn’t mean that business stakeholders will go along with the plan. Having built the case for the project (item #1) helps, but if stakeholders don’t understand the oversight level the project has, they may hesitate to give their approval for an artifact that doesn’t spell out the full details of the solution to be implemented.
How to fix this issue: As described in the book Switch: How to Change Things When Change Is Hard, what looks like resistance is often lack of clarity. Most people won’t be familiar with your requirements process. That’s why you need to reach out your key stakeholders early in the project to educate them about the steps ahead, and set up the right expectations. Stakeholders should be given a clear explanation of what needs to happen before the development works starts (who needs to be engaged in the various phases of requirements discovery from business objectives and metrics to detailed requirements, what mechanisms are in place to ensure that requirements are approved, managed and tracked appropriately, etc.). Give stakeholders clear answers for these questions: When should they expect to get a first draft of a requirements artifact? How fast will they be expected to provide initial feedback so that it can be incorporated for the next iteration without causing project delays? What formats of requirements will be available for review (visual diagrams, slide deck, software requirements specification)? Which portions of the requirements should be approved directly by end-user representatives to prevent decisions made by surrogates who don’t fully understand their needs?
As you explain the process and the demand for their time, make sure to keep the big picture in view (“As previously mentioned, this project is going to help free up 30% of the time of your sales team so they can spend more time on the phone generating and closing deals rather than on repetitive tasks that don’t add value. For that to happen in Q3, we need to make sure the business requirements have been approved by May 15, so here’s the timeline I’m hoping we can agree upon…”).
# # #
In product management, we often talk about “pain killers” vs. “vitamins”. A project that people agree will address a big pain for the organization is unlikely to be delayed by lack of requirements approval. For these kinds of projects (the “pain killers”), decision-makers will find a way to move forward without keeping you waiting for requirements approval. (You may run into a different problem here, of decision-makers rushing to build a solution before the problem is fully understood, but that’s a different story for another day.)
The reality is, delays in getting requirements approved are much more likely to happen when a project is seen as as “vitamin” rather than a “pain killer”: nice to have, but nothing that will bring substantial positive change for the organization or directly benefit an influential group of stakeholders. If the BA can’t identify an important problem or opportunity to be addressed by the project, or the company is facing more pressing, “hair on fire” problems, more important than getting requirements approved is to speak up and recommend the project isn’t pursued at that point. But in many cases (as in the example of the CRM enhancement, initially seen by senior executives as a “vitamin” that wouldn’t contribute to their their goals), the value is there, and only needs to be spelled out for the decision-makers so that they understand how their effort reviewing and approving the requirements is going to help solve their problems and empower them for the future.
# # #
Imagine never feeling apprehensive about sending your requirements for review again…
Crafting Better Requirements is about to close registration for the first half of 2018, and is unlikely to be offered publicly again before 2019.
Due to the high level of interest from BAs who didn’t manage to get budget approval from their organization, we’ve decided to offer a temporary price cut from $1297 to $897 for this 2-month program. If you are among the BAs planning on taking this training, get in touch and we’ll send you the discount code to apply at checkout (please note that we this offer is only valid until the end of April and for non-sponsored BAs).
Program dates
– Class of April 16-Jun 16 in progress.
– Flexible start date enrolment open from mid-April to mid-June (if you contacted us to save a spot, it will remain reserved for you until the agreed upon date). Employer-sponsored participants pay the regular price; non-sponsored BAs are welcome to take the discount offered above.