The best solution for Progress Curves is at this site:

 

http://www.cla-it.eu/TMSDetails-general.html

 

Best regards

you can buy "S curves V2" VBA EXCEL application: http://www.cubixpm-scurves.com/en/

it allows to :

• Create 26 S curves (baseline early and late, physical progress) in automatic connection with a MS PROJECT or PRIMAVERA P6 schedule.
• Spread the weights in a linear or Gaussian way over the tasks of schedule.
• Create S curves with 3 criteria, on the basis of 5 task codes.
• Manage a schedule up to 10,000 tasks.

BR, Jean-Yves Moine.

I have exported data from the task/resource usage tables to excel, the reason being that you can’t hold progressive actuals to measure against the plan curve - all you can pull off are the latest values.
If you want to see a planned curve only, split the window to Gannt & Resource Graph (bottom pane). Then format the graph details to cumulative work (this will give you stepped appearance. Format the bar styles to line. This will give you an s curve for planned work only - unfortunately this is as far as you can go.

Oliver,

Yes, I fully appreciate that it can be very difficult to achieve the best possible alignment, and account for every significant influence. Often though, people aren’t aware of what needs to be done in order to maximise the output for the minimum input. It’s only when the project has started that they realise how important the data alignment and processing systems are. But by that time it’s too late, and they’re stuck with an unenviable mess....which then leads to the feeling of "EV is poo".

Oliver,

Anything that affects the amount of time or cost should be accounted for in programming your BCWS....unless the effects are minimal. If you don’t account for this, then this is precisely why the data becomes totally f**ked. This is also precisely the reason why I’m writing my Applied Methodologies...just to show how big a difference it makes.

I agree that everything should be as simple as possible.....but over-simplification leads to skewed or misunderstood data...which leads to the same old argument.

The costs of doing EV are not necessarily proportional to the value of the project....especially if you are running a proper programme. It all depends on the way that your data is constructed and how you are doing the EV. Because man-hours are probably the most accurate method of doing EV, in our environment, we have a fully resourced programme anyway. The fact that I would have to maintain the programme, regardless of whether we are using it for EV, means that for a given size of programme, the additional time taken for extraction and presentation of EV data is relatively small. The EV data extraction takes about two hours for a team size of 50 engineers or 10 engineers (actually determined by the number of manual inputs). But this is purely because I have set-up all the XL data tables in order to minimise any human input. However, we have one client that is doing the EV in a way that we cannot do "electronically" - purely because of the way that he has constructed his programme. Due to this structure "mis-match", it takes me a disproportionately long time to compile the EV data for a very small team.

Trevor,

You are absolutely right in your assertions – and it all depends upon what measure we use to determine % Complete and how we interpret it. It could be easily argued that, from the perspective of the whole job, your 75% spend-to-date (of the latest forecast) equates to a perfectly valid measure of progress. It matters not as to how many of the bricks you have laid. If we were to assume that 500K/1M bricks had been laid, then we would be 50% physically complete. This obviously equates to a $1.5 cost per-brick. If this cost-per-brick was the correct estimate and you were on schedule etc. then the fact that the remaining 500K bricks are going to cost you $0.50 each is totally immaterial. Numerically, therefore, either measure of “progress” is equally valid. Of course, however, you are perfectly entitled to question why the first 500k bricks are costing you three times as much as the second 500k bricks. This is where the EV equations are extremely useful – because the EV data set gives you the cost per unit output and compares that to the original estimate - but only if you have correctly constructed your BCWS profile.

If you know in reality that your first 500k bricks will have to account for the fact that you will have to learn how to lay bricks, and yet you apply a “simple weighting” (linear cost per brick) and derive a BCWS on the basis of that simple weighting, then you are extremely likely to encounter a very poor BCWP and CPI..….although in reality you are on schedule. Each of your chosen methods will give different combinations of EV data values for the same level of physical progress. Subsequently, any statistical extrapolations are likely to be in error – which is another of your issues. Ultimately, therefore, if you have any questions, you HAVE to understand the original methods of compiling the estimates, how one chose the cost apportionment and what unit of measure was used to calculate progress.


In many cases, I’m sure that most of use would probably just say that $1M/1M bricks = $1 per brick, and then profile the BCWS on that basis. On “average” this would be perfectly true, and comparing whole-job values, is perfectly acceptable. It’s like saying that a 1000Km drive is going to take you 10hrs. It will, if you average 100km/hr. However, during the drive itself, how often will you actually be driving at exactly 100km/hr? In order to correctly gauge your progress, your driving profile should really be, for example: 1st leg: Town Driving: 50km = 1hour. 2nd leg: Good Interstate road for 800km = 5hrs. 3rd leg: Outback: 150km = 4 hours. Mathematically you have averaged 100km/hr. and would finish your journey at exactly the right time. However, if you profiled your journey (displacement/time = BCWS) on the basis of the average speed (simple weighting), you would, at any interim reporting period, show incorrect EV data – thus cause arguments when comparing your real position relative to the computed, baseline position that was indicated by the BCWS. Such arguments would almost inevitably lead to the statement that "EV is a pile of poo"....not because the methodology is wrong, but because it was incorrectly applied, due to a lack of in-depth knowledge as to how the variables interact.

James.

Scott,

As to HOW the forecast was calculated; it makes no difference. The assumption is that the forecast is "accurate". You look, therefore, only at the resultant value.

James.

Gents,

As may be noted, we are currently engaging in rhetoric which may be limiting in terms of taking foward the discussions on the merits of EV and/or other reporting systems. What should we do: provide numerical examples of Good/Bad practice; show examples of how to use it to deceive themselves and clients? Can we each quote a situation where WE ourselves knew what we were doing, but someone else chose to apply a plausible-but-false interpretation in order to make the figures look good?

At the moment, I am writing a document about the principles and applied methodologies of EV. It deals very, very simply with five methods of doing the same thing....and that is calculating progress (% complete). It is designed for people who have always been bamboozled by the plethora of extraneous information that normally accompanies a consultancy-generated EV training day. It cuts through all the crap and gives comparative results. It comes complete with the full set of EV data, including SPI, CPI etc. Moreover, in this example, it definitively concludes (without any form of "manipulation") that the primary element of the EV system relies on the chosen method of calculating progress and how the "value" is claimed.

I often find that EV data is often very easy to question - and is therefore open to easy dismissal. This is especially the case where the PM has merely a few minutes to understand the results of an unexepcted value. They just don’t have time to understand how it works. They often just don’t have the ability to put-aside their own conventional perceptions on how the numbers interact. This is not to say that they are stupid or bad people...but it’s almost as though they want to simplify their lives and find a singular cause of the variances when, in reality, there isn’t one.

Here is one-for-the-pot!! If you have a $1M project, and you have spent $750K and the forecast to completion is $250k, then you are 75% complete.

Discuss.

James.

Trevor,
I will wait for your answer and maybe will be able to add some arguments or examples.
I am sure that our positions are very close and we see the same EV problems.
Regards,
Vladimir

Trevor,

I detect a slight note of cynicism in your posting . Although in some instances I can partially sympathise with your views, I cannot help but say that such views are often borne of bad experience…and the bad experience is often borne out of sub-optimal knowledge of how the methodology works, its characteristic behaviours and the management systems that underpin the data acquisition and number-crunching processes. OK, you and I probably work in two entirely different environments, but that in itself doesn’t make the EV methodology wrong.

I’m afraid that I must strongly disagree with a number of your observations – which seem to be based, maybe, on a lack of understanding of how to get the best out of it. It is completely wrong to say that it “…ignores the critical path…”. If you are doing the wrong tasks, (ie. those not on the critical path) then your ETC curve will push-out the end-date. Like anything else, Trevor, if you don’t generate re-forecasts then you are not going to get the correct data to put into the equations – which means that the output data is also going to be wrong. I’ve used the process now on several large projects – and it’s been near bang-on. The problem is that no-one believed it – so they got themselves right in the sh*t.

Yes you are quite right in that it is possible to get good overall results when, in fact, not all is as well as it seems. Most often, this is down to the chosen method of claiming/earning your “value”, appropriately apportioning the “weightings” (if any) such that when you “earn” your “value”, you are not accidentally skewing your BCWP results. Again, this is where a detailed understanding of the equations and the variables therein will enable you to avoid falling into the trap in which almost everyone becomes caught.

You say that “EV is most useful on a task by task basis……lot less useful when …tasks are smerged…”. Entirely the opposite I’m afraid!! When you have several hundred tasks in progress, how the heck are you to make an overall judgement unless you have a numerical process to crunch and summarise the numbers? Our projects are planned, resource-profiled, booked-to and re-forecast on a task-by-task basis. This is all done electronically via MSP, Project Central (Server) and our Finance system called CIMPAC. With the correct data set-up (knowing how to construct the spreadsheets and apply some very basic comparison equations directly within the software), we can output a full set of EV data, weekly cost and progress variance data and its future effects on the project – all within the space of about 2 hours. The variances can be drilled down to the individual programme task – which retain the same level of comparable information – thus distinguishing every element that has caused any significant variances. The programme itself will still define the critical-path. In fact, the programme is still the primary reference source for all time-phase profiling of the activities, resource loading and the conventional planning roles. However, correct maintenance and husbanding of the programme is probably still one of the most important activities undertaken. Remember, a programme is nothing but an estimated, numerical storyboard and model of the project – live and continually evolving. Used properly, in conjunction with some very basic arithmetic, it’s a wonderful tool. However, one should always remember that it’s only ever an ESTIMATE. Moreover, the integrity of any output data is wholly dependent upon the integrity of the chain of input operations that form the closed-loop feedback system that constitutes Project Reporting. This starts with the engineers and their timesheet bookings. If one link in that chain of events gets broken, then the whole system can come crashing-down. Remember the proverb: “For The Want Of A Nail A Kingdom Is Lost.”

So far, I have found EV to be far superior to anything else. Like anything, though it has to be treated with respect. That respect comes from a full understanding of the way it functions and what is required to make it function properly, ranging from the initial compilation of the programme, to constructing the relatively simple spreadsheets that maximise the output whilst minimising the human input, to applying the appropriate interpretations of the data. It is not a perfect method – nothing is: but virtually all of the failures and subsequent disdain of EV is based on lack of knowledge and understanding, poor application and failure to observe the very basic rules and conventions. Doing EV properly is not easy. However, it is not technically difficult either. It can be somewhat time-consuming, but that is based predominantly on the data acquisition and computational capabilities of the “company systems”.

EV reminds me of the game of Othello: where each person’s counters are sandwiched between their opponent’s and then turned over. It takes a minute to learn, but a lifetime to master.

Cheers.

James.

Trevor,

I believe SPI & CPI are exactly what they are called.

Indicators.

I feel that SPI and CPI were only intended to draw the eye of the PM or senior management team to the important areas of concern. EVA is a tool to track projects, wheread EVM involves integrating othe management practices to mitigate cost and schedule creep.

If you think of a project as the car infront, the indicator show the people following it which way it is going to go.

The skill comes in correcting the steering before you run over a granny.

Nicolas,

SV - Schedule Variance
CV - Cost Variance

Good morning Trevor - and what a beautifully written response. I’ll be more than happy to respond to your comments ASAP, and I’d like to do it this morning. Unfortunately I have rather a lot of work for the next few days - so please bear with me.

Cheers.

James.

James, you are joking.
Earned Value does not supply project planners with the tools for estimating remaining durations of project activities. If to apply Earned Value Analysis for this task the results will be funny.

Nor,

In MSP, Work is a measure of Hours (or man-hours).
% Work Complete = (Actual Hours/Total Hours)*100.

MSP also knows about Duration and Cost.

There is a field called "% Complete", which is about Duration, (Actual/Total)*100.

There is no "% Cost Complete" field but if there was it would be (Actual/Total)*100.

But none of these three is a real measure of progress.
Sure, knowing that you have used 50% of the planned Duration and spent 60% of the planned money, and logged 40% of the planned Hours tells you something, but it does not tell you much about the progress of the Task.

If you are laying cable or laying bricks or pouring concrete, you want to know how many metres, bricks or m3 have been achieved out of what was intended/planned. You could convert metres, bricks or m3 to a %.

You could then compare that to the % Work, Duration or Cost. You could then re-estimate the remaining Work, Duration and Cost.

You can graph cumulative metres, bricks or m3, on individual S curves, but I cannot see the sense in graphing them all on the same curve.