1.4 The Business Requirements Document


Every project, regardless of its size or level of complication, needs to have a defined business view. The Phase 1 lead person creates a document identifying the following information:

  • Who is the end user ?

  • Why do they need this new project?

  • How will this affect them?

  • How will this affect the way they currently work?

  • What additional training will they need?

  • What features do they need in the eventual solution?

  • What benefit do they believe they will obtain from this project?

There are many projects created without a Business Requirements Document. When asked why this document doesn t exist the typical response from management is that the information found in a Business Requirements Document was intuitively obvious or that creating a Business Requirements Document seemed bureaucratic. Some projects are top down; management is trying to streamline the company. Many times management doesn t think it is necessary to pull employees whose jobs will be affected into the process.

Don t fall into the trap of not creating a Business Requirements Document. It is very important to answer the questions posed in a Business Requirements Document. This information solidifies the project s position. Having the information written down explains and verifies the decisionmaking process. Many times the people involved at the beginning of a project are no longer involved with it later, or they become involved at a later stage in the project. Ideas that seemed intuitive today may not look intuitive in the future.

Additionally, many times people believe they are in agreement. Later, they all believe their own recollection is correct, even though their recollections of why they created the project and what business problem the project solved are all different. Writing information down confirms that there is agreement on the ideas discussed. The information identified in the Business Requirements Document is the basis for all decisions made throughout the project s life cycle. Many projects evolve over time. A written document provides a record for when the project changes or new players join on.

Every Business Requirements Document needs to ask and answer the same questions. For add-on projects, the existing user base should be interviewed. Don t shortcut the process. It is necessary to ask and answer all the questions. Businesses are always changing; a small change in business may result in a new need or may refocus existing needs. The main questions that should be identified in this document are: (1) What are the expected user demographics ? (2) What are the existing user requirements? (3) What are the future user requirements? (4) What are the IT/Help Desk recommendations?

The following explains how to identify the questions that need to be asked and where to find the information in order to create a Business Requirements Document.

1. User Demographics

Knowledge of a user s demographics is necessary in order to identify who will use this project. By creating a generic picture of the typical user, questions asked in later steps will be easier to answer. The typical questions to be answered are: How should this project be visually and verbally presented to the end user? What level of online help should be available? What management tools are needed? What level users should the Help Desk organization be prepared to handle?

What level of user documentation will be needed? Does the end user have access to prerequisite hardware and software? All of the answers generated from this information are instrumental in creating an effective project and an accurate budget.

The first step in identifying the user s demographics is to identify who the end user is. For example: Executive staff wants specific information from the sales organization, so branch sales managers will need to file a new report. IT was asked to create a report that the managers can use to input sales data. By visiting a branch office and seeing how the sales organization works, it becomes apparent that the salespeople are currently gathering the requested information in their Palm Pilots. Instead of creating an input screen for the sales managers, it would be more effective to create a report that can be compiled from data residing on the salespeople s Palm Pilots. Salespeople will need a way to transmit data from their Palm Pilots to the branch s server, and managers will need to access reports that are compiled from the downloaded data.

Understanding who has the data, who uses the data, and who needs the data helps to identify what the project and documentation should look like and what type of user interface is needed. The interface will be different if it will be accessed by a manager sitting in front of a PC, or a salesperson using her Palm Pilot, or a loading-dock worker using a shared PC.

2. Current User Requirements

Understanding why and how the users are performing tasks associated with their job, what they like about their situation, and what changes and features they would like to see is essential in understanding a future release. If the new project changes the way end users work it may be necessary to identify and predict the user s reaction. A user base that is opposed to change will need more hand-holding during release. This additional support will need to be built into the cost of the project.

Many times companies overlook talking to their users. They believe they know their users and have enough user information. In some instances companies and organizations have failed to keep up with end users. An example of this was in the Second Gulf War. Many U.S. soldiers visited sporting goods stores to buy equipment since army-issued equipment did not meet their needs. If you don t talk to your user, basic needs may be overlooked and positive features may be designed out.

How to Approach the User. It is necessary to talk directly to users to get accurate information. Talking to your Help Desk organization is another step in creating a Business Requirements Document. Don t shortcut the process. Take the time to talk to users and the people who support them. The people who use the project are the final judges; they will make or break a project. The easiest way to talk to users is through a questionnaire sent via e-mail or placed on the company s intranet. A Web site questionnaire may be an easy way to get timely feedback. In some situations, you will get better, more accurate information by talking to the user directly by phone or by personally visiting him. Many existing users will be flattered to be asked their opinion. By going to the source you get timely, accurate information.

Designing a User Questionnaire. When designing a questionnaire, decide what user questions you want answered. Then design the survey questions that will provide you with experiential information. This is harder to do and harder to analyze than a direct question, but the information received will be more accurate. Trial lawyers don t ask prospective jury members if they are prejudiced. They ask them what experiences they have had with a particular group and ask them what they have been told about that group . Experiential questions give better information. For example, the proposed project is for the company to provide end users in your organization with an authoring tool to create training for the Web. The two choices of authoring tools are either hosted on a server or reside on the user s desktop. The goal of your survey is to find out if users have a preference. A direct question might ask: Would you prefer to use an authoring tool that you access over the Web or one that resides on your PC? An experiential question would ask: Power Point is an authoring tool you currently use. On a scale of 1 to 10, how interested would you be in using Power Point if you had to access it over the Web? This second question will give you better feedback.

Filling in the Survey. Now that a survey has been created, try it out on someone who matches the user s demographics. Fine-tune the questionnaire to make sure the objectives are met. Take a sample of ten to fifteen current users and call them. If they provide similar answers you probably have a good idea regarding their needs. If the answers seem skewed, call ten more users. Ten to fifty users should be all that are needed for most corporate applications. Statistically two thousand responses give you a 97 percent accuracy rate; this is needed for large focus surveys like a presidential election but is overkill for most corporate projects. If customers on yourWeb site will use your application, you may want to perform two surveys. One survey can be performed by personally contacting a small group of users, and the other survey can be placed on your Web site. Depending on your Web traffic, it may be relatively easy to get two thousand responses from your customers. Offering a free gift for taking the survey, a gift such as a T-shirt, will generate a much higher response. You can use the phone call survey as a way to check your Internet survey results. For large or very important projects, you may want to create a focus group. In a focus group five to ten users are asked to attend a roundtable meeting. At the meeting the group is asked questions, and their responses are recorded. Since a group of users may give different answers, create a set of experiential questions. One warning: Don t bias the questions. Don t give the people questioned any more information than they would receive if they were asked to evaluate the project without any access to a company representative. There are many examples of projects that failed despite using extensive focus groups. One reason is the ways in which focus groups are conducted . In the early 1980s, soon after IBM released the PC, they came out with a ˜ ˜chicklette keyboard. Focus groups loved the new keyboard but critics slammed it and users didn t buy chicklette PCs. Upon further study it was found that focus group leaders trained potential focus group members up front by extolling the virtues of a chicklette keyboard. The focus group members were given information that was different from the information provided to the buying public, skewing the results.

3. New User Requirements

Internet technology is a good example of a new technology that may present a different paradigm than expected. You may have a current practice that will be migrated to the Web. Due to the accessibility of the Web, different people from those you traditionally serve may access this new application. For example, a financial services company sends out a newsletter to their customers providing information on government regulations. They plan to migrate this service to their Web site. The proposed Web newsletters will provide keyword search capabilities and a history of past newsletters. Previously the customer s librarians received and filed the newsletters. When the newsletters move to the Web, the customer s government compliance people may want direct access to the site. Does the company have a relationship with the librarians or the government compliance people? Do they know if the government compliance people have needs that could be easily fulfilled online? Talk to a few and find out how they intend to use this application.

Understanding the needs of new users will provide for a richer, betterfocused feature set, and happier end users.

4. Future User Requirements

Apply the user demographics defined previously to define who the target user is. The future user may or may not be your existing user. Call potential users or invite them to a roundtable meeting. Future users may have very different needs from existing users. Don t overlook these differences. For example, your salespeople may be calling on corporate executives. You plan on having your products available to sell on the Web. You may find that executives do not visit your Web site, delegating this duty to an associate. The associate may need additional information from your Web site so he can understand your product and provide his boss with the information to make a decision. It is important to identify who will be accessing the information and who will be using the information to understand how best to create this new application.

5. IT and Help Desk Organization

Internal groups live and breathe the project day in and day out. Don t forget to tap these resources. Again create a questionnaire, and take the time to ask Help Desk people for their opinion. Additionally, you can host an internal roundtable. Make sure you take a sample of employees. Don t always use the same people. Don t always ask the star performers. Some companies are afraid of asking internal people since they are afraid a roundtable will turn into a gripe session. A session, properly managed, with a set agenda and clear goals is informative and positive. For an existing project, have Help Desk employees create a wish list of features they believe should be in the product. This is a list made up of user requests . A wish list is an excellent foundation for the Feature/Functionality List.

6. Sales Organization

For customer-focused projects, talk to your sales organization. Salespeople are intimately aware of what customers want and don t want. Talking with a few different salespeople will ensure that the information provided is not skewed to a single customer s situation and that recommendations will provide across-the-board solutions.

7. Using the Internet

Almost every solution in existence has an Internet chat group. Timely information can be readily accessed on the Internet regarding this solution or market space. The chat groups contain a lot of good market information as well as good vendor information. Search under keywords for the solution being developed and hardware and software vendors names . Other companies might be developing a similar solution; you can learn from their recommendations.

A caveat to watch out for when creating the Business Requirements Document is that people may provide a solution instead of identifying problems and requirements. The Phase 1 lead person should identify when an end user is providing a solution and not identifying a problem. To make the process effective the Phase 1 lead person should have the user explain why his proposed solution is better and what problem his proposed solution solves . The real information the Phase 1 lead is identifying is the problem. The reason the Phase 1 lead wants to stay away from identifying solutions is that end users may be unaware that a better, more cost-effective , or simpler solution is available. Additionally, IT may decide to purchase different software or hardware than the one the end user recommends. Unbeknownst to IT the new software may not have the features the end user really needs. IT s job is to look at requirements and come up with the best solution. The Phase 1 lead should provide IT with accurate information so they can make an informed decision.

1.4 in a Nutshell

The Phase 1 lead person is responsible for developing a Business Requirements Document. This is the document that identifies the user s needs and the effects the project will have on the business.

  • This document is the fundamental building block of a good project.

  • Without a thorough business assessment in the Project Concept phase, the best designed and executed project will not necessarily produce useful results.

  • The Business Requirements Document provides insight into the end users and their requirements.

    Tip  

    Don t shortcut the process. This document provides the company with the necessary information to create an effective project.




Effective IT Project Management
Effective IT Project Management: Using Teams to Get Projects Completed on Time and Under Budget
ISBN: B000VSMJSW
EAN: N/A
Year: 2004
Pages: 105
Authors: Anita Rosen

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net