Welcome! GovernYourData.com is an open peer-to-peer community of data governance practitioners, evangelists, thought leaders, bloggers, analysts and vendors.
The goal of this community is to share best practices, methodologies, frameworks, education, and other tools to help data governance leaders succeed in their efforts.
I just posted a blog article that contains some fascinating insights drawn from a recent Cost of IT study. In a nutshell, the insight from the study is that as organizations with large IT departments get even larger, the cost of IT as a percent of revenue INCREASES. In other words, diseconomies of scale. The blog article summarizes the analysis from the Forrester 2013 IT Budget Planning Guide For CIOs report and makes an argument for the root cause and how to address it.
The results are counterintuitive, and the root cause highlights a dirty little secret in IT. I won’t spoil the surprise, you’ll have to read the blog to find out. I would appreciate some feedback from this group.
John - thank you for your observations. I can attest by bigger is not always better from my experiences. All else being equal (methods, tools) do you think smaller teams or groups in some cases may drive down the costs? IMO the smaller teams streamline communication. I have been in specialized IT teams within a larger super major, for development, delivery, and maintenance of very specific systems for relatively small operating companies (1,000 people) and this model seems to work more efficient. My own observations are just that, micro-level, not at a macro-level such as the report you used in your analysis.
I would agree that smaller teams are better - at least for smaller efforts or larger projects that can be broken down into smaller bite-sized pieces. In the 1980's we called them "high performance teams".
One problem that often emerges in large scale IT shops is one of specialization, Separate teams are established to focus on very specific parts of the IT infrastructure. The problem is that when you have a project that touches a lot of different parts (like a typical integration project) then you end up with lots of people that need to be involved. The solution to this challenge IMO is an architectural approach that emphasizes infrastructure simplicity, standardization, and automation.