Provide Collaborative Leadership

T

his case highlights a core issue facing government CIOs: how tightly to manage information technology in a widely dispersed environment. I have experienced this type of dilemma firsthand in the development of an enterprise information architecture at the Energy Department.

The CIO in this case is a manager who has built up some degree of trust, based in part on his operating with a "light but steady hand." There seems to be momentum for radically improving desktop technology services delivery while providing some level of standardization and, at the same time, reducing overall costs. There is a core group of professionals with the skills and the willingness to carry out this initiative.

As my department began to formulate an information architecture, our CIO's approach to the challenge of getting the programs, field sites and laboratories to work together was quite similar to this scenario. The keys in our effort and I believe to the resolution of Rawley's predicament are the same: Provide collaborative leadership, partnership and openness.

When radical change is sought, outspoken champions must provide effective leadership. Lack of proper leadership is the single biggest factor contributing to the failure of major change initiatives. While there are many leadership styles, the one I find to be most successful in instances like this is that of the collaborative manager.

A collaborative leader ensures that an open forum is maintained, encouraging differing opinions to keep from falling prey to tunnel vision. In our information architecture effort, from the beginning, the CIO stated clearly and frequently that we were not proffering a "one size fits all" solution but rather were creating a framework to ensure our solutions fit the department's business needs. He insisted our goals of interoperability and cost savings should not compromise on quality information technology solutions needed to satisfy our customers' requirements.

In this scenario, Rawley must decide what degree of flexibility can be allowed in formulating the RFP without compromising the primary goals.

I'm not sure that understanding whether the field is overzealously planning or sending messages about the procurement really matters, because either way one of the CIO's top priorities,providing a mechanism to implement change and save money through "commonality in PCs and local area networks",is either being missed or ignored by some.

Since the message that all the organization's components are in this together apparently wasn't clear from the beginning, it must be reiterated by the CIO to the business leaders at each field site.

Effective IT decision-making must ensure that technology supports business processes. The scenario didn't mention how the outsourcing initiative related to any overall IT architecture nor how it fared in running the gantlet of an effective capital IT planning process, both of which are required by the 1996 Clinger-Cohen Act. Use of these processes would add value and legitimacy.

Two other tactics might be tried. Rawley could reengage the team to contact each of the "rogue" field sites and attempt to negotiate with them. Benchmarking their requirements against more reasonable ones from comparable organizations can often help.

Alternatively, he could convene a meeting like the one in the movie The Dirty Dozen, locking the representatives of all the sites in a room until they've worked out their differences.

The collaborative approach may be tough, but I believe it produces the most enduring results. Rawley is on the right course, but will he go the distance?

Michael Tiemann is an information architect at the Energy Department's Architecture, Standards and Engineering Group in the Office of Information Management . He has been in the federal government for 25 years, primarily at the Federal Energy Regulatory Commission and at DOE.

NEXT STORY: Useful Numbers