Monthly Archives: June 2011

Business Analysis is a risk management tool.

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”.

Ignorance and Humility

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.

Scope – “Now” or “Later”

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.

The three categories of risk on an IT Project.

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.

Managing your team’s liquidity

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.

Listening to your team.

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.

Liquidity Risk and your Team

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.

What is the worst risk?

This is a question I ask people when I’m doing financial training.

The answer is “The one you do not know about“.

In finance we prepare a P&L Explanation. The P&L explanation attributes all P&L to an identified risk or change to a trade. Any unexplained P&L could indicate a risk that is not known. Unexplained risk is then investigated by the Risk Management team.

The same is true of IT projects. The worst risk is the one you do not know about. It is the risk you are not hedging or even managing.

If there is an aspect of your project that you do not understand, and that no one is monitoring from a risk perspective, you may have the worst kind of risk on your project.

The first step in IT Risk Management is identifying a risk.

Real Liquidity – Early days

“What is Liquidity?”

I define liquidity as the time it takes from an investor making an investment commitment to the time that investment is realised.

In finance, liquidity is often expressed in the difference between the bid and offer price that a broker will pay you for an asset. The broker buys the asset and then looks to sell the position before the market moves against them. If the daily market size (normal market size in exchange parlance) is say ten ( 10 ) units and a client wants to sell fifty ( 50 ) units, it means that the broker would take five ( 5 ) days to unload the position in a normal market. As the market could move significantly in five days, the broker will bid a lower price for a larger order. Similar arguments for selling large quantities result in the asset being offered at a higher price in larger volumes. Although liquidity is expressed in terms of the bid/offer spread, it is really an expression of the time it takes to realise an investment commitment.

Liquidity was the first financial concept that I translated into management.

Traditional arguments about how to organise an IT department of a business tend to polarise to two extremes.

  1. IT staff work on a system for a business unit.
  2. The IT department is set up as an “internal consultancy” where staff are assigned to projects from the developer pool.

In the former, all staff are locked into a single project. In the latter, no staff are locked in. The latter option is scary for a business that needs developers with experience of their domain to be effective. The former is the norm.

In finance, an asset is liquid if enough of it is being bought and sold each day to satisfy demand. In finance it would be ludicrous to expect all of an asset to change hands each day. In reality an asset is considered liquid if a small percentage of it is available to be bought or sold each day. This was the concept I applied. To create liquidity, make sure a small proportion of the staff is available each day.

At the time I was head of the Global Business Analysis Team (GBAT) in an Investment Bank with approximately 1500 developers. Most of the BAs worked on a single system. The project managers on the systems were reluctant to free up a BA even though they were often not 100% utilised. The reason was simple. The BAs were needed at the start of a project. If the system did not have one, it could take several months to hire one by which time the development had normally started. We promised the project managers that GBAT would provide them with a BA on the day they requested them.

Their next question was always

“How do you that?”

This was achieved through the way we did allocation of BAs to projects. We assessed all the BAs according to two dimensions… Technical Ability and Business Knowledge. We also assessed each BA assignment according to the same criteria. We then allocated the BA with skills that were just under what was needed.

By allocating our least skilled BA to the role, it meant the most experienced BAs were the last people allocated to the project. Our aim was that the experienced BAs massively under allocated to projects. The under allocated experienced BAs could…

  • Pair with someone just allocated a project they were not fully skilled to do. On the job training.
  • Be instantly available to take on any new urgent projects.
  • Network with project managers to find out which projects were coming up so that they could do research on the project.

As a result, some of the the project managers released their BAs into GBAT.

We managed the team to ensure that we had the maximum number of options available at any time.


After a while, the team changed the way we did project allocation. We moved from one on one discussions about who would do a project to a mechanism whereby all requests for work would be e:mailed to the whole team. All team members interested in a project would say and then someone would be assigned responsibility for the project. All team members had the option to pair on the analysis part of the project. We had worked out that the thinking part of the analysis where the real learning about a domain takes place accounts for only an hour a day at most. The rest of the day was spent interviewing business users, supporting the development team, testing and many other things. As such, everyone was encouraged to pair on the analysis. My role as team leader was to ensure that all requests had someone who took responsibility for them.

“End Game”

The team of ten was involved in most of the strategic development over a two year period.

At the end of the period, we suggested the same approach could be taken to manage the developers. The team was disbanded shortly after and the BAs were assigned to a specific project.

Agile and Risk

The reason I use Agile techniques on IT projects is because they allow me to better manage the risk on the project.

Initially I became interested in Agile because it was an interesting new way to do software development. My opinion of Agile was changed by Kevin Tate’s presentation at the first Agile Development Conference in Salt Lake City. Kevin drew a graph of the risk profile of an Agile project and a traditional project from the business investor’s perspective.

A traditional project would move through the stages of analysis, design, development, testing and finally it would be released into production. The project manager would keep interested parties informed of status. It would be 80% complete in analysis, or 20% through testing. The reality is that the only time you can know the exact status of the project is when the software is being used in production. As such, the risk on the project increases for the investor until they get a production release that they can use. An Agile project delivers increments into production on a more regular basis. As such, an Agile project is less risky to the investor than a traditional project.

An Agile project allows the business investor to see the exact status of a project. Analysis being 80% complete is meaningless as the analysis could miss key functions that the business need.

Simply by delivering to production more frequently, you are reducing risk to the business investor.