Admitting Mistakes

If there are any perfect project managers out there, I haven’t heard of them yet. Even the most famous and successful project managers made mistakes. The difference between these folks and some others was their reaction to their mistake. They didn’t pretend it didn’t happen; they confronted the mistake, made corrections and got on with it. That’s how they gained their goals. To do this they kept the focus on the project and achieving its goals and not on their reputations. Mature executives expect everyone to slip up occasionally. What they don’t expect and can’t afford is people who try to cover up their mistakes and fail to learn from them.

The first step in the process is to recognize when a mistake has been made. The symptom will be a variance between project results and your project plan. The variance may not necessarily be that the project has gotten behind schedule, or that the project is over budget. It may be that a team member or group of members are working 10 or 12 hour days for work you allowed 8 hours for, or are producing an unexpectedly high number of defects and re-work. You’ll recognize these symptoms by the background noise consisting of team member complaints.

There are some mistakes that are commonly made by project managers. There is a fairly comprehensive list and description in a set of articles on the three O website: Common PM Mistakes. If you would like more background on what to look for, I suggest reading these articles. This article is not about identifying mistakes, but what to do once you’ve identified a mistake. Keep in mind that the mistakes I’m referring to here are ones you’ve made, not mistakes team members or stakeholders have made.

Do not try to cover the mistake up and hope the project completes before anyone notices. You may be the first to notice because of your proximity to the project, but others will notice before long, either because of the results you report or because the problems worsen. Take ownership of the mistake. You are in the best place to correct the mistake, or at least to identify the proper corrective action, so it stands to reason that you should own the mistake. Analyze the mistake. Identify what went wrong and why. You may want to perform some root cause analysis on your own at this point. Trace back to the root cause by repeatedly asking yourself "why” until you identify the root cause. Now identify a corrective action. Ask yourself if the corrective action can be performed by the team and if so, will it be effective in bringing the project back on track. If the corrective action can be implemented by you without any change to the project plans then go ahead and take the action. You may want to communicate the action you’ve taken to the project sponsor and team, for example in a "corrective actions taken” portion of your weekly status report. The one skill that will separate you from the common herd is your ability to spot the mistake as early as possible. Monitoring the project through work results and "walk about” management are your best tools for achieving this. Don’t hesitate to take corrective action once you have identified a mistake.

Corrective actions that require a change in the project plans will require a change request. Corrective actions may require an extension of the schedule, an increase in the budget for additional or different resources, a reduction in project scope, or some combination of these. Review the mistake, its impact on the project, the cause of the mistake, and the recommended corrective action in a sit-down meeting with your project sponsor. The sponsor may have suggestions of their own to correct the problem and these may require some thought on your part to determine their effectiveness. Don’t be afraid to ask for more time to consider their proposal if you need it. If your sponsor’s corrective action is as good as or better than yours, adopt it. If not, don’t be afraid to tell the sponsor and explain your reasons for preferring your corrective action. Point out any risks attendant on the corrective action and manage these through the risk register.

Once the change request has been composed and approved, implement the change, changing your project plans and baselines as appropriate. The change and the reason it is necessary (i.e. your mistake) must be explained to the team and stakeholders at the next opportunity. This doesn’t require you to wear a hair shirt and abase yourself before the stakeholders and project team; treat the mistake dispassionately by explaining the mistake and its impact on the project in technical terms. Use the "I” pronoun by all means but don’t overuse it. Everyone should have a thorough understanding of the mistake, its negative impact on the project, and how it will be corrected. The ideal opportunity for this communication are team meetings, stakeholder meetings, and steering committee meetings.

Let’s use an example to illustrate what I mean. Let’s say you’re managing a project to build a software system using a new development platform. You’ve planned for the appropriate training, acquired a few SMEs on the new platform and allowed for a learning curve, but that allowance is proving to be insufficient; effort and duration estimates are significantly less than the actual time required to build the system. The cause of this is underestimating effort, but why was the effort underestimated? The immediate reason would be unfamiliarity with the new platform, but why were you unfamiliar with it? The reason might be that insufficient research was done on estimating the learning curve. For arguments sake, let’s say you accepted the vendor’s word for the learning curve without further research. So your mistake was not researching the learning curve sufficiently to support accurate effort estimations for the work. The reason might be any one of many such as a bad formula for calculating the effort, or some other reason. The reason doesn’t matter; you’ll identify it when you perform your Root Cause Analysis. The important thing is the identification of your mistake. Now you can get on with identifying a corrective action. Let’s say your charter identifies delivery of the new system by the deadline as a top priority and delivery to budget as the next highest priority. Examine the requirements in the Business Requirements Document (BRD) to determine the lowest priority requirements and drop enough requirements to allow the project to complete on time, and for the original budget. Now you have the problem described, identified your mistake, and the corrective action which will bring the project back on track. Now is the time to call for that sit down meeting with your project sponsor and explain the problem to them.