system requirements definition and system selection · agenda 1. introductions 2. session objective...

BerryDunn’s Presentation to Texas Association of Governmental Information

Technology Managers for

Tuesday, April 29, 2014

1:30 – 2:30 PM

System Requirements Definition and System Selection

Presented in Partnership with the City of College Station

2

Agenda

1. Introductions

2. Session Objective

3. Presentation

4. Questions and Discussion

3

Introductions

Chad Snow, PMP

BerryDunn

Senior Manager

Ben Roper CGCIO, MBA

City of College Station

Director of Information

Technology

Erin Provazek

City of College Station

Assistant Director of

Information Technology

4

Session Objective

Discuss the importance of functional and

technical requirements in system

selection/development/replacement projects.

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.

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

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?

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

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

10

Requirements Gathering Process (cont.)

According to the IEEE (Institute of Electrical and Electronics

Engineers), Software Requirement Specifications should be:

� Correct

� Unambiguous

� Complete

� Consistent

� Ranked for importance

� Verifiable

� Traceable

Requirements Best Practices and Standards:

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.

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.

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

14

• 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

Case Study: City of College Station (cont.)

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

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

17

Case Study: City of College Station (cont.)

• Ongoing Role of Requirements:

� Used during procurement

• Request for Proposal

• Demonstrations

� Implementation

• Requirements Traceability Matrix

• Testing

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

19

Questions and Discussion

Questions and Discussion

20

Thank You

Chad Snow

csnow@berrydunn.com

207-541-2294

Ben Roper

broper@cstx.gov

(979) 764-3538

Erin Provazek

eprovazek@cstx.gov

(979)-764-3482

21

References

• IEEE Standard 830-1998 Recommended Practice for Software

Requirements Specifications

• Project Management Institute (PMI)

• National Institute of Standards and Technology (NIST)