Project Management Institute

Project management reviews--a case study



Paper Abstract

Managing software projects is a challenging task. One of the important activities in project management is the systematic and periodic review of the project. This paper presents the evolution of the project management review process in Tata Consultancy Services (TCS), the authors' organisation. This paper maps the challenges faced by the organisation, as it grew in size and complexity, in making these reviews effective.

In the 1980s, when TCS was a modestly sized organisation, the project management reviews were need based and informal. Eventually, as the type of clients changed and the organisation began to grow, these reviews were made formal. The frequency of the reviews was mandated. Formal procedures were defined for carrying out the reviews. Projects included the reviews in their project plans. With further growth, centralised scheduling was organised and the reviews were conducted by specialised groups. A huge investment was made for research into understanding project complexities and arriving at simplified models capable of being understood and used by all. Activity Based Costing (ABC) was used as a major backbone for understanding and interpreting the way projects functioned and for identifying potential problems. Collaboration with international universities was also made to facilitate this research.

New techniques and methodologies, such as the use of the Balanced Scorecard, were constantly reviewed and adapted to suit the organisation's requirements. Software tools were developed in-house, and refined to cater to the adoption of these project-management techniques. These include the Integrated Project Management System, the Activity Based Costing system and repositories to maintain and track the presentations and findings of these reviews. Apart from procedures, templates and checklists to facilitate these reviews were designed, developed and used. These underwent many cycles of improvement. The review process was continuously evaluated and refined based on the feedback.

As the process became increasingly mature, focus of the refinement was shifted to making them more cost effective. Statistical Process Control and defect prevention techniques used by the projects provided valuable inputs to the review team to help effective prediction and better management of projects.


Tata Consultancy Services (TCS) is the largest software services and solutions provider in Asia. TCS has been a pioneer in creating the business models, which has made India a key supplier of software services in the world. More than 80% of its 23,227 associates work in projects, and, therefore, managing projects is one of its key processes. An important activity in managing projects is the systematic and periodic review of a project's progress. This paper presents the evolution of the Project Management Review (PMR) process in TCS - the authors' organisation. With the growth of the organisation, in terms of size and complexity, the challenges faced in making these reviews effective, changed. The lessons learnt in adapting and improving PMRs therefore provide valuable learning.

The ‘70's – The first steps

Part of the TATA group, one of India's largest business houses, TCS was set up in 1968, to primarily provide Bureau Services to the group's companies. Although these services were later provided for other Indian clients, it remained as the organisation's key offering util the mid ‘70s. The progress was monitored on a day-to-day and event-driven basis.

The TCS vision to make India a global software player resulted in expansion of its activities to include programming services to clients in U.S.A and Europe. TCS associates worked as contractors in customer locations. Being part of project teams managed by customers, the need for structured project reviews did not arise.

The ‘80s – The Decade of Business Model Maturity

Moving up the value chain, TCS bid for and won a number of turnkey projects during the 80s. This helped in improving the utilisation of our human capital, which in turn, resulted in major business gains. The era of organising ourselves as project teams had started. The status of these projects was reviewed through status reports and on an event-driven basis. The opportunities for learning from the best practices of some of our global customers helped improve the project management processes. This led to the development and use of project-specific tools for project management.

The late 80s saw the consolidation of domain specific experiences leading to major gains in terms of very large projects (more than 300 person years). The need for managing such large projects led to the definition of structured processes for project management reviews. These included periodic and event-driven reviews. Project specific ‘QA’ groups were set up to define these processes. They acted as the PMO and facilitated the PMRs. Special Tools Group for tool development specific to the projects helped automate processes and provided data for the reviews.

The key reviewer was the head of the delivery centre from where the project operated. The review focussed on progress against schedule, manpower plan in terms of team size, defects detected by independent reviews, issues and concerns. Since there were no organisational mandates for these reviews, they were formally carried out only within large projects, and mostly covered the immediate concerns of the project. Additionally, there was no independent verification of whether these reviews were being carried out and their effectiveness.

The ‘90s – The Decade of Process Maturity

The organisation's growing European business resulted in the decision to obtain ISO certification. A special task force was formed to document the organisation's Quality Management System, which included all Project Management processes. This team comprised of key members of successful large projects, helping to leverage from the lessons learnt and best practices. The PMR process thus defined was deployed across all TCS offshore delivery centres. The salient feature at this juncture of the evolution was that the Project Management Review process was totally integrated to the software development life cycle. It was also deployed across delivery centres.

An organisation level ‘QA Group’, independent of projects was formed for deploying and facilitating the conduct of PMRs, along with other processes. Process implementation was verified during project audits conducted by the Audit Group. Project Leaders were given formal training on PM including the PMR process (mandated).

Towards achieving the business need to provide cost effective services, TCS pioneered the setting up of client specific Offshore Development Centres (ODC) in India. A major change in PM practices during this period was the adoption of Activity Based Costing (ABC) adapted to suit the typical needs of the software industry. Detailed tracking of project costs was enabled through activity-wise effort data. Each project tailored the tracking system by grouping activities under project-specific modules, in alignment with the Operational Process in the Project Plan. While capturing the effort, it was linked to cost drivers (such as, normal, organisation-induced and client induced). These cost drivers were mapped to the project's Risk Management Plan. A monthly status card was generated for every project and used as a key input during the PMRs. The report included the project's Cost Of Quality and the total effort spent in terms of Value Added (For example, coding, review, training) / Non Value Added effort (For example, idle time, re-work). Other details such as the effort spent due to various cost drivers were also examined as part of the review. Cross verification of data was performed and questioned during the reviews, thereby motivating improved data quality (For example, correlation between the number of defects logged and the rework effort).

Analysis of the data was carried out and the reviewers provided guidance to resolve problems and suggestions for improvements. A Costing Group, consisting of qualified cost engineers was set up to facilitate the deployment and use of ABC. They also provided the design for a tool, which helped capture timesheets to support the adoption of ABC. Being a knowledge intensive industry, human resource utilisation was a key measure for the organisation. ABC now helped track this to any required granularity, during PMRs.

Towards the mid-'90s there was more emphasis on outsourcing. End-to-end solutions and more involvement in the entire life cycle of projects changed the PMRs to cover all aspects of project management at the level of customer relationship. Templates and checklists gained importance as tools to capture the PMR experiences.

The organisation chose to adapt SEI's SW-CMM, in 1996. The requirements of this model, over and above the existing processes resulted in their upgrade. The impact on Project Management was the use of advanced statistical techniques such as Statistical Process Control (SPC). Centre level process capability baselines were fixed. PMRs now included comparison of project's performance against these baselines. Outlier analysis and the action taken by the PLs were discussed during the PMRs. This ensured better control on projects by the PLs and relationship managers, and detection of potential problems and preventive actions. Management could now have better insight to project issues and progress. The Software Engineering Process Group (SEPG) helped define the processes and design tools to manage projects and simplify PMRs. All Project Leaders were trained on these processes and tools.

The need to review a large number of projects changed the review team composition. It was now made of a panel of senior project managers (of projects other than that under review) and support group representatives. Involvement of the support groups ensured that the action points relating to intergroup coordination are discussed, agreed upon and responsibility for closure identified.

The tracking of the PMR findings was slowly centralised using tools. The end of this decade saw the deployment of an Integrated Project Management System (IPMS) tool in some of the key centres. The ‘issue tracking’ feature of this tool was used for tracking the PMR findings. IPMS also provided the data required for measure such as schedule slippage, effort slippage and defect density. It also helped capture the timesheets. This database was maintained at the delivery centre level.

Exhibit 1 shows the PMR process. The Quality Assurance Group (QAG) at every delivery centre, in charge of process deployment, announces the review teams and prepares the monthly PMR schedule based on the projects at the centre. Projects prepare the presentation for the review based on a standard template, and guided by checklists. The QAG is responsible for the logistics and manage changes to the review team or the schedules. The review team is guided by checklists and also the past data. Centre-level Process Capability definitions, and client specified performance targets (For example, SLAs for maintenance requests, transaction time) are used as baselines for the review. Comparisons with best-in-class projects within the organisation are also carried out. Project audits check for closure of action items and the effectiveness of PMRs.

Exhibit 1

Exhibit 1

The streamlining of the review process and the refinements helped make it more focused. The time taken for the reviews was reduced. The review teams became more efficient. The tracking of the process improved, increasing its effectiveness. Exhibit 2 shows the trend of reviews scheduled vs. conducted, for a large delivery centre. The overall impact was to reduce the review time per project by more than 75%. With the beginning of a formal centre level suggestion scheme, many suggestions for improving the PMR began to be received. These were processed by the SEPG and accepted suggestions were implemented, thereby improving the PMR process.

Exhibit 2

Exhibit 2

The 2000s – Era of Integration and Alignment

With increasing focus on people management practices, the competency development model of the organisation underwent major refinements. Focus shifted from utilisation of individuals to utilisation of knowledge and skills. The progress against competency development plans became an additional focus in PMRs.

An integrated enterprise wide digitisation initiative was rolled out. Integrity of the data improved as it resided in a single database. Associates from across the globe could now log their time into a centralised database. Data relating to projects, associates, competencies and customers were linked through the enterprise-wide system. Requisite information was extracted from this database for use during the PMRs. As a spin-off from the reviews, dashboards were designed to simplify the ongoing tracking of performance.

Balanced Scorecard as a tool was adopted first at a customer relationship level, resulting in the Relationship Scorecard. This was used for tracking and review at a customer relationship level and in-turn acted as a motivator for inclusion of cascaded measures at the project level (For example, manpower resource mix and distribution). Templates and checklists were updated to ensure that these cascaded measures were reviewed during the PMRs.

Use of Balanced Scorecard was then extended to deploy the Organisation-level Strategy. This ensured better alignment of the project's measures and targets to that of the organisation. There was also a shift to include relevant measures in all four perspectives (Financial, Customer, Internal Process and Learning and Growth). Progress against the project's targets for all these measures, was verified during the PMRs. Deployment of a uniform process across the organisation, facilitated by common centralised tools and databases, marked the achievement of a new high in the maturity level of the PMR process. Contribution by the project team to the centre and organization level objectives, like the number of improvement suggestions, contribution to faculty hours, proposal preparation, update of common knowledge base with the project's lessons-learnt and best practices, etc. were also reviewed during the PMRs. The PMR findings across projects were consolidated at the delivery centre level. SLAs were defined for tracking the findings to closure and aging analysis of the findings were carried out (Exhibit 3 and 4). Causes were attributed to the findings, causal analysis done and preventive actions initiated for common causes across projects. Better PMRs have contributed to a large extent in improving the management of the projects (trends for key Project Management process measures shown in Exhibits 5 and 6).

The improvement in PMR process has been closely linked to the overall organizational growth. This has ensured that PMRs have not only helped review a project's progress, but has also helped motivate the adoption of the right Project Management Practices in alignment with the organizational needs.

Aging Analysis (for sample delivery centre)

Exhibit 3 – Aging Analysis (for sample delivery centre)

Aging Analysis - Trend (for sample delivery centre)

Exhibit 4 – Aging Analysis - Trend (for sample delivery centre)

Schedule slippage

Exhibit 5 – Schedule slippage

Effort Slippage

Exhibit 6 – Effort Slippage

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Project Management Reviews – A Case Study
April 2003
PMI – European Congress May 2003-Paper



Related Content