As we continue the process of breaking IT into groups and roles that will support our purpose, today I would like to share a few thoughts on what we’ve learned thus far.
First off, this process takes a lot of time. When we started this journey we felt this would be a fairly quick and easy exercise, however we soon discovered that defining domains (and even more so accountabilities) for each group and role takes much more time that we had originally thought. When we were estimating the effort, we simply thought about breaking groups by those services that IT provides, assuming that defining domains and accountabilities would be an easy task, but we were mistaken. In order to prevent you from falling into the same trap, when estimating the effort required to define the various groups and roles, multiply your time assessment by 10.
Though this exercise is taking more time that we thought, it has brought us a lot of unanticipated benefits in a short time frame. First, this exercise is helping create a strong leadership group. Working for so many hours on restructuring a classic IT department has pushed our IT leadership to reassess how their current teams are operating, as well as the challenges that they all experience. Working together and learning how all IT is tied together has created a strong bond within the IT leadership; so much so that it is stronger than any other IT team that I’ve worked with. I attribute this to their hearing and understanding all the different challenges within the various IT domains, not just the ones that they normally work within. Further, based on this understanding we have defined groups and roles that should better support our IT purpose.
Defining roles, domains and accountabilities has also helped us determine functionalities that in today’s IT world everyone expects other IT domains to perform, but no one is actually accountable for them. We have found a few scenarios where the same accountabilities are shared between different existing associates, which has resulted in some unnecessary tensions in the past. Finally, from my point of view at least, one of the greatest findings has been those roles that are needed to be involved but that are missing from within a particular domain. For example, we found that we were missing a role that represented customer support on new projects. When customer support is involved in the creation of new IT assets they know about the new assets, they are aware of all of the decision making when the new assets are created and they know who did what. This valuable knowledge helps us as an IT organization to resolve production issues with our systems much faster. Regretfully no one today from our customer support domain is involved in creation of new IT projects.
To validate our work, every time we have a flaw or a challenge, we are trying to determine if the new IT operating system (aka structure) that we have already put in place will prevent the flaw or reduce the challenge. This has not only helped us validate our work, but it is also creating a positive atmosphere knowing that we already have solutions for today’s challenges.