La tua richiesta:
EVM: a simplistic example Let's imagine a project aimed at providing T shirts for your neighbourhood annual charity run. The run will require producing 100 T shirts (TS) which will be sold at $15 apiece. Your budget is $550 and all T shirts are to be delivered in 10 days. Day 1: You bought 30 TS ($5 a piece) and $40 of paint and brushes. It took most of the day to do that and you decide to start painting the next day. Day 2: You worked for most of the day and produced 10 TS. Good job! Day 3: You worked even harder today and produced 20 TS. Day 4: Went back to the supply shop and got a bargain, 30 TS at $4. You still got 10 TS done. Day 5: Another hard work day, 15 more TS produced. Bought, 40 T shirts @ $4. Day 6: Saturday, weather looks promising you go away fishing. Day 7: Sunday, tried to avoid attending your mother -in-law birthday party. Didn't work out. Day 8,9&10: back to work! You produced 15 T shirts a day. On Day 9, you also bought $40 of paint. At the end, you can tell that you were on schedule (100 T shirts in 10 days) and well within budget: $510 out of a $550 budget (T shirts: $430 and $80 of paint supplies). But the question is: was it something that you could have guessed during the project? The answer is yes. If we have a look at how money was spent (in % of budget) and of work evolved (in % of task) and compare it with a linear progression from 0 to 100% in 10 days, we would see that the T shirt production rate was following closely the linear Production Management Software - https://www.marketwatch.com/press-release/former-amazon-employee-has-a-plan-to-keep-manufacturing-local-2019-07-12 rate. We were slightly ahead before the week end and of course the non productive week-end got us slightly on the late side. Regarding the spending we were spending faster than a linear schedule almost all times. Luckily spending stabilized themselves after day 5 (as all T shirts which account for 84% of spending had been sourced by that day). As a result, project ended under budget. If a project steering committee had take place at end of day 5, from that figure the project manager could have stated: Project is on schedule; Spending, although still within budget, needs to get monitored, considering its rate. EVM: a few definitions We are in this chapter to define a few Earn Value Management key elements: Earn Value (EV). The EV can be measured in units, monetary ($, Euros) or not. EV represents the value that had been earned so far. Planned Value (PV). The value that should have been earned by that date. Actual Cost (AC). The total costs incurred so far. And let's introduce 2 indexes: Cost Performance Index (CPI), as the ratio of EV over AC. A CPI higher than 1 indicates a project producing more value than what is spent. Schedule Performance Index (SPI), as the ratio of EV over PV. A CPI higher than 1 indicates a project creating value faster than expected. There are other indexes, e.g. aimed at guessing the gap in term of budget and schedule at the end of project. For this paper we will leave them off topic. EVM: a simple implementation in a software project Context Let's consider a software project where the targeted application had been split into use cases. Each use case had been roughly analyzed and costs have been estimated: Task | Estim. cost | Description UC1 | 8 man-day | Login screen, authentication and password retrieval UC2 | 12 man-day | Login screen, authentication and password retrieval UC3 | 10 man-day | Login screen, authentication and password retrieval UC4 | 6 man-day | Login screen, authentication and password retrieval UC5 | 5 man-day | Login screen, authentication and password retrieval UC6 | 22 man-day | Login screen, authentication and password retrieval UC7 | 8 man-day | Login screen, authentication and password retrieval This leads to a development effort of 71 man-day. Adding a 10% user acceptance test assistance and a 15% project management effort, drives the project cost to 89.8 man-day. We will use EVM during the development phase. This phase has been estimated to last 20 days and should cost 71 man-days (excluding PM activities). Settings This EVM method is based on 3 milestones defined for each UC: AN: Analysis phase has been completed and there is no foreseeable reason to refine or change that analysis. Depending on development or internal test phase events, analysis might require some : Development has been completed and UC is ready for internal test. UC might require some rework depending on test : Internal testing has been completed. For each milestone we will define the percentage of value that can be recognized at that stage. These values should be set according to the general practice of the project manager and his/her environment (Sector, Company,..). : 10 to 35%DV: 40 to 75%IT usually 100% Note: Defining these milestones does not imply that development will follow a waterfall approach. The milestones just represents when the 3 main activities can be considered as reasonably completed. Method implementation This EVM method relies on recording for each UC when one of the milestones has been reached. This can be done by each member signalling when a milestone has been reached or during project status meetings. The achievement ratio are: AN=20% DV=65% IT=100% Let's assume that on a given day, the task status are: UC1: DV completed UC2: DV completed UC3: AN completed UC4: IT completed UC5: AN completed UC6: AN completed UC7: nothing completed The resulting Earn Value (EV) can be determined by multiplying for each UC the cost per its achievement ratio and sum up all values: UC1: 5.2 UC2: 7.8 UC3: 2 UC4: 6 UC5: 3.3 UC6: 4.4 UC7: 0 This results in an EV of 28.6 man-day at that particular point. Doing that EV calculation regularly (daily for small projects, weekly for others) and comparing each EV with the Actual Cost (AC, the project cost to date) will tell whether that project is overspending or not. Representing EV,AC couples on a graph will demonstrate the project spending trend and help the project manager to keep the project within budget. Comparing that EV with the Planned Value (PV, the value that should have been attained by that date) will help determining if the project is on schedule or not. Representing EV,PV couples on a graph will demonstrate if the project is staying on its planned course. EV,AC,PV over time The project manager recorded the following evolution for the 3 variables: EV | AC | PV 0 | 3 | 3 0 | 4 | 6 9.4 | 8 | 8 11 | 12 | 10 13 | 15 | 12 18 | 24 | 16 17.6 | 26 | 18 23 | 28 | 20 23 | 31 | 24 23 | 35 | 28 23 | 45 | 32 30 | 48 | 36 30 | 55 | 40 43 | 60 | 44 53 | 62 | 48 53 | 63 | 54 57 | 65 | 58 68 | 66 | 66 68 | 67 | 71 71 | 71 | 71 Interpreting results If we create a graph (using Excel for instance) with: a green horizontal line representing the value of 1 (when work is on schedule and within budget)a red line representing the CPI (ratio of EV over AC)a blue line representing the SPI (ratio of EV over SP) Note: colors are up to the project manager of course. They were chosen here for clarity's sake in the following lines Schedule: We can tell that the project was kept ahead of schedule for the 9 first days and started then to lag behind. Hopefully by day 14, things started to improve and project got back on track. Costs: Project has been overspending a bit from day 9 to 14. That overspending was limited (less important than the schedule drift anyway) EVM: Adjusting metrics and PM practices By looking at the previous exercise we might make the following recommendations: As project went back on track, it could mean that incorrect assumptions during the scheduling process. The PM most likely overestimated work that would be done at earlier stage and the amount of work required to finalize the deliverables. The drop in CPI value at the middle of development where most UCs were implemented could be a sign that the percentage of EV recognized at DV milestone could be a bit low. In other words, the team actually produced more than 65% of the total value, thanks most probably to a high quality in analysis and implementation. As any metric and PM practice, things are never totally static. Adapting and adjusting metrics and practices regularly are key factors to ensure project success over time. These revisions should be driven from post-mortem and lesson learned results.