- Forrester Councils
- Councils Overview
- log in
Posted by Marc Cecere on October 29, 2012
I was talking with a client the other day about the reporting structure of her applications organization. The group had a single leader, but underneath, it was subdivided into groups that were a combination of technology (website, data analytics, intranet), business unit (four major ones), and IT processes (QA). The leader of this group knew that every organization is different based on the culture, size, maturity of managers and a dozen other factors. However, she was seeing a lot of friction between groups and wanted to know what structural changes other organizations had made and what the tradeoffs were.
We started by talking about the direction of the organization. In particular, she needed to determine if the business units were moving to greater integration of their data and processes or whether the business silos formed were just fine. Though most organizations are moving to greater integration, this is not an obvious answer, as some companies have run-off business areas that are in maintenance mode and may be kept separate. For this call, she asked that we assume the company needed greater integration. There were other drivers around growth and cost containment that we discussed as well.
One action we agreed to was to form one apps group into a common apps/apps services group. Here she’d combine applications that are common across the organization, as well as methodology oversight and tool acquisition. If application consolidation and rationalization were needed, more applications would gradually migrate into this group. This would leave the bulk of the applications groups, which were organized largely by business units, to focus more on maintenance. There are risks and requirements to make this work. One of the primary requirements was the leader of this group had to have the breadth of expertise to handle both common applications and the application governance functions. Building and maintaining systems is a different skillset requiring different metrics, styles and incentives than direction setting, tool selection and oversight.
This IT shop also had reporting and data groups spread out among separate apps groups. There is a natural synergy between reporting and data functions such as analytics, MDM, and integration, though reporting tends to be more tactical and mechanical. Combining these would be logical, but again subject to the knowledge of the leader. Because reporting was working well and the more strategic data functions were just starting up, we decided the long-term goal was to combine the groups, but short-term to keep them as they were.
Next we looked at the QA function that was in applications. The purpose of this QA group was to define and oversee quality processes and control software change management. The goal of this group, to protect the organization from bad software, is more consistent with that of the infrastructure organization. No app group is encouraged to deploy poor systems, but incentives of application leaders tend to favor creating functionality. When deadlines are tight, testing, configuration control and other IT hygiene steps are sometimes run through quickly. Furthermore, infrastructure has the clout to stop bad software from going into production. For this and other reasons, this kind of QA function is typically within infrastructure or, in rare cases, reports to the CIO. This doesn't mean that quality can be allocated to a single group, but that there is a one group with the responsibility to ensure quality processes are in place and being followed. However, all changes need to be gated by the ability of the organization to absorb the change. At this time the infrastructure organization was going through too many dramatic changes of its’ own to take this one. We settled on making this a phase 2 action.
Reporting structure is never sufficient to ensure IT is run well. Culture, leadership, processes all play a role. Furthermore, as already stated, there are many company-specific variables that CIOs must consider when defining the structure of their organizations. But structure can provide either hurdles to overcome or a path of least resistance, to good behavior.
Save Money On Your Next Software Negotiation
Work with our software negotiation experts to save 10–20% on your next contract »
Lead BT Transformation
Develop customer-obsessed strategies to drive growth »
Forrester's CX Index
Predict how actions to improve CX will affect revenue performance.
Measure the customer experiences that matter most »