Schedule Requirements Gathering Activities

Requirements gathering activities should be scheduled by your project plan like any other project related activities. If these activities don’t track to the schedule, whether because the schedule isn’t feasible or some other reason, it will cause all the dependant activities to slip. Once you’ve chosen your requirements gathering approach and the stakeholders you’ll meet with to gather the requirements, you can schedule the meetings, or interviews, or other methods for soliciting the requirements.

Remember that the last step in the requirements gathering process is the sign off of the requirements by the stakeholders and the business analysts. The business owners will sign off on the completeness of the requirements and the business analysts will sign off on the feasibility of building them. The sign off will probably be the most challenging step in the gathering process; people are naturally reluctant to lock themselves into an agreement that may not be suitable. It’s up to you to convince the business owners that you’ve captured all the requirements and that developing those requirements will deliver the benefits that support the business case. Educating the business owners in the requirements gathering process and sharing your reasons for choosing that process will build trust in the requirements you’ve gathered. Communicating the Change Management process you’ve crafted for the project is another means of inspiring trust in the business community. More about the relationship between Requirements Management and Change Management later.

Identify all the dependencies related to requirements and schedule requirements gathering activities accordingly. For example, if you’re building an order capture and processing system you’ll need to define requirements for capturing the order before you define the requirements for processing it. Enter the dependencies into your scheduling tool. Leave slack in your schedule to accommodate missed meetings due to weather, illness, or business emergencies. Missing one meeting because of a business emergency should not cause your entire schedule to slip. The final activity in the gathering process will be the sign off. Ensure that you’ve established who is responsible for sign off and how that sign off will happen and that the business stakeholders are aware of their responsibilities in this area. The final dependency should be the dependency of the specification development activities on the sign off of the requirements. Capturing all these dependencies in your scheduling tool will allow you to tell at a glance the impact a slippage in any of the requirements gathering activities will have on the overall schedule.

Track your schedule and report progress to your stakeholders. Be sure to communicate the impact of slippages on all the stakeholders so that no-one is surprised if you escalate a slippage issue. Escalate slippages that exceed the slack in your schedule to the project sponsors. Identify all the possible corrective actions (or preventive actions if you haven’t impacted on the rest of the schedule yet) to the sponsors and recommend the most suitable action.

One corrective action that you can evaluate is to group requirements into separate categories. This will only work if you are building something other than a system which supports one contiguous process. For example, if you were building a system which supports the order capture and processing of software and another for the order capture and processing of hardware, you could proceed with analysis of the signed off software ordering system requirements before the hardware ordering system requirements were signed off. Be careful here. Learnings from the definition of requirements in one area can have unforeseen impacts on requirements that have already been signed off. Be very clear that any changes to signed off requirements can only be brought about through change requests. Do not let stakeholders push you into beginning analysis on requirements which have not been signed off. Effort invested in the analysis of unfinished requirements is at grave risk of being wasted when those requirements change and stakeholders will be unwilling to pay for changes to a requirement which they have not signed off on.