(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?
(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.
In response to a question in a Discussion group on LinkedIn, I posted some stuff about the Float Burn Index (FBI) that it dawned on me some people here might also find interesting. It's a little like the required run rate in a cricket chase -- a measure of how fast you have to go. Here it applies to non-critical paths.
There are several potential flavors: straight, and with a buffer, are two. I'll explain with a simple example of a straight FBI.
1. Let us assume a path consisting of five serial activities (Activities U, W, X, Y, and Z), each an FS successor of the predecessor, and each with 20D of total float. We want to make sure that this path does not slip so much that it burns up all its float and becomes critical.
2. Let us further assume that each activity has a duration of 16D, thus totaling 80D of work for the path.
3. Z's successor is on the CP with zero float, so that the path U, W, X, Y and Z has 80D work in 100D of elapsed time (thus the total float of 20D).
4. The maximum rate at which the entire path can burn its float without becoming critical (or the path's MFBR) is 20D / 100D or .20.
If before U ever starts, an ancestor slips so that U's early start is delayed, reducing the path's float to 15D, its MFBR would be reduced to 15 / 95, or .16. Widespread reduction of MFBRs, even before the paths themselves actually start, can be an important diagnostic, worth tracking and investigating even if the critical path is on schedule.
Once a path of activities with identical float amounts starts (typically running between a burst point and a merge point), the FBI of the path is Actual FBR / Maximum FBR. In the example above, where the MFBR when the path starts is .16:
a. If U finishes on schedule in 16D, the AFBR is 0, the FBI is 0 / .16 or 0, and the MFBR for the remainder of the path is now 15 / (95-16) = .19.
b. If instead U takes 18D and so finishes 2D late, two days of float have been burned in accomplishing what was planned for 16D, the AFBR is 2 / 16 or .11. The FBI is .11 / .16 = .69. Even though some float has been burned, the MFBR for the remainder of the path has increased to 13 / (95-18) = .17 because the FBR thus far has been less than the maximum.
c. If U takes 22D and so finishes 6D late, six days of float have been burned in accomplishing what was planned for 16D, the AFBR is 6 / 16 or .38. The FBI is .38 / .16 = 2.38. The MFBR for the remainder of the path has shrunk to 9 / (95-22) = .12.
One might be able to imagine several other applications for the FBI, and if you do, I'd be delighted to hear (or read a paper!) about them. In its basic form, it is intended to provide a warning siren for a non-CP path that is using up its float too quickly. If the FBI < 1.0, that is what is threatened. And obviously, the higher the FBI, the greater the danger.
One can also imagine using the Maximum Float Burn Rate on the baseline schedule as a weighting modification of earned value for schedule purposes: A CP activity gets a PV equal to budget X (1.0 - planned MFBR). Thus:
1. For paths without float (and thus with an MFBR = 0), PV = budget.
2. For paths with 80D work in 100D elapsed time and float of 20D, PV = budget X (1.0 - .20) = 80% of budget.
Finally, the buffered variation is a risk-averse approach that just says that instead of computing the MFBR of paths based on float slipping to 0, you can elect to have it slip only until TF = 5D. No big deal.
I hope this helps. I'd just like to say that, while FBI is a nice little metric, it's inconsequential compared to truly valuable critical path drag and drag cost, on which topics I will be doing a webinar for PMI's Scheduling Community of Practice on July 10th. It's free to PMI members. You'll find it listed in the righthand column on this webpage:
http://scheduling.vc.pmi.org/Public/Webinars.aspx
Fraternally in project management,
Steve the Bajan
Printer-friendly version
Send to friend
Why am I not surprised that Spider would have this functionality?
Thanks, Vladimir.
Fraternally in project management,
Steve the Bajan
Guys,
Spider Project keeps history and shows trends of any project parameter including total float of any activity and/or project phase that are selected.
You don't need to use Excel or anything else.
We usually look at the speed of contingency reserve consumption (success probability trends) that give more information for project performance analysis.
Best Regards,
Vladimir
Hi Steve,
I agree the measure can be very dynamic (which is why I use trend lines to smooth things out).
But I do find an issue with this and any metric that looks at total float, in that if the project completion is delayed then all non-critical paths and activities have their total float increased (I don't use project completion constraints), which can give a false picture suggesting that everything apart from the critical path is doing well. It's something that can be overcome through explanation, but the more times you have to explain / justify a metric then the less useful it is.
As to using planning software to calculate: yes I think you could set up a calculated field to work out your float burn metrics in most major planning software. You could certainly do it in excel. If I get time (and I probably won't, if I'm honest -Busy boy at the moment, and I'm moving house in a fortnight), I'll have a go at doing so for you. -It would be interesting to run both my float erorison and your float burn measures side by side on a project to see how they compare.
For my float erosion chart, I just take a copy of the total float for each path after each update and plug it into an excel table -no additional calcs are required (other than the trendlines, which excel handles)
Cheers,
G
Hi, Gary. How interesting that we have both been wrestling with the same issue.
I think your float erosion chart is a great idea! As you say, it's got the big advantage of being highly visual. And "trend lines" are great tools for showing where we are headed.
The one thing that I'd say is that I see the data as being very dynamic -- in the example I created, the MFBR changed, due to an ancestor's slippage, before the path ever started. If project completion is delayed, that would simply be another change to incorporate in the data, but in essence it would be no different than if an ancestor slips: in either case, the denominator of the MFBR formula will change, in one case increasing and in the other decreasing.
Unfortunately, I don't know of any PM software that has this functionality, do you? I suppose there may be some way to program a macro that will filter out the durations and float toals of a path and divide it by the elapsed time from earliest early start to the next activity with zero float... but that kind of programming is quite beyond me.
It's an interesting area of investigation, though.
Fraternally in project management,
Steve the Bajan
Hi Both
I am pleased to say that I have no idea what you are both jabbering on about.
Best regards
Mike Testro
Hi Steve,
I've been using a somewhat simpler & coarser method to track the same thing:
I plot a "float erosion" chart, with TF of various paths through the project on the y axis, and time from project start to project completion on the x axis.
It's fairly insinctive & easy to explain to non-planners that if the trend of a path's float looks like it will cross the y axis (i.e. become critical) before the end of the graph (i.e. the end of the project), then timely project completion is at risk from that path of activities.
It's also a very visual way to highlight the impact on risk of delaying the project from both actual delays and potential decisions which do not impact on the critical path.
One problem I have encountered (and imagine would be similar with your approach) is that if the project completion is delayed, it makes all the other paths suddenly look a lot better in terms of float erosion/burn -Any thoughts?
Cheers,
G
Email: PPadmin@planningplanet.com
Replies