TOC and Risk Management for Projects

11 January 2018, Oded Cohen  

In a recent post on TOC4U (8/1/2018) Rajeev Athavale wrote:

“Risk Management” is a standard process covered by PMBOK. It is an excellent process and is highly useful. However, I am not able to connect this process with TOC. Risks may not arise out of constraints. They typically arise out of events – internal as well as external.

Even though Rajeev states that the standard process provided by PMBOK is excellent he requests to learn how TOC handles Risk Management and especially for projects and IT projects.

Rajeev also wrote: “When I look at this [what the PMBOK offers (OC)], I struggle to find any process in TOC which can either invalidate this process or replace this process or compliment this process. I am seeking to know this.”

I disagree with any attempt for using TOC to invalidate other processes that work. What is the point? What for?

In 40 years that I have been with TOC we have never embarked on such a quest. If there is a process that works – it means that there are no problems and no GAPS or no UDEs. TOC also does not make coffee. So what?

We better focus our efforts when there are needed. Bringing Value is only where there is a real need – a problem that cannot be easily overcome.

However, discussing TOC and Risk Management may have its own merit, because unlike Rajeev there may be other practitioners that do not find the PMBOK suggestion practical.

Throughout the years there have been many cases of amalgamation of TOC with other approaches such as TOC with TQM, TLS, Goldratt and Deming and many more. Such amalgamation has been fruitful when practitioners have found that other approaches have suggested the WHAT is needed to be done but has not provided the HOW. In such cases TOC can be of a significant help.

Hence we offer our views.

The general life cycle of a project include four phases:

1. Initiation
2. Planning
3. Execution
4. Post project

TOC has a lot to offer for the first three phases. Once the project has been completed, the post project may be handled as maintenance, production or as mini-project(s) to cover for realized risks – “issues” that have not were not prevented or addressed during the project.

TOC CCPM deals explicitly with the Planning and Managing the Execution.

The CCPM solution is captured by a set of Injections and each Injection is backed up with detailed HOW guidelines and procedures.

During the planning phase the logical structure of the project is rechecked to ensure the achievement of the entire specifications. Detailed checks are made also at the individual task level to ensure that tasks are capable of producing the expected deliverables. Therefore, during the planning phase many practical and known risks can be found and handled – either by eliminating then or by catering for by developing contingency plans.

It still can happen that the people who construct the project plan – usually the project manager with the help of project management office, may be blind to some potential risks that they have not considered. Therefore, once an initial plan is ready it is recommended to present it to the key stakeholders and get their views. Using the TOC Thinking Processes enables the analysis of reservations and suggestions and using them to upgrade the plan.

The execution phase has buffer status and buffer management to raise the alarm for potential risks to the project. The sooner management knows about the risk the faster the reaction and the ability to recover in time and with reasonable cost.

For the initiation phase TOC can be incorporated by using the Thinking Processes.

Usually, during this phase the project design team constructs the general structure of the project through arranging the major blocks of the project breakdown structure.

This structure can be subject to Necessity and Sufficiency logical checks. These checks also highlight the conditions that must exist for the achievement of each block of the project. During this phase data can be collected regarding the risk associated, the difficulties, the need for critical resources, variability of cost etc.

It is also possible to build a project Strategy & Tactic Tree to capture and check all the relevant knowledge and thinking underlying the entire project.

Published by Oded Cohen, 11 January 2018