Get users, IT, and management working together more effectively
We present an outline for organizing a program to develop a business road map and determine benefits in resolving IT issues
Getting the IT department, users, and management talking together often is the first step in making your computing environment efficient. By getting all of the stakeholders working for the same goal, you can eliminate many of the potential problems that planning and budgeting just can't fix: the people issue. (1,700 words)
Over the years, we in the IT business spent most of our time planning and budgeting. Since IT was seen as the "necessary evil" and simply overhead in many corporations, we were forced to justify ourselves at every turn. We had very little ability to do things on our own without someone, usually the financial officer, questioning every activity and dollar spent. This month, we look at a little of the history of the changes in the IT industry and one of the methods we use in our own consulting practice to address this issue. This method, which we describe below, is our training session for IT managers. (While this might seem a little commercial, we believe that your take-away from this column is more of an understanding of how we view the IT industry and how we think you can benefit from working with consultants.)
Based on this history, many IT executives got to the point of being too conservative and lost the ingenuity that tended to set us apart from other disciplines within the corporation. In the early days (the 1960s and '70s), IT was seen as the "savior" of all corporate administrative problems when we provided automated payroll and general ledger processing on the mainframe. In some cases, we were allowed to delve into strategic business initiatives and develop or implement systems that supported key business requirements.
And because of the paranoia caused by justification at every turn, we became too conservative. We hated change. Anything that upset our environment was not good. And if a department wanted some new system installed or a later release implemented, we quoted the "18-months minimum," or said "we don't have the budget for that."
The PC brought power and technology to the local department and to the desktop, and users of IT services became more scarce. Users implemented their own technology solutions on those desktop systems. IT continued with the "administrative" systems on the mainframe while the users implemented local PC-based solutions to support their business requirements. They didn't want to come to IT because of our conservative and obnoxious nature and felt they could implement their own solutions. And, of course, we responded in kind; we provided exactly the kind of support the PC users wanted: none.
IT management wanted no part of that PC environment and let the users fend for themselves. IT management thought the users would find too many technology issues awaiting them, then fail. That way, the IT managers could say: "We told you so, the mainframe is the only solution!" But the PC users didn't fail, or at least, they just wouldn't admit it. PC users used the local technology to support their requirements in a more timely and less costly manner. "We don't need IT anymore, and we're saving a bundle to boot" was their rallying cry.
Client/Server: The great equalizer
Then came client/server paradigm. This new technology provided even more power at the local level and more ability to support local departmental business issues. End users started looking toward replacing mainframe applications and/or new business functions with client/server technology. They still felt they didn't need IT. However, as these new applications were being developed, deployed, and put into production, everyone in the industry started hearing those horror stories of "this stuff doesn't work," "development and deployment is taking longer than on the mainframe," or "the technology isn't ready for prime time." From the IT manager's perspective, it wasn't the technology that was the problem, it was that users never learned what "mission critical" meant or how to support mission-critical applications.
With the advent of client/server technology, it has become more and more of a requirement to support mission-critical applications at the local level -- what we consider the network level. The networked (wide-area or local-area) desktop, application server, and database server are becoming mission critical and need to be supported as such. That's why we coined the phrase, the network is the data center.
Mission critical refers to a set of standards, guidelines, processes, procedures, and management policies that were developed in the data center a long time ago. The data center staff had to implement these management policies based on such issues as budgeting, planning, and overhead.
How do we implement these processes and procedures in a network computing environment based on all those "sins-of-the-past?" We think the time is now. It is time for IT to get back into the thick of technology support and implementation of client/server. How? It takes planning. We have to acknowledge the need for team involvement (IT and users), communication, and planning -- together. But it won't be easy.
How do we get rid of all that old baggage and come together to do things the right way for the corporation? How do we get rid of the politics that have been ingrained for the past 10 to 15 years? This isn't easy either, and can often be harder than dealing with technology because it is cultural. How do we change the IT culture and the end-user culture? We believe that the way to change the IT and user cultures is through something we call IT Infrastructure Planning -- ITIP for short. In fact, we could have called it ITCP for cultural planning, since most of the time we deal with issues such as services provided, service-level agreements, communication, and a common set of initiatives.
As our regular readers well know, during the past year we facilitated more than a dozen ITIP sessions. Most of the participants are from Fortune 100 to Fortune 500 companies. Most have come away with a common plan to deal with the issues. We are including an overview of what the ITIP is, such as who should participate, the benefits, the deliverables, and a sample of issues we cover.
Of course, your sessions might differ depending on the consultants you bring in to run your sessions. The key, however, is to understand the important issues and take action.
Again, we stress that this is not an advertisement for our consultant practice, but rather a view for you on how we organize our thoughts in order to help you understand your organization. What we are trying to do is get the two key stakeholders -- users of IT services and key members of IT together -- in one room, brainstorm about real issues, and identify solutions. The issues are usually not technology related, and it helps to get folks communicating again. If no other problem is solved, then at least we are talking together again as a team from one corporation.
How the program might be organized
Our Information Technology Infrastructure Planning (ITIP) is a highly participative session designed to break down the walls between the various groups such as IT, new technology, and users. Then, using a teamwork approach, we develop a plan for moving forward in the new networked enterprise.
The session focuses on addressing the key issues in providing an integrated support architecture and plan through:
Participants should include:
The benefits of conducting such a seminar for all of the key stakeholders in IT, including senior management, is that the group learns the problems and issues facing other stakeholders. Once the technical staff, users, and management realize the needs and pressures on the other group members, we find that they are more willing to work together, rather than work at goals that might be counterproductive to the overall company's best efforts.
A well-executed program can provide such benefits as:
What kinds of information should IT managers expect to get?
IT managers, as well as other attendees, should expect to walk away from a seminar such as this with a real direction of how to proceed, not just flowery soundbites and "warm fuzzies" about their compatriots. Here are some of the items we provide our attendees; you should ask your consultant about what they provide during the sessions:
The following are some of the issues we cover during our sessions. This is far from a complete list; instead, its purpose is to lay a groundwork for some of the issues you should consider when you plan a session with your consultant.
One cannot expect such a seminar to succeed without the full support and participation of all the stakeholders. But participation isn't enough -- it requires a concerted effort to put into practice the lessons learned. When you meet with your consultant to discuss how to put a seminar such as this together for your staff, remember to get your questions answered on how the seminar will be conducted up front; you want to be sure your stakeholders will get the right message so all your efforts don't go to waste.
If you have technical problems with this magazine, contact firstname.lastname@example.org