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.

“Evolution”

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.