Why Projects Fail and What Executives Can Do About It. The Truth About Requirements Definition and Management

Transcription

1 Why Projects Fail and What Executives Can Do About It The Truth About Requirements Definition and Management White Paper May 2008

2 Contents Executive summary Requirements Definition and Management: A Neglected Business Process Understanding RDM Challenges The Multiplier Effect: Why Failed Requirements Result in Failed Projects The High Cost of Defects and Late Changes Optimizing RDM to Ensure Business Success Using RDM to Improve Product Quality and Reduce Costs Using RDM to Reduce Costly Rework and Meet Rising Customer Expectations Using RDM to Regain Visibility and Control and Increase Reuse Borland: Bridging the Business IT Gap to Ensure Project Success For More Information

3 Executive Summary Software is the engine of the modern enterprise and for many organizations, it is their primary source of competitive advantage. Executives at all levels understand that the right software product deployed at the right time can help them automate manual, costly processes; cut operational costs and boost efficiency; accelerate innovation internally and with partners; and differentiate their business from the competition by improving product and service quality. Software development remains one of the most inefficient and unpredictable areas within IT today. It s well known that most software projects are either delivered late, way over budget, don t meet customer needs, or are cancelled altogether. 1 And software failures across many industries from car manufacturers to airlines cost the American economy billions of dollars annually. 2 According to the Business Analysis Benchmark 2008 study that surveyed 110 companies, nearly seven out of 10 companies involved in development projects valued at $250,000 or more have software projects that are marginal in quality and function or are complete failures. 3 What s the source of the problem? In the vast majority of cases, these undesirable outcomes originate early in the software development process when requirements are first conceived and documented. Incorrect requirements result in costly rework that typically accounts for 40% of a development organization s total spend (with most of the effort focused on correcting defects). Did you know that the cost of correcting an erroneous requirement after a product has been released can be 100 times more expensive than if the error is discovered during the requirements development phase? The good news is that with the right processes and supporting software in place, you can optimize requirements definition and management (RDM) and use it as powerful lever to ensure project success. This paper explains what RDM is, how to do it well using the latest RDM software, and the business impact of implementing RDM solutions as part of a complete Open Application Lifecycle Management (ALM) solution. Requirements Definition and Management: A Neglected Business Process When done well, requirements definition and management (RDM) is a collaborative process of collecting, documenting, and validating a set of requirements that key project stakeholders and those responsible for building the software agree on. Throughout the development lifecycle, the focus shifts to managing changes to those requirements and ensuring that the final product reflects them. It sounds so simple, doesn t it? Everyone agrees on what the software needs to do, and project managers ensure their teams execute in a timely, efficient manner. It s no surprise that most executives assume that their RDM processes are effective and their development teams have clear, accurate, and validated requirements both for new products and changes to existing products. But in reality, RDM is rarely handled effectively in part because few people involved in the development process understand the importance of these requests or how difficult and costly it is to implement request changes later in the development lifecycle. According to Standish Group (2004), three of the top five reasons software projects fail are tied to requirements: Users are not involved enough in requirements definition, which leads to inaccurate requirements Requirements are incomplete or don t meet acceptance criteria Requirements are constantly changing, but these changes are not managed effectively 1 Standish report: 2004 CHAOS Report 2 According to the 2002 American s National Institute of Standards (NIST), software failures cost the United States economy $59 billion. 3 IAG Business Analyst Benchmark,

4 Given the impact that requirements can have on software projects and ultimately business outcomes a growing number of organizations are managing RDM as a critical business process rather than just an IT process. Understanding RDM Challenges How does the RDM process at your business work? The typical process is best described as chaotic and time consuming. Here s why: Requirements can come from all directions. Requirements come from internal and external stakeholders via , phone, meetings, and help desk applications. For example, your end users will both report defects and request new features based on how they prefer to work. Significant changes can also come from customer advisory boards requests that can alter the direction of product development. In many cases, requests can be in conflict with one another from a functional or technical perspective. And because these stakeholders tend to communicate using terminology that is unfamiliar to developers, even simple requests can be misunderstood by your development team a major source of risk in software projects. Without collaboration, it s difficult to create good requirements. Many requirements only become valuable documents for directing execution after extensive collaboration between and validation by multiple stakeholders. Collaboration is critical because people make assumptions about details for which they are not responsible. For example, if your company is developing a sales application, your end users probably want fast access to product, customer, pricing, and order information. How that information is gathered from the various data sources scattered across your company is not their concern or responsibility. Their request may be completely reasonable from a sales perspective but a technical nightmare for a developer because data may be scattered across the enterprise, and back-office systems may not be able to respond with accurate or timely information. It s hard to focus stakeholders on what matters most. Even when stakeholders are willing to collaborate on requirements, it can be challenging to get them to focus discussions about the most relevant issues. Effective requirements definition requires that everyone agree on what the business needs to accomplish and what the priorities are. For example, you may have many requests to improve order operations within a sales application, but from a business perspective, this functionality may be adequate compared to other areas, such as tools for communicating with new prospects. Your stakeholders need to work together to prioritize requirements appropriately. Without the right tools and automation in place, managing changes to requirements can be incredibly complex. Within most companies, project managers rely on fragmented documents, spreadsheets, and sticky notes to manage and track requirements and associated changes. While manual activities may suffice for small projects, larger or more mature projects can be incredibly complex with thousands or even hundreds of thousands of variables and changing details. Software projects can also have dependencies on other projects. This level of complexity, coupled with growing compliance requirements, simply can t be managed effectively without automation and RDM best practices that ensure all stakeholders understand what functional requirements have been agreed upon and how changes to them can impact the teams and deliverables. For these reasons, most companies have considerable inefficiencies in their RDM process that make it nearly impossible to correctly capture and validate requirements up front or manage and communicate changes to developers responsible for writing and modifying code. 4

5 Getting Requirements Right Means Making Difficult Choices Requirements define the scope of work that developers and testers must execute on and project managers must manage to completion. When assessing your organization s requirements, it s not enough to ask, Do we have the requirements? Any project team will have documents with some form of written request, but the state of those requirements must be questioned. Do they express the highest value of the user community? Have they been validated? Who owns them? Are they actionable and reasonable? Are changes to them being managed as business needs evolve throughout the development lifecycle? At the same time, you may need to make difficult choices regarding requirements. The challenge is to strike a balance between keeping customers happy (by implementing their requests) and driving software innovation to create a competitive advantage. When based on careful analysis of business priorities rather than who has the most political clout or who is complaining the most requirements decisions can play a pivotal role in ensuring business success. The Multiplier Effect: Why Failed Requirements Result in Failed Projects Clearly, RDM is difficult to do well especially without the right processes and supporting technologies in place. But how do failed requirements actually lead to failed projects? To answer this question, you need to take a closer look at how requirements are actually used throughout the software development lifecycle. When analysts capture requirements and approve them, they are handed off to a diverse set of teams for execution. These requirements drive the teams responsible for the design, architecture, coding, testing, documentation, and final delivery of a new product or system. When poorly defined, incorrect, and non-validated requirements are handed off to these teams, the mistakes are hard-coded into the project at all levels and far more difficult and expensive to fix. It s akin to building a home when you are not sure exactly what you want or think you do, but find out later that you made a mistake. Consider a couple who wants to build a larger home to accommodate their growing family and evolving needs. For example, they need more bedrooms, a larger kitchen, and a walk-out basement. An architect draws up plans and the couple makes hundreds of decisions regarding everything from the overall floor plan to paint colors. Months later, the foundation is poured, the framing is completed, the plumbing and electrical wiring is installed, and drywall is finished. Now imagine at this late stage the couple decides to switch the locations of the kitchen and master bedroom. Asking the various teams involved in building the home to make this kind of change would not only be prohibitively costly but potentially undoable. In the world of software development, this type of late-stage change request occurs more often than you think. As this analogy illustrates, a requirements mistake upstream can have catastrophic effects on your business downstream. With proper requirements definition, traceability, and impact analysis, you can avoid these situations, as you can quickly assess and scope the time, cost, and resource requirements needed to implement a particular change across all impacted software requirements. RDM failures can impact product quality and delivery deadlines and bring the activities of those responsible for testing, documenting, marketing, and selling products to a grinding halt. The end result is lost time to market, fewer sales, and lower customer satisfaction. 5

6 The High Cost of Defects and Late Changes From sources such as James Martin s An Information Systems Manifesto, we know that 56% of software defects can be traced back to requirements as their source. At the same time, the cost to fix defects due to failed requirements accounts for 82% of the effort to fix defects. Multiple sources state that roughly 40% of any software project is dealing with rework. This means that for a typical, one-month project staffed with 10 people and requiring 1600 hours of effort, 800 hours of the project is rework. Of those 800 hours, 656 hours (or 82%) would involve fixes due to failed requirements. What do these figures mean to your business? If you assume the average, fully-loaded cost of a software engineer is $80 per hour, your company is spending $42K on rework due to requirements and over $600K for a year-long project. If your organization executes on many projects each year, it may be spending millions of dollars in rework due to failed requirements and late changes a painful cost for any business. Cost of neglecting requirements on a 10 person project Month 3 Month 1 Year Total cost of project (in thousands) Cost to fix requirement errors and late changes 6

7 Optimizing RDM to Ensure Business Success In reality, then, RDM is an important business process; it s not just a part of the IT department s software development process. Understanding end user needs and capturing them as clear, detailed, and validated requirements is more about your business than the software. It s about the future of your company and its competitive advantage or reason for being. From a business perspective, this means that you can no longer afford to assume that software requirements aren t relevant to your core business operations or don t impact overall business results. They do and forward-looking companies that take steps to optimize requirements definition and management and achieve sustained business-it alignment throughout the development lifecycle can achieve significant competitive advantage. Consider the following examples of Borland customers who implemented RDM solutions. Using RDM to Improve Product Quality and Reduce Costs Borland worked with a leading global manufacturer of air conditioning systems to improve operational excellence and raise customer satisfaction through greater product quality. The development team had no centralized repository for storing software requirements or providing easy access to their distributed teams. Moreover, they used Microsoft Word documents to capture and communicate software requirements. Each Word document would go through a series of reviews by product marketing and engineering, during which requirements would inevitably change. These documents had to be manually updated and stored primarily for historical reference. Once changes were made, deferred requirements were not well tracked and were sometimes lost. The team also had no way to map functionality driven by industry standards into specific projects, so when a change was made to a standard, the development team didn t know what requirements were impacted. The Benefits of RDM Solutions Using an RDM solution from Borland, the project engineering team automated its processes to provide greater predictability and visibility across the development lifecycle. As a result, the manufacturer has realized the following benefits: Greater efficiency: For a small project with requirements, the company sees about a 15% increase in efficiency, and for larger projects with requirements, they see about a 50% gain in efficiency. Better product quality at a lower cost: Now the development team can re-organize, re-tag, and re-classify requirements throughout the phases of the development lifecycle, which ensures deferred requirements make it into appropriate future releases. As a result, the company can deliver higher-quality products and minimize last-minute rework, which lowers development costs. Simplified compliance: Development teams can easily capture requirements for compliance and ensure that when a standard changes, the change immediately trickles down into mapped requirements in all active and future projects. Using RDM to Reduce Costly Rework and Meet Rising Customer Expectations One of the largest mining machinery and service companies in the world uses Borland s RDM solutions to dramatically reduce project rework costs and consistently meet customer delivery expectations. The company s sophisticated and costly machines are supported by complex computer systems that frequently must be tailored to meet customer needs. When collaborating with customers, the team was relying on manual documentation methods, such as Microsoft Word, to support the RDM process. This created a tedious, inconsistent process for data capture and inefficiencies in analysis, which increased the number of iterations during the requirements review process. The complexity of the mining equipment also 7

8 made manual techniques for capturing requirements and creating use cases especially difficult to manage. Since the company s diverse international customers often describe the same problem and requirement in different ways, accuracy and clarity were also key challenges. The Benefits of RDM Solutions Using an RDM solution from Borland, the company can accurately document and validate customer requirements, as well as streamline the requirements management process. The software has helped to reduce the expectation gap for customers by facilitating the collection and creation of more detailed and accurate requirements that can be shared with all stakeholders using a centralized repository. Over 100 users access these requirements to deliver on key product features with greater precision and certainty. Because all stakeholders can collaborate easily during each stage of the requirements process, the business has reduced rework considerably. In addition, the company realized the following additional benefits: 60% fewer requirements reviews: Requirements reviews have decreased from an average of 10 iterations down to 4 iterations per project, allowing the company to deliver products in a significantly shorter timeframe. End-to-end requirements traceability: Borland RDM software supports end-to-end requirements traceability, complete with detail on all changes for accurate timelines and better feedback to product developers. This results in greater speed and agility in the software requirements management process and shorter production cycles. Reduced risk and greater product reliability: The traceability provided by Borland RDM software has also allowed the development team to confirm that each customer requirement has a validated test and each use case is the result of a documented requirement. This enables the team to more easily estimate and implement requirements-based validation tests, reducing risk and improving product reliability and safety. Using RDM to Regain Visibility and Control and Increase Reuse Borland helped a leading global logistics and supply chain management company use automation to optimize its application development lifecycle for its flagship logistics suite. Demand for the logistics suite was growing rapidly, both nationally and globally and processes used by the development team couldn t support this growth. Management knew it had to put more process, methodology, training, and technology in place to incorporate 50 new employees into the development team. The company was using stand-alone solutions to automate source code management and handle change requests but they were so ineffective that team members often reverted to manual processes. And it lacked an automated solution to help teams effectively define and manage the large volume and the variety of requirements coming in from multiple cultures and in different languages. Improving requirements management would not only prevent unnecessary rework and reduce costs, but promote reuse of code. The Benefits of RDM Solutions The logistics company selected the Borland ALM solution to gain more visibility, control, and efficiencies throughout its development processes. Now they can electronically capture and manage the wide variety of business, technical, functional, and operational requirements gathered from around the world. And because requirements are automatically fed into test script management software, the company has increased control and visibility into project status. As bugs and changes are identified, they are put back into the system as tasks to be delegated and managed. 8

9 The process automation and project visibility made possible by Borland s ALM solution has enabled the company to achieve the following business results: 100% increase in data accuracy: Now the company can make more accurate information readily available to all team members, enabling them to spot trouble areas more quickly and gain visibility into what is available, which fosters reuse. 20% immediate productivity gain: Within just a few months of deploying the Borland solution, the development team saw an immediate jump in productivity. 50% reduction in rework related to requirements: The Borland ALM solution enables the team to trace business, technical, functional, and test requirements all the way through the lifecycle in order to deliver the product as expected. Now they can stay within budget by minimizing misinterpreted requirements and eliminating rework late in the design cycle. Over time, they expect to reduce the amount of rework related to requirements by at least 50%. Borland: Bridging the Business IT Gap to Ensure Project Success Your business can achieve similar business results by investing in the right RDM solutions and implementing proven best practices. When developing your RDM solution, it is important that you address both the process and technology portions of your problem. If you focus strictly on introducing technology without improving processes, you ll simply automate ineffective processes and perpetuate RDM problems. Likewise, refining a process without technology leaves a good deal of manual activity to be performed by project teams. End-to-End Requirements Management with Borland Caliber Analyst Borland offers two products for defining and managing software requirements: Borland Caliber DefineIT and Borland CaliberRM. Both are available individually; or you can deploy them together in one end-to-end requirements engineering suite: Borland Caliber Analyst. Borland Caliber Analyst supports all key RDM processes in a seamless, integrated manner. Borland Caliber DefineIT: Enabling End-to-End Requirements Definition Borland Caliber DefineIT is a complete software requirements definition system that provides support across four key requirements definition process areas: elicitation, analysis, specification and validation. You can create visual specifications that clearly communicate business needs that can generate flows for software test case management. The software also integrates with other Borland and third-party products, enabling you to weave accurate software requirements definition throughout your application lifecycle. By helping to ensure you facilitate collaboration and define accurate, prioritized requirements, the software makes it easier to focus development teams on the highest-priority business needs, as well as reduce rework and lower development costs. Borland CaliberRM: Supporting End-to-End Requirements Management Borland CaliberRM is an enterprise software requirements management tool that facilitates collaboration, impact analysis, and communication, thereby enabling your software teams to deliver on key project milestones with greater accuracy and predictability. CaliberRM also helps small, large, and distributed organizations ensure that applications meet end users needs by allowing analysts, developers, testers, and other project stakeholders to capture and communicate the users voice throughout the application lifecycle. You can ensure that all stakeholders have a common understanding of the business, user, functional, and nonfunctional requirements related to a project even as they change over the course of a project. As a result, you can effectively manage changing requirements, deliver higher-quality products, and boost stakeholder and customer satisfaction by increasing responsiveness and delivering the right software on time and within budget. 9

10 Part of an Integrated, Open Application Lifecycle Management Solution These products can be deployed as part of an integrated, process-driven Open Application Lifecycle Management solution. Borland s vision for Open ALM recognizes customers need to define, manage and measure their software delivery processes based on their own unique needs. As a result, you can invest in new technologies to assist you with requirements definition and management without abandoning your existing tools and processes. For More Information Without the right technology and processes in place, it can be nearly impossible to see when requirements are failing until it is too late (usually about the time you notice that a project is failing). The good news is you can break the cycle and turn requirements definition and management into a source of competitive differentiation and advantage. For more information, please visit the Borland Requirements Definition and Management Resource Center at Borland is the leading vendor of Open Application Lifecycle Management (ALM) solutions - open to customers processes, tools and platforms - providing the flexibility to manage, measure and improve the software delivery process. Copyright 2008 Borland, Caliber, DefineIT and all other Borland brand and product names are service marks, trademarks or registered trademarks of Borland Software Corporation or its subsidiaries in the United States and other countries. Microsoft and all other Microsoft brand and product names are service marks, trademarks or registered trademarks of Microsoft Corporation or its subsidiaries in the United States and other countries. All other marks are the property of their respective owners