Let’s play “Let’s Pretend”! Or, if you want to be more grown-up, let’s follow Einstein’s lead and perform a “thought experiment” using a set of hypothetical situations, following a set of changes through to the end.
Big Insurance Group (BIG) is a horribly non-requisite organization. There are too many layers or too few, depending on where you are. Managers who can lead a group of clerks are assumed to be able to lead a group of programmers or other specialists. Because it is in Insurance, BIG is a grant income company; that is, BIG’s customers give it money to provide a service in time of need, as opposed to making money through selling a good or service.
Let’s say that I was given control of the IT department as a new manager of information systems. How would I create a Requisite Organization?
Postulate 1: Change only happens when the need for it is recognized
In order to create an atmosphere conducive to introducing RO, which is a radical change after all, I will need to show that the current situation is untenable. I can show that RO is great all I want but if everyone is fat and happy in the current situation, the cost of it simply won’t be seen as worth it.
Activity 1: Introduce a more robust form of measurement
Lots of us get the idea that introducing metrics is something that takes a lot of time and that can be sabotaged by subordinates who feel threatened by them. Well, only if you do it wrong. I’m going to introduce some basic metrics to an organization that never measures anything. Or at least, never really measures anything.
First step: introduce on-time metrics for all projects that are based on the original estimates. This is simply what the planners said that it would take, what the project staff then said it would take and what it actually took. This way I can measure whether the planners had a clue and whether the project staff did any better.
Right now, BIG (as far as I can tell) measures on-time deliver of IT projects by whether or not the last project end date was met. Yep, you can change your project date as much as you want. As long as you met that last changed date, you’re golden. No more. If you don’t hit your original target date, the project is late. No exceptions.
I’m not going to go real in-depth on this. I simply want a very basic check on performance to show that they are not meeting what they said they would. This can even be done in a spreadsheet. I would hire someone to do nothing but track this. And I would roll heads of anyone who lied, since lying is one of the few things I can actually fire someone for. It’s insurance: there are rules, thank God.
That should actually work. I know that it seems odd that something so simple and stupid should work, but remember that my goal is not to introduce real metrics, simply to make the current situation as miserable as possible by declaring how bad it really is. I’d also hire an external project auditing firm to audit the projects from initial dates and compare it to industry norms. Sure, those numbers are made up and I know it. I’m not looking for truth here, except for the truth that the current situation isn’t performing, which everyone knows but no one will actually say.
Now I’m going to wait until the situation blows up.