Why do tactical projects live forever and strategic projects die young?


  • They start with a well understood business problem. We need a system that allows us to enter market X or that can allocate via fix/swift or we need a way to see all our clients positions across many disparate systems.
  • Sense of urgency
  • They use existing infrastructure or buy something out of the box.
  • Because it’s tactical, you don’t spend a year building a future proof architecture or gathering requirements. These things are done on a JBGE (Just barely good enough) basis
  • They fly under the radar

All of the above means that the system is up and running very quickly and the feedback cycle is short.

So this solution, let’s call it, Back Office Reporting aGregator, or BORG for short is now in production and is used for equity client reporting.

What happens next is how BORG grows. Manager A is talking to Manager B about wanting to do a transaction store. Manager A says you should “check-out” BORG, it’s tactical, but it has aggregated client positions. All you have to do is extent the feed to include transactions and voila you have a transaction store. It’s tactical, but you can use it until that strategic solution is complete.

BORG now has aggregated client positions and allocations.

Next an operations manager says if we can get fails data and so on and so forth…

Before you know it BORG is being fed by every major system in the bank all while waiting to be replaced by the strategic system, which gets attempted many times but never ever succeeds.

Strategic Programs

Now, let’s look at projects that fail. You can usually spot some of these doomed programs through the name alone. They usually begin with:  Cross asset class, Global or Strategic

Let’s make up a fictional project to highlight what usually happens. We’ll call this project EnterPrIse Cross Functional Asset Integration Layer (EPICFAIL).


EPICFAIL has many of the characteristics of large programs in investment banks that get started and stopped every day.

  • A weighty deck prepared by a reputable consultancy. Usually bound in one of those thick white binders
  • Lots of senior oversight and governance
  • Long requirements gathering process with lots and lots of sign-off in blood which of course leads to even longer sign-off processes because people know they only get one chance
  • Strong change control process
  • Big expectations and promises
  • Distributed and silod teams with some matrix management thrown in for good measure
  • Politics between technology and change management
  • Architecture oversight
  • Really good project manager/program manager to hold it all together
  • A three year deadline

“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. ”

— Gall’s Law

Leave a Comment

Your email address will not be published. Required fields are marked *