Over the last years I had the opportunity to work on projects for really big companies. My initial observations led me to think that the bigger the company the more inefficient its IT operations are. Economies of scale seem to work against Information Technology and software: the bigger the company the more inefficient, bureaucratic and slower it gets.
But it would be too simplistic to say that it's just the "size" of the company what makes it inefficient. It's not. There are big companies that are efficient. True, the bigger the company the harder it gets, but I think it has more to do with the company's age, culture, and the simple fact that they are inadequately structured.
One important problem I've seen in big enterprises is that people are departmentalized by specific roles (Business Analysts, Software Engineering, QA, Operations and Support, etc) and they do not collaborate as they should: they actually fight. They see each other as the enemy. Their jobs are so "silo-ed" that it's hard for them to see the work of others.
A guy in charge of IT Operations for a huge financial firm described it to me with examples:
"We get a request to put an application into production with little idea of what it does or how it behaves. The application might have been in development for over a year, but we (Operations) do not get to see it until it goes to QA... which is roughly a few weeks before going to production."
A big problem: developers do not understand how their solutions are really used in production, and Operations has no input into the development process. A lot of non-functional requirements that are essential for keeping Operation costs down may not be taken into account (like proper logging and monitoring, management of the dependencies).
The Business people blame Operations, which in turn blames the Development team for building unmaintainable software, and the Developers blame it all back to the Business people who never gave them the full requirements in the first place, nor enough time to build it right. But since nobody is responsible for the whole thing, no one fixes it. And every new project is run in the same way.
In small companies (think "start-ups"), individuals wear many hats: from "business analyst" to "operations support". They are all accountable. I bet they are much more efficient. They may produce better solutions, in less time, with shorter release cycles, with less money, leaving happier customers and happier employees.
If I were a chief, I'd try to use a different approach from that of a traditional company.
Instead of having vertical departments in IT (Development, QA, Operations) I would organize IT "horizontally", that is, project-oriented instead of specialty-oriented. The idea would be to divide the big company into smaller more efficient little companies. So, when you identify the need for a new software project you assign a group consisting of business analysts, developers, testers, DBAs and operations people to it. You build a team that is in charge of the whole life-cycle, including operating and keeping the solution up and running. Each team is fully responsible for the solutions they are assigned to, from inception to operations.
This provides other benefits. It's easier to have shorter release
cycles and do more Agile and Iterative Development
I shared this simple idea with the same guy I quoted above. He pointed out that, besides the need for a huge cultural change, it would be difficult to utilize shared hardware environments. One answer to that would be Virtualization technologies, which are becoming increasingly viable and inexpensive (Xen, UML, VMWare, Bochs,...), giving each team a set of "virtual" machines to do their Development/QA/Production, with all the additional advantages of virtualization (saving VM images, on-the-fly migrations, etc).
This is just an idea (and surely not original) and may be hard to put in practice on an already established company. But please let me believe there is be a better way to do things.