WHITEPAPER

Orchestrating Your Requirements Process

How to Stay in Control and Keep Development Efficient When Everyone Isnt Completely Agile

By John Carrillo and Miguel Tam

March 2011

Dave West and Mary Gerush, Forrester Just Do It: Modernize Your Requirements Practices (2009)

Complete, accurate, managed software requirements are critical to successful project outcomes, but traditional approaches to defining and managing requirements are no longer enough.

Not Everyone Is Agile

Since the creation of the Agile Manifesto, many development teams have embraced the guidelines of agile. By focusing on the customer and eliminating wasted development effort, developers have seen dramatic improvements in their software development greater visibility and collaboration, lower risk, faster delivery of builds, and increased adaptability. Chances are that your development team has gone agile or is thinking about it. According to a Forrester survey, 30% of developers have already adopted agile, and if the definition of agile development is more broadly interpreted, this percentage goes up to 45%.1 However, the converse of this statistic shows that older methods are still being used by many development teams.

Informal 31%

Agile 35%

Iterative 21%

Waterfall 13%

Figure 1. Almost 2/3 of developers are still not agile (Forrester).

So why havent some of the more traditional methods disappeared in the midst of this agile transformation? There are key issues that are preventing organizations from adopting a pure agile approach: Connected processes: The reality is that development is an end-to-end series of connected processes not all of which can become agile. For example, the processes and best practices associated with testing and QA still remain very linear and waterfall. A common complaint from QA is I cant test until my target environment is ready, no matter how fast my development team gives me a new build drop. Unfortunately, agile purists perceive this QA reality as process inflexibility. Project complexity: When a companys product portfolio gets larger and more complex, delivering the customer request in an agile manner is not so straightforward and simple. What seems like a simple change to a requirement or code with one self-directed agile team may unknowingly impact multiple teams, projects, and products. Reusing features and technology components across teams is just as difficult. Regulations and standards: Agile developments frequent changes and light documentation practices can run counter to a companys policies regarding regulatory compliance. This is especially true for companies in the defense, automotive, financial, or medical industries.

Even if your development team has gone agile, its likely that other development teams or partners that you work with have not completely left behind the old school methods.

Even if your development team has gone agile, it is likely that other internal development teams or partners that you work with have not completely left behind the old school methods. To further complicate matters, development teams are not purely agile or purely waterfall. Almost 75% of development organizations deliberately mix agile and other methodologies.1 Faced with this hybrid landscape, many organizations are back where they were ten years ago, struggling to deliver applications that customers really want and trying to eliminate waste.
Whitepaper: Orchestrating Your Requirements Process 1

Delivering What Customers Really Want

Great applications or killer products dont originate within and then emerge magically from development. Innovation properly emerges from developments close and iterative engagement with the business. Whether developers use an agile or hybrid approach, focusing on how to consistently deliver quality to the customer remains the single most important strategy for delighting customers. In fact, organizations that effectively manage their requirements process deliver 75% more customer requirements, develop projects 161% faster, and reduce development costs by 75%.2 Staying focused on requirements also helps drive software quality, further helping delight customers. Its safe to say that after all these years, the old adage about quality still holds true: The quality of your product is directly related to the quality of your requirements.

75% More Customer Requirements

161% Faster Development

75% Lower Development Costs

Figure 2. Focusing on requirements yields dramatic benefits (IAG Consulting).

Embracing agile transformation doesnt mean that you can ignore the best practices and methods for managing requirements. In fact, the opposite is true.

But if requirements are so critical, why do so many organizations do such a poor job at managing them? Why have decades-old tools failed to resolve the problem? And why has agile still had limited success across the enterprise despite light management of requirements? The unfortunate truth is that many of the tools that were originally designed to help developers manage requirements are actually responsible for holding them back from delivering on customer requirements. According to Forrester, Application development and program management professionals searching for the right requirements management solution often get tripped up by ambitionThis leads them to purchase a tool thats more complex, more difficult to use, and more expensive than is necessary.3 Development organizations also sometimes get stuck in a feature-function analysis focused solely on requirements management that includes factors such as baselining, versioning, linking, and traceability, while ignoring the broader lifecycle of everything they need to do to capture requirements, understand their complexity and impact, and validate features. Instead of focusing solely on requirements management, often the best solution to developments problems is looking at the entire process and how its impacted by change.

Process Before Tools

Whether they are using agile or waterfall, project teams need to define an end-to-end process that responds to different customer needs. As the portfolio grows and becomes more complex, the overall requirements process can also adapt to handle that complexity. The increase in complexity also comes from the different teams, tools, methodologies, and projects that just one customer requirement may impact.

Whitepaper: Orchestrating Your Requirements Process

Defining and managing requirements is often like trying to change the tires on a moving car. Its not surprising that organizations struggle to define and deliver sound, effective software requirements. To succeed, they must focus on the entire requirements lifecycle.4 But organizations face key questions: How do customer requirements come into development? How are they prioritized? How do you communicate requirement changes to all impacted stakeholders? When and how will requirements be implemented into production? Leading development organizations have already started orchestrating the requirements lifecycle across all stakeholders, tools, and processes: A Fortune 500 financial institution will save millions of dollars each year by eliminating siloed tools and wasteful manual processes for eliciting, managing, and validating requirements. They will also be able to delight their customers and appease their compliance department by reusing best practices to deliver applications faster and by maintaining traceability across multiple project teams, partners, and clients. A Fortune 500 healthcare services company will be able to reduce rework and accelerate software development by 50% by automating processes and creating an electronic change control process across its global teams, multiple platforms, and distributed projects.

IT organizations that orchestrate their requirements lifecycle can reduce development times and save millions each year.

A comprehensive and orchestrated requirements process encompasses five key phases. These phases can all take place during a single agile sprint, as well as across the entire lifetime of a new application. Organizations that successfully automate, coordinate, and integrate their teams, tools, and processes across these phases will increase customer satisfaction, reduce rework, and lower costs.

Capture

Collaborate

Confirm

Continue

Control

Figure 3. Five key phases for orchestrating the requirements lifecycle.

Capture: This is the process for capturing defects, enhancements, or new requests across developers, employees, partners, and clients. This information can be captured online via a helpdesk, portal, or online survey or in person through workshops, interviews, and research studies. Models or visual prototypes may be used to help the definition, prioritization, and approval of requirements. Collaborate: Once initial requirements are captured, organizations need to collaborate with stakeholders to determine if refinement, or decomposition, is necessary. This is the most critical step in the process. Quite often the complexity of the change or lack thereof will make the decision easy. Another quick indicator may be its impact on scalability, interoperability, security, or any other -ility the organization views as critical to the business. Confirm: Once requirements are refined and allocated to development tasks and test strategies, teams can start implementing them via code changes, as well as validate the intended functionality. Maintaining links between features, requirements, software configurations, and test scripts is critical for ensuring that requirements are validated and ready for delivery. Continue: A requirement isnt done once its been delivered. Organizations must continue to maintain and monitor the implementation of that
3

Whitepaper: Orchestrating Your Requirements Process

requirement into production. Did it do what the customer was expecting? Have conditions changed to make the requirement obsolete? Are there any critical changes that need to be made due to technology, business, or competitive trends? Control: Throughout the requirements lifecycle, organizations must manage, communicate, and stay in control as the changes that inevitably happen with requirements unfold. If something changes, they need to be able to determine all potential impacts across stakeholders, teams, projects, and products. And the more products and variants an organization has, the quicker the complexity becomes a logarithmic nightmare.

Six Strategies for Orchestrating Requirements

Orchestrating your requirements process and technologies doesnt happen overnight. However, for organizations to successfully manage the entire requirements lifecycle, there are some common success factors that will help them get there faster. 1. Process focus with flexibility: Above all, organizations must think about the end-to-end process of capturing, implementing, managing, and validating requirements. What are the key steps needed to work with all key stakeholders, prioritize and define which requirements are most critical, and deploy requirements into production as quickly as possible? A successful approach to requirements orchestration will help automate and streamline the process for reviews, approvals, and notifications so everyone is on the same page regarding the latest status of customer requirements. Regardless of whether some teams adopt agile and others evolve into a hybrid way of working, organizations need to determine the right processes for how these teams should best work together. Accommodation of multiple systems: There is no company that can provide all of the technologies you need to manage the entire requirements lifecycle. It's clear that the larger the organization, the greater the likelihood that different teams will use different technologies and techniques across the development ecosystem. Add customers and partners into the mix, and youll soon face a smorgasbord of technologies. An orchestrated requirements strategy needs to intelligently figure out which tools contribute to the efficiency of the process, which can be replaced, and how they can all work together in harmony. Change management: The Greek philosopher Heraclitus could have been talking about customer requirements when he said, The only constant is change. In order to successfully navigate the requirements lifecycle, organizations need to be able to see, understand, and manage the impact of unending changes across all their development projects, customers, applications, and tools. Requirements reuse: Organizations should determine how suitable a requirements reuse strategy is for them. The larger they are, the more projects they have, and the more teams involved in developing applications, then the more it makes sense to reuse requirements. Requirements reuse within an agile strategy has also become an increasingly painful topic for many organizations that are trying to deliver more and more frequent releases. However, requirements reuse isnt just searching for requirements in a centralized repository. Organizations should think about the processes involved in sharing, changing, inheriting, and communicating requirements with impacted stakeholders. Traceability: While regulated industries may care a great deal about traceability and auditability of requirements, all organizations need to ensure that their releases meet the needs of their customers. Even in nonregulated

Organizations struggle to define and deliver sound, effective software requirements. To succeed, they must focus on the entire requirements lifecycle. - Mary Gerush, Forrester

2.

3.

4.

5.

Whitepaper: Orchestrating Your Requirements Process

6.

industries, organizations can incur multimillion dollar penalties for missing key functionality in their applications. Just enough: Just like nobody does agile or waterfall development exactly the same way, there is no single one-size-fits-all solution for managing a requirements process. Organizations should look for just enough workflow and process functionality focusing on processes, best practices, and technologies that give them the right amount of functionality they need. Instead of a rip and replace strategy to consolidate disparate systems, organizations should orchestrate the existing processes and technologies employees have already adopted.

Case Study: Orchestrating Requirements with Agility

A company with thousands of employees wanted to go agile in order to develop higher quality applications faster. However, it feared that agiles documentation philosophy would run counter to regulatory standards that the company had to meet, especially considering that they managed thousands of requirements. Furthermore, not all of its teams, partners, and customers were on board with agile, so they had to find a strategy that could accommodate all stakeholders. This company developed a comprehensive process for the entire requirements lifecycle from initial customer requirement to release into production. No matter where they were located, customers could submit a new feature request via a self-service portal. That new request would get routed as a business requirement to the appropriate business analyst for review. Upon approval, it would get decomposed into functional requirements. An agile team could then be notified and further decompose those functional requirements into agile tasks. Orchestrating the requirements lifecycle was critical. As agile and waterfall teams went through their tasks, or customers updated their requests, an orchestrated process ensured that all participants were kept in the loop as to the latest status and impact to their work.

Conclusion
Embracing agile transformation doesnt mean that you can ignore the best practices and methods for managing requirements. In fact, the opposite is true. Development teams that wish to delight their customers and work as efficiently as possible need to embrace orchestration of their end-to-end requirements process. Companies who have already begun orchestrating the entire requirements lifecycle across hybrid teams are realizing dramatic results happier customers, greater visibility, increased reuse, and complete auditability.

Endnotes
1

Dave West and Tom Grant, Forrester, "Agile Development: Mainstream Adoption Has Changed Agility", 2010. 2 IAG Consulting, Business Analysis Benchmark, 2009. 3 Carey Schwaber and Peter Sterpe, Forrester, Selecting The Right Requirements Management Tool Or Maybe None Whatsoever, 2007. 4 Mary Gerush, Forrester, Right Tools. Write Requirements. Right On! 2010.

Whitepaper: Orchestrating Your Requirements Process

About the Authors

John Carrillo is a thought leader in requirements management and application lifecycle management, with over 20 years experience in the commercial software and manufacturing industries. In his current role at Serena Software, he provides strategic counsel to organizations regarding technologies, process, and best practices for application development and delivery. A former Senior Director at IBM Rational and Telelogic, Mr. Carrillo has deep expertise in process consulting, systems engineering, and product development. Miguel Tam has over 20 years of experience in the enterprise software and manufacturing space, helping high-tech, cleantech, and services firms launch successful new products. Mr. Tam has deep expertise in software development practices and new product development, including experience at Oracle, CA Technologies, and Ernst & Young Consulting.

Copyright 2011 Serena Software, Inc. All rights reserved. Serena is a registered trademark of Serena Software, Inc. All other product or company names are used for identification purposes only, and may be trademarks of their respective owners. Revised 15 March 2011. Document ID: WP-RQM-031511.