Degradation of independence

Technology is a catalyst for business change, but that change doesn't always sit well with departments that have their own sovereignty to look after. David Braue asks whether IT can be centralised and distributed at the same time.

It may have sounded like a relatively straightforward project, but the creation of an intranet portal for Victoria's newly created Department for Victorian Communities (DVC) -- which bundled 15 core government functions into a single new department with 560 staff and an $848 million budget -- turned out to be a period of significant introspection.

As often the case, the challenge lay not in rolling out the technology but in understanding the business -- or the businesses. Many IT executives may have gone through the pain of consolidating after a merger or acquisition, but that's nothing compared to the challenge facing DVC which had to consolidate infrastructure and provide a unified interface capable of addressing the needs of eight government ministers, six separate departments and hundreds of public servants used to doing things their way.

Structural differences between the departments soon became apparent as the intranet team took stock of the departments' existing intranet efforts and began the process of user consultation and system design. Against a backdrop of technical upgrades, including the consolidation of human resources and finance systems and networks, the intranet was the most visible face of the DVC's progress in functionally integrating the various departments.

Meigan Geileskey, project development manager for employment programs and head of the intranet development project, quickly learned that a historical lack of introspection had left the departments to solve the same problems in many ways, yet often those departments were hard pressed to explain what they were doing.

"This made it a situation of 'where do we start?'" she recalls. "We had no policies, no one really understood what [DVC] was and what it meant, who were their colleagues, and what they do. It was interesting that one term means something completely different in a different department. We used the merger as an opportunity to learn from other Victorian Government intranets."

Even minor semantic inconsistencies became examples of why it was important to clarify each department's role in the new organisation. For example, one department's Web site had a section entitled "Our Knowledge" that was no longer relevant when "our" referred to not one but six different agencies. Such details may seem insignificant, but they reflect the difficulties of reconciling six different worldviews into a single unified front.

The project wasn't about changing the departments' internal perspective on the world, but it did require them to explain it in a way that let the intranet become a single voice for all. This required the organisations to hand over some measure of their IT independence to DVC -- a concession that can be difficult to extract in heavily politicised environments, particularly in the midst of such a massive organisational change as that introduced with the formation of DVC.

Extensive user consultation, intranet review, and departmental navel-gazing helped Geileskey's project team not only develop a consistent interface across all member departments, but to do it so the intranet was named one of the world's 2004 10 best government intranets by usability consultancy Nielsen Norman Group.

Pushing towards the core
What Geileskey's team learned is that differences between departments run right to the core of their operations. This is immediately obvious in heavily bureaucratised operations such as government departments, and may be either overtly or covertly a factor in private organisations where myriad business lines each have their own intrinsic operational cultures.

Even where similar functions may be carried out and procedural similarities seemingly obvious, subtle differences can turn even a seemingly straightforward project into a significant and time-consuming effort.

The challenge complicates the situation for IT executives, who must navigate the usual political intrigues and territorial battles to develop and implement IT plans that address many departments' needs in a way that makes them all happy. These days, most such plans reflect the need to consolidate IT infrastructure around a central hub, with spokes stretching across the rest of the organisation. This is a major change from the situation a decade ago, where the ability to centralise IT was limited by inter-site bandwidth and servers that crawled by today's standards.

The obvious solution was to distribute computing power, with departments often given responsibility for their own IT destinies -- and servers, networking equipment, and applications policies. Departmental IT managers were a dime a dozen and each had their own taskmasters and their own perspective on how things should operate.

The technological barriers have disappeared: clusters of high-powered servers and storage area networks (SANs) handle heavy workloads for a variety of applications and departments, reducing the company's total cost of ownership (TCO) by allowing a smaller number of staff to manage a larger number of machines.

Both because it is effective and because it is actually possible today, such consolidation is now accepted as best practice in all kinds of industries. Universities, health authorities, and other large enterprises are already well along the path to consolidation, and the technology to make it happen is slowly trickling down to small businesses -- which, Gartner recently announced, spend up to 60 percent of their IT budgets on infrastructure such as data centres, voice and data networks, desktop management, and help desks.

Just because consolidation is possible doesn't mean it is easy, however. In many ways this is the result of the years in which departments were empowered to make their own decisions about IT; now that the pendulum of IT thinking is swinging back towards the centralised model, it can be difficult to wrench control away from those departments once again.

In larger organisations, departmental dynamics can also become a factor, potentially frustrating efforts by IT executives to roll out a consistent, lower-cost infrastructure across the various departments. Such a project invariably requires some measure of concession from business line owners -- but the situation gets complicated if a specific department refuses to buy into the IT vision and decides to maintain its own IT infrastructure.

Going it alone
The threat of splinter factions in the management of IT may not be a real one in many organisations; IT has become entwined enough with business that many line managers now accept that IT is not a core competency and are more than happy to offload it.

However, conflicting departmental IT strategies are still a reality in many environments -- particularly in companies that have recently been through a merger or acquisition, or in organisations where a highly compartmentalised, divergent business structure with many regional operations makes it difficult to centralise IT planning. Although organisations like Sydney University and Deakin University have been working hard to empower centralised IT departments, the sheer scale of the operation means that functional silos persist.

With thousands of applications in use within the typical organisation, IT organisations are already running flat out trying to build bridges between IT systems and a morass of competing business policies. So it is a small surprise individual departments feel disenfranchised during IT implementations as their business processes are shoehorned into a one-size-fits-all model.

One seemingly innocuous, but highly risky example of this practice lies in the proliferation of wireless LAN access points across departments in recent years. Often installed without a second thought as to their implications, such access points create an instant security hole for organisations whose employees should rightfully know better. In such cases, departmental IT initiatives may well be the result of simple oversight -- but even small acts of rebellion can have serious consequences on enterprise risk models and governance procedures.

IT executives may be able to win over recalcitrant departments through the force of executive mandate, but it's important that those executives not ignore more subtle expressions of frustration that may indicate that the IT department isn't catering for a specific department's unique requirements. This last point remains a major problem for IT executives who, Gartner subsidiary people3 recently warned, are chronically overestimating many businesses' appetite for -- and ability to cope with -- change. According to that firm, 75 percent of executives planning organisational change have failed to consider their organisation's ability and willingness to adapt.

Such a philosophical disconnect can stymie attempts to drive a unified IT infrastructure across the business, since it can fuel an overall loss of confidence in the IT organisation and a feeling that IT is better handled at the departmental level. Gartner recommends IT executives work hard to gauge users' support for organisational change, and to develop self-reflexive measurement systems that can judge the success of initiatives in relevant ways.

Finding a compromise
Trying to run IT at the departmental level may be seen by some as the only way to get timely access to new resources that may not fall into the company's overall IT strategy. It may also be seen as an important step in preserving established best-practice processes through a period of tumultuous change. Whatever the reason, it is a risky move since it requires the department have its own support technicians and its own IT budget. While this may seem acceptable to divisional managers at the beginning, the true cost of independence will soon become apparent, says Jeremy Horey, senior consultant with Dimension Data.

"Over time, these departments find themselves doing more and more infrastructure work," Horey explains. "This is stuff that doesn't really add value to the business of the departments, and they become more willing over time to hand that infrastructure stuff back if it can be guaranteed that they will get a suitable level of service. The long-term cost of being independent is just too high."

Should IT executives, then, just sit back and wait until department heads see things their way? Perhaps IT divisions could engender departmental buy-in through programs in which difficult-to-win managers are actually assigned the task of running their own IT?

Such reverse psychology might well do the trick once and for all, but the operational chaos it would involve makes it an unrealistic option. Instead, the first things pulled out of the bag of tricks should be efforts at building bridges with departmental managers through representation on IT steering committees; frank discussions about the full costs of managing IT; pushing the real value a dedicated IT division can provide; and addressing concerns that departmental individuality will be lost.

Because the biggest expense in redundant is the maintenance of unnecessary IT infrastructure, it may be advisable for IT executives to work towards a compromise arrangement in which departments retain some of their application ownership while keeping responsibility for core infrastructure with the IT department.

Although it falls short of full consolidation, this approach recognises regional differences whilst pulling the most significant line items under the auspices of the centralised IT approach. Although many departments are relieved to have someone else to stress over keeping the IT running, making concessions with those that remain resistant is the kind of compromise that Horey argues is the best approach overall.

"When departments argue the central IT area isn't responsive enough to their needs so they need to do something different, there is often a reasonable case behind that," he says. "But technology decisions are only one small aspect of this. If you're religious about your technology, it's much harder to exist in a shared services model. But if you're prepared to make decisions about what is an 80 percent or 90 percent fit rather than a 100 percent fit, you can still get a lot of benefits."

Case study: Adesi measures the gap
There's nothing like a major change to the business to shake up the established order, and Adesi has certainly had its share.

Having grown out of the IT service division of Woodside Energy, Adesi was positioned as an arm's-length SAP applications management specialist to look after Woodside's new SAP environment. The company has since expanded its terms of engagement by taking on four additional commercial customers, leveraging its SAP expertise into a separate business it hoped to would continue growing.

Shifting from an internally focused corporate culture to an external culture, however, proved to be more difficult than was first expected. Adesi staff, accustomed to working together to manage Woodside's projects, soon found that they had no way of knowing who was involved with what project -- and, more importantly, who was available to help out with projects.

Systems managing project progress, billing, IT service management, and other processes had to be used separately, with data entered into systems that didn't talk to each other. As often happens in such situations, inconsistencies between data and far too many blank fields meant the organisation lacked an overall, ongoing view of its various departments' activities.

The situation was also wasting time -- call centre staff, for example, could spend up to 10 minutes manually copying and pasting details from a client's system to Adesi's own incident logging system -- a process that had to be repeated for each and every one of the nearly 1000 support calls received every month.

"As we added more and more clients, we found it more and more difficult to manage," says Adesi consultant Wesley Franke. "All of our clients were all different, and no one really understood the processes. Some teams were really great with their resources, and others just couldn't be bothered updating [the systems]. It came to the stage where we had no control of our processes."

Poor communication between project teams -- symptomatic more of organisational separation than any endemic political issues -- fuelled the recognition that Adesi had to quickly do something to change the situation. IT strategists stepped back to reconsider the relationships between the systems and the employees using them, and realised that the best solution would be to drive a consistent IT governance framework throughout the organisation.

This framework was built around the Mercury IT Governance Center, a multi-function environment that combined a range of service management capabilities with a comprehensive audit trail and integration across Adesi's business.

Using the application, Adesi was able to model its business structure -- which included 35 different charging rates and a range of unique services offered to various of the company's five clients -- and save users' time by creating automated interfaces between systems that eliminated manual copying and pasting. A single Client Master Record stores all information about client-related work.

However, although the new system provided a better managerial view the rollout wasn't without its issues. Just as IT executives in multi-department organisations may find themselves struggling to convince those departments to buy into a unified way of thinking, Adesi faced resistance from some users who weren't happy about the rigour demanded by the new system. The previous processes may have been fragmented, after all, but users measure the effectiveness of a system for their own work. With more than 200 new projects received every month, some users resisted the fact that they had to spend more time up front to log each and every one of those in detail.

"That's a bit of change control we needed to take care of," says Franke. "People weren't happy about having to create extra project plans, but they've come to realise that if they took the time to create the project plan, it would save them in more accurate deliverables and in other ways down the track. We're trying to cater for all these minor exceptions which were previously taking a long time for us. If the users understand why you're implementing the system, they'll be more inclined to accept it."

Keeping peace with the breakaway department
Dealing with departmental independence can be a major issue for an IT organisation. Here are a few things to consider when managing IT-departmental relationships.

Resistance is usual. It's human nature to resist change, so don't be surprised when departments question or resist the introduction of a new system. The key is not to react but to point them forward.

Trust must be earned. IT organisations are better at this than they used to be, but a perception that the group is ineffective at managing change can be crippling when an IT organisation tries to push change into departments. Get some runs on the board and leverage them to get buy-in.

Executive support is only half the battle. Conventional wisdom says support from senior executives can break logjams -- but just because a department goes along with you doesn't mean they like what you're doing. Anticipate conflict, and be ready to deal with it.

Fragmentation is a governance no-no. Some department heads might try to throw their weight around by professing independence, but in the long term it's important that everyone be singing from the same hymnal. Press upon them the importance of good corporate governance and top-to-bottom transparency and they may feel less eager to become the roadblock.

Who do they think they are, anyway? When pressed to explain their business, even departments may not know. They may use this as an argument to keep process control within their department, but a lack of clear process understanding reflects corporate governance failures that must be addressed. Help departments look past parochial attitudes to see their role in the overall organisation.

Listen. If a particular business unit or manager is resisting change, there's a reason -- and it may have little to do with the technology or with you. Look behind their claims to identify the real problem so you can work together to resolve it.

Monitor. It may go without saying, but we'll say it anyway: you can't measure what you don't monitor. No matter what political manoeuvrings are going on, ensure that you have a way to monitor the performance of even department-run IT solutions. This information will likely bolster your case to bring those systems into the IT fold.

Involve them. User focus groups and steering committees go hand in hand with IT-driven change, and promising an ongoing role in decision-making is a great way to get a business line manager more comfortable with the change. Sit down at the table and you'll both probably learn something.

Compromise. IT infrastructure is a significant long-term expense, and one most departments will be happy to offload. Bring as much IT in-house as makes sense and you can get away with but don't demand a 100 percent solution if you can still see benefits from 80 percent.

They'll live and learn. Even if departments are insistent about retaining IT control now, they may not be so eager down the track when the total cost becomes apparent. Design your infrastructure for scalability and flexibility so you can incorporate recalcitrant departments' IT as they progressively offload it to you over time.

This article was first published in Technology & Business magazine.
Click here for subscription information.