Earned Schedule Values

Question

On this particular project, the performance of the testing team is being tracked against the number of scenarios tested compared to the plan. Using Earned Schedule analysis, the resulting values are calculated:

• Earned Schedule (ES) = August 15
• Actual Time (AT) = September 10
• Independent EAC (IEACt) = November 6
• Planned Time at Completion (TAC) = October 2
• Schedule Performance Indicator (SPIt) = 0.84
• To Complete SPI (using planned EAC) = 2.28

Here's the graph (series 4 is the actual performance):

A TCSPI, like TCPI using Earned Value, greater than 1.10 is considered to be not credible, i.e., impossible. Since our TCSPI is 2.28, recovery should be considered not possible and other alternatives should be considered.

This was presented to the team (not in a manner using a ton of ES technical babble but in a way for most others to understand), suggesting that recovery was unlikely (did not use the word impossible) and that other alternatives needed to be analyzed. The testing team, developers, and other support personnel rejected this notion wholesale, indicating that recovery is not only possible but that they will recover, and dismissing the presented analysis as "textbook." The alternative, more optimistic points of view had no basis behind it; it was just they thought was more true. Others who were listening to this debate tended to lean towards the more optimistic opinions and the general consensus was to continue on and no other mitigating or contingency alternatives were explored.

My question is: why?

Why do we spend time learning the mechanics of various way to analyze data but then reject it in practice? I have observed this chronically across many different types of projects and customers and teams.

There is not a "right" answer to my question so I know this violates the rules a bit, but I think a right answer sort of lives in the collective responses from all of you, those who live this every day. I would like to hear your critical thoughts and opinions on this subject. Thanks.

Answer 1

I believe it's because the people who learn the methods are not those who have to realise the consequences. Due to work share / specialisation this is usually not possible. But why does the non domain experts do not trust the domain expert?

Because within the field of PM even the non domain PM expert might be successful. And therefore, lots of people have strong believes regarding what's right or wrong.

And finally just because you learned a technique does not mean you trust a technique.

---

For me the important but may be additional question behind yours is: How to deal with this circumstances?

Your question is independent of Earned Schedule Analysis. What you describe is the resistant to change and lack of trust in expert knowledge (presented by PM methods)

The project team is doing everyday work and might be satisfied with. They might not see any problems from their perspective so, there is no need for change.

Applying tools or processes, someone (you) is able to forecast the future in a better way than others and is able to predict upcoming problems earlier than the others.

What you need to do is to convince the team regarding the need for change.

I assume, you want the teams expert knowledge to find a solution for the update planning problem? Otherwise / if you already have a planning solution you "just" have to deal with your power in order to make them follow your plan.

But using the expert knowledge to come up with a solution for the re-planning problem is more difficult:

What you need to do in addition is to convince the team regarding the correctness of your prediction.

What you could do:

• Make the belief that you are true by applying expert power - looks like this didn't work for you
• Try to explain the methodology - you already tried without success
• Show the validity of your applied methodology by presenting positive and negative examples
• Extrapolate the close future to a point, the team will realise the need for change on theirselves. Use visual language to make them imagine the situation evolving
• Let the situation escalate in order to prove you prediction. Maybe the project looses now but future ones might win due to the increased experience of the stakeholder. Don't forget to document your warning, e.g. by risk management.
• Hire an external resource to educate the team regarding Earned Schedule Analysis. Consultants are trusted persons often...
• Apply other forms of power, e.g. legitimate power taking into account a missing team buy in

Fore sure, the strategy to try depends on the team and your standing within the team.

By the way: Are you convinced regarding the prediction and need for change? The stakeholder will notice of so - and if not...

Answer 2

I think there are two main misunderstandings in situations like this.

1. The past won't happen again

Looking back at delays on a project, we tend to think of them as "one-offs" that won't happen again, and the future will be smoother. Part of this is that past obstacles are explainable in hindsight: "oh, we were delayed because we forgot to send weekly reports to so-and-so, but we've fixed that problem now." On the other hand, upcoming obstacles are not yet explainable, and harder to conceive.

The truth is that obstacles have popped up, and they will continue to pop up, probably at a similar rate as they have in the past.

2. Less pain to procrastinate

We also have a tendency to delay fixing a known problem, hoping that before facing it becomes inevitable, it will somehow go away. Maybe we'll be able to rally our efforts and catch-up if we're behind, or maybe we'll get lucky and we'll have less problems, etc.

Part of this is that we discount the size of future pains compared to current pains.

Recommended actions

Explain that delays are just as likely to come up in the future as they have in the past, and we should plan on that. Help them understand that—unless something changes—they're much more likely to finish the project according to the forecast modelled on the current situation than on the forecast made when the project started.

Put the severity of the schedule slip in perspective. What does the slip mean for the involved parties? What's at stake? This could help people feel like having a meeting to discuss some options is worth their time and energy.

(On some projects, perhaps such a slip wouldn't really matter at all, and so the time and energy would be a waste. It's a project-specific decision to make.)

It might be worthwhile for a PM to address these concerns one-on-one with key individuals before going to the group. Getting some people on board first can help reduce the bandwagon-effect that you saw as people entered the ongoing debate and took the already-popular side.