Establishing a Winning Approach for Outsourcing Projects

®

IBM Software Group

© 2007 IBM Corporation

Establishing a Winning Approach for Outsourcing Projects

Terence Chow, Rational Technical [email protected]

IBM Software Group | Rational software

2

The fantasy of outsourcing

Focus on the core business

Save cost

Better control on budget

Better ROI

Time to market / Time to profit

Access to expertise

Etc…..


3

Why do Outsourcing Project Fail?

42%

37%

27%

26%

24%

24%

0% 10% 20% 30% 40% 50%

Unclear or continually changing productdefinitions

Product does not meet customer or marketrequirements

Unrealistic schedule expectations

Projects not adequately staffed

Unclear or continually changing priorities

Unrealistic financial expectations

Source: AberdeenGroup, August 2006


4

Why is requirements management so critical?

“Analysts report that as many as 71 percent of software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure - bigger than bad technology, missed deadlines or change management fiascoes”

- CIO Magazine, November 2005


5

The CIO must drive down costs while increasing project success at the same time

Reduce rework in all stages

of development

30% of all project costs are associated with rework. Requirements mistakes account for up to 70% of this cost, at an average of $1,300 in labor to fix each requirement

“Only 41% of projects are considered successful.”– IBM CIO Study

A six-month delay can cost companies up to 33% of ROI on a five year business case

Requirements activities impact up to 35% of a project effort, and can cause waiting time, and redundant activities that eat up to 10% of your budget

Improve requirements definition productivity with current resources

Faster results – minimize delays that impact time to value

CIO Magazine recently reported, “as many as 71%of software projects that fail, do so because of poor

requirements management, making it the single biggest reason for project failure."


6

Analyst

Challenge: Poor collaboration between Parties

Current Concerns

Stakeholder interaction is inconsistent and disparate (email / docs)

Stakeholders overlooked or rely too heavily on delegates

Stakeholders see needs as unique, unable to understand and negotiate

CIO: “Our new strategic roadmap identified several areas we need to consolidate capabilities and costs, lets get the team to evaluate approaches that we can all get behind.”

No synergy, 41% of projects fail to achieve investment return

No Meaningful dialogue or alignment to strategy

Analyst: “People don’t seem to be on the same page”

Stakeholders not engaged Stakeholder:" I do not have time, and no resources, so we

will have to catch up later”

User: “Let me ask my manager if I can get more involved

Low user involvement

No cross-functional collaboration or understanding

Stakeholder:" Here are my needs, in my models, and my documents. Call me today.”

Sidebar conversations

Stakeholder: “My process drives 90% of revenue, tell me when to test my solution

Unrealistic Unyielding

Expectations


7

How’s Requirement flows……

How the customer

explained it

How the project leader

understood it

How the analyst designed it

How the programmer

wrote it

How the business consultant

described it

How the project was documented

What operations installed

How the customer was

billed

How it was supported

What the customer really

needed

®

IBM Software Group


How to Manage Requirement


9

Requirements Are Everywhere

Requirements

Obj

ectiv

eG

oalAim

Reg

ulat

ion

Criterion NeedFeat

ureFunction R

ule

Ris

k


10

Acceptance

test

validating the product

Stakeholder Requirements

V-Shape Requirement Development

Statement of need Operational use

satisfies

Component Requirements

Component test

evaluating components

Subsystem Requirements

Subsystem

test

evaluating the subsystems satisfies

System Requirements

System

test

verifying the system

satisfies

ITIL, ISO9001

Company Standard

confront

Implementation Outsourcing

Design Outsourcing

IT Outsourcing


11

Requirement Database Unlimited hierarchy of Projects/Folders supports scalability

Organize Your Projects

Deleted Folder

DOORS Documents

Folders

Projects


12

Everything you need in one window!

Improves productivity, reduces errors, increases quality

Document Views

OLE

Context

Requirements

Spell check


13

Show only what I am interest!

®

IBM Software Group


How to Manage Requirement Relationship?


15

1. 820.30(b) Design and Development Planning

Each manufacturer shall establish and maintain plans that describe or reference the design and developmentactivities and define responsibility for implementation.

The plans shall identify and describe the interfaces with different groups or activities that provide, or resultin, input to the design and development process.

The plans shall be reviewed as design and development evolves.The plans shall be updated as design and development evolves.The plans shall be approved as design and development evolves.

2. 820.30(c) Design Input2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a

device are appropriate and address the intended use of the device, including the needs of the userand patient.

2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to adevice are appropriate and address the intended use of the device, including the needs of the userand patient.

2.3. The procedures shall include a mechanism for addressing incomplete requirements.2.4. The procedures shall include a mechanism for addressing ambiguous requirements.2.5. The procedures shall include a mechanism for addressing conflicting requirements.2.6. The design input requirements shall be documented by a designated individual(s).2.7. The design input requirements shall be reviewed by a designated individual(s).2.8. The design input requirements shall be approved by a designated individual(s).2.9. The approval, including the date and signature of the individual(s) approving the requirements,

shall be documented.2.10. Questions.

2.10.1. Summarize the manufacturer's written procedure(s) for identification and control ofdesign input.

2.10.2. From what sources are design inputs sought?2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and

list additional aspects.)2.10.3.1. intended use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environment of intended use2.10.3.11. human factors2.10.3.12. physical/chemical characteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historical data2.10.3.20. design history files (DHFs)

2.10.4. For the specific design covered, how were the design input requirements identified?2.10.5. For the specific design covered, how were the design input requirements reviewed for

adequacy?

Comply with FDA Design Control Guidance GMP Regulation

1. Capture design and related information1.1. Input electronically formatted data1.2. Reference external information sources1.3. Reference external documentation

2. Store design and related information2.1. Identify and tag design information as unique “design elements”2.2. Organize design elements

2.2.1. Organize by Design Control Guidance Element2.2.2. Organize by inter-relationships

2.3. Ensure all design elements are available2.3.1. Store design elements by Design Control Guidance Element2.3.2. Store design elements and their historical values

3. Manage all user needs3.1. Identify the source of the user need3.2. Identify all user types (groups)3.3. Identify the customer (s)3.4. Profile the expected patients3.5. State the intended use of the product (family)3.6. Capture the acceptance criteria for each user need

4. Manage design input requirements4.1. Identify the source of the requirement4.2. Identify the associated user need4.3. Capture requirement description and attributes4.4. Capture acceptance criteria4.5. Assign responsibility for each requirement4.6. Manage incomplete requirements4.7. Manage ambiguous requirements4.8. Manage conflicting requirements4.9. Approve all requirements

5. Manage acceptance5.1. Ensure the acceptance of every user need5.2. Ensure the acceptance of every design input requirement5.3. Document the results of every user need acceptance test5.4. Document the results of every design input requirements test5.5. Make acceptance results available

6. Manage change6.1. Maintain history of design element changes

6.1.1. Make complete change history available6.1.2. Maintain history within and across any organizational procedure6.1.3. Maintain history within and across any project milestone6.1.4. Maintain history within and across any Design Control Guidance Elements

6.2. Capture frequency and nature of element changes6.2.1. Provide rationale for change6.2.2. Describe decisions made6.2.3. Identify approval authority for the change6.2.4. Capture date, time, and signature of approving authority

6.3. Identify impacted elements due to a change in another element6.3.1. Create backward traces to design elements within and across any organizational procedure6.3.2. Create backward traces to design elements within and across any project milestone

1.1. Identify impacted elements due to a change in another element Traceability Reports: consistency with driving design elements Impact Reports: other design elements affected Links to impacted design elements1.1.1. Create backward traces to design elements within and across any organizational

procedure Traceability Reports: Procedure Attribute

1.1.2. Create backward traces to design elements within and across any project milestone Traceability Reports: Milestone Attribute

1.1.3. Create backward traces to design elements within and across Design ControlGuidance Elements Traceability Reports: Linked design elements

1.1.4. Create forward impacts to design elements within and across any organizationalprocedure Impact Reports: Procedure Attribute

1.1.5. Create forward impacts to design elements within and across any project milestone Impact Reports: Milestone Attribute

1.1.6. Create forward impacts to design elements within and across Design ControlGuidance Elements Impact Reports: Linked design elements

1.2. Associate changed design elements with related elements Link Change Design Object with affected design element(s) Traceability Links and Reports from affected design element(s) Impact Links and Reports from affected design element(s)1.2.1. Associate design element changes with decisions, rationale, and approval authority

information Change Decision Objects with following Attributes: Disposition Attribute Decision Attribute Rationale Attribute Owner Attribute Management Approval Attribute

1.2.2. Provide associations within and across any organizational procedure Change Design Object Traceability Link on Procedure Attribute Change Design Object Impacts Link on Procedure Attribute

1.2.3. Provide associations within and across any project milestone Change Design Object Traceability Link on Milestone Attribute Change Design Object Impacts Link on Milestone Attribute

1.2.4. Provide associations within and across Design Control Guidance Elements Change Design Object Traceability Link to traced design elements Change Design Object Impacts Link to linked design elements

1.3. Mange the change process Design Change Module Design Change Reports Object History Object History Reports Versions Baselines














adequacy?


























User Reqts Technical Reqts Test CasesDesign

Traceability is the key to Requirement Managmenet

Initial user requirements should be decomposed to detailed requirements, then to design, tests, etc.

Decomposition creates traceability relationships

Relationships define your traceability model

Your traceability model is the basis for your process

Enforce your traceability model; improve your process


1616

Drag-and-drop to link within a document . . .

. . . or from document to

document

Traceability; drag-and-drop linking


17














adequacy?







































adequacy?


























Traceability view

“End-to-end visual validation in a single view”

User Reqts Technical Reqts Test CasesDesign


18

•Increases customer confidence

•Detect missing links

•Creation and deletion of links is recorded in history

Traceability through an Orphan report shows “missing” links

Traceability Verification or “Completeness”


19

StakeholderRequirements

SystemRequirements

SubsystemRequirements

ComponentRequirements

System test plan

Integration test plan

Componenttest plan

Acceptance test Plan

Imp

act

An

alys

is Derivatio

n A

nalysis

Derivation Analysis

Impact Analysis

Impact / Derivation Analysis


20

StakeholderRequirements

SystemRequirements

SubsystemRequirements

ComponentRequirements

System test plan

Integration test plan

Componenttest plan

Acceptance test Plan

All requirements are allocated to subrequirements?

All requirements are tested without an exception?

Requirement Coverage Analysis

®

IBM Software Group


How to Manage Requirement Change?


23

Suspect links are visible directly in the document -

as indicators or as a full description

Never miss a change again

Suspect Links

Clear on a right click


24

structured,

linked and

traced,

Non-

integrated

project data

is imported,

to produce

reports of

managed

information

The Requirement lifecycle

®

IBM Software Group


Requirement is Good now. What about Delivery?

Wu, Ying-Ki YK Rational Technical [email protected]


26

Acceptance

test

validating the product

Stakeholder Requirements

V-Shape Development & Delivery- Now focusing on Delivery

Statement of need Operational use

satisfies

Component Requirements

Component test

evaluating components

Subsystem Requirements

Subsystem

test

evaluating the subsystems satisfies

System Requirements

System

test

verifying the system

satisfies

ITIL, ISO9001

Company Standard

confront


27

Although cancellation rates are downand fewer projects are troubled,

improving software development governance provides increased value to projects, producing about 30% more projects

that deliver expected value.

Source: Standish Chaos Report, Allinean ROI of Software Development

The unsuccessful failure rate for software projects (including outsourcing) is still alarmingly high- Decision making, Accountability, Performance, Risk Management

Software project results

Project success rates average less than 55%

Cancelled projects cost $81 Billion worldwide each year

Of the 50% of projects which are successfully delivered, 28% of these projects are not yielding the expected planned value

Software project waste

$55 Billion

$38 Billion in lost dollar value

$17 Billion in cost over runs


28

Problems of Outsourcing – Risks are not fully shifted to subcontractors as stakeholders bear the risk of project failure.

Features are missing Requirements are not fully tested

Requirement changes are not being notified

Too many bugs in UAT & ProdLack of defect management process

Lack of validation or verification

Last minute delayLack of project transparency

Lack of communication


29

Software Subcontract Management- Repeatable process to manage subcontractors

Outsourcing can be a win-win situation

Activities to perform

Ensure regulatory compliance in a changing global environment

Commitment & Ability to perform

Goals

Verification & Measurement


30

Goals towards SSM- Involves establishing specific, measurable and time-targeted objectives

Committing on goals is the 1st step to success

3) Customer tracks subcontractor’s result & performance against commitments

2) Customer and subcontractor maintain ongoing communications

1) Customer and subcontractor agree to their commitments to each other


31

Goal: Define a clear ‘Acceptance criteria’ - Work towards defined goals


32

Commitment & Ability to perform towards SSM

Assign clear responsibility and allocate adequate resources to reduce project risk

3) Subcontractors are trained and receive orientation in the technical aspects

2) Adequate resources and funding are provided for managing the subcontract

1) Customer manager is designated to be responsible for establishing and managing subcontractor


33

Assign clear responsibility and allocate adequate resources to reduce project risk- Know your team and role

Defines resources & responsibilities

Defines project administrators

Defines Project


34

Activities to perform towards SSM

Communication and tracking to monitor status

3) Customer conducts acceptance testing as part of the delivery of the subcontractor’s software products

2) Documented and approved subcontractor’s software development plan to track the activities and status

1) Contractual agreement between the customer and subcontractor is used as the basis for managing the subcontract


35

Activity: The work to be subcontracted is defined and planned according to a documented procedure- project transparency and communication

Structured plan to fulfill Software Subcontract Management, e.g. Business Objectives, Requirements, Acceptance Criteria, Schedule, Attachments, & etc

Create snapshot to record of your progress.


36

Activity: The work to be subcontracted is defined and planned according to a documented procedure- Schedule check points to review subcontractor progress


38

Activity: A documented subcontractor’s software development plan is reviewed and approved by the prime contractor - project transparency and communication

Clearly define the responsibility of reviewal and approval


39

Activity: Subcontractor’s performance is evaluated on a periodic basis - Requirements are covered by test cases


40

Activity: The software subcontractor’s performance is evaluated on a periodic basis - project transparency and communication

Real-Time tracking of covered

requirements


41

Activity: Plan is used for tracking the software activities and communicating status- Requirement changes are being notified


42

Activity: Plan is used for tracking the software activities and status- Understand which test cases can be impacted due to requirement change (Impact Analysis)


43

Activity: Tracking the software activities and status- Transparent and centralised overview of defect and its status (defect tracking)

Manage, evaluate, prioritise defects in real-time. Understand project health and help to make right decisions.


44

Activity: Tracking the corresponding communication - Transparent and centralised overview of defect and its status

Defect status

In-Context Communication

are kept !


45

Activity: Tracking the software activities and status- Transparent and centralised overview of defect and its status

Audit Trail - Accountability


46

Activity: Tracking the corresponding communication - Transparent and centralised overview of defect and its status (Subcontractor’s view)

Sub-Contractor’s profile: know which projects are involved

Notifications, and defects will be displayed in dashboard

Customisable charts for project analysis

Know what is happening in this

project


47

Activity: Tracking the software activities status - Understand which requirement has associated defect


48

Measurement & Verification towards SSM

Ensure deliver quality products that satisfy customer’s expectation

3) Evaluation acts as input for future subcontractor selection criteria

2) The activities for managing the software subcontractor are measured & reviewed

1) Measurements are made to determine the status of activities for managing subcontractor


50

Subcontractor provides step-by-step screenshots evidence as attachments.

Result Details

Test Execution overview

Verifications are measured & reviewed- Testings are recorded as evidence for validation and verification


51

The activities for managing the software subcontractor are measured & reviewed- Tracking possible over due items, and take actions to minimize risks before project deadline

Tracking over due items


52

The activities for managing the software subcontractor are measured & reviewed- Defects can be traced, and can be filtered

Tracking all the defects


53

Measurements are made to determine the status of activities for managing subcontractor - Views of project status from multiple perspectives- Charting to show healthiness & completeness of project- Performance evaluation- Reference for future project


54

Overview of SSM on quality aspect

JAZZ TEAM SERVER

ManageTest Lab

CreatePlan

BuildTests

ReportResults

ExecuteTests

IBM Collaborative Application Lifecycle ManagementIBM Collaborative Application Lifecycle Management

FunctionalTesting Performance

TestingWeb Service

QualityManualTesting

Security andCompliance

Quality Management

Rational Quality ManagerQuality Dashboard

Open Lifecycle Service Integrations

DefectManagement

RequirementsManagement

- DOORS

Best Practice Processes

JavaSystem z, iSAP

.NET


56

Centralized Outsourcing Management Solution

ManageDefects

ReportResults

ExecuteTests

CreatePlan

BuildTests


Quality Management

Rational Quality Manager

Quality Dashboard


Requirement Traceability

Telelogic DOORSCollaborative Requirement Repository

Impact Analysis Test Requirement

Test Result

Bi-directional synchronization


57

Flexible Deployment

IBM Collaborative Application Lifecycle Management



Impact Analysis




Impact Analysis

ManageTest Lab

CreatePlan

BuildTests

ReportResults

ExecuteTests

IBM Collaborative Application Lifecycle Management

Quality Management


ManageTest Lab

CreatePlan

BuildTests

ReportResults

ExecuteTests

ManageTest Lab

CreatePlan

BuildTests

ReportResults

ExecuteTests


Quality Management


Customer Outsourcing


58

Benefits

Reduce outsourcing projects still have high failure rate [DOORS] Requirement Repository to maintain the “Source of Trust”

[DOORS] Requirement Integrity through Traceability

Mitigate risks of using Subcontractors [RQM] Real Time Quality Dashboard to increase Transparency

[RQM] Test Coverage visibility

[RQM] Defect Management

Improve your winning chance when outsourcing projects Real Time Monitoring & Tracking during lifecycle

Full Lifecycle Traceability ensure No Missing Issue

Highly Quality project delivery


59