I just read an article about breaking down the silos in IT. This piece focused on the application development process and the fact that each group does its thing and then tosses the application over the wall to the next group, from developers to QA engineers to performance test engineers. The problem comes in if all this testing is performed on a “utopian network” on the LAN, so nobody sees how it will perform on a WAN. So when users experience problems due to latency or packet loss, they blame the networking guys.
This is classic siloed, need I say territorial, behavior. The irony is, everyone in IT bemoans the fact that so much of the enterprise functions in stovepipes that it’s a huge effort to lead projects that should be joint efforts across departments or functions. Departmental interests, power struggles and personalities get in the way of effective enterprise IT projects so they don’t get off the ground or the end result fails to meet expectations or isn’t strategic after all. In fact, IT could figure out how to break down silos by starting at home.
It’s really not that hard. The next time you have a brainstorming session or launch a project, seek out representatives from across IT. Get their input throughout the process. Figure out what new processes you may need to create to consider their (and in the end, everyone’s) interests so that your outcome is solid and thoroughly represents the best you can do. If it’s an application you’re building, your project committee will include people from the user community; add an IT subcommittee with people from every part of IT that the application will eventually touch.
Inclusion is a management philosophy, and it gets conflict out on the table early on. Better to hash out your differences before spending the company’s money and then needing to spend more to patch something later on. Any eye-rolling or “but…”s around the room will turn into greater pride and less maintenance at the end.