My team and I are busy rolling out a new innovation internally here at the bank, one which I’ll no doubt be in a position to talk about in a few months. Its quite a transformational thing, and one that most people are excited about.
Yesterday, though, news of our impending internal start-up began to diffuse through our IT organisation, and I got an email from one of our accessibility experts wanting to know if we’d done the mandatory testing that is required of any new system before live.
I’d not been aware of the mandatory requirement, but I wasn’t averse to having the testing done. So I explored a bit more and discovered that we have a testing team dedicated entirely to this process. I could engage them if I supplied an appropriate charge back code.
Naturally, I’d not budgeted for any such requirement, and as the system is being acquired from a vendor and is in any case hosted, I doubt there is much we’ll be able to do if testing finds a problem.
But we will find a compromise that makes sure we address the issue, somehow.
However this situation brings something to the fore for anyone who needs to do a small project in an organisation that is optimised to do very, very big ones.
The big project model requires lots of systems and processes. There are so many moving parts, you have to have something that imposes order if you want to get anything done.
But the small project is one that can’t afford much process and still have money left over to deliver functionality. Big project models usually condemn small projects to failure.
Is there actually a reasonable answer to the problem though? Clearly, if you have a light process model for small projects, the temptation is always to push the edge of what “small” means, just because it is easier to get things done. Sooner or later, if you’re not careful, big projects will be using the small methodology.
Is that a bad thing? Possibly not, but it does mean, inevitably, that all those not-so-small projects will start to get more process heaped on them, burying the truly small projects again.
It is an endless flip-flop between not enough control and too much.
But one thing is certain: process and controls are about controlling change, about slowing down responses so that things become predictable. They are never about moving fast.
That means, as an innovator, a key skill is knowing when to bend, and when to break the rules. And having the wisdom to do it in such a way that it doesn’t raise the hackles of everyone around you.