15 DecThe Bankers’ Plumber on Budgets: Is there anything leftover? Should we revolt?

Christmas is coming and the goose is getting sized up. In Financial Institutions the world over, the planning for the 2017 budget is in full swing. For the last post of the year, a few thoughts on the perennial battle to do more than just mandatory projects.

Budget planning is always based on the same two course menu: mandatory projects and discretionary project. The challenge is always the same; how much of the budget will the mandatory projects consume and will there be anything more than a few crumbs left over for any discretionary projects? The outcome is always pretty much the same too; there is scarcely enough to do the must do things and virtually nothing for the discretionary projects.

So long is the list of demands in the “mandatory” category, that planning for them takes on the familiar approach to writing term papers at university; even though you know what you have to do well in advance, you put things off and then end up pulling an all-nighter to just about get something done in time, perhaps even speculating on deadlines being moved. “Something” in this case means a rush job, with one or other workaround and a dollop of manual work.

Whilst the Change Management team is busy jamming in these under-cooked regulatory deliverables, the Run-the-Bank team are going hungry. It is not a case of “If they have no bread, let them eat cake”. Rather, there is no budget to do anything to fix the inevitable list of defects and small changes both great & small. The consequences are not so immediately obvious.

Running production will become a bigger challenge; your organisation will just about crank out the reports and filings in line with the scheduled. Just. Quality is probably iffy. More defects and change needs will still be discovered and documented, though perhaps not so well. With a growing backlog, a huge amount of time gets spent debating prioritisation. Most of that is philosophical; fixing anything would be better than debating. Often, many defects and change requests are poorly documented, simply because only a half-hearts attempt was done to capture the detail at source. If you know the waiting list is long and your need is not going to be seen to, why bother. Defect fixing or making small changes slows down. People are unhappy and overworked. They quit or they have health issues.

Then there is no capacity to accommodate all those “must do” regulatory projects. You try to master both things; run-the-bank suffers and input to new things is half-baked, resulting in more last minute work that is not entirely thought through. Run-the-bank or production becomes harder still; new stuff that doesn’t work so well and old stuff that is creaking at the seams.

Frogs and boiling water come to mind. There must be a better way.

Lessons Learned: The first step is to understand that “the backlog is the enemy”. As long as it is long and mismanaged, it is going to distract from actually making changes and prevent change, so that people give up hope or, in some cases, do manual workarounds, such as creating yet another spreadsheet.

The next step is willingness to get the investment budget. You have to want to help, you have to want to fight the battles. Then you need to go about working out what you need and how to do it.

Identify Normal: For your business, you need to determine what a normal level of maintenance effort is for your system landscape each year. This is not the effort to do totally new things, just the effort to keep the car on the road. Software companies typically charge 20% of the original license fee as an annual maintenance fee. For a reason; you would shout at the provider of your SWIFT messaging platform if SWIFT changed the format of a message and your platform was not updated. There may well be a very hard battle to fight on the budget front to get that 20%. You have to fight; your people are worth it.

Identify the clean-up need: If you know what your normal capacity for maintenance is, you can then assess your backlog. Then you need to decide how much of a backlog you can live with. If you have a backlog that would need 10 man years of effort and 2 FTE for maintenance, then your backlog would take 5 years to clear. I would suggest that a 6 month horizon is the target. Your people should expect it to take no longer than 6 months to get to the front of the queue.

Clean-up: You now need to dig yourself out of the hole that is your backlog. This needs a SWAT-team type approach. Pick an area for focus, document all the pain points: the sum of all documented defects, change requests and needs which you have not documented, including putting all those self-help spreadsheet things on a proper platform.

Prioritisation: Ignore your prior prioritisation approach. Look through your list and identify groups of related things you can address. Getting some items quickly addressed will also educate the future prioritistion and fix process. Then, any further prioritisation must consider logical groupings of change, the value to the users, and the cost to make the change all together, to ensure that the items addressed deliver the greatest value. Then, if an item never reaches to the top of the backlog over a 6 month period due to new priorities being added, then you must question if the item really deserves to be on the backlog at all.

Lean and Agile practices are a vital ingredient at this stage:

The SWAT team needs the opportunity to be in the same place with big blocks of time carved out to work as a team. Ideally, the IT developers who will work on the solution will be part of that team and hence those gatherings to work together.

Focus and proximity are powerful ingredients; get people in a room with a whiteboard and the path from analysis to solution design is fast. Use another board to do a Kanban-like tracking of change, so the team can see the progress of items from the backlog, to analysis on to design then development and release.

Break large backlog items down into bite sized chunks. Anything that can be done on its own should be a separate task, ensuring that no task is so large that progress with it can’t be observed on one or two-day basis.

Manage that board real-time as tasks are started and completed, with daily stand-ups; in person meetings, where everybody is validating the Kanban board, or perhaps its online equivalent. A stand-up meeting with the whole team improves focus and forces team members to either make progress or ask for help.

I am indebted to the very able Julian Holmes from ThoughtWorks, for his insights and help in shaping this post.

Previous Posts 

Are available on the 3C Advisory website, click here.


The Bankers’ Plumber’s Handbook

How to do Operations in an Investment Bank, or not! Includes many of the Blog Posts, with the benefit of context and detailed explanations of the issues. True stories about where things go wrong in the world of banking. Available in hard copy only.


Cash & Liquidity Management

An up to date view of the latest issues and how BCBS guidance that comes into force from Jan 1 2015 will affect this area of banking. Kindle and hard copy.


Hard Copy via Create Space: Click here

Amazon UK: Click here

Amazon US: Click Here