| p>Requirements gathering activities should be | | | | Track your schedule and report progress to your |
| scheduled by your project plan like any other project | | | | stakeholders. Be sure to communicate the impact of |
| related activities. If these activities don't track to the | | | | slippages on all the stakeholders so that no-one is |
| schedule, whether because the schedule isn't feasible | | | | surprised if you escalate a slippage issue. Escalate |
| or some other reason, it will cause all the dependant | | | | slippages that exceed the slack in your schedule to the |
| activities to slip. Once you've chosen your | | | | project sponsors. Identify all the possible corrective |
| requirements gathering approach and the stakeholders | | | | actions (or preventive actions if you haven't impacted |
| you'll meet with to gather the requirements, you can | | | | on the rest of the schedule yet) to the sponsors and |
| schedule the meetings, or interviews, or other methods | | | | recommend the most suitable action. |
| for soliciting the requirements. | | | | One corrective action that you can evaluate is to |
| Remember that the last step in the requirements | | | | group requirements into separate categories. This will |
| gathering process is the sign off of the requirements | | | | only work if you are building something other than a |
| by the stakeholders and the business analysts. The | | | | system which supports one contiguous process. For |
| business owners will sign off on the completeness of | | | | example, if you were building a system which supports |
| the requirements and the business analysts will sign off | | | | the order capture and processing of software and |
| on the feasibility of building them. The sign off will | | | | another for the order capture and processing of |
| probably be the most challenging step in the gathering | | | | hardware, you could proceed with analysis of the |
| process; people are naturally reluctant to lock | | | | signed off software ordering system requirements |
| themselves into an agreement that may not be | | | | before the hardware ordering system requirements |
| suitable. It's up to you to convince the business owners | | | | were signed off. Be careful here. Learnings from the |
| that you've captured all the requirements and that | | | | definition of requirements in one area can have |
| developing those requirements will deliver the benefits | | | | unforeseen impacts on requirements that have already |
| that support the business case. Educating the business | | | | been signed off. Be very clear that any changes to |
| owners in the requirements gathering process and | | | | signed off requirements can only be brought about |
| sharing your reasons for choosing that process will | | | | through change requests. Do not let stakeholders push |
| build trust in the requirements you've gathered. | | | | you into beginning analysis on requirements which have |
| Communicating the Change Management process | | | | not been signed off. Effort invested in the analysis of |
| you've crafted for the project is another means of | | | | unfinished requirements is at grave risk of being |
| inspiring trust in the business community. More about | | | | wasted when those requirements change and |
| the relationship between Requirements Management | | | | stakeholders will be unwilling to pay for changes to a |
| and Change Management later. | | | | requirement which they have not signed off on. |
| Identify all the dependencies related to requirements | | | | All the project management processes and |
| and schedule requirements gathering activities | | | | procedures are integrated with one another to some |
| accordingly. For example, if you're building an order | | | | degree. Requirements Management and Change |
| capture and processing system you'll need to define | | | | Management are 2 processes which are tightly |
| requirements for capturing the order before you define | | | | integrated. You should be educating your business |
| the requirements for processing it. Enter the | | | | stakeholders and project team in your Change |
| dependencies into your scheduling tool. Leave slack in | | | | Management process at the same time you educate |
| your schedule to accommodate missed meetings due | | | | them on your Requirements Management process. |
| to weather, illness, or business emergencies. Missing | | | | One reason business owners may be reluctant to sign |
| one meeting because of a business emergency should | | | | off on requirements is a fear that their business may |
| not cause your entire schedule to slip. The final activity | | | | change, requiring a change to one or more of the |
| in the gathering process will be the sign off. Ensure | | | | requirements. This may come about due to a change |
| that you've established who is responsible for sign off | | | | in the market place, new technology becoming |
| and how that sign off will happen and that the | | | | available, changed or new government regulations, or |
| business stakeholders are aware of their | | | | any number of external or internal influences. You |
| responsibilities in this area. The final dependency should | | | | must give the business owners of the system you're |
| be the dependency of the specification development | | | | building a clear picture of how these changes can be |
| activities on the sign off of the requirements. Capturing | | | | accommodated by your Change Management |
| all these dependencies in your scheduling tool will allow | | | | process. Reasonable clients will not expect the project |
| you to tell at a glance the impact a slippage in any of | | | | to accommodate these changes at no cost, but your |
| the requirements gathering activities will have on the | | | | process should provide a method of estimating a fair |
| overall schedule. | | | | cost for the change. |