/ risk management

Risk Retrospective — Opened and Quantified

One of the many aspects of project management that is often overlooked is risk retrospective as part of a post-mortem review. The business world is becoming more and more competitive as cost of entry in most market goes down. Projects are often pressured into producing new value at a rapid rate in order to simply keep up with the segment they’re competing in. This means that once key components are accepted into operation by stakeholders, there remains little time to reflect on the project’s performance. Requests for new features are already on the table that require the full attention of the project team.

What then can be done to streamline the retrospective process and ensure a proper dissemination of acquired knowledge?

Risk Lessons Sharing — Problems and Existing Alternatives

How well did the previous project perform? What pitfalls should future endeavors avoid in order to ensure success in their enterprise? These questions will either remain unanswered. If information exists, it will often be locked away in the minds of the finite group of players that participated in the project’s completion. Those players may have already moved on to other things.

Larger companies often have lower employee turnover rates. Knowledge loss is therefore less of an issue because resources may have access to an internal community of practice in which to share their thoughts. A project manager is never further than a phone call or an email away from asking a peer for advice or insight on a potential issue. People often stay long enough within the same circle of communication to ensure that the knowledge remains available to those who need it.

Who then does need help?

What of smaller companies, or even startups, where project management practices are nascent or even inexistent? Some new entrants often take the form of a single person with an idea and the means to potentially generate a viable product. That single person isn’t always surrounded by a community of like-minded individuals that have gone through the gambit that he or she is about to face. Where would a lone wolf entrepreneur go to obtain these lessons and adjust his strategy? There is no clear way for them to assess the risk landscape of what they’re about to launch themselves into. This lack of structure generates a risk in itself to the project. The feedback loop is broken because there are no signs ahead warning of potential dangers down the road.


Tom Kendrick (FailureProofProjects.com), in his book “Identifying and Managing Project Risk” (Amazon, Google Play, O’Reilly) detailed an experiment in risk analytics. The experiment, called PERIL (Project Experience Risk Identification Library), gathered risk lessons description and impact data for over 600 projects over a finite period of time. The author then categorized them following a taxonomy that allowed him to present a landscape of common pitfalls. The result is an analysis on how to ultimately avoid these risks from manifesting themselves.

But why stop there? What if the core purpose of PERIL, being its gathering and categorizing of risk data, became a more permanent fixture? What if we didn’t stop at 600 projects, but rather let the data grow and refine itself over time?

PERIL allowed those who participated in feeding it to input the nature of risk according to categorization, and the effort and funds impact of the risk’s manifestation on their project.

On a more permanent basis, a facility could allow users to input their risk lessons and massage the raw data from all entries into reports that can provide a view into issues that could affect his project, based on specific criteria.

Examples of criteria could be:

  • The industry the project evolved in;
  • The nature of the risk according to a normalized taxonomy;
  • The impact the manifestation of that risk had on the project’s ability to deliver value.

My field of knowledge centers mostly on information technology projects. During lunch with a friend of mine in the industry, one of the first channels that came to mind when single player startups came to mind is version management services, such as GitHub. These service providers often attract the potential user group that would form an early adopters segment. An account could give them access to community tools where they could share their experience as they navigate the highs and lows of trying to put out a quality product. As a branch is merged into production, workflows provide the opportunity to provide feedback on potential pitfalls. Those notes become part of the commit and get added to a global pool for others to learn from.

Obviously, a great disservice to the potential this provides would be the make such an added value service limited to one source of input. Rather than adding on to a single tool, a centralized, separate service with a mature API offering would allow several service providers to access the data and add to it. This could greatly expand potential sources of knowledge as new partners integrate the service into their own offering.

The true value of an offering of this kind is in the quantity and quality of the data it holds. History is rife with examples of projects that failed to pay attention to the lessons of the past and payed the ultimate price because that knowledge was either of poor quality or hard to obtain. We live in an age where near infinite knowledge is literally at our fingertips. Why expect any less when it comes to risk management?