whitepaper orchestrating your requirements process

8/6/2019 Whitepaper Orchestrating Your Requirements Process

1/8

Orchestrating YourRequirements Process

How to Stay in Control and

Keep Development Efficient WhenEveryone Isnt Completely Agile

By John Carrillo and Miguel Tam March 2011

WHITEPAPER


2/8

Complete, accurate, managed software

requirements are critical to successful projectoutcomes, but traditional approaches todefining and managing requirements are nolonger enough.

- Dave West and Mary Gerush, Forrester

Just Do It: Modernize Your Requirements Practices(2009)


3/8

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 havealready 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.

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 fromadopting a pure agile approach:

Connected processes: The reality is that development is an end-to-endseries 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 testuntil 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 andmore complex, delivering the customer request in an agile manner is not sostraightforward and simple. What seems like a simple change to a

requirement or code with one self-directed agile team may unknowinglyimpact multiple teams, projects, and products. Reusing features and

technology components across teams is just as difficult.

Regulations and standards: Agile developments frequent changes andlight documentation practices can run counter to a companys policies

regarding regulatory compliance. This is especially true for companies in thedefense, automotive, financial, or medical industries.

Even if your development team has gone agile, it is likely that other internaldevelopment 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 deliverapplications that customers really want and trying to eliminate waste.

Whitepaper: Orchestrating Your Requirements Process 1

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

Agile35%

Waterfall13%

Iterative21%

Informal31%

Even if yourdevelopment team

has gone agile, its

likely that otherdevelopment teams

or partners that youwork with have notcompletely left

behind the old

school methods.


4/8

Delivering What Customers Really Want

Great applications or killer products dont originate within and then emerge

magically from development. Innovation properly emerges from developments closeand 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 costsby 75%.

2Staying 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.

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 lightmanagement of requirements?

The unfortunate truth is that many of the tools that were originally designed to helpdevelopers manage requirements are actually responsible for holding them back from

delivering on customer requirements. According to Forrester, Applicationdevelopment 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 andimpact, 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-endprocess that responds to different customer needs. As the portfolio grows andbecomes 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.

75% More Customer Requirements

161% Faster Development

75% Lower Development Costs

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

2 Whitepaper: Orchestrating Your Requirements Process

Embracing agile

transformation

doesnt mean that

you can ignore thebest practices and

methods formanaging

requirements. In

fact, the opposite istrue.


5/8

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 intodevelopment? How are they prioritized? How do you communicate requirement

changes to all impacted stakeholders? When and how will requirements beimplemented into production?

Leading development organizations have already started orchestrating therequirements lifecycle across all stakeholders, tools, and processes:

A Fortune 500 financial institution will save millions of dollars each year byeliminating siloed tools and wasteful manual processes for eliciting,

managing, and validating requirements. They will also be able to delight theircustomers 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 andaccelerate software development by 50% by automating processes andcreating an electronic change control process across its global teams, multipleplatforms, and distributed projects.

A comprehensive and orchestrated requirements process encompasses five key

phases. These phases can all take place during a single agile sprint, as well as acrossthe 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: This is the process for capturing defects, enhancements, or newrequests across developers, employees, partners, and clients. Thisinformation 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 tocollaborate with stakeholders to determine if refinement, or decomposition, is

necessary. This is the most critical step in the process. Quite often thecomplexity 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

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

Capture Collaborate Confirm Continue Control


IT organizationsthat orchestrate

their requirements

lifecycle can reducedevelopment times

and save millions

each year.


6/8

Organizationsstruggle to defineand deliver sound,

effective software

requirements. Tosucceed, they must

focus on the entire

requirementslifecycle.

- Mary Gerush,Forrester

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 todetermine 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 aboutthe 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 successfulapproach to requirements orchestration will help automate and streamline theprocess for reviews, approvals, and notifications so everyone is on thesame 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 theseteams should best work together.

2. Accommodation of multiple systems: There is no company that canprovide 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 thedevelopment ecosystem. Add customers and partners into the mix, and youll

soon face a smorgasbord of technologies. An orchestrated requirementsstrategy needs to intelligently figure out which tools contribute to the

efficiency of the process, which can be replaced, and how they can all worktogether in harmony.

3. Change management: The Greek philosopher Heraclitus could have beentalking 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 ofunending changes across all their development projects, customers,applications, and tools.

4. Requirements reuse: Organizations should determine how suitable arequirements reuse strategy is for them. The larger they are, the moreprojects they have, and the more teams involved in developing applications,

then the more it makes sense to reuse requirements. Requirements reusewithin 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 requirementsin a centralized repository. Organizations should think about the processes

involved in sharing, changing, inheriting, and communicating requirements

with impacted stakeholders.

5. Traceability: While regulated industries may care a great deal abouttraceability and auditability of requirements, all organizations need to ensurethat their releases meet the needs of their customers. Even in nonregulated

4 Whitepaper: Orchestrating Your Requirements Process


7/8

Endnotes1 Dave West and Tom Grant, Forrester, "Agile Development: Mainstream Adoption Has ChangedAgility", 2010.

2IAG Consulting, Business Analysis Benchmark, 2009.3 Carey Schwaber and Peter Sterpe, Forrester, Selecting The Right Requirements Management Tool Or Maybe None Whatsoever, 2007.

4Mary Gerush, Forrester, Right Tools. Write Requirements. Right On! 2010.

industries, organizations can incur multimillion dollar penalties for missing key

functionality in their applications.

6. Just enough: Just like nobody does agile or waterfall development exactlythe 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 technologiesemployees have already adopted.

Case Study: Orchestrating Requirements with Agility

A company with thousands of employees wanted to go agile in order to develophigher 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 wherethey were located, customers could submit a new feature request via a self-serviceportal. 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 practicesand 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 hybridteams are realizing dramatic results happier customers, greater visibility, increased

reuse, and complete auditability.



8/8

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.

About the Authors

John Carrillo is a thought leader in requirements management and application lifecyclemanagement, 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 regardingtechnologies, 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, systemsengineering, 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 atOracle, CA Technologies, and Ernst & Young Consulting.

whitepaper orchestrating your requirements process

Documents