Reverse engineering risk

As a project manager I am used to completing risk logs and risk reports. Some are simple, others complex and generally involve updating a spreadsheet of the following columns


  1. Ref
  2. Category
  3. Scenario (Description of Risk)
  4. Business Impact (1-5)
  5. Likelihood (1-5)
  6. Gross Risk Score
  7. Risk appetite:- Accept; Reduce; Avoid
  8. Consequences
  9. Vulnerabilities
  10. Control measures
  11. Responsibility
  12. Assessment of control
  13. Residual Business Impact(1-5)
  14. Residual Likelihood (1-5)
  15. Net Risk (Residual Risk)
  16. Risk appetite:- Accept; Reduce; Avoid – Is risk within acceptable boundaries
  17. Gap – Are there any deficiencies where measures are concerned?


Sometimes it is more columns with more detail. Sometimes less. However writing risks down does not resolve them. It is helpful to understand and acknowledge them but sadly the majority of projects fail because of …

A lack of definition (of scope, goals, acceptance criteria)

A lack of funds (sufficient to meet capital and revenue demands)

A lack of resources (to discuss, define, document, and deliver)


Indeed, instead of looking at possible risks and guessing the consequences it may be more helpful to look at common failures and see what we can do to avoid them. Effectively reverse engineering risk management

  1. Poor planning
  2. Inconsistently defined resources
  3. Unclear objectives
  4. Lack of detail control
  5. Lack of transparency
  6. Lack of communication
  7. Change of direction
  8. Unrealistic expectations
  9. Lack of monitoring
  10. Unrealistic due dates
  11. Poorly assigned roles


Typically the Lessons Learned Report, from previous projects or previous stages is a useful resource

Lack Of Preparation

Example: Skipping or rushing a formal project kickoff meeting with all involved can lead to you being ill-prepared for project tasks or goals.

Inadequate Documentation And Tracking

Example: There isn’t a way to measure project success when important documents are not kept or are not easy to locate.

Poor Leadership

Example: Poor leadership can develop when leaders are not fully engaged because they have too much on their plate.

Failure To Define Parameters And Enforce Them

Example: Project scope creep resulting from project requirements can change planned deliverables as work progresses.

Inexperienced Project Managers

Example: Organizational structures to support good project management and the people who perform it simply do not exist in many companies. Plus, some companies lack a formal project management methodology.

Inaccurate Cost Estimates

Example: There is often a challenge with costing work on a project that has not been done before or is outside the normal type of work created.

Poor Communication Across Teams

Example: Teams are not aligned on project goals because they don’t know how or when to communicate updates.

Culture And Ethics At Odds

Example: Mismatched work ethics, geographic time zone issues, and language barriers can cloud the common goal and affect outcomes.

Poor Resource Planning

Example: Project failure can occur when there are limited resources or there is an inability to get the resources in place to get the job done due to budget and time constraints.

Disregarding Warning Signs

Example: Project Boards o Project Assurance meetings acknowledge the risks but do not make decision or take actions to change the circumstances that give rise to them.



Instead of paying for tasks and time (where everything takes ages and the costs go up unchecked) instead focus in the deliverable and the date. I want x by dd/mm/yyyy and I will only pay when is it delivered and passes the acceptance criteria. This does not deny the vendor payment, but instead focusses attention on the deliverable and the date.

The use of acceptance criteria avoids scope-creep or endless enhancement that adds time and cost but is seldom adding value. It would be better to have Version 1 compete and then go for Version 2 if necessary that forever be working on Version 0.1 which simply never gets finished.

Linking payment to completion (delivered and passing the acceptance criteria) means the vendor has skin in the game. Otherwise the reality is the vendor makes more money by being slow or incompetent.

Linking payment to deliverables with a schedule also clarifies what is fixed-price and what is variable, avoiding problems later if there is a debate on what is included or excluded, fixed or variable.


Competing demands from other projects and business activities can have massive impacts on project productivity as project estimates are often underestimated or do not consider these ‘other’ commitments and distractions when projects are in the planning stage. Furthermore Context Switching (where someone is involved in multiple projects) can also lead to as much as an 80% loss in productivity:

1 project: 100% working time available per project

2 projects: 40% working time available per project. 20% lost to context switching

3 projects: 20% working time available per project. 40% lost to context switching

4 projects: 10% working time available per project. 60% lost to context switching

5 projects: 5% working time available per project. 75% lost to context switching

Problems generally arise when things get delayed and instead of one-thing-at-a-time we are attempting everything all at once. Doing many things at the same time is problematic and everything suffers and nothing gets complete.

Whilst it is appealing to remedy lateness by saying “we can catch-up by doing everything in parallel” often the inter-dependencies of issues (often impacting the same small team of people) make this problematic.

I have previously posted that projects ae like targeting a 26 mile marathon on 4 hours and taking 3 hour to get to the half-way point. It should be obvious that the second half is going to take at least 3 hours. You cannot get back on track by doing the remaining 13 miles on 1 hour!

The secret to marathon running is consistent pace and steady momentum which comes from having a plan, clear milestones and incremental success mile by mile. The same is true in project delivery, incremental progress, rather than an avalanche of tasks at the eleventh hour.

I have more than 30 years’ experience delivering projects, programme and change and have gathered many tools, templates and tips for every type and scale of project. I love drinking coffee and exchanging ideas, so if you need anything please feel free to message me.

Tim HJ Rogers

MBA Management Consultant + Change Practitioner

ICF Trained Coach, IoD Business Mentor, Mediator

Mob 447797762051

We offer #consulting, #coaching, #mentoring, #facilitation and #mediating to support individuals, teams and organisations through #change.