Didn’t We Just Leave This Party?

 

I get it. I really do. Even the best Project Managers can get to a point where their capacity to adapt to new circumstances, organizations, locations, technology advances … the list goes on and on of those things that force us to modify our strategies and tactics if we are to succeed. It’s easy to look back on previous successes, and desire to repeat that success by, well, repeating those managerial approaches, confident in a repeat of the outcome.

But that’s the catch, isn’t it? By definition, every project is unique, sometimes dramatically so. And there’s really no way of quantifying which PMs were successful due to re-loading tried and true strategies, and which were successful by significantly deviating from those very same strategies. Actually, it’s fairly difficult to differentiate the consistently successful PMs from the repeat failures, due to the wide variety of cover-the-backside techniques, so that coming up with a litmus test for telling the successful ones clinging to traditional strategies from the radically innovative ones is probably impossible.

I know this from personal experience. I had been assigned to set up the cost/schedule performance systems for this one major project where the PM insisted, at the very first project team meeting no less, that he wanted a “swim chart” as his primary method for tracking the project.

“You know, a swim chart!”

“Umm, do you have an example?”

With a sigh and a roll of the eyes, he went to the white board, where he drew a comically crude PERT Chart, with the tasks arranged by organization down the X axis.

“Oh, okay, I see what you want. We’ll need to begin with a Work Breakdown Structure.”

“A what?”

“A Work Breakdown Structure. It’s the way we decompose the scope into the tasks and activities that we can then sort by performing organization.”

“Look, I don’t want to hear about any of that. I just want a swim chart! Can’t you just give me that?” (Point of fact: when a manager starts repeating the word “just,” it’s a sure sign that they don’t have a clue of the difficulty associated with the fulfillment of their demands.)

“Not without some groundwork first” I replied, as meekly as possible.

He called my boss and had me removed from the project.

In retrospect, I understand his frustration. It was clear that, on some previous project where he was involved, this report had been generated on a regular basis, and much of the decision-making had been predicated on it. This PM probably didn’t realize that the org-sorted PERT Chart wasn’t simply a cartoon graphic, or the output of a singularly immature system. I just happened to be the unfortunate project controller who broke the news to him that he couldn’t “just” have one quick and easy.

This why-can’t-it-be-just-like-my-last-project phenomena occurred again, when my bosses’ boss, a fairly seasoned executive, wanted to initiate a new action item tracking system, and wanted me to head up the implementation effort. With the software’s reps on the conference call speaker phone, this exec was very ready to spend some serious coin to make it happen. Like an idiot, I had to ask a question.

“I see you have categories for ‘Action Items,’ ‘Issues,’ ‘Concerns,’ ‘Trends,’ etcetera. Do you have a precise definition for each of those categories? I mean, what’s the exact difference between an ‘action item’ and a ‘concern’?”

“We let the individual users define those.”

“What difference does that make?” stormed the exec.

“Well, it’s just that a given ‘issue’ could show up in a wide variety of systems already in place, or even in multiple categories within the same system. If the same action item shows up in multiple places, and the particulars aren’t in agreement, how do you know which one is correct?” I then addressed another question to the software vendors. “Does this system reach into other tracking systems?”

“No.”

“Then, if one item does show up in multiple iterations, and everybody’s not in complete agreement, how will we know which system has the more reliable information?”

I could see the exec getting visibly upset.

“Look, if you have your heart set on this system, I don’t want to be the barrier. I’ll work whatever implementation effort you choose.”

The exec called my boss and had me removed from the project.

Along about this time my capacity for sympathy for managers desperate to recreate previous, comfortable environs was drying up. This exec clearly had no concept of how valid Management Information Systems are set up, or function, and had fallen prey to a slick and shiny software package that had made some inchoate promises along the lines of how they could provide an easily-understandable report that told him what he needed to pay attention to that day, or that week, and this pesky PMP® was throwing cold water reality on the object of his fascination.

Again, I get it. Having to respond constantly to situations that are only marginally analogous to ones where we were confident that we had the optimal solution gets old really quickly. But that having been said, how many parties do “managers” have to attend where they insist that the hostess change everything to match the parties the managers had previously attended before they don’t get invited any more?