Ctrl+Z and the Project Manager
Most Windows applications have an undo command. Hold down the Control key1 and press Z, usually described as Ctrl+Z.
It’s an extremely helpful invention. It allows us to “take back” things we deem incorrect, whether intentionally or inadvertently. Inadvertent misteaks mistakes are an obvious use. Sophisticated computer users will often create or modify something just to get a sense of how it looks and then undo it, in a sense creating a mistake intentionally because they know that reverting to the previous state is a lot easier with undo than with, say, creating an alternate reality.2
So if you realize in a document that you just made a mistake, no sweat. Ctrl+Z it away.
Life isn’t so easy.
What’s a project manager to do when she realizes she’s made a mistake? I’m talking about an actual mistake, not a quick slip of the tongue, for which we already have a verbal undo key.3
There are three common strategies:
- Brazen it out. Pretend that it wasn’t a mistake after all; indeed, maybe you believe it wasn’t a mistake and that others claiming you’re wrong doesn’t make it so.
- Lie about it. Claim that you never said it, or wrote it, or intended it.
- Apologize and attempt to fix the problem as soon as possible.
The NFL4 tried door #1 Monday night. At left is the iconic image of the event, where one referee signals touchdown and the other (indirectly) signals interception, the exact opposite.
This was the last play of the game, and it changed the outcome. Give Seattle the touchdown, and they win. Give Green Bay the interception, and they win. It’s that simple.
There’s no question in almost anyone’s mind that it was an interception; even the most rabid Seattle fans are admitting it. The refs got it wrong. (They stuck with the touchdown call.) But the NFL then tried to claim, both directly and with some weasel-worded statement, that there wasn’t a problem. It was really a touchdown and the call was correct (or at least not incorrect). It hasn’t worked. The brand they’ve tried so hard to build has taken some serious hits the past few days, serious as in “laughingstock.”
They couldn’t change the call the next day; that would open up an enormous can of worms. But they could have admitted their refs got it badly wrong, in numerous ways. (They didn’t confer before signaling. They didn’t confer after signaling. They didn’t correctly interpret the rule on simultaneous possession. And on and on….) That simple admission would have made then look considerably less dumb, and won back some fans.5
I have known a few project managers who tried this strategy. They quickly lost the respect of the client and the project teams.
Strategy #2 is also surprisingly common. “You misunderstood me” is a regular PM refrain in some quarters. A close relative is the lawyeristic version — “technically, if you read the fine print and look at that clause in this particular way, I was right.” Because lawyers are often in positions of organizational power (e.g., a senior partner heading a matter), they can sometimes appear to pull off this strategy because subordinates are afraid to speak up, or may simply accept that the senior lawyer is right because he’s so senior and experienced. However, keep in mind the old saw: Fool me once, it was my fault; fool me 14 times, and I may start to smell a rat.
Strategy #3 is generally the right choice.
It’s hard to admit a mistake.
My experience is that in the long run you’ll take a credibility hit either way, by admitting the mistake or by failing to own up to it.6 However, the damage to your credibility keeps on growing the longer the mistake hangs out there uncorrected — and in the long run, if it leads to a less successful project outcome, the damage can be significant to you, to your practice, and to the client’s interests.
Even if you don’t think it’s your mistake, you can apologize for the fact that something is unclear. “Something’s wrong. Let’s not worry about fault, but about fixing it.”
The problem isn’t whether you should have signaled interception instead of touchdown.7 The real problem is persisting on an errant course or continuing to deny the error.
The sooner you fix it, the sooner you can stop fretting about it and get on with the real work of making your project successful.
That’s how Ctrl+Z works in the real world of projects.