Skip to main content

Author: Claude Emond

Project Risk Management in 12 Questions

Written by Claude Emond on . Posted in Articles. 1 Comment on Project Risk Management in 12 Questions

Many people ask me how I proceed when doing a project risk assessment workshop on a project. Well… I ask questions. Actually 12 of them repeatedly. Not only for the assessment portion, but to cover the whole project risk management process cycle: identification, reality check (not in PMBoK per se), analysis, response, and monitoring and control.


Firstly, I never use the word “risk” in those workshops, but rather “concern” or “worry”. Most people just hate to talk about risks….a primitive type of magic thinking to the effect that if we talk about a risk, it will happen (a curious belief since it is the contrary that will happen!!).

Secondly, I do risk management on the project at stake, not using so-called risk checklists and taxonomies. I start with having everybody on the workshop agreeing on a project charter and a workable WBS (which most of the time do not exist the first time I am called in, six to 12 months after the start of the project). Thus, addressing each of the major elements of the charter, and after of the WBS, I start asking my questions.

I separated these questions by risk management process step, with commentaries, to help you see clearly how this goes.

Risk identification

1- Do you have any worries or concerns with respect to…?

I ask this question systematically to everyone present, for each of the major elements of the charter (constraints, project strategy, key success factors, assumptions, etc..) and then for each of the major element of the WBS (looking in this case at inputs, outputs and the transformation process used to deliver the outputs of the element)

Reality check

This is not in the PMBoK, as a separate step per se. This is a little Ishikawa process I added to find root causes and treat them instead of acting on risk symptoms. (It’s my little contribution to improving on the currently used and often unsuccessful risk assessment methodologies)

2- Why are you concerned or worried? Because of a past experience, a current state of affairs or an intuition about possible future events?

On a 100 M $ project I looked at, after a year since its start, this question helped the risk assessment team (12 people) reduce the original 300 concerns or so, found with the first question above, to 67 root causes that everyone could see “in the present” or concerns based on past experiences (I threw away nothing since many original concerns had a the same root cause)

Risk analysis

I then ask three questions on each root cause identified “in the present”, thus one that everybody can see, a “known-known,” if we use the cryptic terminology of the seasoned PMP. Here, I want everybody on the team to agree on the foreseen impact…and it is a lot easier to agree on this if everybody can see the same present situation.

3- What happens if we do nothing with respect to this concern?

4- Would it put the project objectives or part of them in danger?

5- If we do nothing, how fast can we be endangered?

….measures urgency to act if we have to act

6- What is the probability this thing could happen if we do nothing?

…measures probability of occurrence. I purposely delay talking about probabilities at the latest moment possible, since this is highly fuzzy business and nobody sees the same future. But usually, if I got people to agree on root causes everyone can see in the present, they very rapidly agree about the impact of doing nothing about it. So the probability question is settled very fast, as everybody desires to act on the group-perceived danger of doing nothing.

Risk response

7- So, if we need to act, what do we do?

8- Who is responsible to do it and report on it?

9- When will that be done?

Acting on perceived dangers or current problems is the real reason we do risk assessment workshops on projects. I say that because most organizations, which have documented project risk management processes (not many), do not use them consistently. Most, of the very few that do use them, feel happy with stopping the process after producing those colourful red-yellow-green risk probability-impact matrices (that cannot be understood, by the way, by 15 % of the male population, the men who are color-blind). These nice looking matrices are useless if we do not act on them. So, do something (which is only possible if all stakeholders agree to act on a risk element. They can only agree if they see the same present root causes and are all worried together when they see them).

I got a complete risk response plan with 67 elements (dates, everything) on the 100 M $ project mentioned above, after a discussion of only 90 minutes or so, because everybody (12 people in the workshop) knew that they had to act fast, all convinced of the dangers they ALL saw clearly in the same “present situation” they at last shared on this project.

Risk monitoring and control (so…continuous risk assessment)

10- Does our risk response plan works?

11- If not, what do we do now?

12- …And today, do you have any new worries or concerns with respect to…?

Here we start the cycle all over again.

Since project risk management is a continuous process, who should ask these questions?
Me or another facilitator? No, we are not there all the time.
A “special” risk management manager assigned to the project? No, we already have a manager on this project.

A project manager fully aware that risk management is his/her responsibility, because s/he has been hired to do just that; manage uncertainty? I strongly believe so.

The Rules of Lean Project Management: Part 7

Written by Claude Emond on . Posted in Articles. 4 Comments on The Rules of Lean Project Management: Part 7

By Executing Your Small Promises on Single-tasking Mode

I continue here to expand my set of Rules of Lean PM, following Hal Macomber’s comments in his blog on my original four rules series (http://www.reformingprojectmanagement.com/2008/11/09/883/).

Another lean principle put forward by Hal “has to do with batch sizes of one or single-piece flow.” Hal, as do many Lean and Agile PM proponents, notices that: “Large batch production, whether it’s placing concrete, writing software code, doing design, or performing administrative work, misses the opportunity for learning, creates the circumstances for waste, and delays the completion of the project.”

I have already covered the part about very small deliverables (small batch size) in my blog entry on tracking small promises (http://www.projecttimes.com/content/view/180/92/). Unless I misinterpret Hal’s point, I might not have put enough emphasis on the need to deliver them as much as possible on single tasking mode. This is a very important principle to follow, on an individual level, to eliminate waste and accelerate the delivery of your own promises on any given project.

In my blog entry on tracking small promises I reported that, according to research by Goldratt and others, productivity is greatly improved when you deliver in small promises. Doing this reduces the set-up time required for the Last Planner to continue the work to be done after an interruption, thus increasing productivity dramatically. I omitted to talk about the single-tasking technique one can use to further accelerate individual promises delivery. Still, according to Goldratt, although you might work on many tasks in your multi-project environment, you will be more productive if you tackle those tasks one after the other, when possible (usually tasks on different projects that are independent of one another). So Goldratt proposes that you single-task those multi-tasks, that is do one after the other, to save further on task set-up time.

The productivity increases achieved through this single-tasking strategy can be quite impressive. Hal Macomber once wrote about a small experiment one can run in workshops that goes this way:

  • Split the workshop participants in pairs, one person executing tasks and the other timing execution time
  • Give the following tasks to perform: write three series of characters, namely 1 to 10, a to j, and I to X (roman numbers)
  • These tasks must first be performed in parallel, i.e. write 1, a, I, then 2, b, II , etc…while you time the work
  • The tasks must then be performed in series, i.e. write 1,2,3,4, etc., then a, b, c, d, etc…..while you time the work.

Try this. You will be amazed by the differences between the two ways of doing these tasks. I have tried that with more than 200 workshop participants up to now. The productivity increases come consistently between 20 to 50 %. If multitasking is this detrimental on such simple tasks as writing series of numbers or letters, imagine what is happening to your projects when you keep switching between more complex tasks, from one independent project task to another, in the hope of accomplishing more during your week.

So Rule number seven of eight of Lean Project Management is Execute your small promises on single-tasking mode.

Rule No. 7 of LPM – Once your deliverables are cut into smaller pieces, deliver them one after the other, as much as possible.

By cutting your project work in smaller pieces/promises, you will save on set-up time each time you are interrupted, thus accelerating delivery. This accelerating effect can be increased furthermore, if you also try to execute these promises, one after the other, this saving an additional amount of set-up time. In a multi-project/multi-tasking environment, the most productive strategy is to single-task, doing these multiple tasks in series, when possible.
02/09

The Rules of Lean Project Management: Part 6

Written by Claude Emond on . Posted in Articles. 6 Comments on The Rules of Lean Project Management: Part 6

Opening, Adapting and Closing Often

I continue here to expand my set of “rules” of Lean PM, following Hal Macomber’s comments on my original four rules series in his blog (http://www.reformingprojectmanagement.com/2008/11/09/883/).

Another lean principle Hal said I had left out was the necessity to PDCA everything (the Deming Wheel – http://en.wikipedia.org/wiki/Shewhart_cycle). Hal notices in his blog that “much has been made of the tools, techniques and methods of lean ways of working. But behind it all is Deming’s (Shewhart’s) Plan – Do – Check – Adjust cycle. It’s the embodiment of the scientific method. No company does it better than Toyota. Make it your habit.” Hal has however revisited the PDCA acronym by replacing the original meaning of the “A” (Act) by Adjust. And I will also revisit, because I believe the PDCA cycle, as stated, does not clearly illustrate what should be project work.

In the current edition of the PMBoK (3rd ed., 2004), PMI also acknowledges the importance of the PDCA cycle in project management, but goes on promoting its own version of it, the IPECC cycle (Initiate, Plan, Execute, Control and Close). There are slight but significant differences between those two cycles, differences that mirror those between recurrent operations and projects:

  • PMI “I” (Initiate) is inherent to projects (they start somewhere), hence not included in the more generic PDCA cycle
  • PMI “P” (Plan) is similar to Deming “P” (Plan)
  • PMI “E” (execute) is similar to Deming “D” (do)
  • PMI first “C” (Control) is equivalent to some extent to Deming “CA” (Check, Act). Continuous improvement in project management requires a special kind of acting to handle major project uncertainties and inherent changes. So for projects, Adapt would be a better word than Act and, I believe, more representative of high-uncertainty projects reality than the word Adjust
  • PMI second “C” (Close) is also inherent to projects (they have to close, while we do not want to close operational business processes), hence also not included in the more generic PDCA cycle. Granted, one could argue that Acting in the case of a project includes Closing it.

Hal said that we had to “PDCA everything.” The word everything is, for me, the key to the Lean PM philosophy and is related to LPM rule No. 2 (Track small concrete promises that you can see evolving over time). Everything, for me, means: each activity, each deliverable (daily and weekly promises/deliverables if you think Lean or Agile PM), each work package, each phase/stage of the project as they evolve.

So I submit that, for projects, we have to IPDCAdC continuously. Initiate, Plan, Do, Check, Adapt and Close everything. Open-Adapt-Close often. Open new work, adapt to change as you do it, and close it to the satisfaction of all stakeholders. And one must not forget that some projects need to be terminated before they are completed, if they cannot deliver what is required; so Close can also mean Stop!

In acknowledgement of Hal’s revisited comment, here’s Rule number 6 of 8 of Lean Project Management: The Open-Adapt-Close Often rule.

Rule No. 6 of LPM. Open-Adapt-Close, Open-Adapt-Close, Open-Adapt-Close… all the time.
The IPECC cycle is a recurring process; this recurrence is the true key to successful projects, lean-influenced or not. In order to close a project, you have to open-adapt-close formally at the phase level, to open-adapt-close formally at the work package level, to open-adapt-close for each required deliverable (small concrete promises), to open-adapt-close each required activity undertaken.

The Rules of Lean Project Management: Part 5

Written by Claude Emond on . Posted in Articles. 5 Comments on The Rules of Lean Project Management: Part 5

Rolling the Waves

My little series on the rules of Lean Project Management was supposed to end with Rule No. 4 (Humans, Humans, Humans) discussed in this blog last October. However, I will now expand my set of “rules” following Lean Project Management specialist Hal Macomber’s enlightening comments on my series in his blog (http://www.reformingprojectmanagement.com/2008/11/09/883/).

Hal observed that I left out three important principles underlying Lean PM, namely: make commitments at the last responsible moment, PDCA everything (Deming Wheel), and produce deliverables in small batch sizes of one or single-piece flow. I did not cover those, since I believed they were not unique to Lean Project Management. However Lean gives them a special slant, certainly worth presenting as additional rules or principles. To the three extra principles proposed by Hal, I will also add, in retrospect, another one: the single tasking of multiple tasks.

So let’s continue with Rule number 5 of 8 (….until we find other ones!): The Roll the Waves rule.

Hal notices in his blog that (as last planners – my addition) you should make your choices and commitments at the last responsible moment». He, and other Lean practitioners, noticed a habit on projects to lock down requirements early, to get material on order early, to grab resources early. These steps rarely help and usually add waste to the project. Further, we lose options when we act early.

I would somewhat equate this principle of making commitments when we are more certain of possible outcomes with the practice of Rolling Wave Planning alluded to in the PMBoK and very well presented by Gregory D. Githens in his excellent white paper, Rolling Wave Project Planning (https://www.projecttimes.com/wp-content/uploads/attachments/NP02.PDF). Good project managers and their team understand that it is useless to plan in detail the whole of a project when one does not have the results of the current project phase or stage necessary to elaborate clearly the next phase. For example, it is quite a waste of effort to detail the development phase of a new product before we have a clear definition of its concept and design criteria. It is also presumptuous to commit oneself on the design of a building’s foundations when the results of required geotechnical studies are not yet available.

On one of the projects I helped plan for an architecture firm, the project client ask me to be more specific on things that were planned to happen three years later; he wanted to discuss details about this period. I had to tell him then that this was useless to discuss these points further while nobody had made precise commitments about the feasibility study phase we were about to begin; these commitments were still impossible to make then, because we had yet to have his permission to enter the future project site to assess initial conditions.

The Rolling Wave Planning principles are very simple: take commitments and detail your planning for the work about to begin, for which you have all the information necessary to take proper action (very low uncertainty). These are “work packages” that you can commit to deliver with a high level of certainty for a given budget and schedule. For the work to accomplish in a later phase, most often requiring as input the results of the work packages you are working on, you should stay away from too much detail, since you do not really know what will be needed then. Rather, you can present this latter part of the project as a set of “planning packages” that will be revisited and detailed only when appropriate – when we have a clearer understanding of what has to be done and what CAN be done.

Rule No. 5 of LPM – Make your choices and commitments (promises) at the last responsible moment. Make them in the form of work packages that will deliver the desired results anticipated with a high degree of certainty….

…Roll the waves: plan the work, execute the work, learn and adapt, plan the work, execute the work, learn and adapt, plan the work, execute the work…succeed

Just do it!

Written by Claude Emond on . Posted in Articles. 8 Comments on Just do it!

Implementing best practices and promoting best behaviours on the projects you manage.

For many years now, I have been giving customized project management workshops for various public and private organisations. Most of these organisations had, when they started these workshops, a low maturity level in project management, as defined by OPM3 or similar models. Most of the things I promote in those workshops, the contents of which are validated with customer representatives, just did not exist formally in these organisations when I started this training. Still now, more often than not, those who take these workshops go back and try to apply project management processes and tools that are unknown to their organisation as a whole, hence in an environment that has, apparently, no structure in place to support them.

Because of this lack of formal organisational structure, some workshop participants tell me that they are waiting for their organisation to promulgate the project management policies and put into place the processes, structures, practices, tools and incentive systems to support the use of the knowledge and skills I am coaching them to develop as habits. What I then answer to them is based both on my own experience and on what I have seen happening in most organisations where project managers do what they are supposed to do voluntarily. My answer is: You believe this project management stuff is necessary to the success of your projects and good for your organisation, do not wait for anybody’s permission! Just do it!

After the 250 participants mark in a series of workshops I am involved with, the customer, a world class organisation, made a survey to see what was happening with this training/coaching program? Were there any measurable benefits? What was found was the following:

  • Although not supported by formal organisational elements, two out of three participants (67 %) were actively using the knowledge and skills they had acquired in the workshops. They considered it helped them deliver better projects, with added satisfaction for their team and themselves.
  • The managers of those participants, using their new knowledge and skills, said unanimously that these persons had improved their performance in project mode significantly. Although they did not understand the processes and practices used (they had not been trained and there is no official project management elements in place), they valued the results so much that they asked for these workshops to be given to more resources in the organisation

Those participants, who did not wait for their organisation to give them official directives to apply their new knowledge and skills, found out rapidly that they still were able to create additional value for their organisation through the projects they delivered; and they were rewarded for this. They found out, like I did before them on the projects I managed, that you do not need the permission of anybody to act appropriately on your projects. Actually, the organisation that did this survey has continued to organise these workshops. I am up to 500 people trained/coached and still going at it. The organisation has still to put in place official processes to score better in maturity level with OPM3 and the like. Nonetheless, the maturity is increasing any time a new workshop participant just goes out there and applies what he has learned, because he believes doing so is necessary to the success of the projects he has to manage.

Lately, in one of these workshops, a participant kept repeating that he was waiting for his organisation to give him directives to use what I was teaching them. I simply told him that he was seeing it the wrong way. I told him that if his organisation had permitted him to take this workshop (a 4-day effort spread over four weeks), there was a reason for it. The organisation was now waiting for him to apply his new knowledge and skills to show the way to others.

The message was clear, his organisation was telling him: JUST DO IT!