Better Requirements Yield Better Project Results

Statistically, 31% of projects will be cancelled before they are completed. 53% of projects will take more time to complete and will cost twice as of their original estimates. Overall, the success rate for IT projects is less than 30%. The four biggest causes of failed projects are:

1. incomplete, missing, or poorly written requirements,
2. lack of user input and buy-in,
3. failure to define clear objectives, and
4. scope creep.

All four of these factors result from poor requirements management practices. Current requirement management processes and tools are simply not working.  Below are 14 reasons of why we as an industry need to rethink requirement development and management practices and tools.

1.    Microsoft Word/SharePoint were Not Designed for Requirements Management.

In a recent survey of requirements management tools, 91% of the participants used Microsoft Word for defining requirements.  Most projects require cross-functional teams consisting of various business and technology users. Large Microsoft word documents are simply not easily reviewed, shared or amended across large teams.  Frequently, missing requirements or defects are not discovered during lengthy reviews of large text based documents. This often results in late feedback of critical elements much later in the lifecycle when the information is actually firs seen by a stakeholder in development or testing. Because Word is a static tool, feedback from stakeholders rarely occurs until that individual is affected, possibly as late as development.

Requirements development should be incremental, iterative and collaborative.  Stakeholders should be able to review requirements as they are developed and make comments when they feel that the requirements do not address their needs. Organizations should use a collaborative tool to define requirements, not a word processing tool that was never designed to address the needs of requirement development and management.

Failure to use the right tool for defining requirements will result in:

• Missing or Incomplete Requirements – It is always best to elicit, analyze, and specify requirements in a structured fashion. It is very difficult to accomplish this using a general-purpose tool such as Word or Excel. Failure to gather requirements in a structured fashion often leads to incomplete requirements, which is one of the major reasons for project failure according to a study by The Standish Group.
• Misunderstood Requirements – Good requirements are generally documented with more that text.  Supplemental requirements documentation may include graphic illustrations, discussions, business process models, videos, and links or references to other documents. It is difficult if not impossible to capture this type of information in Word or Excel.  Requirements are often misunderstood when they are not elaborated with additional types of information.
• Lack of Support for Requirements – Buy-in and active stakeholder support is essential for good requirements.  People are reluctant to buy into a gigantic text based document they did not author.  These large text documents are intimidating and overwhelming for most people. As a result, people often provide only a cursory review and reluctantly accept them, but do not truly buy into them. A collaborative tool works significantly better than a large text based document to obtain real stakeholder participation and buy-in.
• Incorrect Requirements – Requirements documents created using a general purpose tool such as Excel or Word are usually stored on the author’s computer, and are not accessible by others in real-time. This makes it difficult to share, discuss, validate, and track changes, which in-turn frequently leads to incorrect requirements.  When word documents are distributed, the author loses control and almost always has a version control problem. Redistributing different versions of the same word document is error prone, awkward, and simply not practical for large teams. Requirement teams should be able to view, edit, and comment on requirements in real time.
• Lost Requirements – It is easy for requirements to drop through the cracks when using general purpose tools such as Word or Excel.  Critical requirements can be lost when the author forgets, is reassigned, or leaves the organization.
• Inability to Support Agile Projects – Many organizations are using agile or other forms of iterative development. Many of these development methods require prioritization of requirements and organization of the requirements into bundles that fit a development iteration. It is simply impractical to try to accomplish this with Word or Excel. The iterations are very short and the team must know what the requirements are before the iteration begins. This requires a data driven approach to requirements versus a document driven approach, as the requirements are maintained in backlog, sized and prioritized. Using the sizing and priorities, requirements are identified and planned for development iterations.

2.    Capture all Five Types of Requirements

Incomplete requirements have for many years been cited as the primary cause of project failures.  According to the IIBA’s Business Analysis Body of Knowledge (BABOK), there are five types of requirements.  Let’s examine each type of requirement below.

• Business Requirements
• Stakeholder Requirements
• Functional Requirements
• Nonfunctional Requirements
• Transition Requirements

Most requirements management tools on the market capture only functional and sometimes nonfunctional requirements.  Not capturing all five types of requirements is a major omission and results in suboptimal project results.

Business requirements are needed to ensure that the solution delivers expected business value. According to industry research, organizations that accurately capture business requirements and use them for benefits realization management achieve 3 times the benefits of organizations that do not follow this practice.

Stakeholder requirements are needed to ensure that the solution meets user needs.  According to the Standish Group, the lack of user input has been the number one cause of challenged and failed projects for the past fifteen years. What good is a requirement tool if it cannot capture user needs?  Stakeholder needs are generally captured in the form of personas and scenarios.  Personas describe characteristics of each user class.  Scenarios are used to describe activities and problems for the stakeholders.  There are three types of scenarios:

• Activity scenarios – Describe how stakeholders perform their work
• Problems scenarios – Describe problems encountered by stakeholders
• Interaction scenarios – Describe how users interact with the system. (These are extensively employed in user-centered design.)

Business and stakeholder needs should be developed before the functional and nonfunctional requirements.  Functional and nonfunctional requirements are given to development teams to create the solution.  They may also be used to evaluate and select a solution if the solution is purchased instead of built.

Transition requirements are developed during solution assessment and validation to ensure a smooth migration to the new solution. Transition requirements address such things as:

• Data conversion and migration
• Organizational change
• Business continuity
• User support transition
• Production cutover
• User access and security

Not defining and addressing transition requirements has resulted in significant operational and user adoption problems for many companies. It is very important for your projects to address all five types of requirements. If your processes and current requirements management tools do not properly address all of these, then you should make switch tools as your current tool is lowering your project success rates, preventing you from achieving maximum business value, and lowering user adoption and satisfaction.

3.    Three Perspective on Requirements

Developing requirements should be viewed from three perspectives: The Business Owner, Users, and Developers.  The business owner perspective is important to ensure that the requirements deliver business value.  The user perspective is important to ensure that the solution will help the users improve their business processes. The developer perspective is important as the developers must be able to understand the build the solution.

Most automated requirement tools are focused on the developer and not on eliciting requirements and ongoing clarification of requirements from stakeholders. In fact, a recent report by one of the leading IT research firms did not even list requirements elicitation or requirement communication as critical components for requirements management. The need for focus on stakeholders should be obvious; who are the requirements for?

An automated requirements management tool should support collaboration and ongoing communications about requirements. Open interpretation of requirements by developers without a checkpoint back to business stakeholders is the most critical aspect in the overall cost of quality. Interpretation errors by developers may mean the wrong application is built. Interpretation errors on the part of a tester translates to a lack of verification of business requirements.

4.    Requirements are Data Centric vs. Document Centric

The notion of creating a large requirements documents is simply flawed. Requirements are so much more than just a single gigantic text document. Requirements management should focus on creating requirement bundles which can be accessed, reviewed, validated and managed online. Requirements bundles consist of much more than just text-based requirements. They include visualizations using things such tools as mindmaps, whiteboards, wireframes, UML models, and concept diagrams.  They include user comments and clarifications about the requirements.  They may also reference various documents such as regulations, competitive offerings, company policies, and the like. They reference business rules. Stakeholders should be able to navigate through requirements bundles using an easy to use web based system using flexible search capabilities and hierarchical links of structured information.

5.    Visualization Promotes Enhanced Understanding of Requirements

According to requirements authority Alan Davis, no single view of the requirements provides a complete understanding. You need a combination of textual and visual requirements representations to paint a full picture of the intended system. Diagrams communicate certain types of information more efficiently than text. Pictures help bridge language and vocabulary barriers between different team members and stakeholders. Videos are very helpful to capture interviews and decisions. Below is a representative list of various techniques that may be used for requirements visualization.

• Data Flow Diagram
• UML Models
• Flow Business
• Process Models
• Mind Maps
• Concept Diagrams
• Videos
• Wireframes
• Rapid Prototyping
• White Boards
• Entity Relationship Diagrams
• Decision Trees

6.    Good Requirements are Needed for Agile Too

For a variety of reasons, companies are rapidly adopting agile development practices. Waterfall based practices for developing requirements simply do not work for agile. Even though agile has a higher success rate than waterfall, there are still hundreds of reported agile failures resulting from lack of user input and poor requirements. Many assumptions that applied to the first agile project simply do not exist today. Let’s examine these flawed assumptions:

1. A single development team being collocated together,
2. A single development team that can address all integration and changes across multiple systems and platforms that is often required in most system projects,
3. A single product owner that can speak for all stakeholders that is collocated with the developers,
4. A single product owner that can also address all organizational change and people issues that plaque many projects.
5. Developers that can communicate clearly and effectively using business terminology with product stakeholders.

These assumptions are simply not today’s reality. Agile offer real promise, but the requirements problem must be addressed. User stories written on sticky notes and attached to a gigantic whiteboard is not the answer.

The best approach is to apply agile methods to requirements development and management. Let’s examine this approach. Stakeholders define their needs using user stories.  Users constantly prioritize their user stories that are maintained in a backlog. Requirement specifications are created from the user stories. Visualizations are prepared as needed to clarify the requirements. Test cases and scenarios are prepared for each requirement as needed.  A requirements bundle is prepared for each development iteration.  Each requirement bundle is validated and approved by both the stakeholder community and the Development Team(s).  Requirements are removed when too many are placed into a requirement bundle making it impossible to be performed within the development iteration. After the bundle has been approved, it is baselined and used as the requirements for the next development iteration.  During development, developers may ask for clarifications on requirements and stakeholders provide clarifications using social networking technologies. New user stories and requirements are created based on information learned during retrospectives. Requirements bundles follow development iterations: stakeholders work on the next requirement bundle, while developers are working on development iteration.

7.    Devine Requirements for People, Processes and Technology, not just Software

Most requirements management practices and tools are focused on capturing only software requirements. The success of projects depends on much more than just the software; ignoring people and process issues is a sure cause for failure.

Stakeholders’ needs are seldom elicited in a manner similar to what we do for software development. For this reason, it is no wonder that 85% of change management efforts fail. This would be like the developers defining the software requirements and telling the users here are your requirements, you must accept them and have no say in the matter. Organizational change and training needs should be elicited in a manner similar to what is done for software.  Organizational change staff should not start on their organizational development activities, just like software developers should not start on their development activities, until the needs of the user/stakeholder communities have been elicited and analyzed.

Changes in business processes should drive software changes and not vice-versa. Starting to modify software without understanding the business process is simply a mistake. Trying to implement new software without modification of the business processes it supports does not work; simply look at the success of ERP projects. Requirements for business process change should be documented prior to development of software requirements.

8.    Requirements Lifecycle Management is more important than Requirements Traceability

Requirements traceability refers to following a requirement both forwards and backwards from the source where it originated through its development and specification, to subsequent deployment and use, and through all periods of on-going refinement and iteration in any phase. Either a business analyst or quality assurance staff generally does requirements traceability. There is generally no involvement by users or stakeholders.

In contrast, requirements lifecycle management is performed by stakeholders. Using the requirements, stakeholders verify that their needs are met through participation in various lifecycle events such as retrospectives, design reviews, acceptance test, training instructional design, and the like. By keeping stakeholders involved, defects are detected earlier, thereby minimizing the cost of rework. Final solutions fully address stakeholder needs, and user acceptance and satisfaction is significantly higher.

9.    Requirements Development is an Iterative Process

Most organizations view requirements development and management as a sequential process. Requirements are developed using a four step sequential process: elicitation, analysis, specification, and validation. Requirements are then turned over for design and development.  The four steps of requirements development should be performed in parallel and viewed as activities, not steps. As needs are identified, they should be analyzed, requirements should be specified, and the requirements should be validated. Individual or group interviews with stakeholders is not enough to capture all requirements.  Stakeholders and business analysts should be involved in the four requirements development activities simultaneously. The only practical way to accomplish is though an automated group collaboration tool such as Enfocus Requirement Suite.™

If development is being done incrementally in releases, then requirements should also be developed incrementally in releases. This will allow development to start earlier and to use lessons learned from development to improve future releases of requirements.

10. Socialized Requirements vs. Closed Hidden Requirements

Requirements are usually never seen until all interviews have been conducted and a detailed requirements document has been prepared.  To be more effective, stakeholders should be able to see their needs analyzed and mapped to requirement specifications. They should be able to express their concerns in the form of comments and express likes and dislikes of requirements.  This feedback helps developers identify problems earlier and prevent inaccurate and incomplete requirements from going to design.

11. Requirements Should be Linked to Enterprise Architecture

Enterprise architecture as a concept and practice emerged about 20 years ago. Enterprise Architecture was introduced initially to address two problems:

• System complexity—Organizations were spending more and more money building IT systems; and
• Poor business alignment—Organizations were finding it more and more difficult to keep those increasingly expensive IT systems aligned with business need.

These problems, first recognized 20 years ago, have continuously been a concern to IT and have now reached a crisis point. The cost and complexity of maintaining IT systems have exponentially increased, while the ability of deriving value from those systems has dramatically decreased. The problem has been exacerbated further by the rapidly changing business environment and the seemingly lack of agility of IT organizations and technologies to respond to this rapidly changing dynamic business environment. Organizations can no longer afford to ignore these problems. Many organizations have looked to Enterprise Architecture as a way to solve these problems.

The problem with Enterprise Architecture is that many organizations have not effective way to link EA Strategy to projects and requirements. Even though the goals behind Enterprise Architecture are sound, many organizations have struggled applying the principles of Enterprise Architecture to managing projects and every day work. From our research at Enfocus Solutions, we believe much of this problem can be attributed to immature enterprise analysis practices at most organizations. Enterprise Architects can prepare a great strategy and wonderful architectural models, but thee models must be applied through effective enterprise analysis.

Enterprise Analysis is a knowledge area defined in IIBA’s Business Analysis Body of Knowledge (BABOK) which describes Business analysis activities that take place for an enterprise to identify business opportunities, build a Business Architecture, determine the optimum project investment path for that enterprise and finally, implement new business and technical solutions.

Enterprise Analysis complements Enterprise Architecture but also overlaps in some areas. Organizations that are looking into Enterprise Architecture and specifically TOGAF should also adopt a Business Analysis framework such as BABOK and integrate them to work together. Integrating Enterprise Architecture and Enterprise Analysis is a great opportunity for optimizing the alignment between Business and IT, and to run an Enterprise Architecture program from a complete business perspective.

Enfocus Requirements Suite™ was designed to make Enterprise Architecture actionable and to be used for Enterprise Analysis activities, requirements elicitation, and requirements development. Enterprise Architectural data is stored and maintained in the Enfocus Requirement Suite™. This Enterprise Architecture data is used for portfolio management to help manage scarce resources and choose the right projects that deliver the most business value. Information is maintained for people, processes and technology.  This information is readily available to business analysts, business owners, enterprise architects, and development teams.

12. Business Rules should be Maintained Separately from Requirements

Business rules should be maintained separately from project requirements. This allows this information to be available to business analysts and prevents the need for rediscovery for each and every project.  Rediscovery is not only costly but almost results in incomplete and inconsistent information.  For example, take business rules. It is common practice to identify business rules to drive requirements for a project. If a similar project comes up years later, the requirements team usually rediscovers the business rules that apply and never refers to the business rules that were defined before.

It is best practice to maintain business rules in a knowledge base separate from requirements and maintained by the business.  The knowledge base can be referred to by any project team member or business user that has a question relating to the business rules. Requirements simply reference business rules in knowledge base.  This process significantly improves requirements, reduces time required from stakeholders, and provides a valuable reusable organization-wide knowledge base of business rules.  Many business process management systems are driven by business rules, but these generally not effective for software requirements where business rules must be enforced by software, database stored procedures, or external rules engines.

13. Business Requirements vs. Detailed Requirements

Clear business requirements should be defined before needs are elicited from stakeholders.  Business requirements generally consist of:

• SMART business objectives,
• Resource, cost, and time constraints,
• A concise problem statement,
• A clear vision of how things should be in the future, and
• Scope statements that clearly specify what is in or out of scope.

There is confusion in many organizations as to whether the problem statement should be defined by the project sponsor, the business analyst, or the project manger assigned to the project. It doesn’t really matter who prepares it, but it must be documented and agreed to by all three of the parties cited above.  This information should also be made available to all stakeholders involved in the project. It is difficult for stakeholders to provide meaningful and relevant input unless they first understand what the business is trying to achieve.  Most requirements management tools do not start with the business requirements; it is no wonder that less than 30% of all IT projects achieve the benefits specified in the business case.  Furthermore, how many individual or group requirement interviews have been conducted where the participants had never reviewed the business requirements?

14. Business Value vs. Wish List and Cool Features

According to the Standish Group, over 45% of all system functionality that is built is never used. This is caused by a variety of factors, but two major causes are gold plating and wish lists.

Gold plating takes place when a developer adds new functionality that he believes “the users are just going to love.” Often, users don’t care about that functionality, and the time spent implementing it is wasted.  Rather than simply inserting new features, developers and analysts should present customers with creative ideas and alternatives for their consideration. Developers should strive for leanness and simplicity, not for going beyond what the customer requests without customer approval.

Often, users simply provide a wish list or request features or elaborate user interfaces that look cool but add little value to the product. Everything you build costs time and money, so you need to maximize the delivered value. To reduce the threat of gold plating and wish lists, each requirement should be traced back to its origin so that you know why it’s included.  In addition, requirements should be carefully prioritized; requirements that are not in scope or do not address the business objectives should be eliminated.  Requirements that provide minimal business value should also be evaluated for exclusion.

If your requirements management processes and tools do not address these issues, then you should look for another tool.  Addressing these deficiencies in current requirement management tools and processes will result in delivering more value to the business, less project rework, lower costs and increased customer acceptance and satisfaction. Enfocus Requirement Suite™ from Enfocus Solutions Inc. addresses these issues and more.  To find out more, download our product fact sheet:

[cta id=”7421″]