The Ghost in the Machine

'Meet the new boss, same as the old boss.' - The Who.

What is the Ghost in the Machine?

It's usually quite invisible and originated well before the company created a system. Created is an interesting word. It sounds like a group of people spent 6 months in a workshop building a system. They did not. The system was built by accretion going back at least 50 years.

Some of the most important applications that support the Capital Markets are probably 30 years old.

There is a difference between an application and a system. Simply put, you can say the application is the software, usually some substantial app. The system is everything: users, applications, processes.

The machine, as I am using it here, is the system's natural operating state. It's how it wants to run the system.

How the Ghost Gets Out of One System

Here is the thing nobody tells you about buying a new system.

When the consultants arrive, they sit down with the users and ask them what they do. It's a reasonable question. The users tell them. They share every step, every process, and every data flow. They document everything they have always done, exactly the way they have always done it.

Now, here is what is interesting. The users think they are describing their work. They are not. They are describing what the old system makes them do. There is one huge problem in this process. No one takes a step back and says, 'Wait, what is the business problem we are trying to solve?' Asking the question would be a start; spending enough time to answer it would be pivotal. Epic.

The consultants write it all down. And that simple act of writing it down, nodding, asking follow-up questions does something nobody intended. It tells the operations team they are right. That this is how the job works. That their process is the process. It feels like all the work they do is validated and that it will get better.

What the process, we can be generous, does is extract the ghost from the old system.

Nobody is careless. Nobody is dishonest. The process is expected. That is what makes it so effective.

Now. What if instead of sending consultants, you sat the operations team down with the people who designed the new system or any system? Perhaps business consultants who were familiar with the domain and experienced enough to see older processes.

Not selling them anything. Not to demo any systems but rather to ask what you are trying to achieve? What is the business problem you are trying to solve? This will be revelatory.

However, unless that question is asked frequently and earnestly, the user's expectation of what they should expect from this change is what they do now and the things they can think of are a little better. Their RFP process -- the demos, the shortlist, the sign-off -- all of it cements those expectations.

Everyone in the room, consciously or not, is now expecting that the new system will not change very much. That expectation will prove correct.

What functions or functionality are needed in the Cap. Markets that have not been built? Go look at Bob's Guide. I have seen very few financial organizations build good software, and many that build rather poor infrastructure. More on Agile, more on that in another document. Leave the software to the vendors unless you're building a competitive advantage. I will write about this.

Amongst all that smoke and chaos, the Ghost from the Old Machine escapes in documents and examples.

What the Technical Team Did

The technical team is not villains either. They did exactly what they were asked.

Since around 2003, developers have tried to use agile. In many implementations, they reacted to user needs, but without context or domain knowledge, with high turnover and no time to refactor or test.

Which means every interface, every workaround, every slightly odd requirement gets built in, perhaps not quickly, or cleanly, but very permanently. No one asks, 'What business problem are we trying to solve is.'

The old systems do not get switched off. After all, they still work, and something downstream still touches them. Nobody is certain what. But the risk of finding out is higher than the cost of leaving them running. So, the new system connects to the old system, which connects to the system before that. Layer on layer. Not because anyone planned it. Because nobody stopped it.

That is another part of the Ghost. The technical one, and it isn't documented. It never is.

Putting the Ghost in its New Home

Capital markets technology has a number. It is about one hundred percent. The average implementation runs more than double the original estimate. Not because vendors are dishonest. Not because project managers are incompetent.

But user satisfaction is different. What gets signed off on day one is a functional definition. It is usually some distillation of the RFP. Remember that is what the users do, and a little bit extra. However, a functional definition is not the project, certainly not this project. Perhaps it is the beginning of understanding what the project is.

It is unlikely that any responsible PM would schedule a project they do not understand. But that is precisely what happens. The RFP closes. The vendor is selected. The contract has been signed. The go-live date is on the calendar. All the important parts of the project are defined in a guess, or politics, or finance. They have no basis in reality, and hence we have +100% spend.

Why does the project run over so much? It's bad estimation.

Why does the functionality fall so far short? The only thing the project staff had as any kind of functional requirement was the Ghost.

Let's talk about the period between 'We want a new system' and 'We are ready to schedule a project'. Not requirements gathering. Not demos. Not a shortlist. A genuine attempt to understand the problem well enough to know whether a solution is even specifiable yet.

Most implementations skip this entirely. The schedule is the pressure that prevents it. And the schedule was set before anyone knew enough to set it.

That is where the money goes.

The Ghost needs to go back to the cupboard. For good.