Ride Your Bicycle Forward

Organisations with a merit and ranking system are like bicycles being pedaled backward.

 

In the 1950s, W. Edwards Deming, then a relatively unknown statistician, conducted seminars among Japanese companies as part of the American effort to rebuild that country’s post-war economy.  

In these seminars, Deming reportedly used the process diagram shown below, to illustrate the systemic nature of a business’s processes. 

 

The diagram showed how the various parties: suppliers, production, ‘quality control’ (inspection), consumers, research, and others, fed into each other and back in one grand system of production. 

 

Despite the diagram’s deceptive simplicity, it was conveying a message that is both deep and shallow. It was a shallow message because everyone who knew anything about operations knew what it was showing. Yet the message was also very deep because the diagram confronted everyone by asking why they did not act as if they knew that. 

 

Deming made the point that because these functions depended on each other in a systemic way, they must be managed together, as a single system. To manage these functions separately, as if they were not dependent on each other is a path to institutionalised dysfunction.

 

In our modern world of systems thinking, processes management, and post the chaotic period of the 1990s ‘re-engineering’, the reminder Deming wanted to deliver can feel anachronistic.  Not only does the diagram look old, it feels old.  It would not be surprising if a modern audience today reacted to this diagram with a: 'Duh'. 

 

Duh indeed, because by this time we all should all know that. And yet it seems we  don’t.

 

So what is the big deal about Deming’s diagram?  While no one seriously questions its truth, many big companies – precisely the ones that really need to internalise this message – are still operating the business in a backward way.

 

We can illustrate the situation by imagining we were given a bicycle, and then shown how a bicycle should run, and yet we proceed to ride it backwards. 

 

In organisations where a merit and ranking system pervades, where an employee’s ‘performance’ is annually ‘assessed’ by their supervisor,  employees become forced to consider their supervisor as their most important customer.  Employees have no option but to direct all their actions and energies to figuring out what numbers the supervisor is tracking and make sure they meet those numbers, to the subjugation of other considerations.  

 

Supervisors themselves need to please their managers, and so treat their managers as their customer, always thinking: “how am I going to be ranked?”  The situation goes on -- the managers need to please their vice presidents; the vice presidents need to please their executives; executives need to please the CEO; the CEO need to please the board.  The board need to please the shareholders, often fund managers. Fund managers need to please their bosses, in a grand system of brown nosing.

Nowhere in all this is the poor paying customer, the source of the company’s income.  No, that's not entirely true.  The customer does sometimes pop up now and then, but only to the extent where they complain thereby represent a risk to the merit and ranking of employees, or where they give praise and enhance the merit and ranking of employees, or where they can be used to further please that most important of customers, the person higher up in the organisation.

This backward operation of the forward system cannot be undone without a transformation -- a deep, difficult, transformation that demands sustained struggle.  Initiating this transformation, and even more important, sustaining such a transformation will require an unbelievable level of courage, focus, and determination.  A constancy of purpose.

Organisations who are able to operate their forward systems in the right direction will eventually benefit. Once they do start moving forward, it will be easier and easier, kept in motion by a reformed cultural inertia,  to operate the system, understand it, speed it up, improve it, and even accelerate it.  They will have realised how far, FAR better it is to ride a bicycle forward.

The New Risk

In the world of risk management, even the most basic things can get confusing.  When it comes to basics, it’s hard to think of a notion more basic than what ‘risk’ is. 

One of these is the distinction between a risk and the event that triggers the risk.  You can see a little bit of the confusion through the risk management standards.  The AS/NZS 4360:2004 standard considers risk as ‘the chance of something happening that will have an impact on objectives'.  Clearly, risk is closely related to, if not actually, an event (‘something happening’).

Compare this with the newer ISO 31000:2009 standard, which is not only an international standard, but also succeeds the AS/NZS 4360:2004 (i.e., the next version of AS/NZS 4360:2004 is ISO 31000:2009). Here, risk is ‘the effect of uncertainty on objectives’.  It is no longer an event.

Now, this very succinct definition also manages to be very confusing -- there are various discussions in LinkedIn about what it actually is trying to say. 

What then, is the difference, between an event (or a circumstance) that brings a consequence versus a risk the brings a consequence? The key to understanding risk is to focus on the word ‘objective’. Start with the objective. What do you want to achieve? This is the starting point. Literally, without an objective, there is no risk.

Once you have determined your objectives (there can be more than one), think of the various outcomes that deviate from that objective.  The third step is to consider the consequences of those various outcomes.

Let’s work through an example.  Suppose you have a job interview, and you identified your objective to be: arrive at the appointment on time.  What are the various deviations?  You can arrive 5 minutes late, 10 minutes late, 30 minutes late, 10 minutes early, and so forth.  What is the consequence of arriving 10 minutes late?  How about 30 minutes?

You can the look at the different possible events, circumstances, or situations that can cause the deviations: traffic, getting lost, underestimating the time needed for travel, forgetting something and having to go back, running out of petrol, having a car accident, etc.

After identifying possible causes, analyse them and implement mitigation plans for the ones that might be more likely, such as traffic, or underestimating the travel time required.  By mitigating the various events, you are reducing the chances of not being able to arrive on time.

You can also mitigate the risk.  But since risk is not an event, you cannot mitigate it from happening.  Instead you mitigate its consequences. So you mitigate the possibility of the deviation from occurring by addressing the events that can cause the deviation, and you mitigate the consequence of the deviation.

	Old World	New World
Risk	An event, or situation, or circumstance	The deviation from your objective
Consequence	The impact of the event, or situation, or circumstance	The impact of the deviation (regardless of what caused the deviation)
Risk Event	An event that brings about the risk	An event that causes a deviation

Woody Allen’s Success Formula

How can you be successful?  How can you attain what you want?

According to film director Woody Allen, “80 percent of success is showing up.” What did he mean? Perhaps he meant that luck plays a considerable part in success (80%).

In my own life, I look back and I see many instances where a successful phase of my life can be traced back to being began at the right place at the right time.  It is not enough of course to be at the right place at the right time.  You have to be the right person. But let me focus on being at the right place.  The place does not have to be a physical location.  Being at the right place also means having the right qualifications -- being there.

For example, if there is a need for an experienced PRINCE2 lecturer, someone who has that experience is already at the right place, using my additional meaning for being there.  They only need to show up at the right place physically.

What am I trying to say?  Maybe it's that in order to be able to show up, you need to plan ahead:

• Determine where you want to show up.  Let's say you want to work for NASA as a rocket scientist.
• Plan how you will show up.  What can you do to achieve the status of someone who CAN be a rocket scientist.
• Execute your plan for being there.  Work hard.
• Show up. Be sure to present yourself at every opportunity for being hired as a rocket scientist

Remember:  It's not the most qualified who gets the job; it's the most qualified among those who show up.  It's not those who show up who gets the job; it's the most qualified among those who show up

Notes on Harold Geneen’s‘Managing’

Harold Geneen was the legendary CEO of the legendary conglomerate ITT.  He wrote a book many years ago, titled "Managing"

Far too often, the solution taken to solve performance problems is to restructure.  But the structure is almost never the culprit.  Basketball teams all have the same structure, but consider the disparity in performance between teams, even between teams whose members are individually comparable in talent.  Geneen has this to say:

“On paper, the structure and organization of ITT was not very different from that of most large corporations in the United States.  But an organizational chart is really only a piece of paper, a static dumb thing, that identifies a chain of command of people and functions.  True management begins only when you put all these people together, functioning together, in a vital, human interrelationship so that the company performs as a single team, driving onward toward the goals set by the chief executive.  These human interrelationships, in all their facets, are what differentiate one company from another..  On paper, one company can appear to be exactly like another, and in reality be completely different.  The important policies, decisions, and activities of a company are those which deal with people, not functions.”

On managing risk:

“Good management is more than solving problems as they arise. Good planning must include the anticipation of problems that are likely to arise and the steps to be taken to avoid them.”

A Better Definition of Risk?

I HAVE conflicting feelings about ISO 31000’s definition of risk.  This standard defines risk as ‘the effect of uncertainty on objectives’, a definition that succeeds at simultaneously being both clear and enigmatic. 

Witness the various discussions in LinkedIn about what the definition means.  Look around the web for many online blog entries, articles, and explanations of what the definition mean, and carefully note the certitude shown by those who wrote those online materials about what the definition means.  Notice how they differ in their understanding.

In light of the absence of any clarifying remarks by the writers of the standard (who seem to be non-existent on the internet) about what they meant by their definition, I have settled on my own understanding of what they meant. 

Their definition seeks to succinctly explain the nature of risk.  When they say ‘effect’, they mean ‘phenomenon’.  They don’t mean ‘consequence’ as many online writers seem to  think.  (Or at least, the standard writers should not have meant ‘consequence’ in sense of a risk eventuating bringing forth its consequences!).   The reason why I feel certain ‘effect’ is not ‘consequence’ is because risk is about something that has not yet happened.  If something has not happened, it has no consequence.  Had they said, ‘risk is the potential effect of uncertainty…’, then it would clear they would have meant ‘consequence’.

My current position is that the standard writers are attempting to explain in the definition what the essence of risk is. 

The best way I can think of of what they are saying is by making an analogy, comparing ‘risk’ with ‘shadow’.  I will propose a definition of the word ‘shadow’:

the effect of an opaque, solid object on a light source. 

I like this analogy because it almost perfectly parallels the ISO 31000 definition of risk.  If you have objectives, and you have uncertainty, the intersection of the two brings forth a phenomenon which we call ‘risk’

If you have a light source, and you have an opaque, solid object, the intersection of the two brings forth a phenomenon which we call ‘shadow’.

Remove either objectives or uncertainty, and risk disappears. No intersection, no risk.  Remove either the light source or the solid object, and the shadow disappears.  No intersection, no shadow.  

I have two criticisms for the risk definition though.  First, the definition, while strictly correct, is near to being useless.  It is an academic, technical definition, not an operational definition that can be acted upon by practitioners ‘in the trenches’.   How would risk practitioners explain risk to lay members or board members of the organisation using such a definition? 

My second criticism revolves around the use of the word ‘objectives’.  The Merriam-Webster definition of objective is “something toward which effort is directed : an aim, goal, or end of action”, accurately reflecting the normal day to day usage of the word to mean something that is being strived for, something to be achieved, something not yet.

But risk is not always (nor even most of the time) about something you wish to achieve.  It is often to protect what you already achieved. 

What you already have are also at risk. 

Strictly speaking, if you have good health and you have a desire to maintain that good health, then you sometime speak of such an objective: to maintain my good health.

But what about other things? People do not consciously state that their objective is to ensure that they keep on having a house. Or that their objective is to remain alive. They have an interest in ensuring they remain alive. They have an interest in ensuring their house remains liveable by them. But they are not objectives in the same degree as things they are striving to achieve, such as a job promotion, completion of a project, and so on.

Your health, your job, your finances, your properties, your relationship. your client list, your market position, your current operating efficiencies, your reputation, etc. are all at risk.  These are things you have already achieved; objectives you already attained.  You are interested in protecting them;  they are your interests.

Risk management is (far more) often used to protect existing interests, while also being used as an aid in ensuring we achieve our objectives.  It is in the former where risk management plays a more central role.  Risk management is key to maintaining what we have; it is the means there.  It is only useful in achieving what we do not yet have; here it is not the means.

My proposition is therefore to change the wording of the risk definition from ‘objectives’ to ‘interests’.   Thus risk becomes: ‘the effect of uncertainty on interests’  where interest refers to things we value, such as health, reputation, property.   But it also clearly encompasses as well as things you seek to achieve but have not yet -- your objectives.

I think this change would be an improvement to the definition.

The Value of Ideas

Ideas are ‘a dime a dozen’ says the old quote.  And it’s true.  Unless and until an idea gets implemented, it has no effect.  It’s like gold that you didn’t know you had. 

Only when an idea is executed can you expect to receive its benefits.  There is a caveat though.  Ideas can also bring unwelcome effects.  Perhaps that is one explanation why many good ideas remain ideas.  We are afraid of the bad effects if we implement an idea.

Some ideas have little negative effect.  Put your money in the bank so it will earn interest.  There is very little danger in there.

Other ideas have potential negative effects. Put your money in the stock market so it will gain value, or at least negate the effects of inflation.  But wait: you might also lose some or all of your money. 

Ideas have an aim.  The idea to look left and right before you cross the street has the aim of keeping you safe when you cross the street.

Ideas are propositions about how things can be better.  The proposition of looking left and right before crossing is that by doing so, you will notice if there are vehicles approaching. 

Ideas have a cost to implement.  Some ideas are easier to implement than others.  Look left and right before you cross is one of those that is easy to implement and cost nothing.  That is why all of us do it.

The idea of backing up your work frequently has the aim of ensuring you have a copy in case something goes wrong with your computer.  The cost of doing so is more than the cost of looking before you cross.  That is why we have to be prodded to do it.

Ideas have an effectiveness.  Some ideas work better than others.  Looking left and right before you cross has a very good effectiveness.  It always works.  The idea of creating a project schedule has the aim (among others) of controlling the project’s delivery timeframes.  It doesn’t always work.

To sum up, ideas have characteristics set them apart from other ideas:

• The aim
• The proposition
• The cost to execute
• The effectiveness

Is there a better idea than looking left and right before crossing the street?  How about listening before crossing?  It has the same aim: to keep you safe.  It has the proposition that you can hear if a vehicle is coming.  The cost to execute is comparable to looking.  The effectiveness is not so good.  We are not as good at judging the velocity of vehicles by their sound.

What are the Different Kinds of Requirements?

ARGUABLY the most well-known categorisation of requirements is the Functional and Non-Functional dichotomy.  So ubiquitous is this classification that one can refer to them with the acronyms F and N/F and people know what you mean. 

F is about what the system must be able to do, and N/F is about characteristics that the system must exhibit to some specified level, such as being “available for use 99% of the time” or ‘of yellow colour’.

Another major classification of requirements is that between business and system requirements.  The vast majority of projects in the IT and Telecoms field will produce two requirements documents: the BRD (Business Requirements Definition / Document), and the SRD (System Requirements Definition / Document).  The key distinction between a business requirement and a system requirement is that the former is about what the ‘business’ (or organisation) needs from the system, whereas the system requirement is about what the solution system needs to be able to do (functionality), and exhibit (non-functional requirements), in order to meet the business requirement.

If a system project is aware of only these two classifications of requirements, then serious gaps exist and it is very likely that the resulting system will not meet the business objectives to the degree promised in the business case.

One way to look at the requirements is that they form a hierarchy which is more than merely the business and system requirements.

Mission Requirements

At the top of the requirements hierarchy lie the mission requirements.  An organisation has objectives that need to be met, such as ‘improve processing speed’, ‘reduce cost per part’, ‘meet regulatory requirements’.  A concept of a solution is developed and mission level requirements are developed.  These requirements specify what is needed from the solution in order that it will meet the business objectives.  The concept solution, if it is to deliver the objectives of the organisation, must meet the mission level requirements.

These requirements may include such things as interoperability with existing organisational systems, availability by a certain future date, or cost only a certain amount.  

Stakeholder Requirements

Next come the stakeholder requirements. What do each of the stakeholders need to be able to do, in order to meet the mission requirements?  If the mission is to 'improve processing speed by 100%’, what does stakeholder A, B, C, etc. need?  These requirements are written in the language of the stakeholders (for it originated from them, and since they need to confirm the cleaned-up version). 

Although these requirements originated from the stakeholders, they almost always need to be elicited from them through capable facilitation.  They also need to be reviewed for completeness.  Stakeholders tend to provide only the most salient requirements prominent in their mind.

Derived Requirements

The Stakeholder Requirements are analysed and reviewed to produce the Derived Requirements.  Derived Requirements are the input to the Design process and the Verification process and therefore are written both in more precise language (e.g., “the system shall…”) and in more technical language.   Since these requirements are derived, there must be some form of written justification as to how a derived requirement meets a stakeholder requirement.  From an administrative point of view, we also need to maintain traceability links back to the stakeholder or mission requirements.

System Requirements

System Requirements are Derived Requirements which specify system-level functionality or characteristics of the desired system.

Component Requirements

Component Requirements are Derived Requirements which specify what specific components must meet.  For example, for a web-based system, components might include requirements for web servers and database management systems. 

There are other ways to classify requirements, but they are orthogonal to the above.  For example, there are things such as Input Requirements, or Operational Requirements, and Schedule Requirements, but each of these also fall within one of the above hierarchy.