Managing Large Outsourced Projects

1. Managing Large Outsourced Projects A presentation By Sanjay Rai

2. The Market • Outsourcing Industry Expected to Hit $100 billion by 2010 • Outsourcing Requires Change in Management Approach • Initial Wave (Small or medium non-critical) applications giving way to large and mission critical application outsourcing • Ability to manage Second Wave projects is key to companies success

3. Key Issues – The Inverted Pyramid Transfer Complex Domain Knowledge Data Collation And Reporting Production Rollout Integrating Multiple User Sets Managing Multi Vendor Deliveries

4. Why Inverted In House Domain Budget Resource Deploy Identify Project From Domain Knowledge Define Project Costs Identify and Allocate Resources Build and Maintain Software Outsourced Budget Resource Deploy Domain Identify Cost Advantages Select Vendor Start Project Transfer Domain Knowledge • Unlike In-house Projects Outsourced projects are built bottom up

5. Transfer Domain Knowledge • Typically Effort in Acquiring Domain Knowledge Versus Effort on Developing the Application is • 30% when the development team starts from scratch • 20% when the development team has domain expertise • 15% when the build team incorporates domain experts from the client organization • Attempts to cut these times leads to a lack of domain knowledge resulting in time and cost overruns due to : • Poor Scoping • Bad Architecture • Incorrect Configuration • Strategy: Use Domain Specialists to: • Knowledge Transfer Session from end User • Get Certification for development team (if available) • Have Formal induction process for each of the project team member • Conduct Internal knowledge assessment sessions

6. Integrating Multiple User Sets • Business functionality is spread across various departments leading to • Conflicting user requirements • Scheduling conflicts leading to implementation delays • ‘Turf Wars’ over ownership of data • Fragmented Business Processes • No single view on end-to-end process for a business operation • Implicit manual intervention where systems are not adequate • Decision making authority for business operations not clearly defined • Strategy: Keep User Management Separate from Development • Have core user team represent all departments – intra organization • Set up internal change management to help users transition to new systems and processes

7. Managing Multi-Vendor Deliveries • Vendors have differing priorities for the project: • Required resources not available at the same time • Commercial constraints restrict vendor deliveries • Scheduled releases of products do not match project schedules • Conflict between vendors • Information not shared across vendors • Delaying tactics adopted by some vendors to prevent others from delivering • Problem resolution sessions degenerate into a “blame game” • Simple technical solutions cannot be implemented due to inter-vendor rivalry • Strategy: Keep Delivery and Commercial management separate • Steering Committees for delivery planning and management • Commercial Manager for handling commercial issues • Formal Organization Structure clearly defining relationships • Clearly define • Responsibilities • Risk Ownership • Backup Strategy (in case of Vendor Failure)

8. Data Collation and Reporting • Process not geared to meet project objectives • CMM alone does not help • Control degenerates into bureaucratic bottlenecks • Process used as an excuse for non-delivery • Data collected is unusable • Validity of data is suspect • Data is no longer relevant • Important information is lost in “chaff” • Lack of data to control scope • Scope measures not defined or not implement able • Scope creep in small increments • “Value Add” taken as license to agree to everything • Strategy: Set up process for delivering user experience • Measure progress against requirement delivery • Hire experts for project management (onsite and offshore) • Project manager travels along with the project (in multi-location cases) • Have project data audited periodically • Do not have separate processes for creating project data

9. Production Rollout • Multiple Environments (Develop, Test, Deploy, Debug) • Different versions in different environments • Traceability from development to deployment • Defects reported from production not replicable • Data inconsistency makes deployment environment unstable • Process adherence looses out to delivery commitments • Quality of delivered application is uncertain • Production configuration does not match delivery • Scope changes not documented • Strategy: Rollout in Phases till steady state • Size phases into manageable “bites” • Use Risk Based Management to schedule phases • Strategize for Product Upgrades • Manage Data as an independent activity

10. Key Management Practices • Identify appropriate management framework based on type of project: • Technology – Object Oriented or Legacy • Strategy – Waterfall, Spiral, RAD, JAD etc. • Location – Single or Multiple • Use an integrated risk management practice • Involve all parties • Make risk monitoring a part of reporting • Centrally manage risks across multiple teams • Keep focus on delivery • Focus teams on deliveries • Ensure all components are delivered together • Make it easy to fix penalties

11. Management Structure

12. Delivery Types • Fixed Time • Scope and Cost can vary deadline remains fixed • Deployment ‘as available’ prevents delays • Makes it possible to plan related activities and schedule resources well in advance • Can adversely affect quality • Fixed Scope • Time and Cost can vary as scope is fixed • Ensures that all user requirements are met • Assumes that all requirements are clearly defined at the start • Pressure on teams to get things “right first time” • Fixed Cost • Scope and time may change but effort remains constant • Protects the budget • Requires imaginative and flexible planning • Danger of having 100% tasks 90% complete when the budget runs out

13. Fixed Plus Variable Type • Create multiple phases with a “fixed time” • Makes it possible to orchestrate multiple parties and activities • Advance planning can significantly reduce costs • Vendor measure for each delivery can be used to measure performance • For each phase have a core “fixed scope” and an optional “variable scope” against a “fixed cost” • Gives client a clear view of the minimum delivery • Gives vendors the ability to add features and functions to improve user experience • Gives planning flexibility to create and execute risk mitigation strategies • Makes is possible to de-centralize the planning and scheduling process • Protects the budget within a band • No need to freeze requirements giving users more flexibility • Helps to scope out subsequent phases since unfulfilled requirements are documented

14. Reviews • Daily Reviews • Plan Vs Actual Yesterday • Tasks Planned for Day • Issues Outstanding • Risk Escalation • Weekly Review • Schedule Vs Actual (YTD, and Week) • Issues Outstanding • Risks • Defect Rates • Monthly Reviews • Schedule Vs Actual (Cumulative and Previous Month) • Plan Changes • Contingency Planning • Delivery Status

15. Key Metrics • Percentage Tasks Completed Vs Planned • Defect Rates • Budget Vs Actual • Percentage Tasks Completed on Time • Risks Materialized • Risks Outstanding • Percentage Issues Resolved • Ageing analysis of Outstanding Issues

16. On Going Registers • Issue Log • Change Control Log • Risk Register • Delivery Log • Defect Log • Configuration Log

17. Thank You