Monthly Archives: June 2011

Complexity Risk

This post is inspired by a discussion on a linkedin group I’m a member of. Other group members are suggesting that people use Black Scholes to value real options. The problem is that they do not understand the complexity of the solution they are suggesting.

Using Black Scholes on real options is the equivalent of using a chainsaw to carve the Sunday roast.

This is how they compare:

  • Using them will give an output but not necessarily what you want.
  • Neither is accurate.
  • Both introduce risks that simpler solutions do not.
  • Neither is understood by the person using them.
  • Both can create real harm.

As an IT Risk Manager it is important to understand when a member of the team is using a tool that is more complex than the context allows. The two reasons the tool may be too complex are:

  • Simpler solutions exist, even the team may not be aware of them.
  • The tool is the best fit for the solution but the team does not understand the tool.
  • The behaviour of the tool changes in different contexts that are not understood by the team.

Black Scholes for Real Options is an example of this.


Its better to ask for forgiveness…

Apparently I have a reputation of being a bit of a maverick. Sometimes people confuse reputations and reality.

As a “maverick”, one of the things I really dislike is when I hear people say “Its better to ask for forgiveness, than ask for permission and be denied”.

This is possibly the most effective way of destroying trust with the person who “might deny permission”. It is also ignores any higher level issues that those persons may need to consider. From a game theory perspective, you are information hiding which means you have adopted the strategy of conflict* in dealing with those persons. The result of this behaviour is that the other person might enforce more onerous controls than previous…. even if you have chosen the correct solution.

When we want to build trust, we foster transparency. If someone has a control responsibility they are much less likely to be intrusive if we actively seek them out to ensure they have the information they need to make their decisions. If we try to hide information, they will seek to impose greater control to ensure they are managing their own risk. A much more effective way to approach this situation is to communicate with them and understand why they make the decisions they do. Once you understand their requirements, it may be possible for them to reduce the level of control and place limits on your behaviour instead. You can agree with them the conditions in which you need to defer to them for decisions. When faced with uncertainty, err on the side of seeking permission. This approach will lead to more trust and greater limits.

I’m reminded of a time from my secondary school days. There were two sets for maths. I was in the top set. One day, one of the boys from the bottom set was sent to sit next to our maths teacher because he had been disruptive. Every time he raised his head to look around our teacher would immediately focus him back on his work.

He was shocked at our behaviour. Students doing exercises freely walked around the room to talk to each other…. Not only discussing the maths as those who had finished their work would openly gossip or joke or discuss other subjects. Anyone struggling with the maths was more likely to ask a fellow student for help than ask the teacher. However if someone wanted to go to the toilet, they would check with the teacher before leaving the room. That was the limit.

His maths set was ruled with an iron rod. No one was allowed to talk. No one was allowed to walk around the room. Only the teacher spoke. If you wanted to ask the teacher a question, you raised your hand and waited to be spoken to.

Why was this so? Our maths had a set of goals that were aligned with the teacher. We wanted to get good grades. We made sure we got the work done. Once we had the work done, we were free to act as we chose as long as we did not disrupt anyone not finished. The teacher was not the only person in the room helping others to learn. We had demonstrated we could be trusted to work within the initially oppressive rules and gradually our behaviour had been rewarded with less and less stringent rules.

That said, we did get in trouble once when we hid the history teacher’s black board. Apparently that was outside of the limits.

*”Strategy of Conflict” by Thomas Schelling

Group watching …

Groups deliver the software. Although a group consists of individuals, a group can also develop a personality of its own.

Because a group consists of an number of individuals, it is possible for a single idea to start with a small subset and then gain momentum and gain the support of the group even though only one or two people support it. As an IT risk manager it is crucial that you monitor the behaviour of the group and ensure that it does not fall victim of group think. Some types of group think are quite subtle such as the Abilene Paradox.

Apart from group think, you need to think about the behaviour of a healthy group.

  • You will hear laughter from team members.
  • Team members have lunch or socialise with each other.
  • Team members might engage in non aggressive banter.
  • People smile.
  • People can have a vigorous argument about something but it does not affect the way they treat each other.
  • Everyone is informed of and working towards the group’s goal.
  • Everyone feels valued.

Once again, if anything changes, you may have an issue you want to investigate as it could have an impact on your ability to deliver.

Issues with groups have been around since the dawn of time. Some IT team experts are now studying shamonic practices from a scientific perspective to see what can be learned.

Once agin, happy to hear of anything people do to deal with groups.

Relationship watching…

Team are made up of people which means that any team of people consists of  a large number of relationships between the individuals.

For the team to be healthy, everyone on the team should communicate effectively with everyone else on the team. Sometimes this does not happen. When team members do not have effective relationships, there is the risk that they may not communicate effectively on something important. As a result the project may be at risk.

If a developer does not tell a tester that they have something to test, the tester may be delayed in starting to test. These delays accumulate.

Relationship watching is harder than people watching because you are looking for the negative space. You are looking for those people who are not communicating effectively. The opposite of a good relationship is not a bad relationship but rather no relationship.

Things I look out for…

  1. People who used to be close who no longer talk.
  2. An absence of humour.
  3. People being unpleasant to each other.
  4. Snarkiness and snide comments
  5. Groups going to lunch together who do not take along certain individuals.

I’d love to hear how others look for broken or absent relationships.


People watching…

Software is delivered by teams. Teams are groups of individuals.

This means that as an IT Risk Manager your greatest risk is your team. No team, no deliverables.

As teams are composed of individuals, you need to be aware of three things


Relationships between individuals.



For individuals your risk is that they are not performing at their optimal level or that they might leave. To manage both risks, the important things is establish effective relationships with your team and to watch their behaviour. If someone’s behaviour changes, you do not make any assumptions as to why, you simply use that knowledge to know something has changed. You can then talk to them to find out whether there is anything that can be done to assist them. A few of the things that could cause a change are:

  1. Things going badly in their personal life.
  2. Things going particularly well in their personal life.
  3. Struggling at work.
  4. Conflict at work.

Although most people strive on an element of stress in their life, after a certain point, an increase in stress can be harmful. The community surrounding the Myer Brigg Type Indicator are aware that stress can cause someone’s MBTI to change.* They themselves may not even be aware that their behaviour has changed.

A small additional stress in their home or work life may be causing them difficulty. When someone is struggling in one part of their life, make sure they relieve stress in another part.

If someone is thinking of changing their job, as an IT risk manager you would ideally like to know about it before they hand in their notice. Get to know them so that they trust you with that information. They may decide they want to come back.

* “Was that really me” by Naomi Quenk

Busy or lazy… Which makes the best risk manager?

As an IT Risk Manager we are interested in managing time rather than costs. The cost of a project is the length of the project multiplied by the daily run rate.

Everyone understands this…. or do they?

When you need some input from your project manager, do you..

  1. Have instant access to them?
  2. Wait an hour or two to catch them between meetings?
  3. Arrange a meeting in their busy schedule?

If you do not have instant access to them, they may be delaying the project. But what does an hour or two matter? An hour doesn’t but lots of hours do. Those delays waiting for your manager accumulate. It only takes 7 and you’ve lost a day off your schedule. 35 and its a week of delay.

However its worse than that. Often the small delays have knock on effects that cause bigger delays, especially on a project being run in multiple time zones.

Think about catching a bus. You are 30 seconds late for the bus which means you have to wait 15 mins for the next. As a result, you are 30 seconds late to catch your train and have to wait 30 minutes for the next… You are 5 minutes late for your plane… which means you have to wait 3 hours to catch the next. Which means you miss your meeting and have to wait a month for the next.

Delays add up in a non linear way. Make sure you manage them and make yourself instantly available. Do less to help your team achieve more.

Just because someone is famous does not make them right.

It is a common mistake that people are considered to be right simply because they are famous. Just because someone has written a book or is well known does not mean they are always right.

Often in their specialist subject, they are probably more right than others, but not necessarily. If they are famous, they are almost certainly experienced at giving the crowd what it wants which makes them even more compelling.

The real risk is when we listen to someone who is well regarded in one field when they opine or state a belief about another field. For example, an expert in lean manufacturing or lean service provision is asked to opine on the subject of lean software development.

The fault is not with the famous person. They are only doing what they have been asked to do. And they are normally given the incentive to do it.

The fault is the people who listens to a lay person and treats them like an expert… Simply because they are an expert in another subject.

Michael Jordan might be an expert in Basketball but I’m not sure I’d ask him about his opinion on IT risk management even if he had spent 6 months reading academic papers on the subject. Similarly I do not think Michael would be too interested in my views on Basketball (Isn’t that the one with the bats?).

It takes a long time to get the IT Risk Management mind set right. However it is a new and exciting subject. Expect experts to appear from all over. Expect experts from Scrum and Lean and Kanban and Real Options to suddenly declare themselves to be experts in IT Risk Management. Existing tools will be made more exciting by adding the word risk. Expect to hear about Risk Burn downs and Risk Retrospectives and Risk Driven Development and Risk Scrums and Feature Risk and eXtreme Risk and Risk Pairing and Risk Stories.

But most of all… Watch out for Michael Jordan, expert in IT risk management. It says so on his business card.