Overcome barriers to good req mgmt

Practical IT Research that Drives Measurable Results

1Info-Tech Research Group

Overcome the Barriers to Good Requirements Management

“As a CIO, if you do not understand your business requirements process, quit.”-CIO, Information Services Organization

Introduction

Info-Tech Research Group 2

• Implementing solutions that enable and support business operations and goals is the obvious mandate for IT organizations.

• However, given IT’s reputation for poor project quality, overruns and rework, it is clear that fulfilling this mandate successfully is far more difficult than it appears.

• A critical cause of this difficulty is the failure to understand business requirements completely and to translate those needs successfully into technical functionality that drives value.

• In this research report, Info-Tech has outlined successful practices for business requirements management gathered from the experiences of your peers. Case studies demonstrate how to overcome common barriers to success to deliver technology solutions that enable the expected business results.

• Through case studies, IT Leaders share their tactics and techniques for requirements management in a way that will enable you to adopt similar solutions and realize similar benefits.

• This storyboard will help you:• Quickly assess the health of your requirements gathering practices. • Objectively identify the challenges you need to overcome.• Identify and select tactics for improving your organization’s requirements

gathering capability.

Executive Summary


• Most IT leaders recognize that poor project performance leads to management dissatisfaction and disappointment. However, many miss the link between poor requirements management and project performance. They focus more on project execution instead of delivering a solution that really fits the needs of the business.

• This mistake becomes a vicious cycle resulting in poor quality, overspending, rework, and damage to IT’s reputation.

• To correct this problem, IT leaders need to help their organizations adopt four key principles of business requirements management:

• Become intimate with how the business operates – information needs, activities and outcomes.

• Determine what the business needs from IT – information and functionality that will drive efficiency, speed, and improved outcomes.

• Validate IT’s understanding of requirements – continuously communicate and test that the intended solution will achieve expected results.

• Recommend alternate solutions – proactively suggest ways where IT can deliver less costly, more efficient solutions or more effective results than otherwise envisioned.

• Adopt tactics practiced by your peers to establish these principles in your organization:

• Build a Business Analysis competency.• Employ an Agile development/implementation methodology.• Adopt standards for managing changing requirements.• Resolve conflicting stakeholder needs.


Case Studies and Best Practices

Business Acumen

Understanding Requirements

Validating Requirements

Assessing Requirements

Business Requirement

s

Connect Project Success with

Good Requirements

Understand the Impacts of Poor Requirements

Perform a Requirements Health

Check on Your Organization

Less than 9 out of every 20 projects are considered successful, damaging the credibility of many IT

organizations.

A successful track record of project delivery is vital for building credibility and reputation of the IT organization and the IT leader.

With their credibility on the line, IT leaders need to take action to ensure that good requirements management practices are in place, projects are being completed satisfactorily and IT is respected as a partner in achieving business objectives.

Info-Tech Research Group 5Source: Info-Tech Survey. Interviews with Info-Tech Panel members, N= 250.

Project success is defined differently depending on the organization, but staying on time and on budget are always considerations when evaluating the

success of a project.

A large majority of IT projects don’t meet timelines or stay on budget, and 62% of projects exceed both time and budget.

Over Budget

84%

Exceed Time

Estimate

88%

Poor requirements are cited as a major factor in both project delays and budget overruns

% of IT leaders that state poor requirements lead to delayed and over budget projects

Exceed Time

Estimate

Series

90%Over budget

93%

IT leaders cite poor requirements management as the leading cause of project failure.


The net result of a “poor requirement”?

Requirements gathering is the most important stage in the project process. If you don’t collect those requirements properly, if business’s expectations are one thing, and yours are something else, the project is going to fail.

-CIO, Real Estate

“

”Poor requirements come in a variety of forms, but they all fail to adequately specify the actual needs of end users and/or stakeholders. The net result of a poor requirement is that the solution will either fail to have a capability that is needed or it will include features that are unnecessary. In both cases, poor requirements run the risk of inflating the cost of the project.

Poor requirements is the most cited cause of project problems

For an overview explanation of requirements management, refer to Appendix I.

Source: Info-Tech Survey. Interviews with Info-Tech Panel members, N= 250.

Poor requirements is cited as the major contributor to project problems 23% of the time, which is more than all other issues combined.

Employ tactics to effectively gather requirements to avoid

post-production rework.


On average, 26% of projects require post-production rework – most of which could have been avoided with an improved requirements gathering process.

When you look at statistics for why projects fail or why organizations struggle, it’s because they spend more time redoing stuff than actually doing it right the first time. -President & CEO, IIBA

We consistently see that defects in requirements – requirements that are wrong, don’t meet the business need, ambiguous, etc. – take up about 20 to 30 percent of the effort on an average project. That’s a huge amount of overhead from poor requirements technique.

-VP Professional Development, International Institute of Business Analysis

”

“

Identify stakeholders: single out the knowledge experts

Set up individual and group interviews: probe for the whats and whys, not the hows.

Define organizational strategy and project goals: meet with business leaders to understand their objectives

Use elicitation techniques to get out the five W’s: employ use cases and prototypes

Separate the needs from the wants: be the arbiter and make recommendations

To minimize cost overruns, catch mistakes early – a correction during the design phase costs 1% of a

correction post-release.

The importance of strong requirements is aptly illustrated by the maxim that a defect found in design costs $1 to correct, one in testing costs $10 and one in production costs $100 (Barry Boehm, Software Engineering Economics).Further, a defect that goes into production undetected can result in lost business productivity, lost sales or lost reputation.


Architect’s adage: "I can move lines on a page very easily, but it is

tremendously expensive to move brick walls.”

Projects have requirements that must be documented and managed for legislative compliance.Large, complex projects that result in many requirements documents.Smaller projects with complex or shared requirements.Projects with many stakeholders involved in the requirements definition.Projects where requirements remain dynamic e.g. development of a new product or process vs.. a well-understood change to an existing system.Project team is geographically spread out, making it difficult to communicate changes to requirements.Maintenance/enhancements projects that start with net new requirements.

Projects have requirements that must be documented and managed for legislative compliance.Large, complex projects that result in many requirements documents.Smaller projects with complex or shared requirements.Projects with many stakeholders involved in the requirements definition.Projects where requirements remain dynamic e.g. development of a new product or process vs.. a well-understood change to an existing system.Project team is geographically spread out, making it difficult to communicate changes to requirements.Maintenance/enhancements projects that start with net new requirements.

Projects possessing the following characteristics demand strong requirements processes to avoid escalating costs.

Projects possessing the following characteristics demand strong requirements processes to avoid escalating costs.

Recognize the need for trust and credibility with business partners.


In organizations today it is common to hear IT staff talking about "the business“, and to hear IT’s internal and external customers referring to IT as “computer geeks”. Its as though both exist in separate worlds where common language isn’t spoken.

In reality, until both sides can develop alignment and synergy, the organization cannot remain in business without IT for very long. And without the business, IT’s rasion d’etre evaporates.

IT needs to spearhead the drive to forge a partnership with their customers. The first hammer stroke is working with stakeholders to develop best practices in business requirements management in order to build trust and credibility.

Info-Tech Insight:

Don’t fall into common requirements management traps. Follow the tips and tricks of your peers to learn what not

to do.


Before you begin gathering requirements, have an open discussion with the project manager to define roles, expectations and the difference between a project issue and a requirements issue.“We used to jump directly into projects - the BAs, the PMs and the stakeholders. I realized very quickly that project managers are a fairly direct, controlling breed because they have to be, and that you could easily have conflict between senior business analysts and the PMs. For example, we have had situations where there was pretty high tension, because a project manager felt that they should be the only person talking to the sponsors. For a long time, I didn’t really have the discussion with the project manager around, ‘This is how I see my role or the analyst’s role, and this is how we see the PM role, and here’s when it’s a requirements issue and here’s when it’s a project issue. How do you want to handle communication to the business?” You have to have that open discussion or the two are going to just run against each other. We also started defining the difference between a project issue and a requirements issue, so we knew who needed to be involved if a problem arose. This upfront, open conversation helped us to develop a sense of peer leadership instead of hierarchy on projects.”

-Senior Systems Analyst, Insurance Industry

The DON’Ts… The DO’s…Don’t leave role of BAs versus role of PM up for debate.

Clearly define the role and expectations of the BA, the PM and the stakeholders.

Don’t involve the technical analysts too early. Bring the developers and the designers into the conversation after the project objectives are defined.

Don’t invest too much time, money and sweat equity in mockups. If they don’t work out, you may demoralize your IT group.

Use mockups but keep them simple. They are meant to seek out issues and ideas, not offer a completed solution.

Don’t forget to involve your stakeholders in review and assessment of requirements.

Maintain dialogue and feedback loop with your stakeholders. Continuously assess and validate the requirements with them.

Define the objectives of the project before trying to solve the problem. Keep developers away until objectives are

defined.


“I have let my technical analysts become overbearing on the requirements process before, and they start getting into what they think is easy to achieve as opposed to what’s needed. Introduction of the technical analysts too soon will get the group into solving a problem before they’ve defined what it is you’re actually trying to do. I think this might be a guy thing - because I do this too. For example, my wife comes home and she’s got this picture and asks me to hang it. Instead of asking where are we going to put it, how high should I hang it, how does this look, I’m immediately thinking, ‘I get to use this tool,’ and ‘oh, I don’t have any of those hooks. I’d better go to Home Depot.’ I’m immediately off solving the problem. In this analogy, the IT people are me, and they have to be brought back to the part where they’re just listening to the business user (my wife), talk about her requirements and think through those issues. She’s not going to walk in and say ‘I want it right here.’ It’s going to change. That requirement will move. You want to get the IT guys in at some point, but how do you control them so they don’t solve the problem too soon? It can ultimately lead to bad placement on the wall.”

-CIO, Energy Industry

Assess the health of your organization’s requirements gathering practices to highlight areas for improvement.


Signs that your requirement management process needs improvement:

Perform your own health check.

Use the “Business Requirements Management Health Assessment Tool” to assess the need for improvement.

Answers

1

Project deliverables are often late because the business requirements were incorrect and we had to go back and redo the requirements/design and development. Somewhat disagree

2Business stakeholders sometimes disagree on what the requirements should be. Somewhat disagree

3In our organization requirements often change during the course of the project. Strongly disagree

4Post production rework or new sprints have to be scheduled to compensate for poor requirements in previous phases/sprints. Somewhat disagree

5IT doesn’t have a solid understanding of how the core business operates. Somewhat disagree

6Changing requirements during the course of the project contribute to project budget overruns. Somewhat disagree

7IT has a problem understanding the language the business uses when they describe their requirements Somewhat disagree

8

The business stakeholders are not receptive when IT provides alternate solutions that address system design constraints or will deliver better business value. Disagree

9Testing results often indicate that the original requirements weren't correct and we have to go back to the requirements phase. Somewhat disagree

10We have difficulty identifying the stakeholders we should be speaking to when gathering requirements. Strongly disagree

11Users signoff on the requirements, but they continue to make changes to the requirements. Disagree

12Once the business case is approved, users pile the requirements on - with the result that the business case becomes untenable. Somewhat disagree

13Solutions are over-engineered resulting in a misalignment of the solution to the actual busienss need. Disagree

14Solutions are under-engineeried - too simplistic and the result isn't really effective in delivering desired business outcomes Somewhat disagree

15

Usability is not suitable - functionality and data requirements may be right, but the system requires a genius level to operate or is far too simplistic for the operators. Strongly agree

Questions

Read the following statements and select the answer that best describes your IT department's state.

Business Requirements Management Health Assessment Questions

http://www.infotech.com/research/business-requirements-management-health-assessment-tool

http://www.infotech.com/research/business-requirements-management-health-assessment-tool


Case Studies and Best Practices

Business Acumen




Business Requirement

s

Connect Project Success with

Good Requirements

Understand the Impacts of Poor Requirements

Perform a Requirements Health

Check on Your Organization

There are four principles that support effective requirements management, leading to higher levels of

project success.


• Most business units lack the skills to draw out their own requirements and document them in such a way that designers can then build systems. The Business Analyst provides that linkage to documenting and understanding their requirements.


• Understanding the business goals and objectives as well as their workflows and processes is vital for IT to build rapport with the stakeholders , understand their drivers and deliver quality solutions.

Business Acumen

• Once specified, validating the requirements is a must, not just once but throughout the project. Goals and objectives may change, priorities shift or misunderstandings occur and it is important that effort is spent ensuring teams are focusing on the right things.


• IT’s responsibility goes beyond simply delivering what the client asks for. For reasons including technical constraints or anticipated business value, the initial requirements may not be suitable. IT must be able to develop and recommend alternative solutions .


Follow the advice in the following case studies to overcome your own requirements management

challenges.Each case study documents:• A requirements management challenge faced by an organization with a specific company profile and project type. • The techniques for overcoming the challenge and the lessons learned.

Following the case study, • Alternate solutions are presented, based on different combinations of company profile and project type. • Details on best practice tactics are provided.• Additional common requirements barriers that are faced by IT organizations are listed, and advice from your peers on how to overcome these barriers.

Project Type

System Replacement – A new system is being developed to replace an existing system.System Integration (e.g.: M&A) – Two existing systems are being integrated.System Modifications – Enhancements are being made to an existing system.Third Party Solution – Commercial off the shelf (COTS) software is being purchased.

Company Profile

Small Enterprise – an organization with fewer than 10 IT staffMedium Enterprise – an organization with 11-25 IT staffLarge Enterprise – an organization with more than 25 IT staff


Business Acumen



A variety of techniques develop a thorough understanding of business operations, leading to improved project

performance.

Percent of organizations with projects over budget morethan 30% of the time and over time 60% of the time

Percent of organizations with projects on time and on budget

Becoming intimate with business operations leads to, on average, a 26% improvement in project on-time, on-budget performance.

67%

Job Shadowi

ng

33%

75%

Use of Busines

s Process Mappin

g

61%

75%

Review Existing Business

Documentation

67%

85%

Use BAs Recruited from

Business

39%

Techniques for developing Business Acumen:

Job Shadowing – develop a program for IT staff to rotate through various business units, becoming familiar with roles, functions and operations.

Recruit BA’s from the Business – Identify “super users” with excellent organizational, problem solving and relationship skills. Assign them the role of Business Analyst.

Review existing documentation - Track down any existing documents or manuals that describe current systems and processes. This step could save a lot of time. Be sure to verify the documents' accuracy with stakeholders.

Use business process mapping – In the absence of existing documentation, conduct interviews and workshops with stakeholders and map out the business workflows, inputs, outputs and processes.

Techniques to Gain Business Intimacy


A lesson in understanding business operations: A manufacturing company goes analog.


Eliciting information… With non-traditional methods…

Resulted in clear understanding of workflows.

++ ==

Avoid massive white board sessions and lots of process flows.

Get them to convey, share and collaborate on information without relying on the technology.

Give everybody a role in the exercise and have them play a role they normally don’t. Get them out of their comfort zones.

Combine tried and true with innovative methods of drawing out information.

Avoid massive white board sessions and lots of process flows.

Get them to convey, share and collaborate on information without relying on the technology.

Give everybody a role in the exercise and have them play a role they normally don’t. Get them out of their comfort zones.

Combine tried and true with innovative methods of drawing out information.

The BA created an environment that helped the blue collar guys from the shop floor really get into the requirements process in a deep way.

Senior board members became engaged and very interested in how the exercise played out.

The process mapping exercise enabled the BA to learn the workflows and made it possible for the stakeholders to convey how they work to IT.

The BA created an environment that helped the blue collar guys from the shop floor really get into the requirements process in a deep way.

Senior board members became engaged and very interested in how the exercise played out.

The process mapping exercise enabled the BA to learn the workflows and made it possible for the stakeholders to convey how they work to IT.

What Happened? The stakeholders opened up…

What did they learn?

Case ScenarioSystem ReplacementMedium Enterprise

•IT was working on a new shop floor demand system and needed to learn current workflows•The system will produce a bill of materials (everything needed to build the product). •Conducted some interviews and feedback sessions but had a hard time getting the shop floor folks to come to the table and talk about their operations.

•IT was working on a new shop floor demand system and needed to learn current workflows•The system will produce a bill of materials (everything needed to build the product). •Conducted some interviews and feedback sessions but had a hard time getting the shop floor folks to come to the table and talk about their operations.

•BA created a large piece of plywood, and wire tied all the tools needed for this particular job and graphically represented everything that was required to go into several job steps. •A tabletop walkthrough was conducted with shop floor workers that clarified for the stakeholders exactly what they do in an analog way. •Made it easier to translate the physical into the logical.

•BA created a large piece of plywood, and wire tied all the tools needed for this particular job and graphically represented everything that was required to go into several job steps. •A tabletop walkthrough was conducted with shop floor workers that clarified for the stakeholders exactly what they do in an analog way. •Made it easier to translate the physical into the logical.

•The preliminary interviews provided a basis, with gaps, that were then filled in with the table top business process mapping sessions.•These tabletop sessions provided stakeholders with a better way to articulate their processes and provide IT with a understanding of those processes.

•The preliminary interviews provided a basis, with gaps, that were then filled in with the table top business process mapping sessions.•These tabletop sessions provided stakeholders with a better way to articulate their processes and provide IT with a understanding of those processes.

A lesson in understanding business operations:

What could IT leaders do in different scenarios?


•Recruit BAs from the business target business units. Look for “Super Users” who have extensive business and organizational knowledge, and good relationship skills and if possible, have worked with IT in the past. •Conduct BA facilitated tabletop workshops with the target business units to walk through their workflows. Role play, using index cards instead of computers to separate what they do (their jobs) from how they do it (the technology).

•Recruit BAs from the business target business units. Look for “Super Users” who have extensive business and organizational knowledge, and good relationship skills and if possible, have worked with IT in the past. •Conduct BA facilitated tabletop workshops with the target business units to walk through their workflows. Role play, using index cards instead of computers to separate what they do (their jobs) from how they do it (the technology).

System Integration/Large EnterpriseSystem Integration/Large Enterprise

Case ScenarioSystem ReplacementMedium Enterprise

Commonly, the business will not be able to fully articulate strategy and goals. Avoid premature project launch until

these key linchpins are in place.


Barrier Solution

•Getting the business to come to the table with a good sense of their strategy and goals and how the project fits into those.

“If I had to put a number on it, I think the business typically comes to us with anywhere from 60 to 70 percent complete in their total view of what could possibly happen or what could possibly be needed by this tool.” – CIO, Energy Industry

•Don’t start the requirements process until the business defines their business goals, and objectives. Continue to validate these throughout the project.•Demand a sense of readiness from the business and if they don’t demonstrate this, assist them in getting there. Facilitate consensus building and information sessions. Make sure senior management is on board to support you.

“On one project I worked on, we stopped the project. I held one facilitative session and realized that the business had no blessed clue about basic things. Sometimes the best project you do is the one that you don’t do.” -Senior Systems Analyst, Insurance Industry

•Identifying a project owner and getting that individual to agree to sign up for the accountability.

“I think one of the biggest challenges we have is that for most projects, nobody seems to understand who the business owner is or who it should be.” -Project Manager, Insurance Industry

•Ensure project sponsorship is in place. Accountability or “one throat to choke” is essential to project success. Typically, the funder of the project is the sponsor. If funding isn’t an issue, then it will be the senior manager of the primary stakeholder.

“If I’m actually putting my dollars into a particular initiative, I’m going to take ownership for it more likely than if someone’s just paying for it and I don’t have that personal investment in it. That’s sort of high level organizational change, but it’s a very, very critical one.” -President & CEO, IIBA

Assigning a Business Analyst improves the likelihood of the project being on budget by 5% and on time by 19%.


Skilled BAs contribute to the success of projects by improving requirements management.

Info-Tech Insight:

Only 21% of Info-Tech clients assign a Business Analyst to every project. While recognizing the value, IT leaders are often constrained by staffing budgets and skills gaps in their organization.

Assign a BA

Do not assign BA

Assign a BA

20%

Project

Over Budget

14%

15%

Project

Overtime33%

Do not assign BA

Organizations that do not assign a BA to all projects are 19% more likely to miss project deadlines.

Whether called Business Analysts, Business Systems Analysts or Systems Analysts there is a growing consensus on the definition of the role.

Business Analyst responsibilities include:identifying business needs helping to determine solutions to business problemsrequirements developmentrequirements management

BA activities include the elicitation, analysis, validation and documentation of business, organizational and/or operational requirements.


Assign the Business Analyst as the pivot, ensuring understanding between both IT and the business


They need to have a variety of characteristics, but at their heart, underlying it all, there has to be a little geekette or geek in them.

-CIO, Financial Services Industry”“

They have to be able to speak business speak, and translate that into speak that the developers and architects can make use of. They have to take technical issues to the business decision makers with options, in a way they can understand – so translate back from techie to business as well.

-Senior Systems Analyst, Insurance Industry

They have to listen to what the business is trying to do, not be judgmental about that, and then come up with ideas about how that could be accomplished.

-IT Leader, Electric Energy Provider

”

”

“

“Info-Tech Insight:

You are not doing your job if the BA feels they are constantly being dumped on. The BA can be the quarterback, but not the whole team .

Make the BA role a formal one.

Use the Info-Tech “Business Requirements Analyst” job description template to create the role in your organization.

http://www.infotech.com/research/business-requirements-analyst

Encourage training for existing BAs and require it of new ones.


Frank, friendly and firmAnalyticalSuperior oral and written communication skillsCombination of business and technology skills and ability to speak both languages fluentlyFlexibility and patience to work with a wide range of business and technical individuals with varying personalities and agendas. Ability to ask the right questions, and questions behind questionsAbility to think logically in stepsAbility to coordinate people and their opinions – deal with the politicsStrong business advocatesStrong relationship managersHave a passion for the solutionGood listenerOpen to change

Frank, friendly and firmAnalyticalSuperior oral and written communication skillsCombination of business and technology skills and ability to speak both languages fluentlyFlexibility and patience to work with a wide range of business and technical individuals with varying personalities and agendas. Ability to ask the right questions, and questions behind questionsAbility to think logically in stepsAbility to coordinate people and their opinions – deal with the politicsStrong business advocatesStrong relationship managersHave a passion for the solutionGood listenerOpen to change

The DNA of a Good BAThe DNA of a Good BA

•Use the apprenticeship model to give the BA a hands on, practical training experience. Assign the BA to an individual who has demonstrated success.

•Hold requirements gathering lunch and learns, where you talk about industry trends and peers’ best practices.

•Partner with a local college to run ongoing classes.

•Use current industry sources such as the IIBA Body of Knowledge to understand the knowledge areas and skills required for business analysis.

•Look for training programs that are in line with professional certification. Encourage certification as a means of professional growth (more information on following slide).

Some training techniques that have proven successful:

For more information on formal certification of the BA, refer to Appendix I.

http://www.iiba.com/bok.cfm

Debate your alternatives when recruiting BAs – success can be achieved with BAs from the business or from IT.


There is ongoing debate as to whether BAs should be recruited internally, externally or a mixture of both. With pros and cons for each argument, in the end, it comes down to

the skills and competencies of the individual, and how they are cultivated in the organization.

“They’re bridging the gap between the technical part of IT and the actual process of the business. “

“They certainly don’t have any chops that would allow them to have any level of discussion that would leave the technical people wailing away thinking of them as a credible interface.”

Implement a BA reporting structure that will best enable a productive relationship with the business.


There are two schools of thought when it comes to where a BA should report and the right answer depends on the organization. Some advocate for the BA reporting to a business leader, others, that they report to IT. Structure the organizational reporting to provide the business with the least amount of angst, however indicate the accountability of the role to work collaboratively with IT.

Report to the Business

Report to IT

Pros The business feels that they are well represented.The BA has the working knowledge of business processes.

•BA is aware of technical constraints that may affect requirements.

Cons •Disconnect from IT may mean difficulty translating requirements for IT.

•Business may have the perception that the BA has an IT bias. •BA becomes disconnected with current business processes.

…for truly exceptional BAs the reporting structure is of little importance, as they can navigate the political structures and needs of either IT or the business side of the house by exercising advanced relationship and facilitation skills. Reporting structure is frequently a result of corporate "empire building"... and therefore has little association with actual business value. -Program Manager, Communications

”

“



Accurately determine and describe the informational, functional and usability needs of the business to define

good requirements.


72%

Business & IT

participate in

requirements

prioritization

88% 87%

Assign a BA to all

projects

Employ Steering

Committees

Document all

requirements using

standard templates

72%

Organizations use the following tactics to define and understand business requirements to ensure understanding.

Steering Committee:Final decision maker for requirements conflicts.

Stakeholder engagement:Agreement on requirement priority ensures that critical functionality does not get left on the table.

Business Analyst:The BA models business requirements for both stakeholder and IT consumption.

Documentation Standards:Agreed upon standards for communicating requirements ensure that misunderstanding is minimized.


A lesson in understanding business needs: An insurance company unites diverse

stakeholders.

Info-Tech Research Group

Getting to the right stakeholders…

By meeting on their terms…

Resulted in agreement on

requirements…•Judgments from a class-action lawsuit were laid against the organization that required several things be offered to their client base in terms of restitution. •The impact was to virtually every individual life insurance system on the books. •All the key stakeholders were unavailable due to projects that were more value and profit generating.

•Judgments from a class-action lawsuit were laid against the organization that required several things be offered to their client base in terms of restitution. •The impact was to virtually every individual life insurance system on the books. •All the key stakeholders were unavailable due to projects that were more value and profit generating.

•Analysts went to the business units to do the process work•They ran focus groups and interview sessions with front-line people .•Once a week, management and business reps were brought in for a run through.• All issues were brought to the table, organized and laid out, in a fashion that enabled decision making and charting progress.

•Analysts went to the business units to do the process work•They ran focus groups and interview sessions with front-line people .•Once a week, management and business reps were brought in for a run through.• All issues were brought to the table, organized and laid out, in a fashion that enabled decision making and charting progress.

++ ==

•IT facilitated and provided clear definitions of the requirements, issues and decisions. •Frequent feedback, follow up and communication made it easy for the frontline, management and legal stakeholders to come to agreement without feeling as though they were giving something up.

•IT facilitated and provided clear definitions of the requirements, issues and decisions. •Frequent feedback, follow up and communication made it easy for the frontline, management and legal stakeholders to come to agreement without feeling as though they were giving something up.

Be respectful enough to involve all the stakeholders and decision-makers.

Know who your stakeholders are. Frontline staff have a different view than management.

You’ve got to know how you’re going to involve them, they may need different approaches.

Plan for handling requirements risk, conflict and issues.

Be respectful enough to involve all the stakeholders and decision-makers.

Know who your stakeholders are. Frontline staff have a different view than management.

You’ve got to know how you’re going to involve them, they may need different approaches.

Plan for handling requirements risk, conflict and issues.

Including system developers in the requirements work and running requirements and design concurrently, shortened timelines.

Involving front-line people, middle and senior management surfaced and resolved issues quickly.

An ongoing issue and decision log to document conflicts and resolution was invaluable.

Including system developers in the requirements work and running requirements and design concurrently, shortened timelines.

Involving front-line people, middle and senior management surfaced and resolved issues quickly.

An ongoing issue and decision log to document conflicts and resolution was invaluable.

What Happened? Stakeholders worked together…

What were the lessons learned?

Case ScenarioSystem ModificationsLarge Enterprise

28

A lesson in understanding business needs: What could IT leaders do in different

scenarios.


Case ScenarioSystem ModificationsLarge Enterprise

•Get the right mix of people:•One or two high-level decision makers from the affected business units •Business process experts from all affected areas •Financial analysts, to determine the ROI of the package with the help of the business experts •“Hired gun” experts in each package who can get a rough handle on implementation costs. Do not leave this job to the package salesperson! •Experts who have a good grasp of current data structures, and data that must be converted to the new system •Select technical staff who will be participating in the implementation

•Get the right mix of people:•One or two high-level decision makers from the affected business units •Business process experts from all affected areas •Financial analysts, to determine the ROI of the package with the help of the business experts •“Hired gun” experts in each package who can get a rough handle on implementation costs. Do not leave this job to the package salesperson! •Experts who have a good grasp of current data structures, and data that must be converted to the new system •Select technical staff who will be participating in the implementation

Third Party Solution/Medium EnterpriseThird Party Solution/Medium Enterprise

•Through interviews and small groups, determine who the management and frontline stakeholders will be. Keep meetings with management and staff together informal so the frontline staff will speak up.•Alternatively, collect information from one group and validate with the other. BA acts as the go between for the groups.•When users try to provide solutions instead of requirements (i.e. “we need a system to do x, y and z”) take them back from the “how” to the “what” they are trying to do and “why”. Don’t dismiss their recommendations, but encourage them to work it through for clarity.

•Through interviews and small groups, determine who the management and frontline stakeholders will be. Keep meetings with management and staff together informal so the frontline staff will speak up.•Alternatively, collect information from one group and validate with the other. BA acts as the go between for the groups.•When users try to provide solutions instead of requirements (i.e. “we need a system to do x, y and z”) take them back from the “how” to the “what” they are trying to do and “why”. Don’t dismiss their recommendations, but encourage them to work it through for clarity.

System Replacement/Medium EnterpriseSystem Replacement/Medium Enterprise

Use specialized techniques to elicit requirements in ways that avoid the inherent limitations of stakeholder self-

reports.


1

Have at least one collaborative sessionHave at least one

collaborative session

Group sessions sort out disagreements between stakeholders. They encourage creative input as individuals become inspired by the ideas of others.

Group sessions sort out disagreements between stakeholders. They encourage creative input as individuals become inspired by the ideas of others.

Don’t follow the process blindly

Don’t follow the process blindly

Each interaction with a stakeholder is an opportunity to better understand their needs. Think critically about the information they provide and ask follow up questions.

Each interaction with a stakeholder is an opportunity to better understand their needs. Think critically about the information they provide and ask follow up questions.

Use more than one elicitation technique to complement differences in each method. Techniques are outlined in the following slides.

Use more than one elicitation technique to complement differences in each method. Techniques are outlined in the following slides.

Use a variety of elicitation techniques.

Use a variety of elicitation techniques.

When choosing requirements techniques, keep the following in mind:

4 5 6 6

Choose at least one face-to-face technique.Choose at least one

face-to-face technique.Interaction with end users through shadowing, prototyping, interviewing, or structured demonstrations can reveal valuable non-verbal information (e.g. reactions, difficulties, etc.) about requirements.

Interaction with end users through shadowing, prototyping, interviewing, or structured demonstrations can reveal valuable non-verbal information (e.g. reactions, difficulties, etc.) about requirements.

Select an audience that is representative of key

interest groups.

Select an audience that is representative of key

interest groups.

Even a seemingly perfect combination of elicitation techniques can be undermined if the process ignores critical stakeholders. Missing stakeholders means missing requirements.

Even a seemingly perfect combination of elicitation techniques can be undermined if the process ignores critical stakeholders. Missing stakeholders means missing requirements.

Don't let the elicitation process eclipse project deadlines. Limit the number of techniques you choose to 2 or 3. Any requirements that are missed can be caught when testing prototypes.

Don't let the elicitation process eclipse project deadlines. Limit the number of techniques you choose to 2 or 3. Any requirements that are missed can be caught when testing prototypes.

Avoid elicitation paralysis.

Avoid elicitation paralysis.

2 2

3 3

See Appendix I for a detailed list and descriptions of elicitation techniques.

IT and the business are partners in developing the requirements, but IT assumes primary responsibility for

the quality.


•A good requirement describes what the future state of business operations look like – from the perspective of business process, people abilities, information, functionality and outcome. •A good requirement is SMART. Approach the requirements gathering process with these characteristics in mind:

Specific – What exactly do we want this to do?

Measurable – How will we know we have met expectations? Achievable – Can we deliver within existing constraints of time, budget and technical performance?Results – How will this requirement improve or change business operations?

Timely – What is the “best-before date” for this requirement?

Ensure requirements meet the standards of quality.

For qualities of highly usable requirements and guidance on requirements gathering and documentation, use the Info-Tech “Characteristics of Requirements Checklist”.

http://www.infotech.com/research/characteristics-of-requirements-checklist

dwilcox

Provide the link to the "Business Requirements Management Characteristics Checklist" which is part of this solution set content.

Missed stakeholders and conflicting stakeholder perspectives are two key barriers that must be overcome.


Barrier Solution•Achieving engagement from all the appropriate stakeholders in the process and gain a commitment of time and effort.

“One of the still truths about requirements gathering is most of wrong requirements are actually missed requirements, and most missed requirements are because of missed stakeholders.” – IT Leader, Insurance Industry

•Identify the owner so they are accountable for the final outcome. For those individuals who are not owners, clarify from the beginning of the project what their roles and responsibilities are. Clearly explain why each person is involved, what you expect of them, how much time it may take, and how they will be evaluated. Put some structure around their involvement expectations and be prepared to negotiate as any pushback may be relevant.

•Managing conflicting stakeholder groups and opinions.

a) Dealing with the difference in perspective between upper-management (who has a view of the future) and front-line workers (who have a good picture of how things work today.)

b) Conflicting requirements between different business units

•A big part of the BA’s role is to overcome this challenge. The BA should have no personal investment in the solution - act as a neutral referee. •Go back to the organizational strategy, the goals, and the objectives of the project that were originally defined.

“If you cater to one group, you risk another group disengaging from the project. It’s a delicate dance, and it is only human. There is no formula to that. You have to get back to the business objectives.” -CIO, Financial Services Industry

a) Break requirements sessions into smaller group sessions – front line people first, and then managers. Figure out who in each group you can put together, and if you can’t do that – act as the go-between.

b) Treat the business as a partner – not a customer. Create a formal intake process so that a business unit cannot just demand you meet a need – they have to prove that their requirements will bring value to the organization.



Implement a feedback loop to test IT’s understanding of requirements, or risk misinterpreted expectations.


Play back the requirements to the business to ensure that IT has a solid understanding of what the business is asking for.

Employ agile

project methodolog

y

56%

Require business sign off of

requirements

67%

Consult business

stakeholders in all project phases

72%

Formally walk

through requirement

s with business and IT

69%

% of organizations using validation techniques

Agile development is emerging as a solution to many of the issues that plague software projects, including how to validate user requirements.

Agile methodology:

Do just enough initial requirements envisioning to identify project scope. Requirements evolve over time and early investment in detailed documentation will only be wasted.

During development sprints, and with the stakeholder, develop the details until a common understanding of what needs to be built is reached.

Harness change for the customer's competitive advantage.


A lesson in validating changing requirements: A research company becomes more Agile.

Rapidly changing requirements…

With a process for managing the changes…

Results in successful projects

•IT’s development process entailed gathering all the business requirements up front, then designing the solution. •A rapidly changing business environment meant that IT struggled with requirements that were moving targets. •IT needed to implement improved requirements gathering processes that would enable swift course changes in solution development.

•IT’s development process entailed gathering all the business requirements up front, then designing the solution. •A rapidly changing business environment meant that IT struggled with requirements that were moving targets. •IT needed to implement improved requirements gathering processes that would enable swift course changes in solution development.

•IT adopted the Agile Development Methodology to enable better responses to changing requirements.•IT and the stakeholders work collaboratively in iterative, time boxes (sprints) - delivering working software every 10 days. •Changed requirements become a new sprint with a new deliverable.•Stakeholders overwhelmingly adapted to the new process.

•IT adopted the Agile Development Methodology to enable better responses to changing requirements.•IT and the stakeholders work collaboratively in iterative, time boxes (sprints) - delivering working software every 10 days. •Changed requirements become a new sprint with a new deliverable.•Stakeholders overwhelmingly adapted to the new process.

++ ==

•Project deliverables are easier to plan and budget.•Agile process supports changing requirements.•Stakeholder/IT collaboration means requirements are better understood.•Frequent deliverables mean ROI is achieved sooner•IT’s investment in process change meant that project stakeholders realize project benefits much earlier.

•Project deliverables are easier to plan and budget.•Agile process supports changing requirements.•Stakeholder/IT collaboration means requirements are better understood.•Frequent deliverables mean ROI is achieved sooner•IT’s investment in process change meant that project stakeholders realize project benefits much earlier.

Estimates are still too optimistic; sometime we don’t meet our goal.Stories are too large for easy tracking but tracking at the task level is too granular.Sprints (2 weeks) may be too short to get best results.Detailing acceptance test criteria (we don’t do this well enough to clarify expectations).Prioritizing backlog to allow for product owner analysis of what needs to be completed .

Estimates are still too optimistic; sometime we don’t meet our goal.Stories are too large for easy tracking but tracking at the task level is too granular.Sprints (2 weeks) may be too short to get best results.Detailing acceptance test criteria (we don’t do this well enough to clarify expectations).Prioritizing backlog to allow for product owner analysis of what needs to be completed .

Trained the entire group so they could easily adopt the terms used by the methodology.Constantly reminded people of the goals/benefits of this change.Dedicated scrum boards for each project.Consistently following the processes we agreed upon (daily scrums, sprint planning, demos).Review at end of sprints to assess processes and we make changes as necessary.Co-location of developers and BA’s.

Trained the entire group so they could easily adopt the terms used by the methodology.Constantly reminded people of the goals/benefits of this change.Dedicated scrum boards for each project.Consistently following the processes we agreed upon (daily scrums, sprint planning, demos).Review at end of sprints to assess processes and we make changes as necessary.Co-location of developers and BA’s.

What happened? A successful process launch…



Case Scenario:System ModificationsMedium Enterprise

A lesson in validating changing requirements: What could IT leaders do in different scenarios.


Case Scenario:System ModificationsMedium Enterprise

Adopt Agile methodology for projects withfrequently changing requirements


37

DefineSystem

SystemOwner

Customers

ReleaseRoadmap

Track andAdjust

Plan Releases

IterativeDevelopme

nt

ReleaseAccept

Work Products

Agile Development is based on iterative development, where requirements and solutions are developed through the collaboration of cross functional teams. Agile methods follow a disciplined project management process based on frequent inspection and adaptation. Functional deliverables are small and time boxed. The best practices allow for rapid, small, high-quality releases that align development with customer needs and company goals.

Implement requirements change control to avoid project scope creep

Most projects will experience changes to requirements regardless of how accurate

the initial requirements are. Change requests can result from changes to business operations or strategy, new

constraints, or something missed initially. Unless properly managed, requirements changes will have a significant negative

impact on your project costs, timelines and scope as resources scramble to address

unplanned functionality without understanding the need for the change.


Formalize requirements change requests. Follow a standard process for changing requirements to minimize confusion.Get stakeholder sign off of initial requirements.Document and log requested changes to signed off requirements.Analyze changes for feasibility, cost, scope impact and rationale.Secure management/steering committee approval for the change.Adjust project scope/budget/timeline accordingly.

Set up a process and stick to it.

Use Info-Tech’s “Business Requirements Change Request Template” and “Business Requirements Change Log” to record and track the status of requirements change requests.

Business Requirements Change Log Template

Introduction: How to Use This Template Requirements may change throughout the project life cycle. Documenting and tracking these changes ensures accuracy when addressing the requests for change. Use this log to track all requirement change requests submitted using the Business Requirements Change Request Template.

To use this template, simply fill in the blanks with the appropriate information. Be sure to delete all introductory and explanatory text in dark grey before finalizing the document. Additional rows can be added to allow for more change requests.

Requirement Number Date Requested Disposition Disposition Date Authorization Scheduled for Which Release/Sprint

101.1 January 18, 2010 Approved February 1, 2010

102.5 January 20, 2010 Rejected

104.4 January 27, 2010 Deferred

http://www.infotech.com/research/business-requirements-change-request-template

http://www.infotech.com/research/business-requirements-change-log

Requirements management tools help larger projects and organizations to manage changing requirements

•The INCOSE Requirements Management Working Group, developed the survey questions for vendors of Requirements Management tools. The vendors have provided ratings of compliance of their tools with each question or feature.

•For the survey responses see : INCOSE site for Requirements Management Tool Survey Responses

•For the summary list of vendors and their contact information, see Appendix I.


Requirements Management tools provide benefits including:•Report Generation•Collaboration•Use Case Development•Requirements change control•Planning releases

For dealing with a variety of projects and thousands of requirements, moving to a database approach to managing requirements allows a metrics-based management of requirements that is simply not practical with paper document-oriented approaches.

Source: International Council on Systems Engineering (INCOSE)

http://www.incose.org/ProductsPubs/products/INCOSERMToolSurveyConsolidatedResults.xls




























































































Recognize when stakeholders finally reach aconsensus on requirements


A

BC

D

If …

All business groups agree on general requirements (A),

Involved business groups agree on common requirements (B, C, D),

And remaining individual requirements are also in scope (E, F, G)

…then you have consensus.

E

F

G

Don’t close the feedback loop too early. Develop an escalation framework to address requirements conflicts.


•The BA should not make any decisions about what requirements take precedence or priority.•When it comes to conflicting requirements the BA’s role is to communicate, facilitate and escalate until a decision is made:

•Inside the scope of the project: Senior managers should get involved and make a decision.•Outside of the scope: Establish a steering committee for larger projects, or a sponsor for smaller ones. Bring the decision to them. •In all cases: Equip the decision makers with the information (rationale, costs, timelines, impact) they need to make a decision.•Document the decisions for all parties

Another stakeholder group exists: IT. Even if all business units agree, the requirements might not deliver value, be out of scope, or IT may not have the capability to meet them. IT has to work with the business to develop alternate solutions and work within the escalation framework to resolve conflicts arising from IT constraints.

Info-Tech Insight:

Consensus is the goal – but what if it can’t be achieved? Requirements within a collection often conflict with requirements in that or another

collection.


Decide when good enough is good enough.Know when to commit.

IT Commitment. When does IT commit to a target of meeting the defined requirements?

IT commits when stakeholders have signed off on the requirements.

During design, issues may arise that mean IT will not be able to build or meet all requirements as defined.

IT will initiate requirements change control to document, communicate and resolve the issue with the business and reach a new commitment.

Confirm Decisions.How is consensus communicated?

Document!

Don’t make assumptions. Provide detailed documentation of requirements, issues and decisions to all stakeholders

Close the feedback loop. When are requirements “good enough,” to move on to the next stage in the project?

This depends on the nature of the project – its size, complexity and timeline. Requirements are good enough when:

Stakeholders have reached consensus on requirements. Conflicts are resolved.

Enough detail has been provided for the designers/developers to understand and proceed.

Stakeholders have signed off.

“See first that the design is wise and just: that ascertained, pursue it resolutely do not for one repulse forego the purpose that you resolved to effect.” -William Shakespeare

Take the advice of your peers to overcome barriers when validating requirements with the business.


Barrier Solution

•Not receiving enough justification (i.e. return on investment) from the business in support of their requirements and project. This makes it extremely difficult for IT to understand what the business is asking for.

•Establish requirement review points throughout the project life, even before the project has started. Make sure business has done their due diligence before they propose a project.

“ We’re putting a process owners’ validation in place because up until now, sponsorship has been missing. The sponsors are senior managers. We’re putting gates in place before the business comes to IT. This slows the process down and is an increased workload for the sponsors as they are now a filter but once you get past the approval process, the project is much quicker because all the work has been done up front. Once the project has started, we have formal reviews – so if we gather a particular set of requirements, then we code to those requirements, stop and go back. We have the users review what we have and tell us if it meets what they asked for and if yes, we move on. If not, we go back and try to figure out what was wrong with our interpretation. “ -IT Director, Oil & Gas Industry

•Not having a complete understanding of what the business is asking for.

•Ask the business the same question in 3-4 different ways. Have an IT person assess any gaps and then go back to the business to discuss these gaps before moving forward with the project.•Consider embedding an IT staff member within the business unit so that they can speak the business speak, and have the technical knowledge.•Define terminology in the requirements document.

Alternatives Recommendation


Recommend solutions that will deliver the same orbetter value faster or for less cost.


IT is responsible for being more than an order taker.

Assess requirements as defined by the business for feasibility and recommend alternate solutions. Arbitrate between conflicting stakeholder requirements until final decision is made.

Anticipate business value and provide solution options that will help to achieve that.

Architect optional, more effective solutions collaboratively with stakeholders.

Articulate stakeholder requirements using standard language, modeling and documentation formats for mutual clarity and understanding.

Affirm stakeholder requirements through collaboration and feedback with the business.

Ensure presence of developers/

designers at requirements

69%

Formally Assign

a Solution Architec

t

79%

Provide value, risk

and impact for

change requests

48%

Developing good requirements entails much more than just “gathering”

stakeholder information

% of organizations using assessment techniques


A lesson in proposing alternate solutions:A financial institution fails to communicate constraints.

Rigorous Requirements Gathering…

Without Understanding Constraints…

Resulted in Project Failure

•IT needed to implement improved technology change management processes throughout the organization•Existing COTS change management tool was to be retained and modified to suit new processes•Stakeholder team of 25 business and IT managers and practitioners participated in 8 weeks of requirements workshops.

•Development team established mandate that customization must be kept to a minimum to enable future software upgrades•This constraint resulted in significant functionality removed from the solution design without consulting the stakeholder team.

+ =

•Stakeholders rejected the solution.•The cost of retrofits caused the project to run late and over budget. •IT made the expensive mistake of not understanding their stakeholders and not working with them to design requirements based on the limitations of the tool.

Ensure the BA is familiar with current and new change management processes.Make technical constraints part of the requirements process; stakeholders can then weigh the business value tradeoffs early in the project and know what to expect.With that knowledge, alternative solutions can be explored with the stakeholders arriving at one that meets expectations and constraints.The result will be IT credibility by positioning themselves as partners with the stakeholders to develop solutions.

Ensure the BA is familiar with current and new change management processes.Make technical constraints part of the requirements process; stakeholders can then weigh the business value tradeoffs early in the project and know what to expect.With that knowledge, alternative solutions can be explored with the stakeholders arriving at one that meets expectations and constraints.The result will be IT credibility by positioning themselves as partners with the stakeholders to develop solutions.

The business analyst, and IT did not attend all the requirements workshops.The BA did not understand the new process.Constraints were not disclosed during requirements phase. Business defined requirements with many customizations.Stakeholders were not consulted when IT changed requirements.Stakeholders saw new functionality during testing.Retrofit workarounds costs blew the project budget /timeline.IT alienated stakeholders and lost credibility.

The business analyst, and IT did not attend all the requirements workshops.The BA did not understand the new process.Constraints were not disclosed during requirements phase. Business defined requirements with many customizations.Stakeholders were not consulted when IT changed requirements.Stakeholders saw new functionality during testing.Retrofit workarounds costs blew the project budget /timeline.IT alienated stakeholders and lost credibility.

What Happened? A Failure to Communicate…


Case Scenario:System ModificationsLarge Enterprise


A lesson in proposing alternate solutions: What could IT leaders do in different scenarios


Case Scenario:System ModificationsLarge Enterprise

Clients that get requirements wrong overspend on the acquisition, customization and implementation of their solutions. Document for clarity.


48

Document for accuracy.

Use Info-Tech’s “Business Requirements Document Template,” to collect stakeholder requirements

Whether you are acquiring new software or making modifications to an existing system, IT needs a comprehensive definition of the business requirements. A requirements document should:

•Detail full customer needs and expectations for a business solution in unambiguous and non-technical language.

•Be used to gain agreement with multiple stakeholders.

•Provide input into the design phase of a project.

http://www.infotech.com/research/business-requirements-document

Document business requirements with proven modeling techniques.

Use Cases provide a detailed view of the requirements. •They do not specify ‘how’ the solution will be developed. •They provide a high-level flow that will need to be considered in product design but do not attempt to design the actual product.


Pictures are worth a thousand words.

See Info-Tech’s “Use Case Template” for guidance on creating a detailed view of requirements.

5 Ways to Optimize a Use Case Model

1. Describe the proposed functions.

2. Represent a discrete unit of interaction between a user (human or machine) and the system. This interaction is a single unit of meaningful work, such as Create Account or View Account Details.

3. Provide the detailed view of the requirements.

4. Provide a high-level flow but do not attempt to design the actual product.

5. Describe the functionality to be built in the proposed system.

http://www.infotech.com/research/use-case-template

Improve the business results by defining good usability requirements.

• This template provides a worksheet for use on projects to set usability goals and measurable usability requirements.

• The worksheet should be kept along with the overall Requirements Specification for the project.

• Test planning and execution will need to include test conditions and cases to prove the usability requirements are met by the solution.

Use Info-Tech's “Usability Goals and Requirements” template to set targets and necessities which will help improve the enterprise's bottom line.


Document for accuracy.

Use Info-Tech's “Usability Goals and Requirements" template to help set usability targets and necessities.

http://www.infotech.com/research/usability-goals-and-requirements

Consider you peers’ solutions to overcoming common barriers when assessing requirements and offering

alternatives.


Barrier Solution•IT treats the business as a customer, as opposed to a partner, and in doing so, takes on the role of just an order-taker.

•IT’s customer is the end consumer – the group of people that the business is providing a service or product too. All projects should support the organization’s strategy to support the end consumer. It is the responsibility of the CIO to make sure this happens.

“There's a lot of evidence that the more successful CIOs are the ones who don't look at business as their customer. They look at themselves as a business executive. So, as a CIO, your job is to be part of the executive team, to define the organization’s strategy, and then take responsibility for the IT-systems part of that strategy. Your job is just as much about delivering services to your customer as everybody else’s is, as opposed to, ‘I'm here to service the business, and the business' job is to worry about the customer.’“ -VP Professional Development, IIBA

•The business gives you the solution, instead of the problem.

•Back the business up. Ask them the whats and whys, before the hows.

“I somewhat play stupid and get them to educate me on how they got to where they did – ‘so help me understand so I can share with the developers what you are trying to accomplish.’ Gently say, ‘That’s really interesting. Have we ever thought about doing X, Y or Z?’ so you can start introducing some alternatives.” -Senior Systems Analyst, Insurance Industry

Summary


• Adopt Business Requirements Management best practices to help ensure project success.

• IT needs to excel at: Business Acumen - Understanding what the business does Understanding Requirements - What the business is asking for Requirements Validation - Validating the business needs

against what has been defined Alternatives Recommendation – Providing alternate solutions to

the business based on constraints or anticipated business value• See the resulting improvements:

Reductions in project budget overruns Reductions in project delays Reduction in post production rework Improved IT reputation and credibility

Appendix I: Tools


• Requirements Management High Level Process Description• Explanation of the benefits of formally certifying your

organization’s Business Analysts• Business Requirements Elicitation Techniques• INCOSE SE Tools Database: Requirements Management Tool

Summaries and Vendor Contact Information

Follow the Requirements Management Process to ensure the solution will meet business objectives.

The high level Requirements Management Process consists of four steps:

•Elicitation: gathering business requirements from various sources including management and frontline stakeholders and process documentation. Techniques include: interviews, workshops and process mapping.

•Analysis: this iterative step involves reviewing requirements priority and feasibility, resolving conflicts and negotiating alternatives. Use prototypes and facilitated walkthroughs to ensure understanding.

•Specification: documenting functional and non-functional requirements in a standard User Requirements Document. Modeling techniques such as use cases or user stories may be used.

•Validation: agreement in the form of signoff from the stakeholders that these are the requirements that will be used to design the solution.

The IEEE “Guide to the Software Engineering Body of Knowledge” (SWEBOK)


Formal certification for Business Analysts offers benefits for both the BA and the organization


The International Institute of Business Analysis (IIBA) offers professional certification for Business Analysts. The Certified Business Analyst Professional ®(CBAP) certification offers benefits to both analysts and the organizations that employ them.

For more information visit: http://www.theiiba.org/AM/Template.cfm?Section=Certification

Benefits to the Analyst

Demonstrated knowledge of the skills necessary to be an effective Business Analyst. A proven level of competence in the principles and practices of business analysis. Participation in a recognized professional group. Recognition of professional competence by professional peers and management. Advanced career potential due to recognition as a professional Business Analysis practitioner.

Benefits to the Employer

Establishment and implementation of Business Analysis best practices as outlined in the Business Analysis Body of Knowledge® (BABOK®).More reliable, higher quality results produced with increased efficiency and consistency. Identification of professional Business Analysts to clients and business partners. Professional development and recognition for experienced Business Analysts. Demonstrated commitment to the field of Business Analysis, recognized as a vital component of any successful project.

http://www.theiiba.org/AM/Template.cfm?Section=Certification

Choose the right elicitation techniques by understanding the pros and cons of each approach.


Elicitation Technique Strengths Weaknesses

Structured Interviews

• Simple and direct. • Encourages participation and helps build rapport. • Allows for full discussion, exploration (e.g. follow-up questions, elaboration, and confirmation).

• Not ideal when consensus is required across diverse group of stakeholders. • Considerable commitment required by the participants and interviewers. • Limited by the interview capabilities and knowledge of the interviewer. • Training may be necessary for good interviews. • Interview transcription can be costly and complex. • Subject to interpretation.

Survey Questionnaire

• Close-ended questions can be effective for getting quantitative data. • Open-ended questions can yield insights not easily obtainable through other techniques. • Can be done quickly and inexpensively. • A large number of responses can be generated from people across a variety of locations.

• Open-ended questions require more analysis. • To ensure unbiased results, the survey process needs to be designed well (e.g. random sampling). • Ambiguous questions won't get good answers. • May require follow-up. • Dependent on subject involvement/engagement. • Will not necessarily provide information about actual behaviors.

Choose the right elicitation techniques by understanding the pros and cons of each approach. (cont’d)



Focus Groups & Workshops

• Can collect detailed requirements in shorter time periods. • Allows for collaboration, mutual understanding, consensus building, decision making. • Can be cheaper and less time consuming than multiple interviews in isolation. • Feedback is immediate and some prioritization can be managed by the group.

• Dependent on the schedules of participants – can be difficult to coordinate. • Success depends on the expertise of the facilitator and knowledge of participants. • Process can be undermined by having groups that are too large or too small, or if strong personalities override quieter participants. • Much less successful if management and end users are in the same meetings.

Shadowing/ Observation

• Provides realistic insight on how the business process currently works. • Elicits information about how people actually use the system. • Elicits information that subjects may fail to recall in interviews. • Excellent for noticing workarounds normally not discussed. • Provides context: observing application use in the context of a bigger business system. • Enables insight into process improvements, not just application requirements.

• Only possible for existing processes. • Can be time consuming. • Can disrupt work of subject when they are required to verbalize their activities. • May not capture unusual situations or exceptions. • Not suitable for intellectual work that can't be observed.




Storyboards

• Excellent way of organizing requirements ideas into a coherent form. • Easier than prototypes to share with large groups of people. • Doesn't give false impression that the system is already built. • Feedback can be easier to accommodate.

• They can become outdated very quickly as UI requirements change over time. • Each iteration can be time consuming if not managed properly – need to know when to stop.

Prototyping

• Allows for early user interaction and feedback. • Supports users who are more capable of articulating their needs using pictures. • Inexpensive means for requirements elicitation, validation, and gap analysis. • Helps designers and developers evolve systems based on end-user needs.

• If the target system is complex, prototyping can take more time. • Assumptions about underlying technology may be required. • Can give users unrealistic expectations of the to-be-delivered system performance, completion date, reliability, and usability.

Use Cases

• Provides more detailed guidance for the purchase or design and testing process. • Non-technical focus on business behavior helps requirements elicitation. • Good for identifying requirements for error situations. • Highlight the overall intent of the system. • Help with priority setting.

• Requires well defined cases or they are not helpful. • If cases are inaccurate, they will capture the wrong requirements. • Failure to use enough use cases can result in missing entire areas of functionality. • Cases can need updating as requirements change. • More of a documentation technique rather than pure elicitation, though they can be used for this purpose.




Structured Demos

• Packaged applications allow users to try out the system they will use. • Built-in software functionalities can be used to probe needed and missing requirements.

• Requires a functional piece of software. • Limited to the capabilities found in each of the software applications. • Test subjects can be overly influenced by non-functional features (e.g. GUI).

Document Analysis

• Team does not have to start the process from blank page. • Using existing materials to discover/confirm requirements. • Provides means to cross-check requirements from other techniques.

• Limited to “as-is” perspective. • Dependent on up to date and valid documentation. • Can be time consuming and tedious to locate and analyze documents.

INCOSE SE Tools Database: Requirements Management Tool Summaries and Vendor Contact

Information (March 4, 2010)1. Accept Requirements (Accept 360)—

Accept Software http://www.acceptsoftware.com

2. Acclaro DFSS Version 5—Axiomatic Design Solutions, Inc. http://www.dfss-software.com

3. Aligned Elements Version 1.5 (AE 1.5)—Aligned AG http://www.aligned.ch/

4. Avenqo PEP Version 1.2—Avenqo http://www.avenqo.com

5. CASE Spec Version 8.15—Goda Software http://www.casespec.net/products.htm

6. Cognition Cockpit (Cockpit) Version 5.1—Cognition Corporation http://www.cognition.us

7. Contour by Jama Software (Contour) Version 2.9—Jama Software http://www.jamasoftware.com

8. CORE Version 5.1.5—Vitech Corporation http://www.vitechcorp.com

9. Cradle Version 5.7—3SL, Inc. http://www.threesl.com

10. Dimensions RM (DimRM) Version 10.1.4—Serena Software http://www.serena.com/products/rm/index.html

11. e-LM.com (e-LM) Version 3.00—e-LM.com http://www.e-lm.com

12. Enterprise Architect Version 7.1—Sparx Systems http://www.sparxsystems.com

13. Envision VIP Version 9—Future Tech Systems, Inc. http://www.future-tech.com/prod01.htm

14. IBM Rational DOORS Version 9—IBM http://www-01.ibm.com/software/awdtools/doors/productline/

15. IBM Rational RequisitePro Version 7.1—IBM http://www-01.ibm.com/software/awdtools/reqpro/

16. inteGREAT Version 4.7—eDev Technologies http://www.edevtech.com

17. IRQA Version 4—Visure Solutions http://www.visuresolutions.com/products/index.php

18. Kovair Global Lifecycle (Kovair) Version 5.5—Kovair Software, Inc. http://www.kovair.com

19. MKS Integrity 2009—MKS Inc. http://www.mks.com


INCOSE SE Tools Database: Requirements Management Tool Summaries and Vendor

Contact Information (March 4, 2010)

20. PACE Version 3—Viewset Corporation http://www.viewset.com

21. Polarion Requirements Version 2—Polarion Software http://www.polarion.com/products/requirements/index.php

22. Project & Test Engineering System (PTESY) Version 5.4—Andromeda s.r.l. http://www.andromeda-srl.com/PRODUCTS/PTESY/brochure.html

23. RaQuest Version 3.0—SparxSystems Japan Co., Ltd http://www.raquest.com/

24. ReqMan Version 2.0—RequirementOne Inc. http://www.requirementone.com

25. Reqtify Version 2010-1A—Geensoft http://www.reqtify.com

26. Requirements Manager (ReMa)—Accord Software and Systems Pvt. Ltd. http://www.rema-soft.com

27. RTIME Version 5—QAVantage http://qavantage.toolsforproductmanagement.com/

28. SoftREQ—Software Requirements, Inc. http://www.softreq.com

29. Teamcenter Requirements (Tc RM) Version 8—Siemens http://www.siemens.com/plm

30. TraceCloud—TraceCloud http://www.tracecloud.com

31. What To Do Next (WTDN)—4SQ Solutions LLC http://www.4sqsolutions.com/

32. workspace.com Requirements Management—workspace.com http://www.workspace.com/workspace/Requirements-Management-Software.html

Cont’d


Appendix II: Methodology


• Info-Tech Research Group engaged in the following primary research activities in the creation of this Solution Set:• February, 2010: Harvested data from Info-Tech’s MeasureIT

benchmarking service, which is focused on the collection of IT budgeting and staffing data.

• March, 2010: Interviewed 13 IT leaders, project managers and business analysts to understand the challenges, impacts and real-life solutions for ineffective business requirements gathering practices, and to collect case study material.

• April, 2010: Surveyed over 250 IT leaders in regards to their business requirements gathering practices, impacts of poor requirements and how they improved their processes.

Appendix III: Top Level Graphs


Full Time Employees

N = 167

5 10 15 20 25 30

10%

7%

11%

19%

13%

16%

12%

13%

1. 1-50

2. 51-100

3. 101-250

4. 251-500

5. 501-1000

6. 1001-2500

7. 2501-5000

8. 5001+

Job Title

N = 167

10 20 30 40 50

4%

10%

8%

23%

31%

12%

9%

3%

1%

1. Owner / president / CEO

2. C-Level officer

3. VP-level

4. Director-level

5. Manager

6. Team lead / supervisor

7. Team member

9. Consultant

10. Student

Revenue

N = 167

5 10 15 20 25 30

12%

8%

11%

8%

10%

11%

20%

17%

3%

1. $0 - $1M

2. $1M - $5M

3. $5M - $10M

4. $10M - $25M

5. $25M - $50M

6. $50M - $100M

7. $100M - $500M

8. $500M - $1B

9. $1B +

Industry

N = 151

5 10 15 20 25

15%

2%

13%

10%

14%

13%

12%

19%

3%

1. Business Services

2. Primary Industry

3. Manufacturing

4. Education

5. Financial Services

6. Healthcare

7. Trans/Utilities/Comms

8. Government

9. Wholesale/Retail

IT Employees

N = 167

5 10 15 20 25

18%

14%

15%

18%

13%

11%

4%

2%

1%

4%

1%

1. 1-5

2. 6-10

3. 11-25

4. 26-50

5. 51-100

6. 101-250

7. 251-500

8. 501-1000

9. 1001-2500

10. 2501-5000

11. 5000+

Technology

Overcome barriers to good req mgmt