The Problem With Big Success

 

Yeah, I know this blog’s title sounds counter-intuitive. If “success” is a problem, than what in the world isn’t?

But stay with me a few sentences, and I promise to make things clear. I want to examine the term of a person “being the victim of their own success.” It usually applies to one who has been successfully implementing a certain tactic for so long that they no longer recognize new scenarios where the tactic is inappropriate, and then fail trying to implement this favorite tactic where it doesn’t belong. Put another way, when we enjoy success on a large scale, it’s very easy to attribute such an outcome with tactics, behaviors, people, and environmental factors that really had little (or even nothing) to do with the achievement being enjoyed. 

As Eric Berne wrote about in his classic book Games People Play (Grove Press, 1964), and I build on Dr. Berne’s ideas in my recently-released must-have book, Game Theory in Management, people tend to construct narratives, or scripts in their minds that serve a variety of purposes, including explaining who we are to ourselves and why our pasts have unfolded the way they did. Now consider the project team member or manager who has been associated with a project that, once completed, was considered a significant achievement and on a large scale. Unless such a person has an advanced understanding of the rules of evidence, logic, and causality (and in many cases, even if they do), odds are that significant parts of the narrative they embrace will contain cognitive biases, such as confirmation bias, which “informs” them of the characteristics of that achievement. Sometimes the association will be valid, and loosely-held. Other times, the association is invalid, and tightly-held.

For example, I was once providing the cost and schedule performance information for a very large and high-profile project. The Control Account Manager (or CAM) for the project management task had recently come off of another high-profile project that had come in on-time and under-budget. At the very first meeting on how we would set up the Earned Value and Critical Path systems, this CAM announced that my team’s first priority would be to generate … a “swim lane chart.” As I exchanged puzzled looks with my team, the CAM went to a white board and drew a set of parallel horizontal lines, and then place boxes representing tasks in between the lines. The “lanes” represented organizations within the project team.

“So, what you’re asking for is essentially a PERT chart, segregated by performing organization?” I asked. After he affirmed that that was what he was after, I offered “I think we need to develop a Work Breakdown Structure first, and then the cost and schedule baselines. Then we’ll be able to create your chart.”

The CAM was adamant. The “swim lane chart” had to be our first priority, period, and he would hear no talk of WBSs or baselines. Apparently, he had had access to these org-chart-arranged PERT charts in his earlier project, had become convinced that this particular format represented his information system silver bullet, and no amount of discussing the particulars of his request could dissuade him. Instead, the team had to essentially create the Work Breakdown Structure and cost/schedule baselines in secret, while maintaining publicly that we were exclusively pursuing the data elements to create the “swim lane chart.”

We were lucky, then. Other “successful” project managers aren’t so easy to work around. Their approaches to new problems can become chock-full of formulaic technical approaches, and any perceived deviation simply must be due to a lack of expertise or recalcitrance from the staff, neither of which is tolerable.

Conversely, managers coming off of poorly-performing projects, or even disastrous ones, tend to have greater respect for common but formidable problems that lead to overruns and delays. They also tend to retain that certain level of humility that leads them to at least listen to the other members of the project team, especially when different alternatives to approaching problem-solving are discussed. Of course, none of this is true when projects fail, and their decision-makers are not held responsible; but, in a free market environment, successful managers rarely repeat mistakes, whereas successful projects may have incurred many mistakes, but they were never identified, much less analyzed.

Andthat’s the problem with big success.