The IT Risk Manager

When people talk about risk or describe risk, you get the impression it is one thing. Risk is a way of thinking about a projects rather than a single thing. There are as many risks as there are variables that can affect the outcome of your project.

In finance, market risk values are normally calculated as the sensitivity to an market data input variable.

Take for example a Credit Default Swap, the simplest Credit Derivative Product.

The Present Value of a CDS, PV = F( C1..Cn, IR1..IRk, CoF1..CoFj, FX, t )

Where C1..Cn, IR1..IRk, CoF1..CoFj, FX, t are the market data inputs (Credit Spreads, Interest Rates, Cost of Funding, Foreign Exchange Rate, the date respectively).

The basic risk (used for hedging) is calculated by bumping each market data input independently. This means that there will be a risk value for each of the market data variables, namely, each of C1..Cn, IR1..IRk, CoF1..CoFj, FX, t… Approximately 100 values.

That is before you consider scenarios and stress tests on the portfolio.

There are process such as P&L explain and P&L attribution to ensure that there are no unknown risks. They ensure that all of the P&L is explained or attributed to the known risks.

In addition, there is operational risk. Operational risk is broken down into…

• Risk of operational failure
• Legal Risk
• Reputation Risk
• Fraud Risk
• Security Risk
• Regulatory Risk
• Model Risk
• And many, many more

In finance, risk is a mindset. It is not a single value.

The next time someone talks about risk on an IT project, ask which type of risk they are talking about.

Control is a mechanism whereby one entity provides directive instructions to another entity. The controlling entity dictates exactly what the controlled entity should do.

A driver controls a car. When the driver turns the steering wheel left, the car should move left. When the driver puts their foot on the accelerator, the car should go faster. When the driver hits the

Limits describe the boundary of operation for the limited entity. Provided the limited entity stays within the limits it is free to operate as it chooses.

A drivers speed is limited by the authorities. In suburban areas where people are more likely to step into the road, then limits are lower. On motorways/freeways the limits are higher. Near a school or hospital the speed limit is even lower as there are people who may run into the road in an “irrational” manner. Occasionally someone may breach the limit such as an ambulance, fire engine or police car on the way to an incident.

Many risk managers confuse controls and limits. Control require constant active engagement. Limits need to be monitored and may require occasional adjustment.

Using limits instead of controls frees the IT risk managers time up so that they can focus on managing other risks in the project.

Imagine children running around in a field of corn close to a cliff. Instead of telling the children what to do at every moment, you can create a line near the edge of the cliff. When they cross the cliff you intervene. You become the “Catcher in the Rye”.

Effective commnication is vital on any IT project. It is even more important on a project under pressure or in crisis. When a project is struggling and most at risk, some people find it harder than normal to communicate. They prefer to struggle on and try to resolve an issue rather than admit that they have a problem.

Its important to build relationships with everyone on the project so that they feel comfortable talking to you. Its useful to speak to people outside of the work place where the social boundaries are little less formal. A meeting room is too formal. “How’s it going?” can sound like the start of an interagation. A coffee bar with a cup of decaf latte or a wine bar with a glass of old speckled hen provide the a much better environment to have a difficult conversation.

But not if its the first time you do it.

Its important to establish the place out of work where to have the conversation before you need to have that first difficult conversation. Otherwise it will be seen as manipulative.

Instead, take time to get to know the team. Take them for a coffee, for lunch, for a glass of wine to chew the fat and get to know them.

When you need it, you will appreciate the option of having a safe place to go and chat where the rule of formality are a bit more relaxed. A place where people will communicate more than they normally would.

As I’ve written this down I’m concerned that someone might read this as a management technique. Its not. I enjoy getting to learn about the people I work with. This is a great way for me to justify those all those coffees I drink.

There seem to be some people around who do not see the value of business analysis. They see business analysts as order takers who simply write down what the business need. The IT equivalent of a waiter.

Business Analysts perform an important risk management role for the business investor. They help the investor understand the implication of the investment before the investor commits to an expensive development phase.

As a business analyst, my view has been that the business analyst adds most value by killing requirements that add no value. A good business analyst is one that helps the business build what they need. An excellent business analyst helps the business realise that they need to kill what they thought they want but do not actually need.

In addition, the business analyst can help the business understand what is actually required to deliver the value they need. Most often the requirement is presented in the form of a “Half-ar*ed solution”. The business analyst can facilitate the discussion with the business to identify the business value. Then they can facilitate the discovery of the capabilities that need to be build to deliver the value. If the cost of delivering the capabilities is greater than the potential value, then the business investor can chose to do the work “later”.

As a project risk manager one of your risks is that a member of the team does not know something that they need to know in order to get a task done.

Some people ask for help when they are stuck or unsure.  Some don’t. People who do not ask for help when they should are an added risk to your project.

I’d be interested to hear what others do about this. I think pairing is a great way to surface this risk.

When I interview someone for a role I keep asking questions until the candidate says “I do not know” or “I’d have to ask someone else” or some such variant. If they cannot admit they do not know something, they are a very real potential risk to the project. When they know more about a subject than I do, I will get someone else who is an expert to probe their knowledge. The area where you are most at risk is in their area of greatest competence as it is here that they are least likely to ask for help.

Whenever I hear discussions about scope, I hear that an item of functionality is “in” or “out” of scope.

This is the wrong way to think about scope. When we say that something is “out of scope”, the person requesting that item will fight to keep it in scope.

Instead, consider things that will be built “now” or “later”.

“Now” means we could start work on it before the next time the business investors meet.

“Later” means we will not start developing it between now and the next time the business investors meet to discuss scope. If the business investors meet on a weekly basis, it means that we will not start working on it this week.

If the business investors only meet once a quarter you will face a lot more pressure to start on an item now than if they meet once a week. As a result there is the danger that you will start work on things because you might need them and as a result build the wrong thing.

If your business investors meet once a quarter, the investment decision process will take a long time. Although the investors might agree on the first, second and third priorities, they will spend a long time discussing the relative priority of items four to twenty.

If your business investors meet once a week, they only need to agree on the first or second priorities at most. This will normally be a quick process.

Also, as the business investors meet more regularly to prioritise investments, they will become more effective at the process. If you do something once a week, you will be better at it than if you do it once a month and much better than if you do it once a quarter.

An “IT Project” is actually a business investment.

Steve Freeman and I first first wrote about the three categories of risk in Agile Times Vol 6 (?). We stated that there are three categories of risk.

1. Delivery risk. The risk that the software is not delivered on time, on scope, to budget or of sufficient quality.

2. Business Value risk. The risk that the business investment does not deliver the anticipated business value.

3. Risk to the Enterprise. The risk that the project will actually damage the organisation.

Most literature on risk in software development focuses on delivery risk. This is because most IT risk is development centric. When considering risk from the perspective of the business investor, delivery risk is only a third of the risk. Minimising delivery risk may increase the business value risk or the risk to the enterprise.

Whenever I join a team there is a guy named Bob. Bob is great. He is the rock that the team is built around. Bob does most of the development and investigates/fixes most of the production bugs. Bob is great. Bob normally arrives a little late because he was working into the early hours the day before. He works late to get his development work done because he spends much of the day investigating bugs or attending design meetings. Bob is a roll your sleeves up kind of guy who gets things done. Bob is on the critical path for all the projects and anything he is not involved in struggles or fails. Bob never has time to adequately explain how the system works to anyone else. Bob is utilised at somewhere between 150% and 200% depending on his need for sleep.

Bob is a IT risk management nightmare.

• Every time a bug or request comes into the project, Bob is rightly involved. Unfortunately Bob is normally assigned the most critical aspects of development on the project. Bob normally sits right on top of the critical path. Every delay to Bob hits the critical path.
• Bob normally enjoys this situation even thought he may complain. He enjoys being the hero. He enjoys the daily praise of IT Management and the Business for saving the day yet again. Although popular, Bob normally does not have a partner demanding their time. The real risk is that Bob gets a partner who objects to the amount of time they spend at work.

The problem comes because of the way we traditionally allocate those staff with the most options to tasks. We normally look at the hardest tasks and allocate them to Bob, then Bobette, followed by Bobina and then the rest of the team pick up the easy stuff. This is because we attempt to optimise

Instead we should consider the liquidity of the project when we allocate staff to tasks. We should consider the time it takes to respond to change (Liquidity).

Staff should be allocated to tasks based on their ability to do a task with support rather than on their own. The developer with the most should options should NEVER be allocated to a development task. Instead they should pair with junior staff (in terms of the system) to transfer knowledge. This means they are instantly available to address any issues (bugs, business changes, design issues) that arise WITHOUT AFFECTING THE CRITICAL PATH.

When an issue arises, they should never address it on their own. Instead, they should pair with someone else with an aim of freeing themselves from being committed to the issue as soon as possible. Whilst they are focusing on an issue, they are not instantly available to address another problem. When the issue is de-risked, they are then free to work on anything else. They may choose to stay working on the issue or work on something else. The key is that they are not the bottleneck. They are not the only person who can address the issue.

An example of how this works.

Some years ago I was head of Business Analysis for a group. I received a call from the business manager. A client had refused to do another lucrative (think tens of millions) deal unless our company fixed a problem with our current process. I grabbed Tarquin, the BA in charge of that business area, and within two or three minutes we were both at the trading desk to discuss the problem with the business manager and trader. Within an hour, the two of us had mapped the entire process and identified the cause of the problem. We then suggest a spreadsheet reconciliation that would act as a control to prevent the problem from recurring. Tarquin and a desk developer worked on the solution for the next two or three weeks. The business were able to inform the client of the plan and I was able to go back to sleep at my desk waiting for the next crisis.

A few years ago I was lucky enough to assist with the facilitation of an end of project retrospective.

At the start of the retrospective the facilitator ran a “Safety Check”. Everyone in the retrospective had to anonymously vote on a post-it note how they felt about the retrospective. “One” meant “I feel really comfortable”. “Two” meant “I feel mostly comfortable”. down to “Five” which meant “I feel very uncomfortable”. Everybody voted “One” apart from one person who voted “Two”. A mini witch hunt progressed with management trying to work out who had voted “Two”. The irony of the situation was lost on most people.

Everyone was meant to say they were really comfortable. Many of the people probably did feel comfortable. Some probably did not. The one person who had expressed a genuine feeling of disquiet were made to feel they had done something wrong and should be hunted down for it.

When it comes to listening, the hardest thing is to create an environment where people want to tell you stuff you do not want to hear.

One of the biggest risks to your project is that one or more team members leave at a time that has a big impact on your staff liquidity…  on your ability to deliver your current and future BVIs.

The best way to manage this risk is to make sure your team do not want to leave.

It is important to understand that the factors that cause people to leave are not the same as those that motivate them. All project managers should make sure they have read the classic Harvard Business Review article by Herzberg “How do you motivate Employees?“. They should also understand Maslow’s hierarchy of needs. Without an understanding of both, you may be attempting to retain or motivate your staff in a way that suits yourself but does not suit them.

Of course, the most effective way to find out how your team feel is to talk to them and genuinely listen to their grievances or concerns.