Managing Customer Relations When Your Customer Is Simply Wrong

 

I was once assigned to provide project controls support to a fellow who thought of himself as highly advanced in project management. At our first meeting, after introductions, he told me he wanted a “swim lane chart.”

“A what?” I asked.

He proceeded to draw on the whiteboard a series of parallel, horizontal lines, and filled them with boxes representing activities, with arrows in-between them to indicate schedule logic. The areas in-between the horizontal lines were labelled with the names of some of the organizations participating in the project.

“Oh, okay, I get it.” I began. “It’s essentially a PERT chart, sorted by organization.”

“It’s a swim lane chart” he replied, emphatically, as if to contradict what I had just said. Rather than dither with a customer about the different label he wanted to give a common schedule format, I simply asked him about the Work Breakdown Structure.

“I don’t want a Work Breakdown Structure, I want a swim lane chart!” he insisted.

“I understand what you want, and I know how to produce one, but first I’m going to need a WBS in order to construct the schedule network we need to generate the ‘swim lane chart.’”

“Look,” he sighed, as if he were trying to communicate an extremely simple concept to a dull child, “I don’t want any of that other project controls stuff. All I really need to manage this work is a swim lane chart, regularly updated.”

At that point it became clear that this guy was deficient in his PM capabilities while fancying himself a genius, and that he held anyone who didn’t agree with him to be an ignoramus. In short, this fellow was (and probably still is) simply wrong.

And, being younger, I didn’t suffer this sort of wrong-headedness very well.

“Actually, in order to get you your ‘swim lane chart,’ we have to start with a couple of basics, and that includes a WBS. Let’s get started on that, and we’ll be one step closer to printing out the ‘swim lane chart.’”

After promising to get me the initial scope documents I would need to create the draft WBS, I left this fellow’s office and returned to mine, where my supervisor informed me that the PM had called and asked to have me removed from the project.  Which was okay, since, as I said, I didn’t (and still don’t) suffer this type of wrong-headedness very well. My replacement did a much better job, but I’m not entirely sure how she pulled it off. My guess is that she created a straw-man PERT chart, sorted by organization code, and then had the genius PM modify the activities, one by one, until they could be arranged into a rudimentary WBS – essentially, backing in to the Work Breakdown Structure (it would have been funny to see how they retroactively arranged the scope documentation, if that is the approach they took).

Fast forward to present-day, and I’m a blogger on a preeminent PM website, where the currency of the realm is ideas. What are these ideas? They represent theories, concepts, and techniques that help project managers do their jobs better. As with any body of knowledge (get it?), there are some good ideas, and some not so good. I’m sure it will not surprise any of my regular readers to learn that I believe that some of ProjectManagement.com’s competitors are pushing notions not derived through the scientific method – i.e., invalid – into the marketplace of PM ideas.

And, again, I don’t suffer this sort of wrong-headedness well.

A notable example of the notions I’m referring to is the idea that Estimates at Completion (EACs) ought to be time-phased. This is so wrong I’m having a hard time figuring out where to begin. An Estimate at Completion is just that – an estimate. It’s saying that, if the project continues on its current performance pace, it will cost X number of dollars. It is neither a request for more budget (when over the Budget at Completion), nor an offer to repatriate existing funds (if it’s under). It’s a performance indicator, nothing else.

But some other organizations maintain that this figure must be time-phased. What does that mean, exactly? It means that, if this notion is followed to its logical conclusion, they are mandating the creation of a rubber baseline. The existing cost baseline is the original time-phased estimate of the costs of the project. By stipulating the creation of multiple time-phased estimates, the original loses its relevance, and becomes, in the common parlance, “rubber.” It’s nearing uselessness because it’s being superseded by “more recent” information. But the altering of the cost baseline is a formal process. To do so otherwise is to set up the textbook definition of a rubber baseline. And those are not good. They are, indeed, often ruinous to projects that employ them.

So, I’m going to take my usual approach, and ridicule the notion. Those who embrace the idea that EACs need to be time-phased will consider me dumb, but that’s okay.

Because I think they’re simply wrong.