CMMI with Agile - Contradict or Complement
5 likes1,893 views
The document discusses the relationship between CMMI (Capability Maturity Model Integration) and Agile methodologies, addressing common myths and realities. It highlights the benefits of integrating both approaches to improve project performance, emphasizing that CMMI provides structure while Agile offers flexibility. Key points include the nature of maturity models, the importance of adapting processes to specific organizational needs, and methods of collaboration for successful project management.
CMMI with Agile - Contradict or Complement
- 1. 1 CMMI with Agile Contradict or Complement ? By M. Rajamanickam SCAMPI Lead Appraiser & Enterprise Agile Coach
- 2. 2 What are we going to discuss? • CMMI and Agile – Myths & Realities • Let’s Revisit CMMI • Let’s Revisit Agile • CMMI with Agile– Similarities and Differences • Benefits of CMMI with Agile • CMMI and Agile Mapping • Q & A
- 3. 3 Agile & CMMI: Some Myths • CMMI is command and Control (Agile is self organizing) • CMMI is a heavy weight process (Agile is light / No process) • CMMI is a rigid model (Agile is flexible/No model) • CMMI is Process Oriented and Agile is People Oriented • CMMI expects/produces lot of documents (Agile does not require/produce any document) • CMMI is for big projects and Agile is for small projects • CMMI and Agile are at odds with each other: They can not go together • There is little or no planning in Agile • Agile teams have free run – No control… • You need very experienced team for Agile • Agile works in Product Development, but do not go together with outsourcing
- 4. 4 Why (or Where) do these myths come (from)? • Historic issues from early adaptors • CMM: Large scale, mission critical, risk averse, contractual projects • Agile: Small to Medium, fast paced, in-house projects with access to customers • Lack of familiarity & negative perceptions of each other • Perceived as two extremes: either CMMI world or Agile world • Confusing terminologies / jargons • CMMI perceived as ‘rigid,’ ‘Waterfall’; Agile perceived as ‘hacking’ • Lack of right information of each other • Improper implementation of Agile (and CMMI)
- 6. 6 Maturity Models – An Overview A maturity model is a structured collection of elements that describe characteristics of effective processes. A maturity model provides • a place to start • the benefit of a community’s prior experiences • a common language and a shared vision • a framework for prioritizing actions A maturity model can be used as a benchmark for assessing different organizations for equivalent comparison.
- 7. 7 What is CMMI®? A CMMI ® is a reference model of mature practices in a specified discipline, used to improve and appraise a group’s capability to perform that discipline. CMMI ® differ by • Constellation (e.g., Development, Services, Acquisition) • Structure (e.g., staged, continuous) CMMI can help • integrate traditionally separate organizations • set process improvement goals and priorities • provide guidance for quality processes • provide a yardstick for appraising current practices
- 8. 8 CMMI Model Framework Note: GOALS are the REQUIRED components and PRACTICES are the EXPECTED components
- 10. 10 CMMI Maturity Levels (Staged Representation)
- 11. 11 Level 1: the “Initial” Level - Success depends on heroes Good performance is possible - but • Requirements often misunderstood, uncontrolled • Schedules and budgets frequently missed • Progress not measured • Product content not tracked or controlled • Engineering activities nonstandard, inconsistent • Teams not coordinated, not trained • Defects proliferate “Processes limit my creativity”“Processes don’t help my delivery schedule”
- 12. 12 Top Management Middle Management Dept. B The Organization Dept. A Dept. C Project 1 Div. BBDiv. AA Project 4Project 3Project 2Projects Processes Sample Level 1 Organization - few processes in place
- 13. 13 Level 2 - The Foundation The basic foundation to be laid is good ‘Project Management’ • Most projects fail due to bad project management practices rather than technical issues
- 14. 14 Top Management Middle Management Dept. B The Organization Dept. A Dept. C Project 1 Div. BBDiv. AA Project 4Project 3Project 2 Projects Processes Sample Level 2 Organization many processes in place but they are project-specific
- 15. 15 Process Areas in Maturity Level 2 • Requirement Management (REQM) • Project Planning (PP) • Project Monitoring and Control (PMC) • Supplier Agreement Management (SAM) • Measurement and Analysis (MA) • Process and Product Quality Assurance (PPQA) • Configuration Management (CM)
- 16. 16 Maturity Level 2 – Summary • Maturity Levels • Maturity Level 1 - Ad hoc, sometimes chaotic • Maturity Level 2 - Activities planned, performed, monitored, and controlled at the level of a project.
- 17. 17 Level 3 – Process Standardization In Level 2, Project Management is disciplined, but not standardized • Very difficult to run big organizations that way • The main need is to standardize the processes across the organization • And to bring the discipline of Engineering practices
- 18. 18 Process Areas in Maturity Level 3 • Requirements Development (RD) • Technical Solution (TS) • Product Integration (PI) • Verification (VER) • Validation (VAL) • Organizational Process Focus (OPF) • Organizational Process Definition (OPD) • Organizational Training (OT) • Integrated Project Management (IPM) • Risk Management (RSKM) • Decision Analysis and Resolution (DAR)
- 19. 19 Sample Level 3 Organization Div. AA The Organization Dept. A Dept. C Div. BB Projects Processes Project 1 Project 2 Dept. B Project 3 Project 4 SEPG Process Asset Library Approved life cycles Standard processes Tailoring guidelines Process database Related documents
- 20. 20 CMMI – complete with High Maturity practices • After Organizational level standardization in Level 3, the focus is on quantitative management and continuous improvement • CMMI Level 4 & 5 are focused on the same
- 21. 21 Summary of CMMI • Select appropriate model representation to suit your business goals • Interpret the CMMI Model appropriately to your project/ organization appropriately • CMMI process areas provide framework for process improvement and for assessing capabilities • Provides “outline” for corporate processes • Specific and generic practices provide foundation for meeting process maturity goals for each process area • Represents industry’s set of “best practices” for engineering and product development • High level of compatibility/synergy with other standards and methods
- 22. 22 Things to Remember • CMMI is a Model, not a Standard • CMMI Process Areas (PAs) are not Processes / procedures • CMMI is not a prescriptive model, it is a descriptive model (CMMI does not prescribe ‘How’ to do it, it only mentions ‘what’ to do) • CMMI does not certify a company (CMMI certified Company is a misnomer!)
- 23. 23 Let’s Revisit Agile Methods
- 24. 24 The Basic Issue of Software Development • Ziv’s Uncertainty Principle • Uncertainty is inherent and inevitable in software development processes and products • Humphrey’s Requirements Uncertainty Principle • For a new software system the requirements will not be completely known until after the users have used it • Wegner’s Lemma • It is not possible to completely specify an interactive system
- 25. 25 Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: 25http://agilemanifesto.org/ Individuals and Interactions Processes and Tools Working Software Comprehensive Documentation Customer Collaboration Contract Negotiation Responding to Change Following the Plan over over over over That is, while there is value in the items on the right, we value the items on the left more.
- 26. 26 Agile Principles • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. • Business people and developers must work together daily throughout the project.
- 27. 27 • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. • Working software is the primary measure of progress. • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Agile Principles
- 28. 28 • Continuous attention to technical excellence and good design enhances agility. • Simplicity--the art of maximizing the amount of work not done--is essential. • The best architectures, requirements, and designs emerge from self-organizing teams. • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Agile Principles
- 30. 30 Features of traditional software! * Standish Group Chaos Report 2002
- 33. 33 Analysis Design Coding Testing 20% done (100% usable!) Ø Develop 20% of the features that deliver 80% of value Ø Develop and deploy highest priority first Ø Stop when you run out of time or money Time The Agile Process
- 34. 34 Traditional vs Agile Development Requirements Cost Schedule Constraints Estimate Cost Schedule Requirements Traditional Agile Source: Michele Sliger: Relating PMBOK Practices to Agile Practices on StickyMinds.com
- 36. 36 Release planning Sprints 1 2 3 4 5 6 7 Release 1 Release 2
- 37. 37 Main Differences (CMMI & Agile) CMMI Agile Discipline Agility Predictability Performance Proactive Reactive Descriptive (What) Prescriptive (How) Quantitative Qualitative Stability Speed Institutionalization (Project & Organization) Project Specific (Individual projects) Standardization Innovation Documented knowledge Tacit knowledge Scalable Scalable? Knowledge sharing across the organization Knowledge sharing within the project
- 38. 38 Myths Revisited… • Some myths: • CMMI is command and Control (agile is self organizing) • CMMI is a heavy weight process (Agile is light / no process) • CMMI is a rigid model (Agile is flexible/no model) • CMMI is Process Oriented and Agile is People Oriented • CMMI expects/produces lot of documents (Agile does not require/produce any documents) • CMMI is for big projects and Agile is for small projects • CMMI and Agile can not go together • There is little or no planning in Agile • Agile teams have free run – no control • You need very experienced team for Agile • Agile and outsourcing do not go together
- 39. 39 What is the Reality? • CMMI is NOT Command and Control, you can interpret CMMI to your specific needs • CMMI need not be heavy weight, can be ‘tailored’ to specific project needs • CMMI is a model, not a standard. • If CMMI is perceived as rigid, the problem could be inappropriate interpretation • While CMMI is process oriented, this does not ignore people (relook at the definition of Process as per CMMI). • Agile is equally process oriented too (Look at the Scrum Process and rules) • CMMI does not expect any unnecessary documents. • If you can not justify a document, do not produce it.
- 40. 40 • While CMMI is conceived for big project environments, it works very well with small projects too (with appropriate interpretation and tailoring) • Many big and complex projects implement Scrum (Eg. Yahoo!) • Agile and CMMI can work very well with each other • There are instances companies have appraised at CMMI Level 5 with Agile processes • Agile too stresses on planning, in fact in multiple levels • Daily Planning, Sprint Planning, Release Planning, Product Planning, Product Strategy, etc., • Agile teams are self organizing: • More effective than command and control • You do not need all experienced people in Agile • Experts and new bees work well in an Agile team • Agile methods suit well for Product Development Environment • However, they can be adjusted for outsourcing environment What is the Reality?
- 41. 41 What are the Similarities? • Both Agile and CMMI focus on Planning • Target of both are High Performance Organization • Both have process (of varying details, though) • Both are based on experience • Both may not work on ‘any’ project Advantages of using both: • CMMI provides the discipline where as Scrum brings in the flexibility & speed • Agile practices could become more mature with CMMI (Matured Agile!) • Agility could be institutionalized across the organization through CMMI • Organizational cross learning of agility through CMMI practices
- 42. 42 Lots of work have already been done! • Standard references are available both from CMMI Community and Agile Community • CMMI or Agile: Why Not Embrace Both! (Hillel Glazer, Jeff Dalton & Dave Anderson) • Scrum and CMMI – Going from Good to Great (Jeff Sutherland, Carsten Ruseng Jakobsen) • Scrum and CMMI Level 5: The Magic Potion for Code Warriors (Jeff Sutherland, Carsten Ruseng Jakobsen & Kent Johnson) • And many more…
- 43. 43 CMMI & Scrum Cross Mapping for Maturity Level 2
- 44. 44 Process Areas in Maturity Level 2 • Requirement Management (REQM) • Project Planning (PP) • Project Monitoring and Control (PMC) • Supplier Agreement Management (SAM) • Measurement and Analysis (MA) • Process and Product Quality Assurance (PPQA) • Configuration Management (CM)
- 45. 45 Requirements Management • Purpose: • The purpose of Requirements Management (REQM) is to manage requirements of the project’s products and product components and to ensure alignment between those requirements and the project’s plans and work products. Requirements Obtain an Understanding of Requirements Obtain Commitment to Requirements Traceability Matrix Maintain Bidirectional Traceability of Requirements Identify Inconsistencies Between Project Work and Requirements Manage Requirements Manage Requirements Changes Requirements Obtain an Understanding of Requirements Obtain Commitment to Requirements Traceability Matrix Maintain Bidirectional Traceability of Requirements Identify Inconsistencies Between Project Work and Requirements Manage Requirements Manage Requirements Changes ✔ ✔ ✔ ✖ ✔
- 46. 46 What needs to be done… • Do the preparative activates in Sprint Zero • may not be classical Agile practice! Sprints Zero 1 2 3 4 5 6 7 Release 1 Release 2
- 47. 47 Major activities in Sprint Zero • Identify Team (& Get them on board) • Train the team on Agile, if not done already • Gather high level requirements (Build Initial Product Backlog) – Write initial User Stories • (Relative) Estimation of User Stories • Release Planning, if required (with cost estimation) • High level architecture (where required) • Logistics Setup (Technical Infrastructure) • Identify major risks, constraints & assumptions • Prepare an overall plan (and still be flexible!) • Sprint Zero may not have potentially shippable product increment. That’s OK!
- 48. 48 Project Planning • Purpose: • The purpose of Project Planning (PP) is to establish and maintain plans that define project activities. Determine Estimates of Effort and Cost Planning Data Establish Estimates Estimate the Scope of the Project Establish Estimates of Work Product and Task Attributes Define Project Lifecycle Determine Estimates of Effort and Cost Planning Data Establish Estimates Estimate the Scope of the Project Establish Estimates of Work Product and Task Attributes Define Project Lifecycle Establish the Budget and Schedule Planning Data Develop a Project Plan Plan for Data Management Plan Stakeholder Involvement Plan for Project Resources Project Plan Establish the Project Plan Identify Project Risks Plan for Needed Knowledge and Skills PMC Establish the Budget and Schedule Planning Data Develop a Project Plan Plan for Data Management Plan Stakeholder Involvement Plan for Project Resources Project Plan Establish the Project Plan Identify Project Risks Plan for Needed Knowledge and Skills PMC Obtain Commitment to the Plan Reconcile Work and Resource Levels Project Plans Review Plans that Affect the Project Obtain Plan Commitment Relevant Stakeholders Obtain Commitment to the Plan Reconcile Work and Resource Levels Project Plans Review Plans that Affect the Project Obtain Plan Commitment Relevant Stakeholders ✔ ✔ ✔ ✔ ✔ ✓✖ ✓✖ ✖ ✖✖✖ ✖ ✔ ✔
- 49. 49 Project Monitoring and Control Context • Purpose: Provide understanding into the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan. Project Plan Monitor Data Management Monitor Commitments Monitor Project Planning Parameters Conduct Milestone Reviews Monitor Project Risks Analyze Issues Take Corrective Action Monitor Project Against Plan Conduct Progress Reviews Monitor Stakeholder Involvement Manage Corrective Action PP Manage Corrective Action to Closure Project Plan Monitor Data Management Monitor Data Management Monitor Commitments Monitor Commitments Monitor Project Planning Parameters Monitor Project Planning Parameters Conduct Milestone Reviews Conduct Milestone Reviews Monitor Project Risks Monitor Project Risks Analyze Issues Analyze Issues Take Corrective Action Take Corrective Action Monitor Project Against Plan Conduct Progress Reviews Conduct Progress Reviews Monitor Stakeholder Involvement Monitor Stakeholder Involvement Manage Corrective Action Manage Corrective Action PP Manage Corrective Action to Closure ✔ ✔ ✓✖ ✖ ✓✖✔✔ ✔ ✔ ✔
- 50. 50 Measurement and Analysis • Purpose: • The purpose of Measurement and Analysis (MA) is to develop and sustain a measurement capability used to support management information needs. Information need Specify Measures Measurement Repository Collect Measurement Data Measurement Results Establish Measurement Objectives Communicate Results Specify Analysis Procedures Measurement Objectives Store Data & Results Analyze Measurement Data Specify Data Collection and Storage Procedures Procedures and Tools Align Measurement and Analysis Activities Provide Measurement Results Information need Specify Measures Measurement Repository Collect Measurement Data Measurement Results Establish Measurement Objectives Communicate Results Specify Analysis Procedures Measurement Objectives Store Data & Results Analyze Measurement Data Specify Data Collection and Storage Procedures Procedures and Tools Align Measurement and Analysis Activities Provide Measurement Results ✖ ✓✖ ✖ ✖ ✖ ✔✔✔
- 51. 51 Process and Product Quality Assurance • Purpose: • The purpose of Process and Product Quality Assurance (PPQA) is to provide staff and management with objective insight into processes and associated work products. Reports and Records Objectively Evaluate Processes and Work Products Provide Objective Insight Objectively Evaluate Processes Establish Records Communicate and Ensure Resolution of Noncompliance Issues Objectively Evaluate Work Products & Services Relevant Stakeholders Reports and Records Objectively Evaluate Processes and Work Products Provide Objective Insight Objectively Evaluate Processes Establish Records Communicate and Ensure Resolution of Noncompliance Issues Objectively Evaluate Work Products & Services Relevant Stakeholders ✓✖ ✓✖ ✖ ✖
- 52. 52 Configuration Management • Purpose: • Establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits. Change Request Database Configuration Management System Identify Configuration Items Establish Configuration Management Records Establish a Configuration Management System Perform Configuration Audits Change Requests Action Items Audit Results Create or Release Baselines Reports Establish Baselines Establish Integrity Control Configuration Items Track Change Requests Track and Control Changes Change Request Database Configuration Management System Identify Configuration Items Establish Configuration Management Records Establish a Configuration Management System Perform Configuration Audits Perform Configuration Audits Change Requests Action Items Audit Results Action Items Audit Results Create or Release Baselines Reports Establish Baselines Establish Integrity Control Configuration Items Track Change Requests Track and Control Changes One of the major issues of Agile is the lack of explicit focus of CM activities. This can be taken care by the CMMI processes
- 53. 53 Supplier Agreement Management Purpose • Manage the acquisition of products and services from suppliers external to the project for which there exists a formal agreement. Product Establish Supplier Agreements Determine Acquisition Type Transition Products Accept the Acquired Product Select Suppliers Supplier Requirements Execute the Supplier Agreement Establish Supplier Agreements Satisfy Supplier Agreements Supplier Agreement PI TS Monitor Selected Supplier Processes Evaluate Selected Supplier Work Products ProductProduct Establish Supplier Agreements Determine Acquisition Type Transition Products Transition Products Accept the Acquired Product Accept the Acquired Product Select Suppliers Supplier Requirements Execute the Supplier Agreement Execute the Supplier Agreement Establish Supplier Agreements Satisfy Supplier Agreements Supplier AgreementSupplier Agreement PI TS Monitor Selected Supplier Processes Evaluate Selected Supplier Work Products Agile methods do not talk about any sub contracting. Use your CMMI processes, if needed. Ensure the sub contractor also follows Agile !
- 54. 54 CMMI & Scrum Cross Mapping for Maturity Level 3
- 55. 55 Process Areas in Maturity Level 3 • Requirements Development (RD) • Technical Solution (TS) • Product Integration (PI) • Verification (VER) • Validation (VAL) • Organizational Process Focus (OPF) • Organizational Process Definition (OPD) • Organizational Training (OT) • Integrated Project Management (IPM) • Risk Management (RSKM) • Decision Analysis and Resolution (DAR)
- 56. 56 Engineering Process Areas • Most of the Engineering practices are not explicitly covered in Scrum. However, it is suggested to use the following Agile Methods / practices: • Popular eXtreme Programming (XP) practices • Peer Programming • Refactoring • Continuous Integration (CI) • Test Driven Development (TDD) • It is also a good practice to use tools for TDD & CI
- 57. 57 Organizational Standardization PAs • Organizational Process Focus (OPF) • Organizational Process Definition (OPD) • Organizational Training (OT) • Scrum (or any other Agile Methods) do not explicitly address any of the practices of OPF, OPD and OT. The focus of most of the Agile methods are at project level (not organizational standardization of practices). • However, institutionalizing these practices at the Organizational level (which does not hinder Agile implementation in the projects) will help in making Enterprise Agile, which is a new topic of interest with the Agile Community.
- 58. 58 Integrated Project Management • Purpose: • Establish and manage the project and the involvement of the relevant stakeholders according to an integrated and defined process that is tailored from the organization’s set of standard processes. • Process and Product Measures • Documentation • Lessons Learned OPF Project’s Defined Process Use Org. Proc. Assets for Planning Project Activities Manage the Project Using the Integrated Plans Manage Stakeholder Involvement Stakeholder Coordination Issues Contribute to the Organizational Process Assets Manage Dependencies Resolve Coordination Issues Documented Critical Dependencies Collaborative Activities and Issues Coordinate and Collaborate with Relevant Stakeholders Use the Project’s Defined Process Establish the Project’s Defined Process Integrate Plans Integrated Project Plans Establish the Project’s Work Environment OPD • Process and Product Measures • Documentation • Lessons Learned OPF Project’s Defined Process Project’s Defined Process Use Org. Proc. Assets for Planning Project Activities Manage the Project Using the Integrated Plans Manage Stakeholder Involvement Stakeholder Coordination Issues Contribute to the Organizational Process Assets Manage Dependencies Resolve Coordination Issues Documented Critical Dependencies Collaborative Activities and Issues Coordinate and Collaborate with Relevant Stakeholders Use the Project’s Defined Process Establish the Project’s Defined Process Integrate Plans Integrated Project Plans Integrated Project Plans Establish the Project’s Work Environment OPD
- 59. 59 Interaction Between OPD and IPM Project A’s Defined Process Project B’s Defined Process Project A’s Project Plan Project C’s Defined Process Project B’s Project Plan Project C’s Project Plan Tailoring Guidelines Lifecycle Model Descriptions Organization’s Measurement Repository Organization’s Process Asset Library Organization’s Set of Standard Processes Process Architectures Project Environment Organizational Assets OPD IPM IPM IPM Work Environment Standards Project A’s Defined Process Project B’s Defined Process Project A’s Project Plan Project C’s Defined Process Project B’s Project Plan Project C’s Project Plan Tailoring Guidelines Lifecycle Model Descriptions Organization’s Measurement Repository Organization’s Process Asset Library Organization’s Set of Standard Processes Process Architectures Project Environment Organizational Assets OPD IPM IPM IPM Work Environment Standards
- 60. 60 Risk Management • Purpose: • Identify potential problems before they occur so that risk-handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives. Determine Risk Sources and Categories Define Risk Parameters Identify Risks Evaluate, Categorize, and Prioritize RisksDevelop Risk Mitigation Plans Implement Risk Mitigation Plans Risk Repository Prepare for Risk Management Identify and Analyze Risks Mitigate Risks Establish a Risk Management Strategy PP Determine Risk Sources and Categories Define Risk Parameters Identify Risks Evaluate, Categorize, and Prioritize RisksDevelop Risk Mitigation Plans Implement Risk Mitigation Plans Risk Repository Prepare for Risk Management Identify and Analyze Risks Mitigate Risks Establish a Risk Management Strategy PP
- 61. 61 Decision Analysis and Resolution • Purpose: • Analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria. • Applicability: • Documented guidelines should be provided when formal evaluation processes are to be used. • Not supported in Agile. Existing CMMI processes may be used with proper modifications (looking at Agile requirements of DAR)
- 62. 62 Decision Analysis and Resolution - Context Establish Guidelines for Decision Analysis Guidelines Evaluate Alternatives Select Evaluation Methods MethodsCriteria Establish Evaluation Criteria Select Solutions Identify Alternative Solutions Proposed Alternatives Evaluate Alternatives Other PAs Establish Guidelines for Decision Analysis Guidelines Evaluate Alternatives Select Evaluation Methods Methods Select Evaluation Methods MethodsCriteria Establish Evaluation Criteria Establish Evaluation Criteria Select Solutions Identify Alternative Solutions Proposed Alternatives Evaluate Alternatives Other PAs
- 63. 63 Conclusion • Agile and CMMI could be complimentary to each other & they bring lot of advantages to an organization • Agile brings in the flexibility & speed whereas CMMI provides the discipline (and sustenance) • Agile practices could become more mature with CMMI (Matured Agile!) • Agility could be institutionalized across the organization through CMMI • Organizational cross learning of agility through CMMI practices
- 64. 64 M. Rajamanickam (mrajamanickam@gmail.com) SCAMPI Lead Appraiser & Enterprise Agile Coach Managing Partner, ProXL Consulting, Chennai – 600 101