Much of the mistrust that occurs between the business and IT sides of an organization is founded on misunderstanding and questions about resources. Consequently, building a successful IT organization requires a culture of transparency. Transparency is a trendy word for two concepts that every IT professional has heard over and over: measurement and communication. Do you measure project status? Who can see it? Can anyone in the organization go to a page on your intranet and find out whether or not that new payroll project is on time and on budget? Poor IT organizations hide their failings while good ones are only too happy to trumpet their success. In between is an uncomfortable no-man's land where you know you have problems, want to get better, and realize that the only way to do it is to air your dirty laundry in public, so to speak.
A good first step is to begin measuring the things that matter to your organization and share those with a smaller audience at first, say IT managers and the CEO. Then as the organization becomes comfortable with the measurements and has started to react to them (and they will react), widen the audience little by little. A recent issue of CIO Magazine had an article on transparency that included three case studies on tools you can use to increase the transparency in your IT shop.
The first case study is about how the IT department at Hines, a Houston-based real estate company, uses SLAs. SLAs play into a transparency strategy by defining what to measure, what the targets are, and communicating those goals to service users. One key to internal SLAs is ensuring that they're realistic. Sometimes IT departments are pressured into SLAs they can't meet with current resources. Sometimes they even volunteer for them in an effort to please. One tactic I've seen work is to start out for a period of time measuring actual service levels and then base goals on realistic increments from current levels rather than some idealistic end state.
The second case study shows how Southern Company uses internal economies to force accountability onto the business units that the IT department serves. I'm a big believer in this concept, but it's easy to screw up. Utah, for example, uses the concept, which it calls an "internal service fund," to fund some central IT operations, but the prices were artificially set based on expected legislative actions rather than being based on true costs. People didn't want the price to go up without a legislative appropriation to cover it and they most certainly didn't want it to go down if that meant their budgets would shrink. To work, the markets have to be realistic. Thomas Malone of MIT has written about internal markets. Dean Meyer, in his book entitled Decentralization, gives very concrete advise for IT departments in this area.
The third case study is on balanced score cards. In this case study, BNSF Railway uses balanced scorecards to communicate IT operations data to business managers, giving the CEO and others insight into why, for example, demand for computing resources was increasing even though business was flat. Balanced scorecards have been popular for measuring how businesses are doing in meeting their strategic and operational objectives, but they've probably been underutilized by IT departments as a communications tool. I know I've not had much experience with them.
One transparency tool that wasn't mentioned in the article or the case studies is blogging. I believe that narrating your work can have real value in communication within the IT department and between the IT department and the business. There are some places you can misstep, to be sure. One of the biggest problems is employees who see honest communication as a threat to their "image." The "never let them see you sweat" attitude. Two years ago, I moderated a panel on using blogs in the IT organization. The points we covered are still relevant. Of particular interest are the issues surrounding creating a culture that supports open honest communication.