What shall I write about?

What is this blog for?  Why did I put up this blog?

First, I want a place to write down some of my thoughts, and play with them.   Writing helps you clarify your thoughts.

Second, this provide a place for me to communicate some of my ideas.  You may find them useful, or you may find them dangerous and mistaken (in which case, please let me know).

Third, this is an outlet to write in a less formal way and to sharpen my writing skills (and boy do they need sharpening).

Fourth, this is a place for me to jot down ideas that get my attention.

What subjects will I cover?

I do not want to limit my subjects, but it will surely include those areas of my professional interest: systems engineering, project and programme management, risk management, lean and agile solutions, organisational behaviour, computing, etc.

Who is my target audience? 

Me.  I am writing mainly for myself, but you are welcome to listen in.

The Working Advisor

The title of this blog is inspired by Leonard Sayle’s book, "The Working Leader: The Triumph of High Performance Over Conventional Management Principles"

A leader gets his hands dirty and interact with the day to day environment, adjusts his ideas to accommodate reality.

I am a consultant.  To many people, the word consultant brings to mind a professional who comes in to an organisation, looks at problems, writes up a document recommending solutions, and then leaves, without having any responsibility for implementing those recommendations.  Oh, and the sends a huge invoice for his services.

I believe a consultant is one who, although they may do the above, stays and helps execute the ideas they recommend. 

Execution and implementation reveals faults.  There is no harsher or more fair judge than reality.  Ideas that look good on paper may collapse when tried. 

PRINCE2 Themes

Prince 2 identifies 7 themes that the project must address continually.  By integrating these themes in its normative processes, PRINCE2 ensures that the themes are addressed.
The PRINCE2 themes are:

1. Business Case – why the project is being undertaken
2. Organization – for PRINCE2, the project is the project organisation. This theme describes the roles and responsibilities.
3. Quality – is about defining and refining the quality attributes of the product, and how the project will meet those attributes.
4. Plans – activities are planned for.  PRINCE2 defines the plans that need to be developed and the steps to undertake to prepare those plans.
5. Risk – PRINCE2 describes how project risks can be managed.
6. Change – assessment of the impact of change to the project
7. Progress – the monitoring and control of the project to ensure it remains viable and what steps to take if reality deviates from plans.

Risk - What Can Go Wrong

There are so many definitions of risk.

The newer versions include 'positive risk' and variations thereof. These definitions try to be very inclusive, to make sure they cover all possible perspectives and manifestations of risk. It can be a bit confusing. Some days

I am tempted to find a simple, clear, usable definition of risk.

I am not yet convinced that 'positive risk' should have the word 'risk' appended to it. On those days when I look at risk management as 'the management of uncertainty' I have no problem accepting that positive risks belong to this domain.

But for now, I will use as the most basic definition of risk:

Risk = what can go wrong.

Risk management = managing what can go wrong

The ‘wrong’ already implicitly includes a reference to our objectives.  If something can go wrong from our point of view, it means something going wrong in relation to our interests.  Something that doesn’t affect us is not something going wrong. So I don’t have to extend it to ‘something that can go wrong with regard to our objectives’  (in any case, I prefer to use ‘interests’ rather than objectives).

The ‘managing’ in ‘managing what can go wrong encompasses identification, assessment, and mitigation.

Let’s see how far these definitions will let me go.

Review of "The Failure of Risk Management: Why It's Broken and How to Fix It" Part 2

In Chapter two of his book, Douglas Hubbard's discusses where the risk management industry has been and where it currently thinks it is.

The chapter starts out with a very brief history of risk management ('800 words' according to the author), tracing the route from the discovery of mathematical probabilities, to its initial commercial application in insurance, and finally down to the modern day emerging 'new character' or risk management, incarnated in regulations like Basel II, and in applications like Enterprise Risk Management. His history is not very complimentary, comparing today's state of risk management as similar to the Old West gold rush towns, where things look brightly painted and pretty, but built on shaky foundations and filled with snake oil peddlers.

His history aligns quite well with Peter Bernstein's own summary, although at a very very high level and, I suspect, very much framed to support his thesis (which I suppose is what the rest of the book is about).

Hubbard then makes a brief discussion of the common risk assessment approaches (expert intuition, weighted scoring, probabilistic models, etc) and suggests that some of these are not up to par for the role risk management is playing (corporate growth survival, after all) and will probably need to be dispensed with.

The next section covers risk mitigation approaches. He has a brief treatment of the common approaches (what risk management book doesn't?): avoid, reduce, transfer, retain. The most interesting part of this section is his list of examples of concrete manifestations of risk mitigation approaches (in contrast to the abstract approaches of
avoid, reduce, etc. His list includes selection processes, contractual risk transfer, insurance, liquid asset position, etc.).

In the final section, Hubbard discusses 3 major surveys of enterprise risk management, conducted by Aon, The Economist, and Protiviti. The surveys show what the executives in these companies thought about what their top risks are (reputation, market, human capital, and regulatory environment figure very high). The surveys indicate that risk management is present in those companies primarily because they are being required to have it (a necessary evil). It also shows that risk
management is well represented and increasingly so at the board level.  The executives seem pretty confident that they are doing risk management well.

Hubbard suggests that that is not the case at all.

The Duck Hunters

Duck hunters shoot ideas as soon as they hear of them.  This is a recipe to become a mediocre team.

Imagine yourself in one of your project meetings.  This particular meeting proceeds just like any other meeting.  You look around checking everyone’s faces. You can plainly see on everyone that unmistakable look that they’d rather be elsewhere.  Everyone knows this meeting is a waste of time.  The meeting conveys nothing that can’t be broadcasted by more efficiently and effectively by email.  But it is a long held ritual and apparently must be perpetuated.

All the ingredients that make up dull meetings are here: meaningless status updates,  the obligatory round-the-table ‘what are you working' on’ exercise, and finally, the question: ‘Is there anything else?’

The more experienced members of the team keep silent.  However, Jack, a new and young member of the team, nervously, tentatively, makes a suggestion:  “Uhm… I was just thinking… uhm… you know how we are implementing the database for this system… I was just thinking, have we determined all the end users who will be using this system?  I was just thinking, they might have different needs and I’m not sure the database as currently designed will be able to handle all their needs. I was just thinking we should maybe make a list of the different kinds of stakeholders and what their needs are”

Jim, the project manager replies dismissively:  “We’ll just be making extra work for us that way. I think you’ll find that even the stakeholders don’t know what they want.”

Bang! A Duck Just Got Shot Down

The project manager’s dismissal of Jack’s suggestion, apparently without even giving it its deserved consideration, is equivalent to shooting down ducks as soon they get spotted. 

Duck? An idea duck.  People who shoot down ideas as soon as they get raised are what I call duck hunters. The moment they hear an idea, they take aim and fire: Bang! Another idea shot down.

Some people are so good at shooting down ducks, almost as soon as they take flight, they are the equivalent of professional duck hunters.  Maybe they find pleasure in shooting down ideas – maybe an ego boost.  Maybe they’re trying to act decisively, but what’s the broader impact to the project?

Let’s take a broader view.

How would Jack feel?  He has put forward what he obviously thought was a good idea, something that he thinks will benefit the team.  But his idea just got shot down, almost not taken seriously.  You can be sure he is anything but more motivated. Next time, he might try again, and when his duck get shot down again, his attempts will come less and less often, until it finally stops.  When people notice their ducks being shot, soon they will stop introducing new ducks. 

How would other project team members feel?  Maybe some of them agree with the project manager.  Maybe some of them agree with Jack?  All of them will notice – at different degrees – how Jack’s idea was shot down.  They will think twice about raising their own ideas.

An environment not conducive to inviting ideas has just been established.  Whether this negative environment continues and reinforces itself to the detriment of the team, or gets weaker allowing more ideas to come up, depends on the next meetings.  If the same thing happens, it will reinforce the negative dynamics. 

When the Ducks Go, the Team Goes

A project team that raises no new ideas, soon becomes a mediocre team, unable to produce anything but the dullest, plainest possible product.

High quality people don’t want to be part of mediocre teams.  A mediocre team will soon experience an exodus of its brightest and most passionate members.  First the exodus will happen intellectually and emotionally.  People will start to tune out.  The team members will still be physically part of the project, but their minds and their passions have long gone.  It is only a matter of time when they also leave physically.

Avoiding Duck Hunting

How does one avoid this problem?  The solution comes from the top.  It must establish a management system where ideas a actively solicited, and rigorously considered. 

I would suggest putting up an idea log, where ideas can be put forward, and discussed and considered, and then rejected, accepted, put on hold, modified, or otherwise acted upon is.  Having a history of ideas generated is a terrific tool for documenting lessons learned.  (Of course, depending on the organisation’s culture, this could be a terrible witch-hunting tool as well).

Save the Ducks

Next time you’re in a meeting, watch for ducks, and for one day -- just one day --  make a note to leave your gun behind and don’t bring it to the meeting.

Risk Versus Risk

One of the most critical processes in managing projects are those addressing project risks.  Some writers go so far as to call risk managent 'project management for adults'.  The implication being that if you’re not doing risk management in your project, then you’re just a kid, you haven’t grown up yet, and have no place among grown-ups (I agree with this view, by the way).

When asked what risk is, quite a few will give an answer that goes something like: 'a risk anything that can go wrong.'  In this view, a risk is something that can go wrong, and therefore risk management is about addressing those things that can go wrong.

But there is another, less commonly known, view of risk.   In this view, risk is something uncertain that may affect the project.  Not something necessarily bad, but something uncertain. 

Let's suppose you are planning a picnic for tomorrow.  Being an adult, you have prepared a risk management plan (your picnics may be boring, but they are predictable).  You have an entry for weather in your risk plan.  In the first view of risk, you look at the weather and look for something that could 'go wrong' that could negatively affect your picnic.  Is it going to rain tomorrow?  If there's a chance of rain, what can we do to mitigate the effects of this rain on the picnic? Perhaps bring an umbrella.  Perhaps plan to hold the picnic nearby an accessible shelter, to make escaping from the rain easier.

In the second view, we look at the weather not as something that is the harbinger of something that can go wrong, but simply something uncertain.  So there's a 50% chance of rain.  Let's prepare for that eventuality.  But there's also a 50% chance of no rain. Let's also prepare for that happy eventuality as well -- perhaps plan to go to a place with a nicer view if the weather clears up.

With this second view, risk is not simply viewed as about bad circumstances that can happen, but simply about all uncertain circumstances. Circumstances which can indeed turn out bad (and whose effects we should be ready to address), but which can also turn out good (which we should be ready to take advantage of).

In the first view, we simply prepared ourselves for the worst.  But in the second view, we also prepared ourselves for the best.