Admitting Failure Before a Project Begins
Here's a slightly counterintuitive project management tip for you: fail before you begin. I'm not talking about a big failure, but a small one; something that you as the PM or one of your compatriots could easily sweep under the rug as being inconsequential to project delivery. Odds are, by the time a project is beyond early discovery, something is behind or some unpleasant surprise has appeared.
A few examples:
- POC Software wasn't delayed in reaching internal QA.
- RFP responder needs extra week to schedule in person pitch.
- Insufficient RFP responses.
- Kickoff meeting delayed 3 days due to scheduling conflicts.
- Basement kitchen space doesn't meet code requirements. The other requirement for the failure, is that you be able to take responsibility. This isn't about installing a fear of failure in the project team; it's about seizing an opportunity to foster frank and honest communication within the team. I fail early and admit the failure to the rest of the team then document how we've recovered from the problem. Effectively, I'm attempting to pattern an immune system for the project. I want light shone on every problem and a support structure that ensures everyone who needs to know is aware of the hiccups and headaches that happen along the way.
What I don't want is a project culture that hides or obscures problems. I want to ensure we're all upfront and honest with bad news. After all, brutal admission of the hardships ahead is correlated with success, not failure.