August 05, 2006
Business Requirements: Key Component for Success
Clear, concise, and complete business requirements are an essential component to the success of any project. Good project managers everywhere realize the importance of solid business requirements. However, ensuring that your business requirements are complete can be more challenging than ever.
An effective way to gather business requirements is via collaborative work sessions. If you are fortunate enough to work in an environment that supports face-to-face work sessions – great! A well run facilitated work session is the most effective way to ensure that all the voices of the stakeholders are heard and to accelerate the building of quality requirements. Another method is to meet individually or in small groups with stakeholders to gather requirements. But what happens once the initial requirements gathering process is over?
Often additions or changes to requirements are discussed in weekly project meetings, in conference calls, or in hallway conversations – with the hope that these requirements will be captured and eventually make their way into the “official requirements document”. As office communication methods have evolved, more and more requirements are being shared via email and instant messaging. These forms of communication, along with the more common obstacles of gathering requirements such as budget, resource, time constraints – not to mention speed to market pressures, are also having an impact on the requirements gathering process. Often requirements buried in emails and IMs go unnoticed and are not folded into the requirements gathering process. When ignored, the consequences can spell disaster.
While we do not advocate using email or instant messaging as vehicles for requirements gathering, their presence cannot be ignored. Even when teams are encouraged to use other forms of more reliable communication, emails and IMs often result. So, how can we best manage this less-than-ideal way of communicating requirements when they pop up?
Capturing Requirements Submitted via email and Instant Messaging (IM)
Recently, while working on a project that was well into the design phase, the project manager started to receive a flurry of additional requirements via email and even via instant messages during project meetings. The project manager and team had been faced with some of the typical requirements gathering obstacles of budget and resource constraints. The team did not hold a formal requirements review session prior to the “lock down” of the requirements. The requirements had been completed in a vacuum with only a limited number of subject matter experts.
The result: incomplete requirements. Sound familiar? Many project managers face similar situations. The project manager was faced with the challenge of ensuring that all the ideas being hurled his way were captured, and making certain that they made their way into the proper project documentation.
First, the project manager had to take a step back and identify what must be done immediately to address the incomplete requirements. It was clear he needed time to regroup. The development schedule was re-worked to allow an additional short amount of time to focus on gathering and confirming a more complete set of requirements.
Second, the project manager shifted his focus to capturing all the potential requirements that had been sent via email and IM during various project meetings. But, how? Time was of the essence.
A way to capture, validate and trace the source of all of the additional requirements had to be developed. Often, the requirements were buried deep within the text of a long email. The method had to be quick and effective with little to no re-work on the part of the project manager.
The solution was to capture the emails and instant messages in one single document. That document was then used as an input into collaborative requirements work sessions. Since the project team was geographically dispersed and most members only worked on this effort part time, a web meeting tool was utilized to conduct the review meetings. The project manager held several virtual meetings so that the document containing the additional suggested requirements could be shared with the entire team and reviewed together, real-time. As the team refined the requirements, the final wording of the additional requirements was added to the formal project requirements document. Once the requirements were complete and had received the proper sign-offs, the developers were able to include the additional requirements and complete the design phase of the project.
Change controls were also put in place to manage any further suggested changes to requirements.
Tips for Capturing Requirements Submitted via email & IM
1) Determine Common Essential Information
Often requirements sent via email and IM have several pieces of information in common…
General topic or requirement category
The potential / suggested requirement itself
Person submitting / suggesting the requirement
Date of submission
Medium used to submit the requirement (email / IM)
2) Determine Method for Logging Requirements
Depending on the amount of time a project manager has to devote to logging these requirements, there are two approaches that have proven to be successful.
As the emails begin to come in, separate the potential requirement or brainstormed thought from the text of the email, and place it in a single word document and include as many of the essential information elements as possible for traceability. Continue to capture requirements in this single document as they are received.
1) Category: Reporting Requirement
Requirement: Month-end financial balances must be available to Sourcing and Finance by the 3rd business day of the
Submitted by: Jane Smith
2) Category: General Requirement
Requirement: All users need to be able to access a tool to change their
password every 30-days.
Submitted by: John Smith
This method requires a little more time and is also a more formal method of capturing requirements buried within an email or IM. This method can be a simple way to capture the requirement in its original, most raw format and serve as a way to trace the requirement to its final destination (i.e., formal requirements document, change control, requirement eliminated). Regardless of whether the requirement makes it into the final document or not, at least there is a place that the thought was captured and becomes part of the historical materials of the project.
Person Submitting Req.
(email / IM, other)
Impact to Project if Requirement not met
(Final Req Doc, Change Control, Not Used)
Checklist for Controlling Requirements Submitted via email & IM
- Create a standard Requirement Submission Form and agree to only submit additional requirements using this method.
- When team members submit requirements buried in emails & IMs direct them back to the standard form for “official” submission.
- Define what the starting point and ending point for using this document will be.
- Collaboratively develop email and IM Ground Rules when determining how the project team will communicate during the