How To Improve Project Delivery through Good Business Requirements
by Niall Kennedy
Creating good business requirements not only assures that the proposed project will address all of the organization's needs, but it helps to guarantee that the project is delivered on time and on budget.
Here are some of the key reasons that improved project delivery can be achieved through good business requirements.
· You are more likely to receive approval sooner from all stakeholders regarding the intended purpose of the software. This will accelerate the remaining phases of the project and help to insure that original project deadlines are met.
· Risks will be identified and mitigated early on in the project lifecycle. This will reduce or eliminate unnecessary project delays, avoid losing the trust of the stakeholders, and reduce the likelihood that unexpected costs will result.
· The design process will take less time and the results will be more accurate. This will also accelerate the remaining phases of the project and ensure that the development cycle goes more smoothly.
· The development process will take less time and there will be a less likely chance that key processes will be overlooked. Developers and database administrators will spend less time seeking answers or clarification on issues and more time on direct project-related tasks.
· It will be easier to test because testers will have used the requirements.
· It will be easier to maintain the system because all processes will be documented.
· It will be easier to change the system in the future because all processes will be documented.
· The entire project management process will go smoother because each phase will benefit from the quality of the business requirements document.
· Communications between all stakeholders and the project team will be improved as the result of holding business requirements gathering meetings.
· The customer will be more satisfied with the system and more likely to accept the project as complete. This avoids unnecessarily extending deadlines and having to re-do work that does not meet the client's requirements.
· Cost savings will result from the increase in project development efficiency because staff time will not be wasted asking questions and seeking clarification.
· Increased accountability will result in a smoother development process. Each team member will know exactly what is expected of them and the Project Manager will have solid documentation to use when measuring project progress.
Tips for Writing Excellent Business Requirements
Understand that the purpose of the business requirements document is to ensure that the design and development team has a clear and well-defined understanding of the tasks that are going to be automated, how those tasks fit into the organizational context, and who the role players are.
Ensure that the requirements analyst meets with the major stakeholders in the project for a series of meetings designed to flesh out the requirements of the system. Subsequent meetings may include secondary stakeholders and actual end users. This is to make sure that all roles are uncovered and properly documented.
The business requirements phase of the projects consists of these three steps:
Phase 1: Conduct meetings with all stakeholders and role players. Phase 2: Assimilate all of the information that was gathered at the meetings. Phase 3: Create the business requirements document.
Phase 1: Steps to conducting the business requirements meetings
1. Prior to the meeting the analyst should create a list of questions that will be asked of each stakeholder and user involved in the business requirements gathering process.
2. The analyst should note the answers to the questions and identify new issues that were not previously identified.
Phase 2: Steps to conducting the business requirements meetings
1. The analyst should summarize the information gathered at the meeting, prepare a report, and then create another question and answer form targeting the new issues that came to light in the previous meeting.
2. This process should continue until the analyst is able to produce a final report that everyone agrees encompasses all of the business requirements.
Phase 3: After the business requirements gathering phase is completed
1. The analyst prepares the formal business requirements document and presents it to all stakeholders for approval and signoff.
2. If signoff it received, the business analyst's work is finished unless and until additional requirements are identified later in the software development cycle.
3. If signoff is not received then it is likely that the project will go back to Stage 1 for additional business requirements gathering and analysis.
Because the success of the projects depends upon it being built to the client's specifications and expectations, the business requirements document is a key deliverable. This stage of the project should never be skipped in order to expedite the development cycle.
Failure to identify and document all business requirements creates unnecessary project risk that will be very difficult to mitigate later in the software development project lifecycle.
10 Top Tips for Creating Good Business Requirements
Creating good business requirements will go a long way towards ensuring the success of the project and eliminate design and development risks that result from poor business requirements documentation. Here are the Top 10 Tips for Writing Good Business Requirements:
1. Develop a clear understanding of the problems that the proposed software is being designed to solve. This will ensure that the subsequent business requirements document addresses those problems fully.
2. Identify all project stakeholders and involve them in the business requirements gathering process from the start. Work to build trust and establish credibility early on so you can maintain stakeholder support throughout the project. Learn the individual personality traits of each stakeholder in order to be able to better manage them during the requirements phase of the project.
3. Clearly document all business data including workflow, current problems, anticipated risks, and required performance metrics. Use project-approved tools and methodologies to ensure that the documentation conforms to the client's requirements.
4. Use approved templates for all documentation. Ensure that terms used throughout all documentation either exist in the project dictionary or are added as required. No one reading the business requirements document should encounter unfamiliar terms that cannot be quickly resolved by reviewing the project dictionary.
5. Identify potential privacy and security issues early on so these problems can be mitigated to a level which satisfies the stakeholders that these risks have been managed properly. This helps to build trust and ensures that stakeholders remain committed to the project.
6. Make a concerted effort to identify and document all risks, the impact of these risks on the project's costs and timetable. This will avoid unexpected project delays as well as help control runaway costs.
7. Conduct both group and one-on-one meetings to insure that all business requirements, risks and concerns are identified.
8. Present a draft of the business requirements document to key stakeholders for preliminary review and tentative approval. This helps to ensure that the final business requirements document will be more easily accepted by all stakeholders when it is presented.
9. Rewrite the draft business requirements document to address any issues discovered during step #8. This may requires repeating the stakeholder meeting process until you are sure that all issues have been identified and documented.
10. Present the completed business requirements document to all stakeholders in a formal meeting. Take notes in order to maintain the collective project memory and be ready to address any issues or concerns which may be raised.
Managing Stakeholders in the Requirements Process
Navigating the process of gathering business requirements and creating the business requirements can be hard enough without adding the issue of stakeholder management to the equation. Nevertheless, fulfilling the needs of the stakeholders is what the project is all about, so it is critical that the analyst keep them on his or her side throughout the project.
Tips for Gaining Stakeholder Trust
It is critical that all of the stakeholders trust the business analyst to complete the business requirements phase of the project accurately and professionally. Loss of stakeholder trust is a critical issue that must be addressed by the Project Manager the moment that any trust concern is raised.
Here is one key method for managing stakeholders during the requirements gathering process:
Conduct One-on-One Interviews - One-on-One meetings enable the analyst to create a strong relationship with each individual stakeholder in these ways:
· Draw out Concerns from Hesitant Stakeholders
Some stakeholders do not like to convey their concerns in group meetings, especially if very senior stakeholders are present or if he or she holds opinions or concerns that are contrary to the group's. These stakeholders are more likely to communicate freely during one-on-one sessions.
· Better Manage Troublesome Stakeholders
Very often group meetings will be dominated by one or two stakeholders who are either disruptive or exhibit some other type of behavioral symptoms which affect the other meeting attendees in a negative way. Meeting with these people in a one-on-one environment gives the analyst the opportunity to gently bring the stakeholder's attention to the disruption issues and, ideally, foster better participation in future meetings.
· Build Rapport - Building rapport by fostering personal relationships is crucial
Other Tips for Managing Stakeholders in the Requirements Process
· Never argue with any stakeholders, disagree in a diplomatic way.
· Never embarrass a stakeholder in a group meeting.
· Remember that some stakeholders may work against your goals because they fear that the project will eliminate or affect their job.
· Always communicate bad news the moment that it is discovered.
About the Author
Positive is a UK provider of professional Business Analysis. Contact Positive at http://www.Be-Positive.co.uk for more information about Requirements Engineering.
All rights reserved. This article may be reprinted in full so long as the resource box and the live links are included intact. Copyright Be-Positive.co.uk