Using the Project Premortem to Identify Risk Areas

Last week I came across an article titled Performing a Project Premortem written by Gary Klein of Applied Research Associates. The commentary presented the concept of a project Premortem to aid in identifying the potential project roadblocks, before they have a chance of derailing the project. It is essentially risk assessment, although with a procedural twist that holds merit. The premortem is a forum for airing the project execution concerns of the team. Having always been a fan of going in the trenches to ask the team what's not working, this aligned well with my strategy of discovering the unknown.

What could possibly go wrong? Answering this requires an understanding of the possible "what-if" situations while in the planning phase of a new project. It's about risk management and the ability to uncover a comprehensive set of possible negative scenarios and prioritizing them, dismissing some and mitigating others. Assessing technical risk is common; assessing project execution risk is far less likely to be addressed.

An unknown risk to a project will lead to an element of unpredictability, if it becomes a reality. There would not be any forethought of the possibility; therefore there would obviously not be a mitigation plan in place. The team runs into a brick wall and then regroups to find a way to navigate around the wall. A well conceived plan is suddenly thrown off track because a risk was not identified during the planning stages.

Now back to the project premortem. The idea is to establish an environment that allows the team ferret out all the possible risk areas. The premortem concept enables the successful identification of risk via the following principals:

• Establish a mechanism for soliciting inputs from a broad cross section of the team.
• Seek out the worker bees in addition to those in the management hierarchy.
• Create a non-threatening environment that is comfortable for the team's voice to be heard.
• Listen with an open mind, saving judgment for later.

Consider hosting a premortem activity while in the planning phase of projects to provide a regular opportunity to seek out risks and get them on the table. Through a routine emphasis on this risk assessment process the team becomes confident there will be a place for concerns to be aired and addressed, thus enabling them the opportunity to optimize their project contribution. For your next project utilize a premortem to find the answer to "What could possibly go wrong?" and realize a new level of predictability in project flow.

Uncovering Project Execution Risk Areas

Risk free - never. Risk conscious - absolutely essential. The ability to determine, assess and mitigate risk is a requirement of projects that must display a higher level of predictability. The challenge is in revealing the risk areas that need further attention, the unknown hazards that transition to reality and disrupt the project flow like hitting a block wall.

Technical and business risks are typically addressed to a reasonable degree; project execution risks by and large lack the attention they need. A good definition of execution risk would be areas related to the people aspects of a project such as information needs, expectations of each other, deliverable requirements and so on. I would also include the thoroughness of the plan and resource availability in the category of execution risk, since these are also people related.

So how does one go about finding the execution risks? Since they are predominantly people related a good place to start would be to ask the team members. Some of the execution risk will be related to a specific project while the majority will likely be systemic risks that span multiple projects. People related risks tend to hide well; therefore good detective and people skills will be required to uncover them. A formalized discovery activity will provide a thorough assessment of the risk areas, particularly those related to project execution.

Where are all the project risks? The team has valuable input on this; it is in the projects best interest to make sure their concerns are aired. Hold a project Premortem to provide a venue that grants the team a voice. Sift through the information that is gathered to find the golden nuggets of information that will make it well worth the time spent. Discover the unknown execution risks that quietly disrupt project flow and remove a large source of project unpredictability.

Guiding the Team Through Surprise Free Execution

When effort is put into finding the reason for a project surprise it is essential to make sure that future projects do not repeat the same mistake. Work through solutions with the team, gain consensus and add them to the library of actions to be used for future projects. Some would call this library best practices. I choose to call it same practices to signify that things are done the same way, project after project. Many may argue about something being the best but no one will argue the benefit to predictability when projects do things the same way, with the same expectations and deliverable requirements.

In simple terms the same practices library objective is in reaching absolute clarity of the who, what, when, where and how of every activity. To be clear - this is not the tasks in a project plan, it is the nuts and bolts details of activities and deliverables for every project action. Think of same practices as the source of information necessary to enable full clarity of tasks, objectives and deliverables for everyone working on the project.

Where are these same practices kept and how do you make them available to the team without becoming a burden to the users? The least effective implementations tend to be those that have a best practices document on a shared project drive on the network. It's far better than nothing but it's not optimal for the team. The best implementations are those that are web 2.0 based and contain the process sequence, the people, the plan, the schedule and the documentation all in one simple point and click user interface.

Where there is an ineffective atmosphere in place to guide the development process and same practices, project surprises should be expected. The magnitude of surprises will be reduced with an emphasis on a comprehensive process sequence and deliverable expectations along with a simple environment used to relay this information to users. When full clarity of individual objectives and deliverables are met, surprises will fade. This is not rocket science; it's people science!

Understand the Source of Project Surprises and Eliminate Them

What would enable every member of a new product development team to produce at such a level that projects flowed forward with negligible backtracking? You know, the backtracking that comes from failing to do it "right" the first time. The backtracking that silently eats into project efficiency, increasing costs and delaying revenue. Look back at those project surprises that caused a frenzied attempt to recoup what was lost. Why did they happen? Was it destiny, possibly fate, or was it because of a flawed assumption that should have never been made?

The last time a negative impact surprise made it's way into a project, what was the source? In most cases we will immediately conclude "something that was not planned, should have been". Although that possibility is certainly valid, it should not be assumed to be the end of the investigation. A project surprise usually means there will be backtracking to a previous task to rework something. It is essential that the root cause is uncovered whenever the project sequence is rewound to an already completed task.

More often then not when a task needs to be revisited it is due to a flawed objective of the task, the output or deliverable did not meet downstream expectations. That's not a timeline estimate issue; it's a task clarity issue that impacted the timeline! As dates for a project are developed, clarity is assumed, although often not ensured. Clarity of expectations will only result when two people (task deliverer and receiver) have consensus on when, what, how and where something will be provided. Reaching this agreement is a people thing, one where we can't depend on technology to make it happen.

In addition to a thorough project plan there are two crucial items that must routinely be addressed to keep surprises under control. The first one is to always consider the people aspect of a project's dynamics. Avoid a pure reliance on technology and methodology as the only guidance mechanism for a project. People know their function and are clearly capable of identifying an issue that impacts their productivity, if they are asked. The second one is related to investigation. If a project surprise occurs that causes negative impact to a project, it must be investigated to the root cause. Once uncovered, changes in the process must be made to ensure it will never be repeated on a future project.

The simple formula for eliminating negative project surprises is this - when something breaks the planned project flow, find out why by talking to the people involved and then do something about it. Technical tools and methodologies will be no help here, so put them away for this assignment. This one depends purely on people skills, so brush up on the one on one investigative skills that enable discovery of root cause. Do this well and enjoy a "Freedom from Project Surprises" that will lead to predictable and streamlined new product releases.