Identifying Requirements Approvers

We mentioned previously in this section that a Statement of Work (SOW) embedded in the contract for a project will serve as the master blueprint for your requirements. Although we haven’t consistently stated this disclaimer everywhere in this section it should be understood that no requirement, no matter how you gathered it, no matter who contributed it, no matter who approves it, can be a part of the required product unless it’s stated or implied in the SOW! Keep this fact in mind when you identify the approvers of your requirements.

You must identify the approver, or approvers, of the requirements for your software system. This person, or these persons, must be identified before requirements gathering can be completed and should preferably be identified before you start requirements gathering activities. The project’s business sponsor is the right place to begin your search for requirements approval. Your sponsor may want to delegate this authority/responsibility to someone in their organization who has a better grasp of the detailed business needs in that area. The authority will be theirs to delegate because they bear the ultimate responsibility for the success or failure of the business the system is designed to aid. If your project, and sponsoring organization, is small enough for the business sponsor to be able to sign off on all the requirements, so much the better. If not, you’ll have to get the sponsor to identify the person, or people, in the organization who can sign off.

The line between who has input into the requirements and who has sign off authority will tend to get blurred when you have conversations around finalizing the requirements so be clear and specific with the language you use here. You’re looking for one person who can approve the requirements after all the other stakeholders have contributed their input. If the sponsor wants to delegate authority to different individuals in different groups throughout their organization, ensure they identify one, and only one, person in each group and be sure that the requirements can be clearly identified with each group. You’ll still need to identify one person who is responsible for the requirements that support all groups across the organization. For example, you shouldn’t have a different log in routine for each group in the organization. One log in should provide access to all groups (you might have different privileges or abilities depending on which organization the user belongs to). You’ll need your sponsor to identify an approver for universal requirements, such as the log in requirements.

Your next step is to meet with the person, or people, identified as the requirements approver(s). They will probably have had the details of their authority/responsibility stated to them in business terms by the business sponsor. You need to clearly state their responsibility to the project; that responsibility is to complete their requirements gathering activities to an agreed upon schedule. You should involve them in scheduling the requirements gathering activities and in executing those activities. They are in a position to help you with requirements gathering because of the influence their position of authority now gives them. You may even want to have them contribute to the decision on which gathering methods and techniques to use, depending on their familiarity with requirements gathering. The next step is to communicate the identity and authority of this person, or people, to the project stakeholders and team. You need to do this so that the various business stakeholders who will contribute to the requirements, and who may even have input to the decision, know who the decision maker is and what their responsibilities to the project are.

Your approver(s) will need the help of an estimator to facilitate their decision making if your project has budget or schedule constraints. They’ll need to know how much the requirement to be decided on will cost in terms of effort, which will affect both budget and time. You may not have to provide this help if your approver(s) have business analyst experience and a depth of knowledge about the software being used to create the system. Otherwise, you’ll have to make a business analyst available who can provide rough estimates of effort for the requirements and this may hold true even when the project has an SOW. The SOW will usually describe system capabilities in general terms. Requirements will support these capabilities by describing the feature or function in greater detail. You and your approver(s) will have to identify those requirements which can be delivered within existing budget and schedule constraints. Requirements should be prioritized based on their cost (budget and schedule) and benefits. The use of a weighting scale to quantify both cost and business benefit can be useful when prioritizing requirements. You could choose to relegate all requirements whose business benefit is below a chosen level to a future release of the system. The requirements that are left will still be prioritized which may help you further down the road if it becomes evident that the project is not capable of delivering all the approved requirements. Remember, you won’t have an accurate forecast of the effort required to develop a requirement until the developer who will write the software receives a design from the business analyst.

The key date, or dates, affecting requirements gathering activities is the "approved requirements” milestone. This milestone enables the beginning of software development. Only when requirements are approved can work by the business analysts begin. You, as the project manager, may own responsibility for meeting the schedule for the other requirements gathering activities but your approver(s) own responsibility for meeting this date and should understand that failure to meet this date will impact on the delivery date for the software system. Ensure that the requirements gathering activities that provide the approver(s) with information, both requirements and estimates, they need to make their decisions and then make them accountable for meeting their decision dates. Where they choose to allow other business stakeholders to provide input into the decision, failure on the part of those stakeholders to meet deadlines the approver has given them does not excuse an approver’s failure to meet their deadlines to the project!

The time and effort you invest in choosing the right approvers, identifying the tools and techniques you’ll use to reach decisions, and scheduling the decision making can make or break your project so make sure you have a process and schedule that will deliver the right decisions in time, and then hold your approver(s) accountable for meeting their dates.