Requirements elicitation is an important if not the key part of any project. If we don’t understand what is needed and what it is that we need to achieve then planning to get there becomes a moot point. But many organizations and project teams do not give this key functionality its due importance and ensure that due diligence is conducted to ensure comprehensive understanding of needs:
1) Have a clearly defined Requirements Elicitation process:It is very helpful to have a clearly defined requirements elicitation process that clearly depicts how the clients will be approached, which other functions or groups will be involved (and in what capacity) and how this entire process will be conducted. Also ensure that you indicate the level of involvement that would be expected from each group and at what points in the sequence of steps.
2) Have a Requirements Elicitation process that is geared towards the main categories of work conducted in your organization:We all know that the depth and breadth of requirements that need to be captured for a sustainment type work request is very different than that for a full-fledged project. Also, when we think of projects, they are not all alike. Within IT, we know that Infrastructure project require a very different perspective than an application selection or implementation project. Because of this, it is helpful to have a process for each of these main category types.
3) Have a comprehensive and yet easy to read Requirements Gathering document:
Many a time organizations create a very complicated Requirements Elicitation document. This not only becomes very cumbersome for the person filling it out but also makes it very difficult to truly engage the client or the project (or work) sponsor. Because of this, the analyst conducting the requirement gathering workshop may try to skip or bypass capturing crucial information which would have helped in Solution Design.
So, to avoid all this ensure that you are creating a Requirement Gathering document which provides various sections to capture key information. Always remember that meaningful sections along with document style, font, line spacing all play a very vital role in making a document more readable as against of a dull & drab complicated (think tax) document!
4) Express the Requirements in simple sentences from the perspective of the requestor:
We are capturing requirements because there is a need. Something is missing that the requester would like to happen. Instead of stating the need ‘as if’ in void, if we capture the requestors view of the need, it will provide much more comprehensive information than mere technical words.
For e.g. let’s say a Payroll Manager would like to have a report that indicates the time spent by her staff to correct timesheet errors. One, you could capture the requirement as; Provide report that indicates time spent by the payroll staff to correct timesheet errors and the second would be as I wrote it above- Payroll Manager would like to have a report that indicates the time spent by her staff to correct timesheet error. The first way of writing is cold and non-personal where are the second style makes it a requirement-user-story. Someone wants something, so they can in turn do something else.
Stating requirements in this style of user-story soon creates a “Requirements Ambience” which the subsequent Solution Design needs to meet in addition to the actual delivered artifacts (in our example above, the actual report).
Capturing requirements in this way, also makes validation that much easier- since the user’s requirement have been captured from their perspective, it is easier for them to identify with that stated need, validate it and approve it in the Requirements Gathering document.
5) Map Gathered Requirements to Delivered Functionalities:Not many projects go this extra mile to ensure that they provide a detailed mapping of how- what they are providing as deliverables, actually maps with the original requirements. Of course clients and sponsor need to agree that their needs are met by the project deliverables for them to accept them and sign off on the project, but by actually mapping delivered functionality to the gathered requirements- it provides for better traceability during sustainment as subsequent changes and modifications are done to the original deliverables.
By mapping gathered requirements to delivered functionalities, projects can provide a more comprehensive and robust Operations document.
These are five crucial ways in which you can modify your Requirements Elicitation Process to ensure more effective Requirements gathering that help in formulating better solutions to satisfy clients and provide detailed information that can be easily utilized by the Operations group. A win-win way of working… happy clients, happy operations and engaged & satisfied project team members!
1) Have a clearly defined Requirements Elicitation process:It is very helpful to have a clearly defined requirements elicitation process that clearly depicts how the clients will be approached, which other functions or groups will be involved (and in what capacity) and how this entire process will be conducted. Also ensure that you indicate the level of involvement that would be expected from each group and at what points in the sequence of steps.
2) Have a Requirements Elicitation process that is geared towards the main categories of work conducted in your organization:We all know that the depth and breadth of requirements that need to be captured for a sustainment type work request is very different than that for a full-fledged project. Also, when we think of projects, they are not all alike. Within IT, we know that Infrastructure project require a very different perspective than an application selection or implementation project. Because of this, it is helpful to have a process for each of these main category types.
3) Have a comprehensive and yet easy to read Requirements Gathering document:
Many a time organizations create a very complicated Requirements Elicitation document. This not only becomes very cumbersome for the person filling it out but also makes it very difficult to truly engage the client or the project (or work) sponsor. Because of this, the analyst conducting the requirement gathering workshop may try to skip or bypass capturing crucial information which would have helped in Solution Design.
So, to avoid all this ensure that you are creating a Requirement Gathering document which provides various sections to capture key information. Always remember that meaningful sections along with document style, font, line spacing all play a very vital role in making a document more readable as against of a dull & drab complicated (think tax) document!
4) Express the Requirements in simple sentences from the perspective of the requestor:
We are capturing requirements because there is a need. Something is missing that the requester would like to happen. Instead of stating the need ‘as if’ in void, if we capture the requestors view of the need, it will provide much more comprehensive information than mere technical words.
For e.g. let’s say a Payroll Manager would like to have a report that indicates the time spent by her staff to correct timesheet errors. One, you could capture the requirement as; Provide report that indicates time spent by the payroll staff to correct timesheet errors and the second would be as I wrote it above- Payroll Manager would like to have a report that indicates the time spent by her staff to correct timesheet error. The first way of writing is cold and non-personal where are the second style makes it a requirement-user-story. Someone wants something, so they can in turn do something else.
Stating requirements in this style of user-story soon creates a “Requirements Ambience” which the subsequent Solution Design needs to meet in addition to the actual delivered artifacts (in our example above, the actual report).
Capturing requirements in this way, also makes validation that much easier- since the user’s requirement have been captured from their perspective, it is easier for them to identify with that stated need, validate it and approve it in the Requirements Gathering document.
5) Map Gathered Requirements to Delivered Functionalities:Not many projects go this extra mile to ensure that they provide a detailed mapping of how- what they are providing as deliverables, actually maps with the original requirements. Of course clients and sponsor need to agree that their needs are met by the project deliverables for them to accept them and sign off on the project, but by actually mapping delivered functionality to the gathered requirements- it provides for better traceability during sustainment as subsequent changes and modifications are done to the original deliverables.
By mapping gathered requirements to delivered functionalities, projects can provide a more comprehensive and robust Operations document.
These are five crucial ways in which you can modify your Requirements Elicitation Process to ensure more effective Requirements gathering that help in formulating better solutions to satisfy clients and provide detailed information that can be easily utilized by the Operations group. A win-win way of working… happy clients, happy operations and engaged & satisfied project team members!
| |
#RequirementElicitation #ProjectManagement #BusinessAnalysis #SandhyaBhat #ProjectDelivery #LearningandDevelopment #CorporateTrainingTV #Leadership #Management #Coaching #Mentor
