## FLEX Metrics, original story

When I was working on a post about the FLEX metric, I dug into the PlanningPlanet forum to get some examples and, by chance, found an original post when the idea of the new metric was discussed. I found this story to be very interesting and decided to save it and share.

If you are too busy to read the full story, you can read highlighted text only.

This story demonstrates the importance of a ‘collaborative space’ where practitioners can share ideas, challenge each other and develop new methods, techniques and tools.

Enjoy.

Planning Planet Forum. Topic “To split or not to split FF Activities’ (23 March – 16 April 2013)

Participants:

• Rafael: Rafael Davila, Project Management guru
• Steve: Stephen Devaux, Project Management guru

Grammar and spelling remain unchanged.

v

Sat, 2013-03-23 02:20 (Rafael):

For purpose of the discussion I am to Call FF Activities all duration type activities that have a FF predecessor link.

A FF link can create reverse logic computations that are relevant to scheduling strategy. If the FF link is driving the duration of the activity might be increased without this causing a delay on the project duration and at times it can even cause a reduction.

By adding a zero duration activity whose predecessors are equal to the FF Activity and whose successor is the FF Activity we can determine a duration amount by which the activity can be increased before the FF link stop being the driving link, will be equal to the free float of this zero duration split activity.

I am looking for some functionality that will disclose this duration without the need for the user to create the split. It will be computed only for activities with FF predecessors and will be used for the user to determine if the activity will be split, if the duration will be increased or left as is; a management decision, not a computer decision, on a one to one basis, one of my reasons to be an avid advocate for continuous activity scheduling.

Of course being an advocate of continuous activity models means this issue must be identified and handled in an efficient way by our continuous activity models.

Perhaps some right click functionality can create the split for the user, this split will be a new duration type activity of zero duration with same start links as the original and a second activity linked FS(0) and remainder definition similar to the original. Then the user will determine how to spread duration and resources among the activities. If there is need for more splits the functionality can always be applied to the remaining activities.

Any comments, corrections and alternate strategies will be welcomed.
Best Regards,
Rafael

v

Sat, 2013-03-23 23:16 (Steve):

Hi, Rafael.

We have of course discussed this previously.  You know my feeling — that the continuous activity is an assumption that:

1. Can delay a project schedule (thus perhaps making the project less valuable, more costly, and sometimes costing human lives) for no reason other than the way the CPM algorithm was programmed in the 1960s.
2. Is an incorrect assumption the vast majority of time — more than 99% of the time, the activity CAN be interrupted.

That said, we don’t have to debate the issue and can agree to disagree as long as the software does precisely what you are proposing! I would be supremely comfortable with such a solution! I absolutely agree that a software package that uses the continuous activity assumption should:

1. Make the user aware of the issue and its potential impact (most users don’t have a clue about it!); and
2. Point the user correctly to the FF (or SF, by the way!) relationship that is causing the constraint/delay.

It seems to me that the simplest way to accomplish this if the activity is on the critical path is through drag computation: a task which is causing the reverse critical path anomaly will have negative drag.

This of course makes no sense, as drag is a measure of how much an activity is pushing out the end of the project, and an activity cannot be pushing out a project by a negative amount! It is actually NOT the task that is delaying the project, but the FF or SF relationship! And that is where the software should point the user in diagnosing the cause of the project delay. Relationships and constraints, including lags, dependency relationships, calendars and calendar constraints, and resource constraints can ALL have critical path drag, and the software should diagnose it, identify the cause of the drag and measure it.

None of this, of course, addresses the case of the FF or SF relationship delaying an activity that is NOT on the critical path and therefore does not have critical path drag. It’s less important (less critical?) of course if it is off the CP, but still has an impact. That impact is to decrease the activity’s or path’s float. I believe I am correct in saying that the issue only occurs when an activity has BOTH an FF or SF predecessor AND an SS or SF successor. Perhaps the software could simply look through the network, identify any such activities, and list them for the user as areas where attention might be warranted?

So glad to see you looking at this, especially in the Spider forum, as Spider is seems to be the only s/w package that both computes drag and seems aware of this as an issue.

Fraternally in project management,

Steve the Bajan

v

Sun, 2013-03-24 00:36 (Rafael):

Deveaux,

What is wrong is to assume splitting is always in order, that can be anything the computer decides.

Continuous models assume nothing nor it does prevents splitting, if you want to split one such activity or all will be a management decision, once you split the activity it is better than equivalent as you still got to decide where to split 50-50, 90-10, or perhaps 60-60 (>100) as very frequently split comes at a cost and overall duration will have to be increased as well as resources.

Users of the continuous model are aware but some extra functionality might help to identify such suspects for splitting.

You said the majority of activities can be split, I would add it is not only that can be split but that it is better if you split them on the majority of cases. Of course this does not solve the issue on how to split. I would tend to split my activities on my own terms and keep the free float between the last two splits as a buffer. If the activity is neither critical or near critical I might be tempted not to spilt the activity, the benefits of continuous work will prevail.

Because criticality changes as the job progress the desirability to split or not to split might change, therefore the need for continuous monitoring of metrics that will warn you, good management is a continuous operation.

Maybe a “Merge” functionality will also be of help. Perhaps double links shall be taken into account on the split and merge functionalities.

Best Regards,
Rafael

v

Sun, 2013-03-24 00:49 (Steve):

Hi, Rafael.

First, I was trying to avoid getting back into our debate about the software’s assumption of continuous or non-continuous activities. We agree on almost everything, including all that you have said about making management decisions about where to split the activity.  We seem to agree that:

1. An activity can almost always be split if it is valuable to do so.
2. Where we split an activity should always be a management decision.
3. The software should point the user to where the constraints are that might result in a reverse CP anomaly.

All that is agreed. The only place we disagree is:

What should be the default that the SOFTWARE, not the user/scheduler, applies in creating the schedule. Again it’s NOT a disagreement about what the user should do, only about what the algorithm, which has been programmed “generically” by someone who has not a clue about the specifics of the project, should do.

1. You are used to the continuous activity assumption that is programmed into CPM algorithms so that you seem not to see the continuous activty default as an optional assumption. The software HAS to make an assumption and it chooses to make the assumption that the activity is continuous, which often makes the project longer in a way that is not clearly visible to most users. We seem to completely agree that this should be made more visible, and I am quite comfortable with using the continuous assumption provided that this is made highly visible and the software identifies the drag with the delaying constraint/assumption.

The other possible default that the software could use is to generate the shortest possible schedule (which most users actually think that the software is doing!). This is certainly a legitimate alternative, and is both practical and better (i.e., shorter schedule) in the vast majority of instances. But once again, the software must show the user what it is doing by:

1. Emphasizing the early start date of the SF/FF successor as being the prime driver;
2. Stating that it is splitting out a milestone as the activity’s SF/FF finish; and
3. Telling the user the amount of time being saved on the project duration through the input of the milestone.

By the way, the Sumatra.com Project Optimizer add-on to MS Project that computes drag does all of this and, additionally, does it ONLY if the user specifically elects to implement “optimization” of the schedule by splitting out milestones on activities with SF/FF predecessors. Once the user does this, they can see the impact and then go in and change where the activity is split, if they so choose.

Again, we are in complete agreement about what the user/manager should do, and about the fact that the software should act in a transparent and helpful manner.  Our disagreement is just about the CPM algorithm’s default, which I believe should be to emphasize producing the shortest possible schedule, not assuming a longer schedule in a not-very-transparent way due to making an assumption (i.e., that the activity MUST be continuous) that is almost never valid.

Fraternally in project management,

Steve the Bajan

v

Rafael,

do you mean finding minimal free float of preceding activities (in case calendars are the same)?

Sometimes to split is necessary for optimizing project schedule like in this example:

v

Sun, 2013-03-24 06:06 (Rafael):

I am looking for a strategy to decide when to mimic P3 contiguous scheduling. On the second figure Task B is split into intermitent work, it reduces the duration of the overall job, although in other ocassions might not. P3 solution is not controllable and do not recall disclosing the distribution of the split(s). I prefer to decide when to split and how.

I am looking for a metric that will tell me how much the duration of Task B  can be increased without delaing end of (itself) task B.

Then if I decide to split some functionality to make the split easy.

v

Rafael,

it is an analogue of superfloat but to the start direction.

v

Sun, 2013-03-24 08:56 (Rafael):

I believe both are of much value.

I am looking for a value that is independent of total float – “I am looking for a metric that will tell me how much the duration of Task B  can be increased without delaying end of (itself) task B.” Something that might happen only under reverse logic path.

Best Regards,

Rafael

v

Rafael,

it works in both directions. Existing Superfloat – Total Float shows duration flexibility in forward direction, you want to add the same to the backwad duration. Together they will show activity duration flexibility in both directions.

Best Regards,

v

Mon, 2013-03-25 11:27 (Rafael):

Exactly I want to see flexibility in both directions, about the math you know better than I do, most probablhy you will not have to use the dummy split to figure it out by going to the core CPM calculations.

My guess is that it shall be = Activity Early Start – Max {Early Finish + lag of all Activity Start Predecessors}

v

Rafael,

my intital estimate also went this way (remember I wrote about free floats of preceding activities).

Just imagine two activities linked by both SS and FF. Succeeding activity duration is smaller, preceding activity is critical (no floats, no lags).

v

Mon, 2013-03-25 19:54 (Rafael):

But how would you name this value? Maybe on ADM literature there is a name for similar value that makes sense under ADM jargon but we are on PDM and although today PDM is dominant I have not being able to find a reference to it.

Best regards,

Rafael

v

Mon, 2013-03-25 21:09 (Steve):

“Together they will show activity duration flexibility in both directions.”

This will be very nice.  It would dissolve most of my concerns about computing drag with the continuous activity assumption.

“My guess is that it shall be = Activity Early Start – Max {Early Finish + lag of all Activity Start Predecessors}”

After some thinking, that seems like the right formula to me, Rafael.

And if I might be so bold as to suggest, “flex” (or “critical path flex”) would not be a bad name…

Fraternally in project management,

Steve the Bajan

v

Mon, 2013-03-25 23:25 (Rafael):

Steve the Bajan

Agree, I like the idea about using the term Flex/Flexibility so much because is a descriptive term that say much about the value, as usual Vladimir is on the bulls eye with his choice of words.

Perhaps Start Flex and Finish Flex (Superfloat) can be considered. The instant response by Vladimir to relate it to Superfloat makes me believe that Superfloat can be re-named to Finish Flex as to show this relationship.  In this way when a new user looks at the terms he/she will be confronted with the relationship between both values and activity duration.

Best Regards,

Rafael

v

Ok Guys,

Thank you for proposal!

Flex is accepted.

Regards,

v

Tue, 2013-03-26 15:57 (Rafael):

Many thanks in advance, you know how tedious these computations can be if done outside the CPM but now I will have it at a click of the mouse. I will compare values after unleveled schedule run versus after leveled schedule run.

I have no doubt you have investigated this and many other similar computations.

Not sure if it makes sense to create some special functions that can make these values available for formula usage. I know of no software that allows the user to explore these computations in an easy way.

Something like:

1. CPM(min/max, ES/EF/LS/LF, pred/succ)
2. others you as a developer might think

Best Regards,

Rafael

v

Sat, 2013-04-13 23:24 (Rafael):

Thanks, it came out perfect,  AWESOME, all float types are visible at the columns selected for display as well as at the activity dialog box. Not only in hours but also in days, very convenient for when some workdays have less hour than the others.

As you can see with the Start Flex I will be able to filter active reverse logic and will be able to know available slack if I split the activity. This particular value to me is extremely relevant when using FF/SF links that can cause reverse logic. A topic I rarely see people debating, as if float values do not matter except only Total and Free Float for delay claims. My focus is not on claims but on using the model as a practical planning tool to get better plans.

[Broken image]

Under resource leveling it becomes even more interesting, the activity splits can be driven by resource dependencies, you might have activities with Start Flex and no Total Float. It is important to know how these splits will impact the schedule as in some cases starting ahead work on some split can impact other unsuspecting activities via the resource dependencies. Just another reason why intermittent work shall be transparent, another reason why interruptible schedule durations on a single activity is such a bad model.

[Broken image]

I recall long ago advanced software would show several types of float in addition to the very basic Total and Free Float, I recall Artemis by reference when it was a mainframe only software. With these values there is much understanding of the logic, with these you do not have to go and search all predecessors/successors links to find out about what is driving and near [insane and impractical for everyday procedures]. I remember the literature would tell you about how to use them. I guess I will have to do my homework and re-learn lost knowledge.

I was frustrated before finding about Spider, I was starting to believe we were moving backwards and nobody cared, or perhaps that I was wrong. But I know you would not add functionality if it does not add real value, so maybe I was not that wrong. At times I think about following the masses and move to low quality and full of bugs but best selling software, but find it impossible to lower the standard and miss such functionalities.

Guess Spider team will have to continue competing against themselves, the gap is big and continues widening.

Best Regards,
Rafael

v

Tue, 2013-04-16 01:53 (Rafael):

Some developers insist on negative float to be embeded into the total float field in order to display criticality of unattainable date constraints. This is not necessary to show criticality, it is similar to making open ends critical without use of functionality that creates negative float.

The application of impossible date constraints to Late Dates that are prior to Early Dates distort not only Total Float values but also other float values. This makes other float values to loose meaning, make them erroneous.

I believe this might be one/main reason why some developers do not show other types of float.

Best Regards,

Rafael

v

Rafael,

let’s imagine that activity has total float –5. What happens if it will be delayed for 10 days?

I don’t know the answer to this question without detailed schedule analysis.

One of the options – nothing, because next activity has TF=-15.

Float values shall be useful for decision making and show what may happen with the scheduled dates in the current schedule.

v

Tue, 2013-04-16 08:48 (Rafael):

Trying to reason the logic on negative total float and the manipulation on late dates makes no sense, in any case makes a joke.

Take a look at the following schedule, if you run it on software that do such manipulation will give you negative float for the first two activities, will give positive free float for the first and zero for the second activity. Being zero and positive values greater than negative values it will display free float values greater than total float, it does not makes any sense.

[Broken image]

There is a logical relationship between different float definitions, calculations are based on Early and Late Dates. If you tamper Late Dates with artificial values the relationship will be broken.

If you add resource leveling it becomes beyond any comprehension.

Best Regards,

Rafael

#### Alex Lyaschenko

PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma

## Activity FLEX Metrics

FLEX is a metric of activity duration flexibility, introduced by Rafael Davila. Flex shows whether using fewer resources (or reducing resource workload) is possible without delaying other activities.

Activity Start FLEX shows the time difference between the earliest activity start and the planned activity start in the current schedule without violating any constraints and without delaying activity finish.

Activity Finish FLEX shows the time difference between the latest activity finish and the planned activity finish in the current schedule without violating any constraint and without delaying activity start.

Both metrics associated with FLEX mean increasing activity duration by keeping activity start or finish intact.

Start FLEX = Activity Early Start – Max {Early Finish + lag of all Activity Start Predecessors}

Let’s review the next scheduling fragment. It has four activities and Finish milestone:

All activities are on a critical path, and it takes 13 days to deliver this project. Activity Durations depend on resource assignment and were calculated based on 100% workload. 3 workers are available to perform the work, but they are mostly on the bench.

FLEX can be used for optimizing resource allocation. If increasing activity duration does not lead to any changes, we may decide to use fewer resources on activities with positive FLEXes to optimize resource requirements and project budget.

Should we baseline this project and commence execution? Not yet. We need to check if project duration can be reduced first. How can we find out if an acceleration is possible? Let’s calculate Activity Drag, Start and Finish FLEX!
I will use the project delivery tool, Spider Project, and specify in the setting that DRAG and FLEX need to be calculated:

The schedule is calculated with the next metrics: Total Float, Drag, Start and Finish Flex.

From the calculation, we can see that Activity C has some duration flexibility! If we reduce the allocated workforce, we can commence this activity 5 days earlier (Start FLEX) and/or delay it for 3 days later (Finish FLEX) without delaying the successors.

Also, this activity has a Negative Drag! By increasing the duration of this activity to 3 days, we can reduce the duration of the project. Let’s recalculate the schedule again but this time let’s tool automatically adjust durations and workforce.

As expected, the duration of the project is reduced to 10 days (23%)

The logic in the schedule is exactly the same as before. The acceleration was achieved by reducing the workforce of Activity C from 100% to 38%. It increases activity duration from 3 to 8 days. Critical Activity D can now commence 5 days earlier (as it has Start-Start dependency) and even has 2 days of Total float. Overall project duration is reduced from 13 tp 10 days. This schedule acceleration method is called Anti-Crashing.

It is counterintuitive to accelerate project delivery by reducing resource allocation. It is hard to identify such opportunities without calculating FLEX and DRAG metrics.

For effective project delivery, it is important to understand how resources could reallocated and what effect it makes to project delivery dates. Activity FLEX metrics give such visibility!

In simple words, FLEXes show how an activity duration can be changed without delaying other activities. It allows the use of freed-up resources for other activities and even, in some cases, reduces project duration.

#### Alex Lyaschenko

PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma

## Project-Portfolio Management Snails

Project-Portfolio Snail

A typical Project Portfolio environment echoes the “fractal” form of the common garden snail’s shell.

A small organisation may only have ad-hoc projects managed independently, and a large corporation portfolio of projects is subdivided into “sub-portfolios “, each of which is managed as a portfolio in its own right. The same applies to program and project levels.

A definition of each fractal level is required for effective communication, but applied definitions are soft and vary between organisations and government bodies. The boundaries between levels are arbitrary and determined individually as well.

Two organizations carrying out similar projects may have significant differences between levels (or even the presence of levels), but the overall nesting from large to small is constant: groups of projects always consist of many interrelated tasks performed by project resources. What would fall under the definition of a project in one organization may be a program or even a portfolio in another.

Also, companies may use different delivery methods or even develop their terminology but the ‘fractally increasing’ principle applies.

Also, companies may use different delivery methods or even develop their terminology but the ‘fractally increasing’ principle applies.

The current establishment of a project management discipline relies solely on experiential records and opinions rather than a sound logical or theoretical foundation. Ideally, there is a need for a universally accepted and testable set of fundamental principles in project management. These principles would serve as a common reference point for a set of ‘generally acceptable practices,’ aiming to facilitate the creation of successful products. ‘Project-Portfolio Snail’ is one such principle.

A program-centric portfolio has many types of ‘snails’ that look the same but are not. It is challenging to mature such a portfolio as project people in the same portfolio don’t speak the same language.

Even within a project, the language barrier may not be recognised. Project people move between organisations and even industries, and it is usually assumed that team members can easily speak the same PM language. They can’t, and they don’t understand that they can’t!

It is easy to recognise a gap for a new term. However, when a common project management term, like ‘stream’, has a slightly different meaning, it is incorrectly assumed that the whole team applies the term in the same way.

It is better to assume that a project team don’t have a common language. It opens an opportunity for PMOs to develop custom-made training where project management terminology is clarified and made mandatory for project stakeholders, from a project coordinator to an executive team, to attend.

#### Alex Lyaschenko

PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma

## Monte Carlo simulation challenges. Activity lead (negative lag) challenge.

Odesa anecdote:

– Tram. Can you tell me when the Deribasovskaya stop will be?

– Follow me and get off two stops earlier!

Lead (or negative lag) is a situation when the successor activity overlaps the predecessor activity.

It is very beneficial to overlap activities as it may help to shorter project delivery, so leads should be encouraged. However, the leads need to be used correctly to get the expected result.

Usually, an activity with a lead is linked to the completion of another activity. Practically though the trigger to start the successor activity depends on the achieved result of the predecessor activity, not the completion date. The forecasted completion date of the predecessor is a PROXY that could be used as a trigger. It could be a good proxy or a bad proxy.

The best practice is to define the required result (via a volume of work) and link the successor to this result.

This simple example demonstrates the challenge.

Task A requires completing four units. Task B takes three days and can commence after three units of Task A are completed. With a planned productivity rate of one unit per day, it takes four days to complete Task A, and Task B can commence on the 4th day. The whole project takes six days.

Such a scenario could be programmed in two ways:

## Option 1: Completion date is a PROXY.

Use the predecessor completion date as a proxy.

If Task A does not progress as planned and the actual productivity rate is one unit per two days, it takes eight days to complete Task A. Task B can commence on the 8th day, and it takes ten days to complete project:

## Option 2: Volume of work is a PROXY.

The successor is linked to SS + 3 units (not the same as SS+ 3 days). The schedule has the exact activity durations, start and completion dates as option 1.

If Task A does not progress as planned and the actual productivity rate is one unit per two days it takes eight days to complete Task A, but Task B can commence on the 7th day. It takes only nine days to complete the project.

A project planner can adjust lead durations manually, but during the Monte Carlo Simulation analysis, it must be done automatically based on changed project conditions.

A similar problem occurs when the predecessor activity progress is better than expected. In this case, the schedule incorrectly shows that the successor activity can commence when practically the required work volume is not yet achieved.

If the schedule with (FS – X days) leads is used for the Monte Carlo Simulation, the simulation result may be impacted as simulations don’t represent how work could actually be performed.

The forecast completion date of the predecessor may not be the best PROXY for activity leads. Often, it is the only available proxy (due to scheduling tools constraints).

The application of activity lead is beneficial but planners developing a project delivery model need to apply leads correctly.

#### Alex Lyaschenko

PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma

## Best practice vs Best workarounds

Many planners mix up ‘Best scheduling practice’ with ‘best workarounds’ in a particular scheduling tool.

When they heavily apply one of scheduling tool, they start to believe that the workarounds are the best practice, refuse to learning alternatives and even debate that other tools must support such workarounds even if they are not required. The same applied to project risk managers.

How to avoid the ‘Overconfidence Bias’ trap?

• Learn theories behind planning and risk management.
• Always be curious about what a tool can’t do, whether workarounds are possible, and if they are, think about the downsides.
• Look for chances to learn about other tools.

Remember, a not-so-great specialist just knows what a tool can do. A good one understands the problems and workarounds. An excellent specialist also knows the bad side of workarounds and can suggest other tools when needed.

#### Alex Lyaschenko

PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma