Variance is a good thing.

It means our EVMS is working and giving us real data. No one is playing with the data to get Cost  Variance (CV) and Schedule Variance (SV) to be zero.

A variance analysis is required in most contracts when the variance exceeds some predefined negotiated threshold.  Whether you are the Control Account Manager (CAM) addressing the variance or the PM who needs to know the cause, getting to the root cause is the goal.

"I have a negative CV because I spent too much" is not a root cause, only a restatement of fact. "I have a negative SV because those engineers took longer than planned." Again, no useful information.

A very long time ago I watched a US Dept of State ¾" video tape training program on working within other global cultures. The speaker was trying to explain how to identify the cultural things we do. When confronted by someone doing what you think is odd you can ask them, "Why do you do that?"

"My Dad did it."

"Why did he do it?"

"I guess his Dad or Mom did it."

"Why?"

"I don't know."

Bang, you have run into a cultural habit. Ask "why" at least three times.

Asking "Why" three times can help get us to the root cause of a variance. "Why do you have a negative cost variance?" "Because I had to pay for more senior engineers". "Why?" "Because my original team was stuck." "Why?" "Because they were not familiar with the required technology." There is the root cause. Thank you.

Back to top

A while ago Sun Microsystems (now part of Oracle) was standing up a Program Management Office (PMO). They asked  the engineering workforce "Who wants to be a project manager?" A good percent of their hands went up and they were trained in PM basics and made PMs.

Two years later management tossed 60% of them back into engineering. Yes, there is Gates, and Jobs, and ... but the Wright Brothers never made a cent building airplanes, save one contract with the US Army.

Engineers generally don't have business sense. It's not just about features and cool things. Sooner or later you have to build it. As famously quoted, "There comes a time in the life of all projects when you have to just shoot the engineers and move into production."

Here's a possible engineer-turned-PM attitude. "I have a technical problem there must be a technically elaborate solution." Or. "I have a cost problem. There must be a technically elaborate solution." Or. "I have schedule problem. There must be a technically elaborate solution."

Being a PM is a shift in mind set. That is why virtually all MS Degrees in Program Management come out of the "school" or "college" of Business. Imagine that, a project run on business principles.

t's why engineers often can't make this shift and they fail as PMs. Business is risk adverse; engineers like cutting edge stuff. You can't blame them. An engineer needs and wants state of the art experience on their resume. That is why most attempts to reuse prior subassemblies and products never materialize. There is no "up side" for an engineer in reusing technology.

For the PM using cutting edge technology represents a risk, an avoidable risk if reuse is possible. Two different attitudes trying to work together. It's no wonder many engineers have little use for PMs who ask for unknowable answers to "when will it be working?"

Back to top