5 min read
How to get your IT team to deliver on time
It’s about trust. Why do banks insist on having everything? Because they think if they only insist on some, they’ll never get the rest.
Having it all by asking for less
The other day, I heard the CTO of a large traditional bank say something that nearly brought a tear to my eye.
He was talking about some of the challenges the bank face internally. Spreading his arms wide, he said (to the best of my recollection), “I’m aware that very soon our organisation is going to be asking for all of this from you, and I know it can’t all be done at once.” Bringing his hands closer together, he said, “We’re going to try our very hardest to only ask for this”. I wanted to run up to him and hug him (but thought better of it - HR: “while we appreciate you meant well, it’s still technically assault.”)
I felt he had grasped something that most senior executives either can’t or if they can, are unable to do anything about.
In large organisations, everything is big and most things are slow; the oft-used analogy of trying to manoeuvre an oil tanker is an apt one. Wrapped in decades of calcified process and fear-driven escalation, it takes a lot of effort to get things changed, to get things approved.
So, if you try and do anything, you have to make sure the thing you’re going to do is worth the effort. This is why features are grouped into ‘projects’, and projects get batched up into ‘programmes’. Budget approvals - the MTP (or ‘Medium-Term Planning’) cycle - comes around but once a year, so whatever it is you want to do, you’ll need to work out how much money you’ll need to keep doing it until the next cycle. And if you realise after two months that it was a bad idea and isn’t going to work, well, you’d better look busy for the rest of the year and have a good story ready.
But I digress.
So when you get this budget signed off, you’ve committed to delivering a whole bunch of things. Internally, your stakeholders - the people that are stumping up the cash - know that you won’t deliver on time or on budget, because teams in big banks never can, so they ask for every feature they’ll ever need. Everything. Presumably because they view it as a negotiation, and that anchoring ‘high’ would mean they’d get more.
Many years ago, as a junior software developer, I worked for an IT department in a European bank that was building a wealth management platform. We used a clunky old issue tracking system for bugs and requirements. Each item could be given a priority from one to four: 1 = Critical; 2 = Major; 3 = Minor; 4 = Cosmetic. Simple. Traditional. Our internal customers had many requirements, and they were all priority 1. So then we embarked on a game that is, in software terms, as old as the hills…
Dev Team: “Which of these ten items are really critical?”
Customer: “Everything is critical!”
Dev team: “Yes, but we can’t do all of them. Which can you - literally - not do without?”
Customer: “We must have all of them.”
Dev Team: “Okay, so which should we do first?”
Customer: “In that case, do 1, 4 and 6 first.”
Dev Team: “Great. Can you mark the rest as Priority 2, then?”
Customer: “No, we can’t do that. They’re all critical!”
I could continue, but you get the idea. What happened next rather defied common sense. We had to pay an engineer to come in to add a new priority to the issue tracker (“Priority 0 = ShowStopper”). And then everyone was happy. Happy, that is until we only managed to deliver 1,4 and 6 by the due date. Even as a junior developer I felt like asking, ‘Does anyone not think this is complete nonsense?’
This sort of thing has been going on in most large organisations for as long as IT has existed. Work is planned in big chunks, and it’s impossible to predict delivery dates with any accuracy (and more time spent planning, contrary to popular belief, does not increase the accuracy.).
So there’s a complete lack of trust. We don’t think you’ll deliver to our timescale, so we’ll push you to deliver more, earlier. But you’ll fail, so next time we’ll push harder. And so on, and so on.
An internal conspiracy then usually ensues, which involves everyone agreeing that the project did deliver on time, even though the thing that was delivered doesn’t really work properly, or else is incredibly unstable because they compromised on the foundations. That project with the priority-zeros? Naturally, we didn’t delay. We went live (champagne, etc.), then had a ‘patch release’ three weeks later, to, you know, make it work. With theatre, as they say, the ‘show must go on’…
Money can’t buy everything
So back to the bank CTO, and it genuinely seems like he’s prepared to ‘break the cycle’. If he asks for the bare minimum, we’ll give him that in a few weeks, and maybe we’ll give him more. Then we go again. And every time we deliver what we say we will when we say we will, the trust increases.
What he could have said was, “We need all these things, and we’ll give you more money…”
Money won’t help.
It won’t help the project go faster. The only thing it might help you do is keep going once your go-live date is receding in the distance. The thinking usually goes that if the project has more resources, it can get more done. If you’ve reached the level where you call people ‘resources’ (pro tip: avoid referring to people as ‘resources’), then it’s likely they’re only numbers on spreadsheets, and you’ve forgotten that these resources have different skills, experiences, different lives.
One of the worst situations that can happen to you when you’re on a tight deadline is to be given more headcount. Not only do you have to spend huge amounts of time recruiting (the ‘wrong’ person is worse than no person. Always.), the organisation probably has complex hiring policies meaning you can’t hire the right people in the right places, and then they’ll say, "You’ve got all these people, why can’t you deliver on time?"
So yes, deliver regularly, and deliver in small chunks. Build a culture of delivery, of working software. There are books devoted to this subject, but all the tools and techniques in the world won’t help without trust. It has to start from the top, from the executive, the stakeholder, the customer.