Defining Requirements for Selecting Technologies

1. Defining Requirements for Selecting Technologies Virginia Anderson, CIO, Cato Institute Christopher Butcher, principal/CIO Heuristic Solutions

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

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

4. The Standish Group Report (1995)Chaos

5. Categories of failure

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

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

8. Next steps? • Build? Bad experience • Buy? Bad experience • Do nothing? Bad experience • GOVERNANCE!

9. High-level path to governance Convene leaders Arrive at common purpose Grapple with mission Strategic Understand business context Define priorities Evaluate initiatives Analyze system requirements Evaluate vendors Achieve executive approval Functional Define project expectations Make decisions throughout project Evaluate project outcomes

10. Cato departmental mapping Media Relations Government Affairs Store Communicate Purchase Influence Scholars Attend Author Meetings Speak Give Learn Subscribe Development Web site Subscriptions

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

12. 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)

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

14. What is a requirement? It is a statement that allows. . . . . .project managers know how to scope the job and track progress Requirement . . .end users know how to validate that the system works the way they want it to . . .quality assurance staff know how to test the system . . .Programmers understand how to code the system

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

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

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

19. Using the requirements document

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

21. Possibilities of success

22. Where are we now? • Energized stakeholders • Strong budget risk management • Realistic schedule • Executive buy-in

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

24. 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?

25. Thank you! Christopher Butcher Heuristic Solutions cbutcher@heuristics.net 703.243.3376 x14 Virginia Anderson Cato institute vanderson@cato.org 202.789.5262