Establishing a Winning Approach for Outsourcing Projects

1. Establishing a Winning Approach for Outsourcing Projects Terence Chow, Rational Technical Specialisttchow@hk1.ibm.com

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? Source: AberdeenGroup, August 2006

4. Why is requirements management so critical? “Analysts report that as many as 71 percentof 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. “Only 41% of projects are considered successful.” 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." – IBM CIO Study The CIO must drive down costs while increasing project success at the same time Reduce rework in all stagesof 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 Improve requirements definition productivity with current resources 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 Faster results – minimize delays that impact time to value A six-month delay can cost companies up to 33% of ROI on a five year business case

6. 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 Meaningful dialogue or alignment to strategy Stakeholders not engaged Stakeholder:" I do not have time, and no resources, so we will have to catch up later” Analyst: “People don’t seem to be on the same page” Sidebar conversations Low user involvement Stakeholder:" Here are my needs, in my models, and my documents. Call me today.” User: “Let me ask my manager if I can get more involved Unrealistic Unyielding Expectations No cross-functional collaboration or understanding 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 Stakeholder: “My process drives 90% of revenue, tell me when to test my solution No synergy, 41% of projects fail to achieve investment return Challenge: Poor collaboration between Parties Analyst

7. How’s Requirement flows…… How the project leader understood it How the customer explained it How the analyst designed it How the programmer wrote it How the business consultant described it How it was supported How the project was documented What operations installed How the customer was billed What the customer really needed

8. How to Manage Requirement

9. Goal Feature Function Rule Regulation Risk Objective Need Aim Criterion Requirements Are Everywhere Requirements

10. validating the product Stakeholder Acceptance Requirements test satisfies verifying the system System System Requirements test confront satisfies evaluating the subsystems Subsystem Subsystem ITIL, ISO9001 Requirements test satisfies evaluating components Component test Component Requirements Design Outsourcing Implementation Outsourcing IT Outsourcing Company Standard V-Shape Requirement Development Operational use Statement of need

11. Requirement Database • Unlimited hierarchy of Projects/Folders supports scalability Folders DOORS Documents Projects Deleted Folder Organize Your Projects

12. Document Views Spell check Everything you need in one window! Context OLE Requirements Improves productivity, reduces errors, increases quality

13. Show only what I am interest!

14. How to Manage Requirement Relationship?

15. Design Test Cases User Reqts Technical Reqts 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

16. Traceability; drag-and-drop linking Drag-and-drop to link within a document . . . . . . or from document to document  16

17. Traceability view User Reqts Technical Reqts Design Test Cases “End-to-end visual validation in a single view”

18. Traceability Verification or “Completeness” • Increases customer confidence • Detect missing links • Creation and deletion of links is recorded in history Traceability through an Orphan report shows “missing” links

19. Acceptance Stakeholder test Plan Requirements System System test plan Requirements Impact Analysis Impact Analysis Integration Subsystem Derivation Analysis test plan Requirements Derivation Analysis Component Component test plan Requirements Impact / Derivation Analysis

20. All requirements Acceptance Stakeholder are allocated to sub test Plan Requirements requirements? System System test plan Requirements Integration Subsystem All requirements are tested test plan Requirements without an exception? Component Component test plan Requirements Requirement Coverage Analysis

21. How to Manage Requirement Change?

22. Suspect Links Suspect links are visible directly in the document - as indicators or as a full description Clear on a right click Never miss a change again

23. structured, linked and traced, to produce reports of managed information The Requirement lifecycle Non-integrated project data is imported, 

24. Requirement is Good now. What about Delivery? Wu, Ying-Ki YK Rational Technical Specialistwuyingki@hk1.ibm.com

25. validating the product Stakeholder Acceptance Requirements test satisfies verifying the system System System Requirements test confront satisfies evaluating the subsystems Subsystem Subsystem ITIL, ISO9001 Requirements test satisfies evaluating components Component test Component Requirements Company Standard V-Shape Development & Delivery- Now focusing on Delivery Operational use Statement of need

26. 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 Although cancellation rates are downand fewer projects are troubled, improving software development governance provides increased value to projects, producing about 30% more projectsthat deliver expected value. Source: Standish Chaos Report, Allinean ROI of Software Development

27. 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 & Prod Lack of defect management process Lack of validation or verification • Last minute delay Lack of project transparency Lack of communication

28. Software Subcontract Management- Repeatable process to manage subcontractors Goals Commitment & Ability to perform Activities to perform Verification & Measurement Ensure regulatory compliance in a changing global environment Outsourcing can be a win-win situation

29. Goals towards SSM- Involves establishing specific, measurable and time-targeted objectives 1) Customer and subcontractor agree to their commitments to each other 2) Customer and subcontractor maintain ongoing communications 3) Customer tracks subcontractor’s result & performance against commitments Committing on goals is the 1st step to success

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

31. Commitment & Ability to perform towards SSM 1) Customer manager is designated to be responsible for establishing and managing subcontractor 2) Adequate resources and funding are provided for managing the subcontract 3) Subcontractors are trained and receive orientation in the technical aspects Assign clear responsibility and allocate adequate resources to reduce project risk

32. Assign clear responsibility and allocate adequate resources to reduce project risk- Know your team and role Defines Project Defines resources & responsibilities Defines project administrators

33. Activities to perform towards SSM 1) Contractual agreement between the customer and subcontractor is used as the basis for managing the subcontract 2) Documented and approved subcontractor’s software development plan to track the activities and status 3) Customer conducts acceptance testing as part of the delivery of the subcontractor’s software products Communication and tracking to monitor status

34. Activity: The work to be subcontracted is defined and planned according to a documented procedure- project transparency and communication Create snapshot to record of your progress. Structured plan to fulfill Software Subcontract Management, e.g. Business Objectives, Requirements, Acceptance Criteria, Schedule, Attachments, & etc

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

36. 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

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

38. Activity: The software subcontractor’s performance is evaluated on a periodic basis - project transparency and communication Real-Time tracking of covered requirements

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

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

41. 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.

42. Activity: Tracking the corresponding communication - Transparent and centralised overview of defect and its status Defect status In-Context Communication are kept !

43. Activity: Tracking the software activities and status- Transparent and centralised overview of defect and its status Audit Trail - Accountability

44. Activity: Tracking the corresponding communication - Transparent and centralised overview of defect and its status (Subcontractor’s view) Notifications, and defects will be displayed in dashboard Sub-Contractor’s profile: know which projects are involved Customisable charts for project analysis Know what is happening in this project

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

46. Measurement & Verification towards SSM 1) Measurements are made to determine the status of activities for managing subcontractor 2) The activities for managing the software subcontractor are measured & reviewed 3) Evaluation acts as input for future subcontractor selection criteria Ensure deliver quality products that satisfy customer’s expectation

47. Verifications are measured & reviewed- Testings are recorded as evidence for validation and verification Test Execution overview Result Details Subcontractor provides step-by-step screenshots evidence as attachments.

48. 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

49. The activities for managing the software subcontractor are measured & reviewed- Defects can be traced, and can be filtered Tracking all the defects

50. 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