Catch-Up Scheduling

Question

Say I have a project X that is due to be complete by Date Y Right now we are 10% behind schedule (Should be say 50% and right now 40%), How can I estimate what level of "effort" is required to catch up?

I.E. the original schedule expected 1% of units of work a day to be done, but to catchup to the schedule by some date Z (which is <= Y), we need to work 1.2% units of work a day, I'm looking for a way to identify the 1.2% units part based on an existing schedule.

I'm not sure what this is called but if someone that has editing rights has a better idea for the phrasing, I would be grateful if they could reword it.

Hoping this doesn't make it a "tool recommendation, or shopping question", again reword if it sounds like it, however if you know how to find the above information using tool, can you please provide a "how to" on that tool, this is really what I'm looking for, my project is currently using MS-Project, but I don't think it would be too tricky to insert "start/end dates" into another tool, if it has this feature? I would ultimately like to be able to run a report estimating what "units of work per day" are required to complete the entire project, broken down by tasks that are behind only.

Answer 1

I'm not sure that I understand the question, but it sounds to me like you're asking for the To Complete Performance Index or TCPI.

Roughly speaking, the TCPI answers, "How far behind are we, and how much are we going to have to accellerate in order to make our deadline?" The TCPI is TCPI = (Work Remaining)/(Budget Remaining)

Of course that assumes that you've quantified the work to be performed and the work that has been done. If you didn't set up earned value when you did your WBS/WBS dictionary, and/or you didn't review it when the task started, then TCPI won't help you in the slightest.

As the estimable @codegnome has pointed out, knowing how much faster you need to work doesn't really tell you how to work faster. What activities can you drop without causing a loss of quality? Which staff members can you terrorize into overtime without damage to overtime & employee relations?

Answer 2

If you determined where you are by using earned value and your EVMS is credible, you can apply this formula:

ECR=(BAC-BCWP)CAR*remaining PoP in years

where

CAR=(BAC/Planned FTE)/PoP

This should result in the level of FTE at which you will need to operate in order to catch up to the schedule by the end of the PoP.

You can run this same formula, replacing BCWP with ACWP, to figure out what FTE burn you need to catch up from a cost variance.

Example:

Given:

Period of Performance (PoP) = 2 years or 104 weeks; Hours = 24,000; Planned FTE = 6; Budget at Completion (BAC) = $21,600,000; Weeks exhausted = 29; Weeks Remaining = 75; Budgeted Cost of Work Performed (BCWP) = $5,900,000; Budgeted Cost of Work Scheduled (BCWS) = $6,023,077; Actual Cost of Work Performed (ACWP) = $6,200,000; Schedule Performance Index (SPI) = 0.98; Cost Performance Index (CPI) = 0.95; Actual FTE = 6.18

Following the formula above, the ECR = 6.05.

This suggests you need to run at 6.05 FTEs versus the 6.00 FTE planned or the 6.18 actual FTE.

However, 6.05 is less than 6.18 so it does not make sense that "dropping" to 6.05 will cure your schedule when you were late at 6.18. So you need to interpret carefully, meaning you may need to add 0.05 FTE to your 6.18, making it 6.23 to correct the schedule.

We also know that crashing your schedule does not always result in making things better but worse. Nevertheless, this is the math. Use it with care.

Answer 3

TL;DR

Identify a root cause for the slippage, re-estimate your level of effort for each task, and adjust your schedule accordingly. You can't identify the cause of a slippage from a schedule; at best, you may be able to identify the process or task dependency that's holding back your project.

Problems with Percentages of Units of Works

There are some problem domains where you can usefully quantify percentages of units of work, but in general this is now accepted as a Bad Idea™. In manufacturing, for example, you can safely say that if you have three tires attached to a new car, then your wheel task is 75% done. In most endeavors, though, making a broad statement like "100% of tasks are 40% done" is not really very informative.

What You Should Do

You should do a few basic things before proceeding. First is to identify why your schedule is slipping. Accelerating your schedule on paper will not necessarily accelerate your completed work. To do that you need to identify the cause of the slippage, and determine whether you have:

1. a process problem,
2. a resource constraint,
3. an unrealistic schedule, or
4. some other hidden issue that needs to be brought to the surface.

Once you've identified the problem and gathered buy-in for a solution, you can then adjust your project plan based on updated plan elements. You have a number of choices there, too:

1. Reduce scope to meet the current deadline.
2. Add resources to meet the current deadline, although you should keep Brook's Law in mind.
3. Modify your deadline to reflect what you've learned about your project's process and resource constraints.

What Not to Do

What you should probably not do is press some magic "Go Faster™" button based on an accross-the-board accelerated schedule. Shortening every task by 2/10ths of a percent is unlikely to yield useful results.

Think about it this way. If I have a 4-hour task that I've decided is 1.2% behind schedule, that means I'm running a little less than 3 minutes per person behind schedule for that task. Let's say it's assembly-line work, and I speed up the assembly line by 0.2% (miles per hour? widgets per second?), possibly increasing the error- or stop-work rates in the process. Having done so, which 172.8 seconds of that 4-hour process are the waste that I expect each person to eliminate?

Answer 4

I completely agree with CodeGnome. Actually "we are 10% behind schedule" can only have a "statistical" meaning and statistics are usually applicable to large data set only -> very fine grained task definition, or a huge project that is out of my experience. Probably your is the latter case, but in my projects I had big trouble to identify a creep of 10%. Actually my tool identify creeps and also tries to adjust the work plan, but usually the problem cannot be solved "going faster". I work in a agile oriented way with a very motivated team, when we are behind schedule, is because the schedule is wrong :-). Overworking never helped us.