why do project fail? - ibm · pdf filewhy do project fail? 42% 37% 27% 26% 24% 24% ......

IBM Software Group | Rational software

1

Why do 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


2

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

®

IBM Software Group

© 2006 IBM Corporation

How to Manage Requirement


4

Requirements Are Everywhere

RequirementsObjective

Goal

Aim

Reg

ulat

ion

Criterion NeedFeat

ureFunction R

ule

Risk


5

Acceptance test

validating the product

StakeholderRequirements

V-Shape Requirement Development

Statement of need Operational use

satisfies

ComponentRequirements

Component test

evaluating components

SubsystemRequirements

Subsystem test

evaluating the subsystemssatisfies

SystemRequirements

System test

verifying the systemsatisfies

ITIL, ISO9001

Company Standard

confront

Implementation Outsourcing

Design Outsourcing

IT Outsourcing


6

Requirement Database� Unlimited hierarchy of Projects/Folders supports scalability

Organize Your Projects

Deleted Folder

DOORS Documents

Folders

Projects


7

Everything you need in one window!

Improves productivity, reduces errors, increases quality

Document Views

OLE

Context

Requirements

Spell check

®

IBM Software Group


How to Manage Requirement Relationship?


9

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


1010

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

. . . or from document to

document�

Traceability; drag-and-drop linking


11














adequacy?







































adequacy?


























Traceability view

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

User Reqts Technical Reqts Test CasesDesign


12

•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”


13


SystemRequirements



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


14


SystemRequirements



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?


16

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


17

structured,

linked and

traced,

Non-

integrated

project data

is imported,

to produce

reports of

managed

information

�

The Requirement lifecycle


18

Problems (or Risk) of Outsourcing –Risks are not fully shifted to outsourcing as Stakeholders bear the risk of project failure.

� Requirements are not fully covered by testing

� Lack of defect management process

� Lack of validation and verification

� Lack of Project Transparency


19

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 is still alarmingly high

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

®

IBM Software Group


How to Plan ?


21

Quality management planFirst step to succeed

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

Create snapshot to record of your progress.

®

IBM Software Group


How to Manage Test Coverage ?


23

Test CoverageFind requirements that have or have no test case


24

Test Coverage on updated (suspect) requirement


25

Test Coverage on updated (suspect) requirement

®

IBM Software Group


How to Manage Defect ?


27

Defect Management Transparent and centralised overview of development requests and status

List of defects with status


28

Defect Management – DashboardProvide information about the project status

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


29

Defect Management – Vendor to fix defects

Vendor fixes defect and update

status

Important communication is kept in discussion

section

Find Potential Duplicates


30

Defect Management – Audit Trail


31

Defect Management – Traceabilityunderstand which requirement has defect

®

IBM Software Group


How to Verify Quality ?


33

Validation on Quality Management Plan

Reviewal and Approval


34

Verification on Quality

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

Result Details

Test Execution overview

®

IBM Software Group


How to Manage Project Transparency ?


36

Project Transparency - On demand reportingSnapshot views of project status from multiple perspectives

Customizable reporting enables sharing and communicationof vital project information


37

Project Transparency - Finding overdue items

Over dueitem


38

Project Transparency – Finding all outstanding defects

Have vendor fixed all the defects?


39

Project Transparency – Acceptance Criteria

®

IBM Software Group


How to Manage Multiple Projects ?


41

Multi-Project SupportRepresentation of software projects

Different Project Area for different vendor


42

Summary

Business Benefits:

� Requirement Coverage – Make Sure that Project is focusing on defined Requirement inside the lifecycle, not at the end.

� Defect Management – All parties have visibility on defects and all activities, Sub-Contractor will be notified when new defects raised. Can be traced to requirements.

� Validation and Verification – Review + Approval + Collaboration. Evidence to meet Acceptance Criteria.

� Project Transparency – Real-time Dashboard + Report.

� Business Stakeholders and subcontractors can be anywhere in the world and work around the clock.

Sub-Contractors

SubSub--ContractorsContractors

Quality Assurance

Quality Quality AssuranceAssurance

BusinessBusinessBusiness


43

Centralized Quality Management Solution

ManageDefects

ReportResults

ExecuteTests

CreatePlan

BuildTests

IBM Collaborative Application Lifecycle Management

Quality Management

Rational Quality ManagerQuality Dashboard


Requirement Traceability

Telelogic DOORSCollaborative Requirement Repository

Impact Analysis Test Requirement

Test Result

Bi-directional auto-synchronization


44

Flexible Deployment




Impact Analysis

IBM Collaborative Application Lifecycle ManagementIBM Collaborative Application Lifecycle Management



Impact Analysis

ManageTest Lab

CreatePlan

BuildTests

ReportResults

ExecuteTests


Quality Management


ManageTest Lab

CreatePlan

BuildTests

ReportResults

ExecuteTests

ManageTest Lab

CreatePlan

BuildTests

ReportResults

ExecuteTests

IBM Collaborative Application Lifecycle ManagementIBM Collaborative Application Lifecycle Management

Quality Management


Customer Outsourcing


45

Benefits

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

� [DOORS] Requirement Integrity through Traceability

� Mitigate Potential risks of using Sub-contractors� [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


46