Have you ever been in a requirements session that starts off with a discussion of business needs and quickly derails to the implementation details? It's a common detour, but one that should be avoided until the business rules and objectives are clearly defined and all project stakeholders understand the problem the project is trying to solve. By looking at the goals of a project, the client needs, and what the project is to deliver, we are more apt to properly define our needs and the expected outcome. The end product will display the benefits of this focus. With approximately 85% of software defects introduced during the requirements stage, it is critical to concentrate on the intended behavior of the system.
I've been in many joint application development (JAD) and other types of requirements sessions where the technical team's wheels start turning, quickly taking the meeting from one of requirements definition to technical design. While it's important to have the technical staff attend these meetings, it's often hard for them to stay centered on the planning and discovery of what the client needs. It is, therefore, important to be cognizant of the potential to get too deep too quickly.
This awareness is particularly important in JAD sessions, where the session brings business unit users into the development process as active participants. While the purpose of a JAD session is to gain consensus regarding business requirements and solution options, with an expanded audience it is even more critical to find ways to keep the group focused on the overall business goal and issue the project is trying to solve. The following are a few steps that I've found extremely helpful in keeping a requirements session focused on processes and objectives, rather than design.
Step 1: Review Lessons Learned Prior to the JAD or requirements session, the Project Manager should present post-mortem review results on both controlled, successful projects and those with overruns. The impact of this review should be highlighted by metrics, displaying the performance results as well as customer service survey data. Showing the project team the direct impact of ineffective requirements, and creating internal systems to tie performance to compensation will allow the technical team to see how their contribution affects the organizational financials and their individual rewards.
Step 2: Lay the Ground Rules and Set the Tone In preparing for the joint application development/requirements session, remind the project team of the goal of the session and set running rules to follow for the session.
Keeping things light is always a plus and you should look for interactive and fun ways to keep the group centered during these sessions. Listing workshop don'ts on a flip chart is one way to make everyone aware of what not to ask and serves as an ongoing reminder throughout the session. Creating games with the winner being the person with the most questions related to what the system should do is one way to keep everyone in sync with the goal of the session.
It is the PM's responsibility to manage the meeting, the client, and the project. This doesn't mean that you should be a complete stickler, but you should impart your own personality to the situation, keeping things focused but light.
Step 3: Understand the Affected Business Processes Participants should begin discussing the process from end-to-end along with alternative paths. This documented flow will then need to be broken down to the lowest level possible with detailed views and narrative messaging for both successful and failed paths.
Determining the business drivers is not always a straightforward discussion. The software team and implementation consultants should ask many leading questions to better understand the inner-workings of the organization in order to determine the most appropriate solution.
Business rules should be identified with full force investigative interviewing to uncover all rules and the ins and outs of what really happens in offline processes. Questions should be asked that will impact scenarios and paths through the application. Examples of questions to ask for nearly every business requirement include:
Who in the organization is responsible for the process being discussed?
How often does the process occur?
Who in the organization are contributors to the process?
What must happen before the process occurs?
What triggers the process?
What is the common flow of the process?
What alternative flows are possible?
What must occur after the process has been successfully completed?
Throughout the entire session, and until there is agreement on what defines project success, the PM must reign in these technical how-to discussions, tactfully reminding the project team that the focus at the planning stage is on what the system will do, not how the system will do it.
Step 4: Capture Usable Requirements
When capturing requirements, the PM should also keep in mind that generally requirements should be verifiable, attainable, unambiguous, consistent, traceable and concise. Each of these items are attributes of effective requirements:
Verifiable: Can the responsible business unit confirm that the requirement has been met after development is completed? If not, the requirement should be removed or revised.
Attainable: It almost goes without saying, but those items detailed in the requirements document must be possible within the confines of the project.
Unambiguous: A system requirement should not leave room for interpretation.
Consistent: Individual requirement statements should not have an adverse impact on system behavior or other requirement statements.
Traceable: Each requirement must be uniquely identified and assigned an identifier which is used throughout requirements and QA documentation.
Concise: Ensure that the requirement is stated simply and clearly and doesn't require someone on the project team to explain.
For instance, instead of saying: The system shall allow users to purchase books and literature. Try revising this requirement and applying the rules above. A possible suggestion might be: REQ 1.001. The system shall allow authenticated users to place an item for purchase within his/her online basket.
There are various software packages available to assist with requirements capture and management. Breaking things down to a low level will allow each requirement to have its own identifier and therefore be traceable during QA. Requirements should not mention implementation details and should be able to stand alone. The analysis and design phases will uncover component relationships. Right now, your focus is on adequately detailing the deliverables and components of the deliverables which will later become the foundation for your project work breakdown structure (WBS).
Staying on course and keeping requirements sessions from going down the path of how things will occur is not always easy, but it's time well spent. Keeping the focus on what needs to be done--not the mechanics of how to do it--will lead to a more successful implementation and end product.
Comments