Archive for June, 2021

The Perfect Business Requirements Document

June 10th, 2021

A Business Requirements Document is a formal document that effectively provides a contract between a “supplier” and a “client”. The “client” is typically a business department and the “supplier” is the company or other business department that will create and deliver the new product, system or process. The document describes in detail every business need and is written in response to a known business problem or shortcoming. The Business Requirements Document is not expected to describe in detail the solution to the business needs but to describe what the business wants and needs. For technical products, such as new or modified software systems, further technical specifications will be prepared.

Various techniques, such as brainstorming, story boarding, use cases and interviews, will have been used to gather the requirements during a business requirements analysis process. That information needs to be written down in a clear, concise format in language familiar to the business users. The process of documenting and refining the business requirements helps to identify conflicting requirements and potential issues early on in the project lifecycle. It is the key document in the effective project management of any type of project.

The business requirements document effectively defines the Scope of a project. This is the description of what will be included in the project and also what is specifically excluded from the project.

Scope is a definition of the limits or boundaries of a project and the reason it is so important is because poor management of the project scope is one of the major causes of project failure. Good management of the project scope by the project manager involves 3 key factors:

devote adequate time to fully defining the requirements
reach a formal agreement on the scope with the stakeholders
avoid scope creep
Scope Creep

Scope creep is when un-authorised or un-budgeted tasks lead to uncontrolled alterations to the documented requirements during the course of the project. The business requirements document should address the possibility of requests for additional tasks in a project and state how they will be dealt with. This usually involves a formal Change Request Procedure that requires the agreement of all stakeholders to any changes of specification, budget or delivery time. The fact that the business requirements document is a formally approved document assists the project manager in implementing and sticking to a Change Request Procedure.

There is, of course, a tendency for changes to be requested during the life of a project. As projects progress, the end-users inevitably see areas where additional features could provide increased benefits. And the purpose of scope management is not to prevent such changes either being requested or implemented, but to ensure that all changes bring substantial, well-defined benefits. And that the budget will be increased accordingly and that the extended duration of the project is acceptable to all parties involved. Failure on the part of the project manager to manage scope adequately undermines the viability of the whole project as approved in the Business Requirements Document.

All changes to the requirements, budget and schedule must be approved by all stakeholders. In large projects it is common for end-users to see their opportunity to have all the “nice-to-have” elements added while major changes are underway – to some extent this is understandable but only if the new features add real business value such as efficiency or accountability and do not require the project to change in such a way as to lose sight of the original business needs that instigated the project in the first place

Document Iterations

A business requirements document is likely to need several iterations before it is close to reaching a document acceptable to all stakeholders. Writing such a document can be a complex and intricate process and will probably need many more iterations before approval is actually achieved. This is no reflection on the thoroughness of the analysis process but rather on the simple human difficulty in translating thoughts and speech into clear, unambiguous and thorough wording on the page. Whilst adequate detail is required to fully define the requirements, conversely, too much detail prevents the readers from absorbing the key points. Writing a document that achieves this balance is a skill in itself.

Fortunately, there are a number of best practice approaches and industry standards that can be used to good effect when writing a business requirements document.These will assist in defining the project scope and managing scope creep once the project is underway.

Key Document Elements

Whether the author of the business requirements is the business analyst or the project manager, they should have an understanding of the different levels of requirements and the different elements within the requirements. They must be able to state the business needs clearly, understand the current business process and the key business objectives driving the project.

The following list, whilst not exhaustive, covers the main areas that should be documented in a business requirements document:

Business Problem Statement
Current Business Process
Scope Statement(s)
Key Business Objectives
Project Completion Criteria
Limitations
Risks
Assumptions
Functional Requirements
Non-Functional Requirements
Features and Functions
Reporting Requirements
Delivery Method
New/Modified Business Process
Data Retention/Archiving
Training
Stakeholder List
Quality Measures
Checklists (Process and Requirements)
Ensuring each of these elements is incorporated in to the document with sufficient detail and clarity is the first step to creating a perfect business requirements document. Techniques for writing effective business requirements are covered on both general project management training courses and on specific business requirements courses.

Are Business Requirements Important in IT Project Implementation?

June 10th, 2021

Information Technology Projects within large organizations are frequently started in response to some business need or business failing. There is a tendency in organizations to seek funding and approval for project implementation through proposals based on high-level business needs. Usually proposals are attractive, inviting in appearance and are laid out in the form of a statement of work. They focus on the needs and objectives to be met and put emphasis on the persuasive factor of getting the project approved with the intent of “selling the project.”

A common approach is to proceed with the project implementation based on “the solution only” by defining the required resources, plan of action, deliverables, timelines, and estimated costs. The critical part of documenting business requirements is omitted and a brief list of very high level requirements is inserted to obtain funding and approval.

“The three major reasons that a project will succeed are user involvement, executive management support, and a clear statement of requirements.” “Opinions about why projects are impaired and ultimately cancelled ranked incomplete requirements and lack of user involvement at the top of the list.” Source the Sandish Group report: Chaos.

The main goals of documented requirements should be to deliver value, reduce time and cost, increase satisfaction and achieve success. In my experience, the three integral aspects that are necessary for the success of projects, but that are often missed out or not detailed enough, are:

1. Benefits and business value:

People lose focus of the project’s benefits and sponsors do not commit to measuring and achieving the defined benefits. It is very difficult to achieve business value if there is lack of commitment to attain the defined benefits. The benefit statements should be clear, concise, and quantified.

2. Detailed business requirements:

Documented requirements are Important!!! In order to align the solutions for delivery of business value, the business requirements must be captured and the solution must be managed to meet them. In my opinion business requirements should be S.M.A.R.T., namely Specific, Measurable, Achievable, Results-focused and Time-bound. Furthermore the solution should be designed to satisfy and comply with organizations enterprise architecture.

3. Documented quality assurance processes:

The lack of detailed requirements creates a huge problem for the Quality assurance team that is expected to ensure the quality of the project as a whole. The quality assurance team needs to have the means to compare what was delivered, to what was required. The more detailed the requirements are, including what is the proof of success, the more likely quality could be achieved.

Findings from surveys of over 100 companies in Keith Ellis’s report: “The Impact of Business Requirements on the Success of Technology Projects” determined that “Companies with poor business analysis capability will have three times as many project failures as successes. 68% of companies are more likely to have a marginal project or outright failure than a success due to the way they approach business analysis. In fact, 50% of this group’s projects were “runaways” which had any 2 of: Taking over 180% of target time to deliver; Consuming in excess of 160% of estimated budget; Delivering under 70% of the target required functionality. Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their projects. Over 40% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization. The vast majority of projects surveyed did not utilize sufficient business analysis skill to consistently bring projects in on time and budget. The level of competency required is higher than that employed within projects for 70% of the companies surveyed.”

One must always remember that people in different roles will view the project from their own perspective and will not always see the bigger picture. A consolidation phase of requirements analysis needs to be done to look at these different perspectives and present an overall holistic best solution.

In FAO gathering business requirements is performed through brainstorming sessions with the business units and/or defining phased deliverables to be used as prototypes. The Information Technology Division in FAO has put in place mechanisms for ensuring Quality Assurance involvement in all phases of project implementation, from the project inception to project closure phases. In addition, emphasis for all IT projects to measure benefits and liaise with our business units to develop detailed business document requirements has become a prerequisite to project approval. In 2015 the IT division will measure the rate of improved project delivery due to increased business requirements definition.

In Karl E. Wiegers presentation, the “Cosmic Truths about Software Requirements” the following points are some key points to remember:

If you don’t get the requirements right, it doesn’t matter how well you execute the rest of the project; Requirements development is a discovery and invention process, not just a collection process; The interests of all the project stakeholders intersect in the requirements process; The first question an analyst should ask about a proposed new requirement is “Is this requirement in scope?”; The requirements might be vague, but the product will be specific.

On a final note, as considerable resources in terms of people and money are used to deliver what is actually needed for the realization of the expected business value and objectives, good business requirements are instrumental to avoid failures and complete successful projects.

Author: Omar Hajjar (Senior IT officer) – Food and Agriculture Organization of the United Nations (FAO). The