1 Prototype Driven Requirement Elicitation for Business Intelligence September 11, 2015 Mike Krajnak [email protected] Steve [email protected]

1

Prototype Driven Requirement Elicitation for Business Intelligence

September 11, 2015

Mike Krajnak [email protected] Strohl [email protected]

2

Agenda

2

Introduction

Why Projects Fail

Why Data Governance

Requirements Prototyping

Success Stories

© 2015, Information Control Company

3

About Mike About Steve

• Started career Battelle on defense systems• Spent 7 years in Alaska

– Lead Architect on Exxon Valdez Oil Spill Project

– Reported BI data to national news

• Master Data Management and Data Governance Practice Lead

• Sr. Business Intelligence Architect• 35+ years of IT experience• 15+ years building analytical solutions


Little Known Facts

ProfessionalProfessional• Business Intelligence Requirements

Practice Lead• CBIP, CDMP• 35+ years of IT experience• 20+ years building analytical solutions

Little Known Facts• Started career as system’s programmer• Scoutmaster for 7 years in the Boy

Scout troop that Steve’s father started• Met wife on trip to Israel• Traveled to China to adopt daughter

4

Business Intelligence (BI) Overview


Raw Data

Fuzzy business

rules

Unclear data Relationships

Meaningful Information

Reports

Decisions

Opportunities

Getting the right information . . .

. . . to the right people . . .

. . . at the right time.

5

Business Intelligence Requirement Gathering Landmines


o It is estimated that 85% of defects in developed software originate in the requirements*

o Fixing defects is costly

o Unrealistic scope and expectations hurt timelines o Multiple data sources and fuzzy business rules cause complexity

o Business requirements are hard to articulate (users do not know what they want)

o Lack of data governance (data quality/ Integrity) cause confusion

(* Young, Ralph R. Effective Requirements Practices. Boston: Addison- Wesley, 2001.)

$

Time

6

Multiple Approaches to Solve this Problem


Monolithic WaterfallCons Pro

Long time between requirements and deployment

Complete and robust requirement planning

Requirement changes have serious project impact

Tangible defined handoffs between stages

Linear dependencies cause project delays

Stable Processes

Pure AgilePro Cons

Business and IT working together

Loss of connection to the big picture causes requirement drift

Flexible to handle changes Lots of rework due to requirement changes

Clarify requirements as you go Sprints too small to create deployable artifacts

7

Combine the Best of Both into a Hybrid Approach


Monolithic WaterfallCons Pro

Long time between requirements and deployment

Complete and robust requirement planning

Requirement changes have serious project impact

Tangible defined handoffs between stages

Linear dependencies cause project delays

Stable Processes

Pure AgilePro Cons

Business and IT working together

Loss of connection to the big picture causes requirement drift

Flexible to handle changes Lots of rework due to requirement changes

Clarify requirements as you go Sprints too small to create deployable artifacts

Scrum

Fall

Water

8

Our Approach


Design & Build

TestRequirements & Prototype

Data Governance(common thread)

Planning Release

6 weeks

8-12 weeks

6-8 weeks 1-3 weeks 2 weeks

Total: 23-31 weeks

“Water Scrum Fall” Process

9

According to the Data Governance Institute, Data Governance is …

“The organizational bodies, rules, decision rights, and accountabilities of people and information systems as they perform information-related processes.”

It refers to the operating discipline for managing data and information, including the:• People• Processes• Technology

And categorizes data as a key enterprise assets

Why Data Governance?

Technology

Process

People


10

Data as an Asset:

No governing body No data policies, procedures or processes No business glossary No data quality checks No remediation process

The Problem

Badly formed or incorrect social security numbers Incorrect or obsolete addresses Incorrect dates (birth, admittance, discharge, policy etc…) No standard descriptive or type values Duplication of data across source systems Different data for the same person across source systems

The Result


11

Bad Data


Data Management

System

Data Management

System

Good Data

12

GoverningBody

Roles and Responsibilities

Policies, ProcedureAnd Processes

Data Quality Rules

Data Remediation

Data Governance Program

View data as an asset!

13

Our Approach– Planning


Planning

6 weeks

• Identify the business needs, suggest projects to meet those needs

• Validate that the pre-requisites can be met on each project• Estimate the costs, and rank them by return on investment• Identify stakeholders to champion the projects. • Find people to fill the roles for the BI project

o Project managero BIBA – Business Intelligence Business Analysto Data Analysto User Interface Specialisto Report Specialist

Deliverables:• Prioritized list of projects with estimated cost and ROI• Roadmap showing project timelines

14

Our Approach– Requirements and Prototype


Requirements &

Prototype

6-8 weeks

15

Our Approach– Requirements and PrototypeSME Interview Business Questions Glossary Data Governance Business Model Working Prototype

Artifacts CreatedInterview Guide List of Business Questions

Business Terms Business GlossaryFacts Qualifier MatrixSource Qualifier MatrixData Profiling Results

Logical Business Model

Physical DDL

Semantic layer

Prototype Reports

Functional Specification

Business Requirement Document


16

Data Stewardship Roles


Contributors

• Identify the people responsible for identifying the business element and data quality rules

Facilitator• Identify the person responsible for managing the workflow process

Approvers

• Identify the people responsible for approving, modifying or rejecting the data element or any part of the data element.

Reviewers

• Identify the people who will view the data elements but only have read authority

17

Consumer(read only)

Reviewer(read only)

Reviewer(read only)

© 2012, Information Control Corporation

BusinessTerms

BusinessTerms

BusinessTerms

Submit

Review,Submit

Eval

Eval

BusinessTermsBusiness

TermsBusinessTermsBusiness

Terms

Publish

InterviewsSME’s

Published Area

Abstain

Approved

Approved

Approved

Rejected

Rejected

We have now reached a Consensus!

All business terms have been approved.

Approved terms can now be used to build the modeling objects and prototype package

Business Q’s

Consumer(read/write)

Facilitator

Approvers

Contributor

© 2015, Information Control Corporation

Approvers

Our Approach– Term & Rules Work Flow

18

Prototype - Which would you rather have?


• Manual or online requirements

• Paper based or accessible artifacts

• Wire frames or working prototype

• Which is easier to develop from?

19

Consensus Tool- saves 2 weeks of time gathering requirements – links requirements to a logical model

20

Consensus Accelerates Output


Semantic Model

DDL

Documentation

Table with sample data

21

Demo the Prototype and Obtain Business Signoff


22

Why Prototype Requirements?

1. More Accurate Requirements

2. Less Risk

3. More Satisfied users

4. Less Cost


23 © 2015, Information Control Company

Retirement6 month project (Balanced Score Card)Production results after 2 monthsContinued rollout at month 4 and 6

Restaurant4 month projectProduced dashboards across 4 subject areasColocation, management support

Ten Success Factors1. Cooperation between Business and IT2. Championing by the Business Stakeholder3. Narrow Defined Scope (No Boiling the Ocean)4. Prioritized list of Business Questions5. Having a PM that understands BI6. Mitigation Strategy for Data Integrity Issues7. Following Data Governance Principles8. Available Personnel with Correct Skills9. Using accelerator tools (Balsamiq, Consensus)10. Stand up and Status meetings

Success Stories

24

Q & A


Documents

1 Prototype Driven Requirement Elicitation for Business Intelligence September 11, 2015 Mike Krajnak [email protected] Steve [email protected]