1. © Mahindra Satyam 2009 QMS Overview- DH/RH Module

2. 2 © Mahindra Satyam 2009 Session Expectations  Understanding the Current QMS from DH/RH’s Perspective  Obtaining overview of the DH/RH’s role specific activities in a BU

3. 3 © Mahindra Satyam 2009 QUALITY POLICY To satisfy our customers by ensuring that the products and services we provide meet or exceed customer requirements and expectations.

4. 4 © Mahindra Satyam 2009 Process Structure Project Knowledge Base, Process Database Templates Tailoring Guidelines Methodologies Life Cycle Processes Project Mgmt Processes Support Processes Quality Policy Manual Training Kit Standards Work Instructions

5. 5 © Mahindra Satyam 2009 Quality Policy Manual Quality Policy Manual states the policies of Mahindra Satyam as applicable to the  Development and Maintenance of software  Engineering  Internal support services  Consulting Services  Managed infrastructure and Technology support services

6. 6 © Mahindra Satyam 2009 Quality Policy Manual For example,  In order to proceed with software development, the customer’s complete, unambiguous set of functional and non-functional requirements shall be documented – By Mahindra Satyam, or – By Customer and reviewed by Mahindra Satyam

7. 7 © Mahindra Satyam 2009 Methodologies Methodologies describe the life cycle phases for a particular project, depicting the ETVX (Entry, Task, Validation, Exit) criteria For example,  Object Oriented Methodology  E-Learning Methodology

8. 8 © Mahindra Satyam 2009 Project Management Processes Processing Project Proposals Project Initiation Project Planning Project Tracking and Monitoring Delivery and Deployment Project Closure Project Metrics Risk Management Configuration Management Project Estimation Inspections and Reviews Main Processes Generic Processes Conducting Contract Review Defect Prevention

9. 9 © Mahindra Satyam 2009 Life Cycle Processes Requirements Gathering and Analysis Design Construction / Unit Testing Integration System and Acceptance Testing Warranty Programming Guidelines

10. 10 © Mahindra Satyam 2009 Support Processes Processes for the activities of Support Units For example,  Corporate Quality Processes  N & S Processes

11. © Mahindra Satyam 2009 Overview of Project Life Cycle

12. 12 © Mahindra Satyam 2009 Overview of Project Life Cycle Processing Project Proposals Project Initiation Project Planning Delivery and Deployment Project Closure Conducting Contract Review Project Tracking and Monitoring Project Acquisition Estimation Project Planning Project Execution

13. 13 © Mahindra Satyam 2009 Project Acquisition Proposal Preparation Customer Master Agreement Sends ‘or’ PO Review WOs Request for Proposal Sends Proposal Project Planning Sends

14. 14 © Mahindra Satyam 2009 Project Acquisition – DH/RH’s Responsibilities  Ensure adherence to QMS while processing – RFP from external customers – In house requisition from internal customers  Approve projects for skill / competency building in new technology areas  Review the basis for Customer’s rejection, if any, of the proposal, along with the proposal team and the receiver of the RFP  Review the analysis of data on proposals submitted, proposals accepted and rejected by the BU

15. 15 © Mahindra Satyam 2009 Project Acquisition – DH/RH’s Responsibilities  Approve the initiation of projects where a formal contract is not available.  Control contract related deliverables like Signed Contract or Purchase Order/Work Order

16. 16 © Mahindra Satyam 2009 Project Planning A Identification of PL Project Kick-off meeting Access to On-line systems B Project Information in SPR Resources from RCC Resources from SSUs Negotiations Project Acquisition Project Initiation

17. 17 © Mahindra Satyam 2009 Project Initiation – DH/RH’s Responsibilities  Provide necessary documents/relevant information for initiating the project  Approve billable and non billable projects

18. 18 © Mahindra Satyam 2009 Project Planning B Inputs for Project Planning C Project Estimation Risk Management Identification of Roles and Responsibilities Project Plan Preparation Defect Prevention Project Execution Project Initiation

19. 19 © Mahindra Satyam 2009 Project Execution Project Delivery Project planning Status Updation (TSMS) (MS Project) Customer Communication Organization of Team Training to Team C D Project Tracking Project review meetings Work Execution Work Allocation Configuration Management (VSS) Inspections/ Reviews Audits Metrics Testing Defect Prevention

20. 20 © Mahindra Satyam 2009 Project Closure Project Tracking Acceptance E D Onsite Installation Software Replication & Delivery Project Delivery

21. 21 © Mahindra Satyam 2009 Project Closure E Release of Manpower and Terminals Taking Back-ups Revoking access to On-line systems Handing over Project File to Library Project Delivery Project Retrospective Meeting Project Retrospective Report Best Practices and Lessons Learned

22. © Mahindra Satyam 2009 DH/RH’s Responsibilities at BU Level

23. 23 © Mahindra Satyam 2009 Alliance Management  To be in charge of all the operations of the Alliance as per the agreement.  To ensure that the Alliance operations meet the mutually agreed Service Levels and Objectives

24. 24 © Mahindra Satyam 2009 DH/RH’s Overall Responsibilities  To ensure that all types of resources are made available in Mahindra Satyam in a timely manner for effective implementation of QMS and addressing customer satisfaction.  To ensure that the Quality Policy and the QMS are followed by all the levels in the Group  To ensure that the responsibilities and authorities of the associates in their Group are defined and communicated, as relevant.  To ensure that appropriate communication takes place in their Group.

25. 25 © Mahindra Satyam 2009 DH/RH’s Overall Responsibilities  To ensure that quality objectives are established at all relevant levels in their Group,in line with the overall quality objectives of Mahindra Satyam  To ensure Business Continuity and Information Security in their respective Groups  To ensure that customer requirements are determined and fulfilled with the aim of achieving customer satisfaction  To participate in the corporate and Group level Quality Management Review meetings

26. 26 © Mahindra Satyam 2009 Terminology Refresher EstimatesProject Metrics Metrics Baselining Project Knowledge Base (PKB) Suggestion HandlingInspections CAR and DP PMR and QMR - PMR PMR and QMR - QMR Team CharterShared Vision DAROID Pareto Analysis

27. 27 © Mahindra Satyam 2009 Estimates The initial estimates would be arrived at during Project Acquisition Phase  These estimates are communicated to the customer  These estimates form input to estimation at Project Planning Phase The estimates at project planning may differ from those at project acquisition  These estimates are internal to the project (may not be communicated to the customer)  These estimates are used for tracking the project  Required planning need to be done to cover the discrepancies

28. 28 © Mahindra Satyam 2009 Project Metrics Measure  Measures are numerical values assigned to software attributes. E.g., 80 Lines of Code (LOC) Metrics  a metric is a combination of measures that provides insight into software development. E.g., – 80 LOC per person day(a ratio) – Planned 8 person days;Actual 10 person days (a comparison) Metrics Analysis  The use of metrics data to – compare the performance of the process against the target – identify problems – assess problem impact – project an outcome, or – evaluate alternatives related to issues

29. 29 © Mahindra Satyam 2009 Project Metrics  The objective of Quantitative Project Management is to manage the performance of the projects through metrics  The typical measures are size (FP or LOC), effort(in person days), schedule (in calendar days) and defects (in number)  The typical metrics are effort estimation variance, schedule estimation variance, defect density, productivity  During metrics analysis, previously collected data is converted into information that is used by the decision makers  Statistical techniques like Run charts, Control Charts and Cause-and-Effect Diagram are used for Metrics Analysis and decision making

30. 30 © Mahindra Satyam 2009 Metrics Baselining Process capability baseline is derived by Metrics Group of Quality every 4 months based on the data from completed projects It is calculated at Company-level and Unit-level. It indicates  what performances have been achieved, and  what the process is capable of delivering  It is represented in two different ways  Process Capability Limits  Process Performance Percentiles It is used for  Estimating performance of future projects  Identifying areas for process improvements

31. 31 © Mahindra Satyam 2009 Project Knowledge Base (PKB)  Project Knowledge Base (PKB) in QUALIFY is a one point reference to – Process database containing metrics data and baselines – Best Practices – Lessons Learnt – Risks – Tools – Sample Documents  The information is collected from completed or ongoing projects in retros and intros  The information is used in the projects for better execution  PKB is managed by the PMG

32. 32 © Mahindra Satyam 2009 Suggestion Handling Suggestions (and Ideas)  Can be given by any Associate  Will be received by the Process Management Group (PMG)  Are entered into the QMS Changes database in Qualify  PMG  Takes action on the suggestions  Updates the QMS Changes database for process improvement suggestions  Tracks the suggestion to closure

33. 33 © Mahindra Satyam 2009 Inspections  Inspections are more structured than reviews  Inspections are mandatory for Project Plans, URD, SRS, High Level Design document, User Documentation  Inspections are mandatory for detailed design and code review when the team member – is new to the project – is new to the technology

34. 34 © Mahindra Satyam 2009 CAR and DP De fect  A defect is what was wrong or incorrect in the work product  Defect Cause  A defect cause is some preceding incident that brought about the defect  Causal Analysis and Resolution (CAR)  to analyze the defects  to identify the causes for the same  Using statistical techniques e.g. Pareto, Cause-and-Effect  Defect Prevention (DP)  to implement actions that will prevent those defects from recurring  The actions are reviewed for their effectiveness

35. 35 © Mahindra Satyam 2009 PMR and QMR - PMR Project Management Review(PMR) Meetings  are meant for monitoring the progress of the project at milestones  attended by the PM, PL and the project team  are used to decide on preventive and corrective actions wherever necessary  are used for information sharing within the project team on project-based issues Inputs: Project Workbook  QUANTIFY reports for metrics and DP  Project Risk Report  Internal Quality Audit and PPM Reports Output: MOM in Project Workbook

36. 36 © Mahindra Satyam 2009 PMR and QMR - QMR Quality Management Review (QMR) Meeting is for  Setting the Quality goals for Group within the frame work of Organizational Quality Goals  Reviewing the plans and Progress  Resolving quality related issues  Learning and contributing towards Group /Organizational Quality Journey  Attended by – BU Head (as Chairperson) – PM Heads or equivalents – Other persons, as decided by BU Head – Quality Representatives

37. 37 © Mahindra Satyam 2009 Team Charter  A team charter is a documentary evidence that establishes roles and responsibilities of the project Team (PM, PL, TMs) with required authority  In our context, Project Plan forms the team charter  The roles of the team members, their interaction channels, interfaces and communication channels with the support units are established in the Organization structure in the project plan

38. 38 © Mahindra Satyam 2009 Shared Vision Shared Vision is that common objective that drives us, as teams, as a BU, as a company, etc. Examples of shared vision are :  Team level – Project plan, project requirements, project standards, etc.  BU level – BU vision, Orbit 5 journey, BU level measures and their percolation down to account and project levels  Organization level – Quality Policy, Orbit 5, Qualify, standard tools like Quantify, Business objectives and directives

39. 39 © Mahindra Satyam 2009 Pareto Analysis  Pareto analysis is a process for ranking causes, alternatives, or outcomes to help determine which should be pursued as high priority actions or opportunities for improvement  It is a useful technique following 80-20 principle  Pareto charts can be used at various stages in a quality improvement program to help select the steps to take next  Pareto charts are essentially frequency counts or amounts displayed in descending order

40. 40 © Mahindra Satyam 2009 DAR  Decision Making Steps  Identify the decision to be made together with the goals it should achieve  Get the facts  Develop alternatives  Rate each alternative  Rate the risk of each alternative  Make the decision

41. 41 © Mahindra Satyam 2009 DAR  Decision Making Techniques  Pugh method or decision-matrix method  Brainstorming  Delphi Method  Software QFD

42. 42 © Mahindra Satyam 2009 OID  Organizational Innovation and Deployment  A first of the kind  Originating from the activities of the Organization  A thought wave envisioning benefits

43. 43 © Mahindra Satyam 2009 Let’s participate in the Quality Journey!