Abstract
This paper discusses the key issues faced by IT Service Providers in their projects under the category of Firmed Fixed Price (FFP). It further discusses the utility of Earned Value Management (EVM) concept for Cost and Schedule variances under FFP, suggests how to manage costs in pre-agreed Delivery Cycles and also guides Project Managers for certain actions to address this issue. All these concepts and their applications are discussed through a Case Study for one of the leading Indian IT Service Providers.
Key issues related to Firmed Fixed Price (FFP) projects:
Any Firmed Fixed Price engagement can be thought of comprising two main cycles namely the Bidding Cycle and the Delivery Cycle.
Bidding Cycle:
Theoretically, FFP type of outsourcing projects should have very clearly defined Scope of the assignment, along with clearly and specifically stated Statement of Work (SOW), which should be adequate for the service providers to accurately estimate the project efforts involved. However, in reality, in many instances of project outsourcing to offshore destinations like India, the outsourcing agreement is signed, although the engagement scope is not clearly defined. This creates problems of scope creep, time and costs overruns, increases risk and reduces the profitability of the assignment for the service providers.
Delivery Cycle:
Taking the final negotiated Firmed Fixed Price in the Bidding Cycle as the base price, the Project Manager has to manage the project costs and schedules. Quite often the project may need to be rebaselined during the Planning Phase of Delivery Cycle. The following are the conflicting motives, between clients and service providers in FFP engagements:
- Clients want to minimize their cost and time risks (even without knowing the exact scope of the assignment), and generally negotiate for a lower than RIGHT Firmed Fixed Price for engagements, in order to meet their annual budget targets and get maximum work done.
- Service Provider's corporate management wants to get a higher revenue from the engagement in order to meet their objectives of profitability.
It is apparently very difficult to resolve this conflict, but EVM analysis can help the Project Manager to manage this conflict. The authors are suggesting an approach, which can guide Project Managers to take the help of EVM analysis and a set of actions need to be taken within their control, so that the situation can meet most of the expectations of all the stakeholders. This is also illustrated through a real-life case study, where it proved successful.
Before going into the case study, here is a brief outline of the concepts of EVM.
Broad understanding of EVM:
EVM is a method of measuring project performance by comparing the amount of work planned with that actually accomplished and the actual cost incurred, in order to determine if cost and schedule performance are as planned (Fleming, Hoppelman, 1996, p9). It is a management approach that integrates the scope of work, the schedules and the costs, allowing for the continuous measurement of integrated performance throughout the lifecycle of the project and calls for corrective actions. The scope is defined in terms of Work Break-down Structure (WBS), clearly describing the deliverable-oriented grouping of project elements, assigning the clear responsibilities and the planned budgets for those deliverables. Then ALL the elements of WBS are to be placed into time frames, based on some scheduling method so that the performance (or the lack of it) can be measured throughout the lifecycle of the project.
The basic concept of EVM is quite simple. There are three basic data elements defined, as listed below, but all are in monetary terms. Scheduled Work is expressed in terms of budgeted costs of the elements of WBS in a given timeframe. Work Accomplished is expressed in terms of budgeted cost of the work actually completed (or part completed) in WBS elements in the same timeframe; and finally the Actual cost incurred for the work accomplished in the same timeframe.
| Basic Data Element | PMI Terminology | Original Management Terminology |
| Scheduled Work | Planned Value (PV) | Budgeted Cost of Work Scheduled (BCWS) |
| Work Accomplished | Earned Value(EV) | Budgeted Cost of Work Performed (BCWP) |
| Actual Cost of Work Accomplished | Actual Cost (AC) | Actual Cost of Work Performed (ACWP) |
Derived from these three basic data elements, the following performance metrics are defined, and the interpretation of their values are listed below. These are normally computed at the end of each key milestone, or a timeframe or at some pre-determined project review period. The review frequency is determined based on the duration of the project.
| Basic Performance measure | Definition of metric | Interpretation of Metric |
| Schedule variance (SV) | SV= EV-PV | ‘+ve’ indicates project is ahead of schedule, ‘zero’ indicates project is exactly on schedule ‘-ve’ indicates project is delayed |
| Cost Variance (CV) | CV= EV-AC | ‘+ve’ indicates project is within budget, ‘zero’ indicates project is exactly on budget ‘-ve’ indicates project has gone over-budget |
| Schedule Performance Index (SPI) (Also called Work Efficiency) | SPI = EV/ PV | ‘>1’ indicates project is ahead of schedule, ‘= 1’ indicates project is exactly on schedule ‘<1’ indicates project is delayed |
| Cost Performance Index (CPI) (Also called Spending Efficiency) | CPI = EV/AC | ‘>1’ indicates project is within budget, ‘=1’ indicates project is exactly on budget ‘<1’ indicates project has gone over-budget |
| Critical Ratio(CR) (Meredith, 2000, p479), (Lewis, 2004, p315-316) | SPI*CPI | ‘>1’ indicates project is better than planned ‘=1’ indicates project is exactly as planned ‘<1’ indicates project has gone worse than planned |
EVM can also be used to forecast the performance of the project, based on its performance at the time of review. Following table lists the metrics, which can be used for predicting project future performance. Based on the basic data, the costs ‘Estimate At Completion’ and ‘Estimate To Complete’ can be predicted in terms of following:
| Basic Forecast Metric | Definition of Metric | Formula |
| Authorized Work | Budget at Completion (BAC) (budget approved at project start) | |
| Forecast (revised) Budget | Estimate At Completion (EAC) (expected project cost, at the completion, based on progress) | EAC = BAC/ CPI; (when there is no variance from the BAC) OR AC + ETC (When original estimate was defective) OR AC+BAC-EV (when current variances are unusual) OR AC+(BAC-EV)/CPI (When current variances are normal) |
| Forecast Budget Variance | Variance At Completion (VAC) (expected variance of original budget and the forecast revised one) | VAC = BAC- EAC |
| Additional Budget required to complete Project | Estimate to Complete (ETC) | ETC = EAC- AC |
The Forecast Budgets indicate the type and amount of actions to be taken by project managers for achieving project success. Critical Ratios need to be captured at every work product level (Lewis, 2004, p315-316). There is a rule which says that if a project with duration of 100 weeks is in trouble at the end of 15 weeks, it is going to be in trouble for the rest of its life (Lewis, 2004, p307). This rule of 15% can only be defied by a series of actions a project manager can take, based on EVM concepts.
The success of the EVM lies in clearly determining the baseline, properly assessing the progress of each WBS element and capturing all the costs (Fixed, Variable, Direct and Indirect) in any time frame.. Also, proper systems need to be in place to store unit costs of all resources, capture all costs incurred on a daily basis including a comprehensive Project Management System supporting EVM. Appropriate Review Frequency is critical to the success.
The earned value data can be plotted graphically to assess the project performance. At any point of time, there can be any of the following nine scenarios as a combination of PV, EV and AC. Control Limits need to be established as per the organizational policies for applicable scenarios.
Scenarios:
| AC > EV | AC = EV | AC < EV | |
| PV > EV | Behind Schedule Over budget (case -1) | Behind Schedule On budget (case -2) | Behind Schedule Under budget (case -3) |
| PV = EV | On Schedule Over budget (case -4) | On Schedule On budget (case -5) | On Schedule Under budget (case -6) |
| PV < EV | Ahead of Schedule Over budget (case -7) | Ahead of Schedule On budget (case -8) | Ahead of Schedule Under budget (case -9) |
Depending upon each of these scenarios, the Project Manager can take certain actions in terms of people, processes and tools. These actions will make sure that the project meets its difficult and competing objectives of scope, time and cost (Kerzner, 1998, p742).
Various Scenarios:
| Ahead of Schedule /On Schedule | |
| Possible Causes | Corrective Actions |
| Productivity higher than estimated | Ensure that Quality is further improved |
| More resources deployed than necessary | Redeploy resources to other future deliverables within the project and outside |
| Process automation tools deployed | Replan remaining tasks to manage target margins |
| Original planned schedule was very conservative | Review planned schedule and sustain performance |
| Behind Schedule | |
| Productivity lower than estimated; Wrong estimates | Redeploy resources from less to more critical tasks; introduce automation/ reusable components/ re-estimate and ask for Change Requests |
| Excessive Rework | Use Productivity tools, Retrain resources; get clear specifications; motivate team |
| Lack of Scope Clarity | Discuss with end users |
| Unclear Roles and responsibilities | Clearly define and communicate Responsibility Assignment Matrix |
| Skilled resources not available in time | Try for better skilled resources; invest in training |
| Scope creep is absorbed | Define scope change process; raise Change Requests; re-plan |
| Delay is caused by client's processes or indecision | Involve senior management team from client's side to resolve issues |
| Low utilisation of budgeted resources | Closer interactions with team to resolve their issues; change the team if necessary |
| Under Budget / On Budget | |
| Lower cost resources deployed | Ensure Quality is not suffered; introduce more testing |
| More team productivity than estimated | Ensure cost efficiency does not lead to delay |
| Process automation/ Tools deployed | Celebrate- for contributing to higher profit margin to company |
| Original Estimates were on higher side | Re-estimate remaining Tasks; off-load resources to other projects |
| Over Budget | |
| Low productivity of resources | Introduce automation/ reusable components; invest in training |
| Low utilization (high idle time) of resources | Improve planning and review; Identify team issues and resolve them |
| Excessive re-work | Use Productivity tools, retrain; get clear specifications; motivate team |
| Costlier resources deployed | Try monitoring the Off-shore- On-shore ratio; or have right mix of resources |
| Resources lack requisite skills | Train them; or possibly replace them |
| Unplanned resources deployed | Improve planning process, re-deploy idle resources if possible; train for future needs |
| Scope Creep absorbed | Define scope change process; raise Change Requests; re-plan |
| Delay caused by client's processes | Involve senior management team from client's side to resolve issues |
| Incorrect original project Effort estimates | Re-estimate the remaining work and ask for CR |
| Costly delivery process | Reduce avoidable Direct, Indirect, Fixed, and Variable costs |
The Case Study
This case study is related to an ERP implementation for one of the largest universities in Asia. This University (hence forth referred as Client) has over 50 institutes in different disciplines imparting education for more than five decades now. In 2004, the Client decided to implement an ERP system for its enterprise and student needs. The objectives were to improve efficiency of its Finance, HR and Student Admin processes and enhance visibility across various stakeholders and establish a common process across institutions. . This case describes how Earned Value Management (EVM) was used as a tool for the Project Rescue in an FFP when the implementation turned “Red”.
Project Challenges
Complex Change Management:
The project covered all the educational institutions within the University spread across different countries. The institutions are run on a federated structure and have varied business processes with only few key aspects driven by the central team. The customer has so far never engaged on such a large IT project earlier, requiring all institutions to work together involving large number of stakeholders, with often incompatible demands. The Client had a Culture of federated decision making, which would have been appropriate if the project had sufficient time for various stakeholders to converge, understand the benefits of the new system and adopt.
The magnitude of the implementation, spanning multiple institutes and geographies, needed rigorous change management. The client wanted to streamline and establish one common process across all institutions as part of the ERP implementation. The enormity of the change management challenges was not assessed properly at the beginning of the project, and deadlines were planned to be tight because of business compulsion.
Product fitment:
In specific process areas, the product did not fit entirely to the process requirements of the Client. Though the product was developed keeping in mind the requirements of international community, some of the processes were designed closely to the US university practices. Because of which, some of the Client processes could not be mapped well on the product, resulting in unforeseen extensive customization.
Project ownership:
Educational institutions are usually organized in a federated structure with different people responsible for the academic aspects and administration aspects, and Head of Institutions taking care of the respective institution. The university also has IT function, HR Function and Finance function which operate on centralized model for reasons of scale. In an ERP implementation that touches various business processes and is also seen as an IT project, the ownership of the project is difficult to ascertain
Senior Management involvement:
The engagement of the Client Senior Management with the project was slow because of the initial impression that the implementation is an IT project. This trend is common with many clients, despite best efforts to bring in the business community involvement from the beginning.
Change of key persons midway:
Continuity of key people involved in the project is crucial for smooth completion of any project. Unfortunately the key sponsor from client left the company due to various reasons. The transition of his duties and re-establishing the credibility had absorbed some time affecting the progress.
Project Eco-system
Satyam has setup a dedicated Project Management Office (PMO) to oversee projects that are delivered to its clients. The PMO drives various initiatives focusing on improving the processes, practice and results of Project Management through periodic Project Reviews. Satyam has adopted a proprietary Balance Scorecard model (6P-5R-STARTRACTM) which measures both assets and results. Projects are also tracked using this model.
Project Progress: On Target
Project planning and requirements gathering was the first phase of the project. During the planning phase, there were some challenges in committing resources to the plan. These issues were discussed with the customer. Requirements were gathered as per the original schedule, with minor deviation in effort. The customer sign-off was delayed beyond the planned schedule. Since this is a common feature in most implementation projects, the Satyam team decided to proceed to the next phase.
The project was being tracked by using some simple metrics. The variances at the end of this phase are presented in the table below:
| Effort Variance | 0% |
| Schedule Variance | Appeared to be 0% |
| Cost Variance | 0% |
Project Progress: The first signs of trouble
Mid-way during the design phase, the client came back on the project requirements sign-off. Some more institutions were added to the scope. Negotiations on scope changes were started but not concluded soon.
The project started slipping on schedule. Additional resources were added to bring the project on track. Due to extended scope, it was difficult for the Satyam team to track the project progress with a fair degree of accuracy with simple metrics. EVM was introduced to provide integrated status on the project on different parameters..
There are prerequisites for EVM, which were ensured before the implementation of it. One of the key challenges in implementing EVM for an IT project is the ability to correctly asses the amount of work completed at the milestone. In this case the WBS was broken down to the lower most possible level, and work accomplished at WBS item was quantified against the overall work completion. Multi-party assessment of work completion at Work Package was introduced. The owner of Work Package, and Project Managers of Satyam and the Client independently asses the percentage of completion and the normalized data is rolled up to the overall project level. The project should also have systems for collecting all the costs incurred in the project.
Rescue initiatives:
- Senior management intervention from both Client and Satyam's side
- Pre-determined and more frequent review process involving the senior management teams was established
- Impressed upon the client that Organizational Change Management with their team is crucial
Project Progress: Slipped into deep Red
With the client's Senior Management team involvement, a subsection of the users started participating in the design and process standardization. During this phase the sponsor from the client left the organization, and a new sponsor was identified.
- Impact of scope and design changes was felt
- Variances increased due to incomplete handling of the scope change
- New Project Manager from Satyam was brought in to take control of the project.
Once the project started slipping into deep red the team started loosing focus and it took a while to get them work together.
Project Progress: Actions
- - Internally used EVM to track the extent of overrun on the project; EVM gave a clear indication of where we stand and are we recovering on the project, and based on the analysis (Exhibit 1 – EVM chart)
- - New Project Manager engaged with all stakeholders and established need for a firm scope management
- - More frequent reviews; involving customer senior management
- - Team meetings and outings to ensure that the team doesn't lose its motivation
Project Progress: Project Recovery
Many actions were taken to direct the project towards recovery. With the thrust on scope and highlighting to the customer that scope control was critical to complete the project in time, scope management improved. The business users started engaging better and devoting more time to the project. Though there were minor slippages, the project started aligning to the project plan.
Actions:
The Client Project Manager did not have adequate support in the organization. His influence was limited to only a few institutions. The project sponsor was brought in to ensure that all institutions that were part of the implementation cooperated with the team. He participated in each weekly review to ensure that the importance of the project was communicated to all the stakeholders. He helped to expedite many pending issues.
Scope changes in a fixed-price engagement have a visible impact on the implementation partner. The impact on the customer, however, is not very evident. To illustrate this issue, the Satyam team presented a case to the customer senior management. Problems arising due to the scope change, such as loss of credibility for the project due to an ever-extending implementation cycle and delay in realizing benefits from the project, were covered. This, along with the regular engagement with the client's senior management, resulted in the customer signing the pending scope changes. The schedule of the project was re-baselined considering the changes.
The customer initially wanted to adopt the best practices in the product. Due to the regulatory framework, the processes followed in most of the institutions differed from the product. Aligning the existing practices required multiple levels of approval from regulatory authorities. The customer realized that this would take some time, thereby delaying the implementation. The processes were redesigned wherever approvals were not required. The process gaps were carved out and moved to the Phase II. This prevented the implementation from extending, thereby providing early successes.
The Satyam team also advised the Senior Management to communicate the importance of the project to the institutions. This brought in the buy-in from the institutions. The project was treated as one of the top priority and resources were allocated as required.
Throughout this whole recovery, EVM gave clear indications whether the project was recovering and the pace of recovery. Though EVM itself wouldn't give the guidelines for project recovery, it is an apt tool for judging the health of the project and indicating corrective action.
At the End of Project
Exhibit 1 – EVM chart
Concluding Remarks
This paper described the conflicting motives of Customers and Service Providers in any FFP engagement. Further, during the Planning phase, it is necessary to the assess the scope correctly and re-plan the baseline(PV). Since a large number of parameters are external, Project Managers can play a very important role to take actions which are within their control, using the concept of EVM, and trade-off the conflicting requirements of various stakeholders.
Proper systems need to be in place to store unit costs of all resources, capture all costs incurred on a daily basis including a comprehensive Project Management System supporting EVM. The review frequency needs to be determined based on the duration of the project. Finally, the utility of scenario and action-based approach will help improve project performance as demonstrated through a real-life case, where the project was actually rescued using this approach.
