Chapter 3. The Organization

Having completed the exercises in Chapters One and Two, you have established realistic expectations for your automation initiative and a clear purpose statement to match. With input from your staff, users, and management, you diagnosed the problems and opportunities of automation in the contextof your technology and process architectures. Now you need to assess the project in the context of your IT organizational structure and formally establish the team that will plan and execute the project.

A couple of years ago, I helped an insurance company address the organizational, process, and technology issues they faced as they were embarking on their first (perceived) distributed, client/server implementation. This company had been operating in legacy mode for over 30 years. The mainframe had been supporting their applications as long as they could remember, which was a long time, since most of the IT managers were "lifers" in the organization. They were quite anxious about the impending insurgence of the new UNIX- and Oracle-based technology, but they said nothing about the process and organizational implications. I suspected they could handle new technology; the real concern lay in their ability to change their processes and integrate new talent.

I used the term "perceived" in the preceding paragraph because the organization had been supporting a network for over a year. Novell and NT servers were up, running, and managed by a so-called "network group." The beleaguered network manager was the new hire in the organization, and his input and perspective were virtually dismissed by the incumbent legacy managers. The only time the incumbent operations manager worked with the "rookie" network manager was to resolve simple interface issues. In fact, the legacy managers built a wall to separate the mainframe from the network servers in the computer room. Talk about matching logical (attitudes) with physical (support)!

The physical and professional separation was a real shame for lots of reasons. In addition to the obvious relationship problems brought on by the "us against them" behavior, the lack of synergy did not permit the benefits of shared perspectives and experience, let alone joint problem-solving. The legacy operation was mature and stable but the newly established network group could not participate in the established, integrated production processes. Conversely, the network group brought the enterprise valuable technical knowledge but the legacy personnel weren't learning anything new. Every time the groups needed to work together, they ran headlong into a physical and attitudinal wall.

My initial directive-recommendation to the CIO? "Knock down that wall." We dealt with the organizational issues first, and then built an integrated team to address the challenges of new technology.

Whatever the project, managers must concern themselves with three critical aspects: people, process, and technology. In Chapters One and Two, the matrixes and exercises dealt with the technology and process architectures. The people issues were addressed in advice and tips about how to involve people in project definition by engaging them in evaluation of the opportunities and diagnosis of the problems. In every chapter, you will find advice and tips on how to engage, manage, and work with the people who will approve, execute, and experience change as a result of your automation project. These aspects of the automation project are interleaved in every subject and at every phase of the project and this book. This chapter contains a concentrated discussion of two "people" issues: first, how automation may impact the IT department's organizational structure, and second, how to establish an automation project team in the context of your IT department and enterprise.

This book is not focused on the structuring and restructuring of IT organizations, project management, or team building. However, your initiative is driven by and reliant on people. We need to stop and look at how your department is organized (why and what changes you might need to effect), and how to leverage that organization to build your automation team.

As you read this chapter and apply the ideas to your environment and challenges, expect to answer the following key questions:

• How am I organized compared to industry standards and norms?

• What management relationships outside Infrastructure/Operations should I be trying to nurture with respect to this initiative?

• For what typical organizational issues and challenges should I look?

• How should I compose and initiate an automation project team?

• What changes must I take on as part of this initiative?