Doing more with less

I’ve just had an interesting chat with Adrian Foxall, CEO of Rimo3 (a new company, which gives its customers the tools needed to understand their full application estate, helping them make informed decisions for managing it).

Some of his war stories seem awfully (and I stress “awful”) familiar. Big bank wants to migrate x thousand employees from one OS to another. So the person responsible comes up with a plan, with costings etc and the bank says “go ahead”.

OK, then an edict comes down “reduce cost by 10%” And again, “another 10% cut please”. So. our hero asks whether s/he can migrate fewer people or take longer? “No”. Oh well, can s/he do less testing, do a cheap and dirty migration? “No, of course not”. Can s/he get in more skills from outside or spend money on training people to work better? “Don’t make us laugh!”

So, migration proceeds and the only thing that has changed is the cost target. It succeeds and costs what was originally estimated – no surprise there (in fact, all praise to the project manager, I’d think). Our hero is then hauled over the coals for not meeting her/his cost reduction targets. But how was that unexpected? S/he was given no degrees of freedom, just a constraint to accommodate. If you want something cheaper, quality suffers, or it takes longer, or you reduce scope. Or, you “invest to save” in process improvement initiatives. In the world of Harry Potter, there may be more options, but not here. Hopefully, our hero will learn to stick an extra 20% on her/his estimates next time, so s/he can harvest the brownie points from meeting the cost reduction targets – and, no, that is NOT a Bloor recommendation.

The point is that something like Rimo3’s technology may well “speed up migration projects, reduce licensing costs and enable efficient, long-term application portfolio management”, but there’s a partnership and both sides have to be engaged for it to work. A company like Rimo3 should probably link what it is paid to the success of what it is doing, so that it shares the project risk – but its customer must have the maturity to identify its “success metrics”; to be prepared to “spend to save”, to avoid “blame cultures”, and to make fact-based decisions. It’s a governance thing really – unless both sides understand and are in transparent control of what they are doing, it ain’t going to work.

So, someone in an immature company asks, what do we do then? We can’t just give up. Well, I can think of very successful immature companies, which get things done fast and cost-effectively – in the short term. Think of Microsoft and the compromises that let it take over the world with Windows NT – and the consequent cost of fixing these compromises, including Patch Tuesday, that continue today; were they worth it? Possibly – but is Microsoft’s future now like Nokia’s or like Samsung’s? So, in an immature company, you can just do your best – and try to have fun doing it.

In an immature culture, you will have to play politics, “game” your estimates, rely on “heroes” who may burn out or leave, play “blame games”, get lucky. Best of all, you’d better plan in advance to move on before things go wrong – low maturity can be successful but it brings lots of risks, some of them hidden…. Basically, you will have a stressful life, possibly a fun life (if you like that sort of thing) and you still might not succeed.