As a younger project manager, I had a conversation with my boss. “We can’t meet your schedule. Here’s what it’s going to take.” My boss said, “You can’t be serious about not meeting my schedule. I’m sure if you just put your mind to it, you’ll meet the date.” My jaw dropped as he walked away.
Denial, as in denying that the desired schedule is a pipe dream, is alive and well. It’s not limited to women managers, although to me, the name “King of Denial” sounds a little funny. (For those of you who don’t speak English as a first language, remember Cleopatra? She was Queen of the Nile and certainly in denial about a bunch of facts. This is a pun on Queen of de Nile.)
Denial occurs for a few possible reasons. The most common one I’ve seen is when the manager in question wants to encourage the project team, as my manager did. Sometimes, people are in denial because they’re in fear that the project won’t meet it’s deadline. By denying the possibility of failure, they actually guarantee failure because they haven’t performed any risk acknowledgement and management. Sometimes, managers disregard the actual schedule because they don’t have any data, and it’s easier to disbelieve the PM’s assessment of project state than it is to believe it.
Some possibilities to deal with denial, especially the denial that occurs from disbelief of failure or fear of failure:
- Write down those risks and their potential impact. Especially when I’m dealing with denial, I use High, Medium, and Low to discuss severity and exposure, not numbers.
- Show what you can do and measure the velocity you actually have on the project. Yes, iterations are your friend here. And velocity charts may help explain what’s really happening.
- Make sure people on the project have the solution-space domain expertise to perform the work.
- Investigate why your manager is in denial.
If my manager thinks that denial is the way to encourage the project team, I suggest alternative encouragement techniques. Usually, that means encouraging the manager to go do something else that would either benefit the project team (negotiate a smaller list of requirements for example), or move that manager’s attention to some other project. In my experience, the managers who think that encouraging the project team by denying problems or potential problems tend to get in the way. Focusing their attention on some other project is a useful technique for moving their attention off your project :-)
Queen of Denial is a disaster only when the PM is the one in denial. One project team decided they would self-organize and ignore the PM. After attempting to have the PM accept reality, they gave up. They stopped attending project team meetings, ignored everything the PM said. They built pieces of the project and developed some data (but not velocity charts). After a few months, when it was clear the project was not where the PM said it was, the PM was fired. But the project team had lost so much time by that point, they had many fewer opportunities to manage what they could deliver when.
Inevitably, reality comes face-to-face with denial at some point, which is why Queen of Denial isn’t always a disaster as a schedule game. When the manager does see reality, make sure you have some part of the product working to show that manager and some data so you can discuss what to do next. This is a good time to consider how little you can do, so you can complete this project and plan better for the next one.