Virginia Anderson, CIO, Cato InstituteChristopher Butcher, principal/CIO Heuristic Solutions

Defining Requirements for Selecting Technologies

What do we want to accomplish?

Help organizations that are terrified of making technical decisions to: do so competently and with positive

results know that:

you are not alone there is a path to success

Take-aways

Good decisions are the result of a disciplined process

It’s not about the software. Let your organization—not your vendor dictate what you do

Your ability to meet needs is dependent upon your understanding of those needs (i.e., requirements)

Requirements exist in a variety of scopes: business and functional

The Standish Group Report (1995)Chaos

Rank

Success factors %

1 User Involvement 15.9

2 Executive management support

13.9

3 Clear statement of requirements

13.0

4 Proper planning 9.6

5 Realistic expectations 8.2

6 Smaller project milestones 7.7

7 Competent staff 7.2

8 Ownership 5.3

9 Clear vision and objectives 2.9

10 Hard working, focused staff 2.4

11 Other 13.9

Rank

Failure factors %

1 Lack of user input 12.8

2 Incomplete requirements and specifications

12.3

3 Changing requirements and specifications

11.8

4 Lack of executive support 7.5

5 Technology incompetence 7.0

6 Lack of resources 6.4

7 Unrealistic expectations 5.9

8 Unclear objectives 5.3

9 Unrealistic time frames 4.3

10 New technology 3.7

11 Other 23.0

Categories of failureArea Reason

Strategic (i.e., you didn’t take on the right project)

4. Lack of executive support6. Lack of resources7. Unrealistic expectations 8. Unclear objectives

Tactical (i.e., you didn’t do it right) 3. Changing requirements and specifications (scope creep)9. Unrealistic time frames

Functional (i.e., the system didn’t do what it was supposed to)

1. Lack of user input2. Incomplete requirements and specifications

Adoption (i.e., the system does what it is supposed to but people don’t believes it)

1. Lack of user input3. Changing requirements and specifications4. Lack of executive support

Skills deficit (i.e., people didn’t know what they were doing)

5. Technology incompetence10. New technology

Our story Who is Cato?

501(c)3 public policy think tank Funded mostly by individuals, some

foundations Large sponsorship base, but emphasis on large

individual gifts for funding Hybrid fundraising/membership organization

2002 adopted Siebel as CRM Staff of 75 Had been using out-dated database Tried a custom-developed CRM which failed

Our story: two failures Why did custom-build fail?

“I don’t know anything but so-and-so does and they will set it up.”

Decision driven by non-technical executive relationship Limited requirements gathering Driven by political agenda No stakeholder consensus

Why did Siebel fail? “Here’s your system now make it work.” Decision driven by executive relationships Post hoc requirements performed by implementation

team Limited flexibility in system

Next steps?

Build? Bad experience Buy? Bad experience Do nothing? Bad experience GOVERNANCE!

High-level path to governance

Convene leaders

Arrive at common purpose

Grapple with mission

Understand business context

Define prioritiesEvaluate initiatives

Analyze system requirements

Evaluate vendors

Achieve executive approval

Define project expectations

Make decisions throughout

project

Evaluate project outcomes

Strategic

Functional

Cato departmental mapping

Purchase

Attend

Speak

Subscribe

Give

Author

Influence

Communicate

Media RelationsGovernment

AffairsStore

Meetings

Subscriptions

Development

Scholars

Learn

Web site

What does Cato need?

All-in-one solution (i.e., “Battlestar Galactica”)?

Department-specific solution? Answer:

Services-oriented architecture (SOA) Core integration platform (e.g., “Web

Services”) Best-of-breed departmental functionality

Define priorities

System must function as a nerve center for entire organization

Ensure availability of data for other functions (i.e., events, purchases, subscriptions)

Where is the pain? Focus initially on development function (i.e., fundraising contacts, mailings)

Requirements types Business requirements

Defines what the business is and what you are trying to accomplish

Defines how the business goes about pursuing its mission

Captures rules relevant to how the organization conducts business

Systems requirements System capabilities

What is a requirement?

Requirement

. . .Programmers understand how to code the system

. . .quality assurance staff know how to test the system

. . .end users know how to validate that the system works the way they want it to

. . .project managers know how to scope the job and track progress

It is a statement that allows. . .

Gather requirements in the SRS Software Requirements Specifications

(SRS) includes: All known functional requirements (what the

system needs to do) All known functional wishes (low priority but

nice-to haves) All known reporting requirements (data

relevant to decision-making) All known business rules/constraints All known non-functional requirements (i.e.,

platform requirements) Use cases

Requirements in negotiation

Asked vendors to address requirements as follows: System meets requirement without

modification System meets requirement through

configuration by Cato staff System meets requirement through

configuration by vendor System meets requirement through

customization System does not meet requirements

Interest Codes      

Priority: High      

The system shall be able to indicate the various interests a constituent has:

B    

It can have several codes and several levels - perhaps a tiered category/value system, such as that in Siebel.

B    

An unlimited number of different issues of interest or other types of codes, attributes and designations

B    

The ability to right click or drill down (or hover) on an issue code (or event code, etc.) and view a text explanation of the code; i.e., where it came from (for example, Forum Trade = "people who are interested in trade and who should be invited to trade forums and related events, but they or we don’t want to send them all the trade studies").

E A description of the code is available however the size is limited. This type of informational view would require a modification to application behavior. An additional field can be added to track the descriptive data for each code. New links to display the description at the field level would also need to be added.

8 hours per field; assuming

1 field

What makes a requirement good? Atomic Clear to various stakeholders Testable Defined priority

Using the requirements documentStage Effect

Gather requirements Energized stakeholdersGained clarity of purposeIdentified prioritiesShaped scope of exercise

Select vendor Eliminated unsuitable vendorsClarified expectationsEstablished cost structure for otherwise unknowns

Presentation Established authority with executive sponsors

Supported implementation

Eliminate lower priority functionality

Requirements in negotiation Asked vendors to address requirements as follows:

System meets requirement without modification System meets requirement through configuration by

Cato staff System meets requirement through configuration by

vendor System meets requirement through customization System does not meet requirements

Possibilities of successArea Reason Outcome

Strategic 4. Lack of executive support6. Lack of resources7. Unrealistic expectations 8. Unclear objectives

Gained executive supportAllocated needed resourcesSet realistic expectationsDefined objectives

Tactical 3. Changing requirements and specifications9. Unrealistic time frames

Established change control processDefined time frames

Functional 1. Lack of user input2. Incomplete requirements and specifications

Achieved user inputGathered requirements from stakeholders

Adoption 1. Lack of user input3. Changing requirements and specifications

Achieved user inputEstablished change control processGained executive support

Skills deficit

5. Technology incompetence10. New technology

Selected competent vendorSelected proven technology

Where are we now?

Energized stakeholders Strong budget risk management Realistic schedule Executive buy-in

Take-aways

Good decisions are the result of a disciplined process

It’s not about the software. Let your organization—not your vendor dictate what you do

Your ability to meet needs is dependent upon your understanding of those needs (i.e., requirements)

Requirements exist in a variety of scopes: business and functional

Where are you?

How do you feel? Do you believe you can follow this? What are constraints you expect to

face in implementing something like this?

Thank you!

Christopher ButcherHeuristic Solutionscbutcher@heuristics.net703.243.3376 x14

Virginia AndersonCato institutevanderson@cato.org202.789.5262