challenging the clowns and clerks
@DG. Great if boards were not as thick as planks. So far, I know of none who had a clue or seemed to want one. What I do see are are clerks in suits (managers is how they style themselves) who like to create not IT kingdoms, but fiefdoms of paper driven procedural droids, creating processes to stop things happening, so they can be involved in "managing" them. Outsourcing amplifies this degeneration of the organisation into mutually hostile camps.
eg; Since IT governance, to use the current term of abuse, consists of adversarial relationships, you have client change control, PMs, designers, spec writers and a sprinkling of managers. On the Finance side, more managers and a PM/co-ordinator or two. Repeat for sales. Finally, the IT team will have the same as the customer/client, plus hopefully, a coder or two. Missing are the actual business users. Standard process strait jackets will be used, including using off the shelf stuff which fits the PHB decreed product lists, whether or not they work. Success is judged by how well the paper is pushed, processes comply with the process droids wet dreams and ensuring no-one can be blamed.
No wonder goal posts become sprinters, IT staff become paper pushers and whatever gets delivered is, at best, a disappointment. The mess is controlled badly by invoking some set of guidelines (ITIL, say) which is implemented as a set of draconian rulez to keep the suited clerks sense of power fueled. The process is well described in "Skunk Works" by Ben Rich describing the horde of process droids hindering the development of the stealth fighter.
In the bad old days (TM) the business owner would approach the IT department, describe their issues, discuss it with them, often with involvement of knowledgeable users and decide on possible solutions. IT would get costings. Client dept would do their budget or apply for funding and get it. Once funding approved the project would be built and running, with fixes and upgrades as required in test and acceptance phases. Old system would be switched off when client happy, which happened quickly because they owned the system and helped design it. The IT manager would not co-operate in allowing a proliferation of OS and applications, unless customer had a very good reason. Problems were solved by people talking to who-ever was responsible and discussing how to fix problem, not how to develop a process to fix problem.
AC because this is situation too familiar in 3 TLA firms I worked for.