How UPS Delivers Modern Requirements · PDF fileHow UPS Delivers Modern Requirements Management November 5, 2015 Pedro Alvarez UPS –Business Analysis Practice Manager

How UPS Delivers Modern Requirements Management

November 5, 2015

Pedro Alvarez

UPS –Business Analysis Practice Manager

© Copyright 2014 United Parcel Service of America, Inc. UPS, the UPS brandmark and the color brown are registered trademarks of United Parcel Service of America, Inc. All rights reserved.

•  UPS at a Glance

•  The UPS Business Analysis Prac6ce

•  UPS Requirements Defini6on & Management

•  Requirements Traceability

•  Adop6ng a Requirements Defini6on & Management Tool

•  Tool Adop6on Success

Topics for Discussion

© 2015 United Parcel Service of America, Inc. UPS and the UPS brand mark are trademarks of United Parcel Service of America, Inc.. All rights reserved.


UPS at a Glance


•  The world’s largest package delivery company

•  Leading global supply chain and logis6cs provider

•  $58 billion (US) corpora6on

•  18 million packages daily

•  9.8 million daily customers

•  Serve 220+ countries and territories

•  Every address in North America & Europe

•  $1 Billion IT Budget

•  $58.2 million tracking requests per business day



UPS at a Glance


435

58.2 4.6

9.8

99,892

1,990 5,461 73,774

2014 DELIVERY VOLUME


Award Winning Team

© 2014 United Parcel Service of America, Inc. UPS and the UPS brand mark are trademarks of United Parcel Service of America, Inc.. All rights reserved. © 2015 United Parcel Service of America, Inc. UPS and the UPS brand mark are trademarks of United Parcel Service of America, Inc.. All rights reserved.

•  Informa(onWeek Elite 100: #1 Overall Most Innova(ve Users of Business Technology, 2015

•  Computerworld: Premier 100 IT Leaders – 2015, 2014, 2013

•  CIO Magazine: CIO 100, Business Intelligence for ORION, 2014

•  Supply & Demand Chain Execu(ve 100 Award for ORION, 2014

•  Postal Technology Interna(onal Awards for ORION (last mile delivery), 2014

•  CITE Awards – Auto Arrive and Depart (AAD), 2013

•  Associa(on of Telecommunica(on Professionals (ATP), 2013

•  Mobile Enterprise Magazine’s 2013 Mobilizer Award

•  Informa(onWeek 500: Most Innova(ve Users of Business Technology, 2013

•  Technology Associa(on of Georgia Excalibur Awards Finalist, 2013

•  E3 Award, 2013

•  Informa(onWeek 500: #8 Overall Most Innova(ve, 2012

•  Informa(onWeek 500: Business Innova(on award for UPS My Choice, 2012

•  Technology Associa(on of Georgia Excalibur Awards Finalist, 2012

•  Enterprise CIO Forum: Transforma(onal CIO Leadership Award, 2012

© Copyright 2015 United Parcel Service of America, Inc. UPS, the UPS brandmark and the color brown are registered trademarks of United Parcel Service of America, Inc. All rights reserved. © 2015 United Parcel Service of America, Inc. UPS and the UPS brand mark are trademarks of United Parcel Service of America, Inc.. All rights reserved.


UPS Business Analysis Practice

•  Established in 2008

•  Formed by ground-‐up BA Community

•  A federated model

•  A lean enterprise-‐level team

•  Prac6ce Leads throughout porZolios

•  Standards, oversight, training, mentoring, and support for 275 BAs worldwide

•  Maturity model for business analysis

•  Responsible for support and adop6on of tools

•  3 founda6onal pillars: People, Process, Tools



UPS Business Analysis Practice

•  People •  Formal training

•  Internal cer6fica6on program for all UPS BAs

•  Maturity model for business analysis

•  Process •  Standard Requirements Defini6on &

Management Process (RDM)

•  Cons6stent standards and common language for BAs / Stakeholders

•  Tools •  Enterprise standard Visualiza6on tool and

diagramming tool

•  Requirements tool deployed enterprise wide in 2015



Requirements Definition and Management

PDD BRD

FRD

RTM

Architecture0Deliverables

Design0Deliverables

Test0Deliverables

RTM

Project0Management0Plans


30 – 65% of all defects are introduced in the requirements phase!



Feasibility

Analysis

+

3.0Develop / Update Project Glossary

+

20.0Baseline & Centralize

Requirements

Project Approved forFeasibility Phase

+

1.0Capture Project

Information

+

2.0Define Project Objectives

and Area of Study

Requirementsapproved

+

3.0Develop / Update Project Glossary

+

5.0Define Essential

Business Processes+

4.0Develop As-is Business

Process Model

+

6.0Define Business Requirements

+

7.0Define Business

Rules

+

8.0Develop Requirements

Visualization

+

18.0Conduct Formal

Requirements Review

+

19.0Capture and Manage Requirements Defects

BRD rejected

FRDrejected

+

10.0Produce Business Requirements Doc

~

+

12.0Develop Use Cases

+

11.0Develop To-be Business

Process Model

+

13.0Define Application

Requirements

+


Visualization

+

21.0Manage Requests

for Change

~

No changes toBase-lined Requirements

Changes toBase-lined

Requirementsrequested

+


Traceability

+

15.0Produce Functional

Requirements Document

+

14.0Develop Business Data

Dictionary

+


Traceability

Peer Reviews

+

17.0Conduct Team Lead Review

+

16.0Conduct Peer

Review

Peer Reviews

+

17.0Conduct Team Lead Review

+

16.0Conduct Peer

Review

Project Approved forAnalysis Phase

+

14.0Develop Business Data

Dictionary

The UPS RDM Process




The UPS RDM Process

•  A guide for excellent requirements

•  Procedures for Elici6ng, Documen6ng, and Managing requirements

•  Standard set of tasks

•  Required deliverables

•  Quality standards

•  Requirements wri6ng Paderns

•  Aligned with BABOK Knowledge Areas and Techniques

PDD BRD

FRD

RTM

Architecture0Deliverables

Design0Deliverables

Test0Deliverables

RTM

Project0Management0Plans


© Copyright 2015 United Parcel Service of America, Inc. UPS, the UPS brandmark and the color brown are registered trademarks of United Parcel Service of America, Inc. All rights reserved. 12 12


“A Business Rule is a rule which governs the business. A Business Requirement is a

requirement of the business.”


© Copyright 2015 United Parcel Service of America, Inc. UPS, the UPS brandmark and the color brown are registered trademarks of United Parcel Service of America, Inc. All rights reserved. 13

Requirement Type BABOK ClassificaOon

Project ObjecOve –

Organiza6on / Customer goals; reasons for the project; measurable

Business Requirement

Business Requirement –

Business capability desired by the Project Sponsor and Stakeholders; bridge to solu6on requirements; technology and design independent

Stakeholder Requirement

FuncOonal Requirement –

System behavior; WHAT the system must do in response to condi6ons / triggers; HOW the system must behave; Not how the system must be designed

Solu6on Requirement – Func6onal Requirement

Non-‐funcOonal Requirement –

Constraints to system func6onality; Quality of service requirements; Govern system behavior; Categorized in types

Solu6on Requirement – Non-‐func6onal Requirement

Business Rule –

Condi6ons that govern work; business constraints; technology and design independent perspec6ve; categorized in types

N/A

13

Requirements Definition




Requirements Management

•  Requirements Traceabililty

•  Impact Analysis

•  Change Management

Requirements Traceability

Business Problem /

Opportunity

Project Objectives

Business Requirements

Business Rules

Functional Requirements

Non-functional Requirements

Functional Requirements





Requirements Quality

Project ObjectivesProject

Objectives

Business RequirementsBusiness

Requirements

Functional RequirementsFunctional

RequirementsUse CasesUse Cases

BusinessRules

BusinessRules

Business Problem / Opportunity

Business Problem / Opportunity

Non-‐functional Requirements

Non-‐functional Requirements

Recommended traceability.

Required traceabilityBusiness Initiative

Business Initiative

Context Level Diagram

Context Level Diagram

External Agent

External Agent

Essential Business Processes

Essential Business Processes

CapabilityCapabilityBusiness Process

DiagramBusiness Process

Diagram

BusinessData EntityBusiness

Data Entity

User Interface Requirement

User Interface Requirement

Reporting RequirementReporting

Requirement

Service Level Agreement

Service Level Agreement

Business RequirementsBusiness

RequirementsUse CasesUse Cases

PDD/Scope Item

PDD/Scope Item

Can Trace Downstream to All Items


Adopting a Requirements Definition & Management Tool


Dilbert, August 9, 1999 * Copyright 1999, Scott Adams


Requirements Definition & Management Tool


Problem Statements

•  Document-‐centric requirements management

•  Manual, labor-‐intensive Requirements Traceability

•  Inefifcient Requirements Change and Impact Analysis

•  Very lidle requirements reuse

•  Fragmented collabora6on among BAs

•  Inconsistent feedback and approval processes

•  Duplica6on of effort






ObjecOves

•  Support the UPS RDM process

•  Provide means to create complete Traceability

•  Eliminate the use of requirements documenta6on over 6me

•  Facilitate impact analysis and change management

•  Promote reusability and foster collabora6on

•  Provide single approach to reviews and approval process

•  Develop Enterprise libraries for Business Processes, Business Rules, Business Capabili6es


Tool Vendor EvaluaOon

•  Spent 2 years looking before making investment

•  Conducted reasearch – prepared several RFPs •  Conducted Pilots on 3 different tools

•  Desired features

•  Usability

•  Flexibility for different types of users (BAs vs. Stakeholders)

•  A tool that shows value right away – can be sold to the stakeholder community, not just BAs




Why Jama?

•  Designed with usability as a founda6on

•  Review Center, Collabora6on, and Traceability were important features for the BA community

•  Easy to design and configure

•  Other tools didn’t align with our expecta6ons on usage or value

•  Jama scored the highest across the 25 evalua6on criteria we used

•  The only tool to be endorsed across all the PorZolios




Guiding Principles for Pilot and Deployment

1.  Meet current requirements, but think about the big picture and the future

2.  We will need to make some compromises

3.  Don’t let the perfect be the enemy of the good

•  There are going to be some things we don’t like

•  Focus on where we will be beder off

4.  We will learn and evolve as we use the tool

5.  Understand the needs of our stakeholders

•  Don’t make it an academic exercise for the Business Analysts




Enterprise-‐wide Deployment

•  Obtained execu6ve approval and support for a limited pilot then full deployment

•  Posi6oned that there is no choice but to use the tool

•  Involved porZolio BAs in the design and configura6on of the environment

•  Developed a deployment plan to meet immediate needs and build founda6on for expansion

•  Developed a training plan based on the deployment needs

•  Gave porZolios the op6on to train all at once, or just in 6me

•  Applied a train-‐the-‐trainer approach




Challenges

•  Applying a mature process to a tool

•  Built a mature process over 6me then now asked people to change again

•  Needed to allow for flexibility while remaining consistent

• Selling the tool •  This is not a change to current processes – it’s

a tool to increase efficiency

• Custom configura6on to accommodate robust rules for requirements management




Challenges

•  Applying a mature process to a tool

•  Built a mature process over 6me then now asked people to change again

•  Needed to allow for flexibility while remaining consistent

• Selling the tool •  This is not a change to current process – it’s a

tool to increase efficiency

• Custom configura6on to accommodate robust rules for requirements management



Do not overwhelm and frustrate your end users!


Benefits We are Tracking •  Both the tangible and the not directly quan6fiable

Tool Adoption Success


Value Lever Description Re-Use Reduce time and effort with reuse of artifacts from a previous release

Traceability Creation Create multi-leveled associations between requirements, across projects; facilitates impact and coverage analysis

Historical Information Address requests for view of current state; Expect time savings, increased accuracy and improve quality in project estimates

Documentation Rework Reduce time in creating documentation; eliminate duplicate effort

Impact Analysis Reduce time and increase quality in planning and estimating based on impact (for both RFCs and new requirements)

Cross-functional Collaboration

Reduce number of work sessions, duration, and frequency; eliminate duplicate sessions with same stakeholders

Knowledge Transfer Reduce/eliminate re-work with an enterprise library of requirement artifacts; facilitate knowledge sharing for new team members

Requirement Reviews Streamline requirements reviews with targeted content; obtain feedback and receive required approvals; eliminate “marathon” review sessions


What We are Learning

•  It’s a gradual change – of process and of mind

•  Hard to get away from document templates

•  BAs and stakeholders s6ll want to produce documenta6on

•  Documenta6on should become an output of the data in the tool

• Consistency and structure gets you out of the gate – Flexibility will ul6mately yield success

•  Define a change process for tool configura6on

• BAs and stakeholders are re-‐learning how to define and manage requirements





Clear expectaOons

Tools support your process – not define it

Structured Flexibility Balance – Not Rigidity


Use common sense – Avoid the angry mob

Take-‐aways




© Copyright 2015 United Parcel Service of America, Inc. UPS, the UPS brandmark and the color brown are registered trademarks of United Parcel Service of America, Inc. All rights reserved. 31 31 © 2015 United Parcel Service of America, Inc. UPS and the UPS brand mark are trademarks of United Parcel Service of America, Inc.. All rights reserved.

QuesOons?


Thank You!


Documents

How UPS Delivers Modern Requirements · PDF fileHow UPS Delivers Modern Requirements Management November 5, 2015 Pedro Alvarez UPS –Business Analysis Practice Manager