System Requirements Definition and System Selection

Transcription

1 BerryDunn s Presentation to Texas Association of Governmental Information Technology Managers for System Requirements Definition and System Selection Presented in Partnership with the City of College Station Tuesday, April 29, :30 2:30 PM

2 Agenda 1. Introductions 2. Session Objective 3. Presentation 4. Questions and Discussion 2

3 Introductions Chad Snow, PMP BerryDunn Senior Manager Erin Provazek City of College Station Assistant Director of Information Technology Ben Roper CGCIO, MBA City of College Station Director of Information Technology 3

4 Session Objective Discuss the importance of functional and technical requirements in system selection/development/replacement projects. 4

5 Why Document Requirements? Depending on the industry report, anywhere from 25-75% of software implementation projects fail to meet user expectations. One of the most common reason software implementations struggle is a lack of well defined functional or technical requirements. A requirement is a necessary attribute in a system; a statement that identifies a capability, characteristic, or quality factor of a system in order for it to have value and utility to a user. One of the greatest challenges in developing requirements is not documenting what the users want; it is helping users identify what they need. 5

6 The Role of Requirements Document future system needs Document future system wants Used as an input to the process of analyzing current and future business processes A tool to be used in the procurement process to compare vendor products (COTS) Can serve as the basis for demonstration scripts Test cases for custom development Referenced during implementation Requirements traceability matrix Test cases and system validation 6

7 Requirements Gathering Process Understand the Current (and Future) Environment Identify current challenges and unmet business needs Future process vision and application scope Identify key stakeholders Review often and adjust as needed Getting Started Organizational artifacts Policy and procedure manuals Legislative directives and local ordinances End user survey What is working well? What needs to change? 7

8 Requirements Gathering Process (cont.) Getting Started (cont.) Walkthroughs Observe current processes firsthand Collaboration work sessions Discuss current unmet needs and potential future processes Document initial set of requirements Organize them into smaller, manageable components Business area Module Technical Interfaces 8

9 Requirements Gathering Process (cont.) Refine Requirements Requirements workshops Joint Requirements Planning (JRP) Joint Application Design (JAD) Update and re-distribute requirements to stakeholders for review Finalize and document a process for change control 9

10 Requirements Gathering Process (cont.) Requirements Best Practices and Standards: According to the IEEE (Institute of Electrical and Electronics Engineers), Software Requirement Specifications should be: Correct Unambiguous Complete Consistent Ranked for importance Verifiable Traceable 10

11 Case Study: City of College Station Why ERP Now? City business needs have evolved and changed as the City has grown. Departments have identified possible shortcomings in the existing applications, and in some cases, have had to develop workarounds to complete work. Technology has changed and evolved. Is there a better solution? Reporting and data analysis difficult. 11

12 Case Study: City of College Station (cont.) ERP Implementations According to Gartner, nearly 50% of all ERP implementations fail to deliver even one third of their expected business benefits. Lack of software fit. Unrealistic implementation expectations. Lack of executive buy-in and support. Propensity to customize software, rather than leverage standard functionality. Lack of ERP implementation expertise. 12

13 Case Study: City of College Station Initiated project to assess options to upgrade, replace or enhance current enterprise wide applications environment in 2012 Scope of functional areas included: Finance, Procurement, Accounts Payable, Budgeting, Accounts Receivable, Miscellaneous Billing Payroll, Human Resources Utility Billing, Work Orders Community Development (Permitting, Planning and Zoning, Code Enforcement) Integration to other existing and future systems 13

14 Case Study: City of College Station (cont.) Comprehensive Needs Analysis First step in stakeholder identification Identified Challenges and unmet business needs Challenges and unmet business needs was an input to functional and technical requirements Options for future environment Business Case Pros and Cons for future options Justification for moving ahead with competitive procurement 14

15 Case Study: City of College Station (cont.) Requirements Gathering Process: Stakeholder re-validation End user web survey Observations and walkthroughs of processes Fact finding meetings 33 meetings across 26 functional areas Requirements Validation Process: Preliminary Requirements developed and distributed for end user review Joint Requirements Planning (JRP) sessions held to validate, confirm requirements 15

16 Case Study: City of College Station (cont.) Requirements Validation Process: Preliminary Requirements developed and distributed for end user review Joint Requirements Planning (JRP) sessions held to validate and confirm requirements 30 sessions 5,800 individual requirements for 26 functional areas 16

17 Case Study: City of College Station (cont.) Ongoing Role of Requirements: Used during procurement Request for Proposal Demonstrations Implementation Requirements Traceability Matrix Testing 17

18 Key Takeaways Initial planning should include high-level goals for the future Identify stakeholders early and reevaluate throughout the process Use several inputs to the requirements gathering process Policy and procedure manuals Workflow diagrams Observation of business processes Follow a structured process for documenting requirements (IEEE or other standard) Continue to use requirements as part of procurement (development custom developed applications) and implementation phases 18

19 Questions and Discussion Questions and Discussion 19

20 Thank You Chad Snow Erin Provazek (979) Ben Roper (979)

21 References IEEE Standard Recommended Practice for Software Requirements Specifications Project Management Institute (PMI) National Institute of Standards and Technology (NIST) 21