For the past six years I have been a participant observer in the implementation of five large application systems at a multi-division insurance company. A string of past system implementation failures prompted the COO to ask me to revamp the company’s process for implementing systems and to guide a set of major system implementations planned over a five year period. Five systems have been completed successfully so far and another one is scheduled to go live by the end of 2003.
Being a participant observer has allowed me to see how these systems are implemented in practice and how the design of the application system and the design of work actually takes place. I now have a better understanding of how some of the notions from research and some of the prescriptive literature play out. While this only represents one case, there is nothing particularly unique about the setting. It is a company committed to serving its clients (who are well defined); it holds from 50– 70% market share across the various lines of business; it prides itself in its human resource policies and concern for its workers; it strives for consensus and participation in major decisions; it has a clear vision of where it is trying to go (in terms of business strategy and execution of the strategy); and it has the resources to execute the strategy. This chapter has
Technology and the design of work revisited 119 given me the opportunity to reflect on the five implementations, particularly the regularities and the differences among them. But I do not characterize my observations as research.
The importance of the RFQ/proposal evaluation process cannot be stressed enough. Requirements evolve through a dialogue among various interest groups. Almost more important than the requirements themselves is the mutual learning and understanding that comes from the process of working through the requirements. It permits agreement to be reached on scenarios and assumptions and it leads to exploring implications. Requirements are dynamic and they evolve over time; they are not known in advance. And they are never known completely. It is important for executive management to stay engaged in the process so that the outline of the requirements, the business strategy, and the expectations of senior management stay aligned.
An extensive search for potential systems and vendors is the next step. In any application area, the number of systems and system suppliers is extensive, often in the hundreds and always expanding. One cannot rely on any one source of information, for example a particular set of industry reports. Information needs to be gathered from general to specific. And one can learn a lot from listing to the vendors. How do you know when you have searched enough? When you begin to converge on the same set of systems and vendors. Once the general search is completed, the systems and vendors can be ranked and the poorer ones eliminated. This permits a more detailed investigation of a relatively small set of finalists. One method we have used is a two-stage solicitation: first an interest qualification round followed by detailed proposals. One of the major purposes of the search is to prepare the team for vendor selection.
Vendor selection needs to involve a broad representation of interested parties. Key to this is a formal proposal evaluation method. The important dimensions of evaluation need to be identified and each proposal assessed on the basis of how well they do on each dimension (often closely related to a set of requirements). We make a distinction between objective and subjective dimensions and try to keep them separate. In fact, we term the objective portion ‘assessment’ and the subject portion ‘evaluation’. Interestingly, in all six cases to date the finalists were not obvious in advance and they were never the front- runners.
Another important factor is the organization and staffing of the project teams. It is important to assign the best people in a functional area to the evaluation and implementation teams. This human resource allocation will not take place without the involvement of executive management. And resources need to be allocated to backfill for workers assigned to projects. Team dynamics and processes need to be monitored and a cadre of qualified team leaders developed.
Key to the success of organizational change projects is an oversight or governance mechanism to monitor project activity. The key executives of the firm need to be involved in this process along with all the important stakeholders. Such a process reduces opportunities for politics and it permits real-time resource reallocation and project replanning. It is much harder for project leaders to deceive management as to the true status of a project with oversight reviews keyed to milestones and it greatly reduces coordination costs since everybody is involved in key project decisions. We have learned that having the same group of executives involved in oversight across all projects is a benefit; the same issues tend to arise on each project and the executive team quickly becomes experienced and gains trust in each other in this context. Part of my role has been to design and evolve this oversight mechanism and to act as an ‘honest’ broker at meetings.
We have refined the notion of a ‘model office’ where business processes are documented, analysed, and best practices introduced into processes by domain experts, often provided by the application system vendor. How much change to introduce into a project is a risk factor that needs to be decided explicitly. The model office develops and tests all business processes and procedures prior to a system ‘going live’. When modifications to a system are produced, they are regression tested in the model office. It is our dynamic test bed. Test scripts and test libraries are developed there. So is all user documentation. And staff training is worked through the model office so the staff can be trained immediately before a system goes live.
Finally, it has become clear that the customer service environment requires a firm’s separate application systems to be integrated so that they can share information. Doing this in practice is both a research question and a practical challenge. It means being precise about what data mean in each system and mapping this to a common representation. And it means building a mechanism for exchanging messages among applications and between applications and the infrastructure.