Importance of documenting key decisions
Scenario
This is one of the most underrated and boring activity that many project managers ignore. Typical reason provided is – I don’t have time. But trust me, this will become a costly mistake more often than not.
Below are a few scenarios to give you an idea:
During the initial phase of the project, a component leader is under pressure to pull in the schedule. Just to get away from the pressure for today, he will make a decision: "in current release performance is not important, let us focus on functionality; in next release, we will plan for a feature focused on performance improvement". Everyone including requirements, development, testing, release management and senior management agrees to this plan. The reason is – There is a need-by-date set by a senior leader (ex: Executive Vice President) based on a customer commitment or requirement. All is well for six months and the release is delivered to customer. One of the first test done by the customer is to load the system to a typical live product usage and the system breaks! The first person who will be asked "Why" typically is the project manager.
At the beginning of the year, an aggressive target for the year-end is set by a group leader. Everyone knows that it is impossible to meet the target. However, the target is set for typical reasons like – Impress the boss, avoid scrutiny of lower targets.. Everyone is happy and as expected, the year ends and surprise surprise -- The target is not met. Once again, the first person who will be asked "Why" typically is the project manager.
As a Fresh Project Manager
The first mistake I made in these scenarios was – Trust the stakeholder (who made the decision) will own the consequences of this decision. That is not normally how the practical world works! A typical question is – Who made this decision? Many will act ignorant and will say - "I was not involved in this decision."
The second and more significant mistake I made was – I did not document the decision and ended up defending the decision.
With a Salt -N- Pepper Look & Many More Battle Wounds
I will send a "high important" email with all stakeholders involved. The email should cover following aspects:
TO List. This is very important. One of the fundamental project management principle is – communicate, communicate, communicate. I have never suffered because of over communication. Building on this idea, always err on the side of including as many people as you can think of. The list should include senior management who will potentially challenge the decision and also include those who will say "I was not involved in this decision."
Document the decision clearly: There should be no ambiguity in the decision. It should be clearly stated.
Document the risks: There are typically some obvious risks as well as some that you can think of based on your project management experience. All the risks should be clearly documented in the email. Most likely at least one of more risks will materialize and will be the reason for the failure.
Provide a date to challenge the decision if someone disagrees: Provide a clear deadline by when you expect an answer. Clearly state that - No response by the deadline would mean, they agree with the decision.
This email will be your answer to the question "Why the failure happened". While this doesn’t solve the failure, it takes the blame off the project manager. This will lead to everyone involved to own the failure, everyone will contribute to a root cause analysis discussion and constructively find improvement actions for future projects.