THE IMPLEMENTATION COORDINATOR
The Project Manager's Ally
by Howard Fallon the President of the Kilton Peele Company of San Francisco, California, a technological consultancy dedicated to solving business problems. Mr. Fallon's latest book is How To Implement Information Systems & Live To Tell About It published by John Wiley & Sons.
A job description for the person responsible for implementing information systems into the operational environment.
The role of the Project Manager for information systems' projects is increasingly being subdivided into a number of specializations. The reason for this segmentation of the Project Manager's responsibilities is the increasing complexity of the overall task. As the construction and implementation of information systems evolves and expands, so does the level of complexity. This in turn necessitates the segmentation and further specialization of the Project Manager's duties. Specialization is the natural response to complexity. Breaking a job down into discrete roles concentrates expertise on particular functions and promotes control by having individuals accountable for individual functions.
Many information systems projects today have a number of different people performing duties that used to be solely the responsibility of the Project Manager (see Figure 1). On the front-end of a project you have Joint Application Design (JAD) facilitators and team builders. Over the life of the project are people responsible for quality assurance and Total Quality Management (TQM). On the back-end of the project are yet other people are responsible for implementation coordination and training.
For the implementation phase of projects Project Managers are finding a need for coordinators who can build networks of cooperation for getting things done. The Implementation Coordinator (IC) is the person who ensures a successful implementation through the orchestration of activities, the facilitation of meetings, and the integration of technologies.
YESTERYEAR
In days past Project Managers for information systems were typically someone from the organization's Management Information Systems (MIS) division. Today Project Managers are coming more from the business or user side of the organization. This is appropriate because the Business Users are the ones who fund and ultimately take responsibility for the information system, so they should be in charge. When the Business User is the project's manager they invariably encounter certain inherent project difficulties. Such as how do they fight for what they want as the user of the system to be implemented and still be conciliatory towards those whom they want to do things for them? One way that works well is by having an IC intercede with those whose contributions the Project Manager needs. With an IC on the project the Business User as Project Manager can aggressively campaign for what they want, yet not be caught up in all the implementation issues. The Project Manager doesn't have to fret about everyone working together towards the system's implementation. That's the IC's responsibility.ICs aren't characterize as Project Managers because that implies ownership of the system. The IC is a proponent of the system's implementation, not it's proprietor. Since the Project Manager is the person who is accountable for the system, the IC is more properly known as the Project Manager's ally. The Project Manager provides leadership while the IC provides coordination through the dissemination of information and the marshaling of energies.
AUTHORITY
ICs have no explicit authority. Explicit authority devolves from the Project Manager and the organization's upper management. ICs have the responsibility for the implementation but no direct authority to make it happen. Responsibility without authority can be a curse or a creative challenge. So ICs typically just jump right in and start helping some people, while making demands of others. For example, some people on every project can be counted on to do their piece for the implementation in the needed time-frames. However, there are others who will never get their part done on time. When it's evident someone is not going to get their part done on time the IC escalates this issue to the Project Manager's attention. ICs use their judgment to determine what it takes to get the information system implemented. Sometimes they use escalation and at other times they utilize friendly persuasionCOMMUNICATION
ICs find that most implementation problems deal with communication. Communication is fraught with ambiguities that create mismatched or misunderstood expectations. It's difficult to get things right even when all parties to an agreement believe they've achieved mutual understanding. Technological problems stand in contrast to communication problems. Technological problems, whether in hardware and/or software, reside in environments with predefined rules, so it is a straightforward process to research the situation and determine the best possible alternatives. There is little equivocation. In their dreams, ICs wish every implementation would have only technological problems, because they know that in real life it's the communication problems that get you in the end.ICs know that taking care of the numerous unremitting communication issues that can develop into problems is essential to the success of every implementation. ICs don't wait for communication issues to develop into problems because by that time it may be too late to effect any solution.
FACILITATION
The Business User as Project Manager cannot facilitate a fair and non-manipulative implementation meetings because they has a personal investment in the meetings' content and outcome. It's hard for the Project Manager to play the role of the person who makes the decisions and also play the facilitator's role of making sure everyone is heard. These are opposite points of view, and no one should be expected to play both roles effectively. Project Managers who conduct their own implementation meetings are the most active participants, which restricts energy, information, and consensus. However, with an IC facilitating the implementation meetings the Project Manager is assured all the possibilities, issues, and concerns will be voicedNETWORKED ORGANIZATION
The hierarchical organizational structure is disappearing as rapidly as the technology of information is changing. In the hierarchies stead we find the networked organization which is downsized and decentralized. In these distributed, cross-organizational, and multi-platform computer environments everything from palmtops to mainframes is or will be sharing information and resources. Organizations now have national and international networks of information systems. Implementing information systems into the operational environment of the networked organization is becoming a complex endeavor involving many people, institutions within and without the organization, and differing technologies.Most implementation efforts in the networked organization are accomplished in temporary horizontal work-groups that function like task forces. These work-groups or teams cut across the traditional lines of command by bringing together as peers those persons necessary to accomplish a given task. These autonomous teams, known for their expediency and flexibility, are protean--capable of forming, disbanding, and reforming all through the implementation effort. These teams also interact with other implementation teams to form networks that continually expand and contract to fulfill implementation requirements and to resolve problems situationally. Without an IC to orchestrate and coordinate this transitory organizational structure of horizontal teams and expanding and contracting networks, the implementation effort risks a gradual degeneration into total chaos.
RESPONSIBILITY
The issue of where responsibility begins and ends is always one the biggest problems with implementations. The tasks (or parts thereof) that fall through the cracks between the beginning and end of responsibilities can have devastating consequences. What ICs find with every implementation is that people always tend to define their role as being smaller than anyone else would define it (see Figure 2). Therefore, the IC must clearly define where responsibility resides amongst organizations, groups, and individuals. All participants in the implementation must explicitly understand their responsibilities.Too often during implementation efforts, the participants don't spend enough time thinking about and negotiating their responsibilities. They proceed just on the basis of their own assumptions. ICs help the participants validate their assumptions amongst themselves. Misunderstandings are rampant with every implementation and tend to play havoc with the implementation schedule. Therefore, ICs are continually asking questions that validate assumptions, eliminate ambiguity, and define responsibilities.
By their nature, organizations tend become compartmentalized, and groups within them tend to assume that other groups will always take care of their responsibilities. Yet this is seldom the case. For instance, are the required resources for which other groups are responsible going to be available in time for the ICs implementation? ICs deliberately assume no one is looking out for their implementation's interests. They know that they have to get out and beat the bushes to make sure that whatever resources their implementation requires are going to be available when the time comes.
IMPLEMENTATION COORDINATORS IN PRACTICE
The term IC is still relatively new, so senior management has been known to ask, "Why do we need an Implementation Coordinator?". Typically the Project Manager responds, "Because the IC keeps us from going around in circles." This roundabout answer means that the IC is the person who usually brings the Project Manager's attention to implementation issues requiring the Project Manager's attention or decision. A more rational answer is that the IC is the professional who manages the logistics of the implementation.Virtually every project has someone coordinating the implementation, yet few organizations formalize the role with the tile of 'Implementation Coordinator.' Some titles that are used are: Product Implementation Manager, and Project Implementation Manager. However, you'll usually find that practicing ICs bear titles that seem inappropriate--such as Senior Systems Engineer, Quality Assurance Officer, or Business Systems Analyst. Since people are usually known more for the functional contribution than their formal title, a person's title may not signify their true role on a project. (This is why organizational charts are often misleading). Therefore, although the title may not fit, the role of IC is much in evidence.
Return to theIC home page.