Telecommunities '95



[Rapid Contents] [Conference Home Page] [Program Information] [Proceedings]





Building New Leaders in Equity-Based Telecommunity Initiatives:
Reshaping the Client-Consultant Relationship

Dr. Dottie Eastman, Ph.D., The Fielding Institute, Santa Barbara, California
Dr. Efrem Mallach, Ph.D., The University of Massachusetts, Lowell, Massachusetts

Abstract

Promoting equity in community-based telecommunications systems involves more than access to electronic information. Equity implies equal opportunity for self-determination, for designing and managing a telecommunications system that reflects the values and needs of the community itself. Until members of under-represented communities design, build and manage their own systems, they will not have equal status in the emerging global circle of telecommunities.

Although a community may have high energy and enthusiasm, external technical and managerial expertise is often needed to efficiently design and build a telecommunity. The outside consultant influences the nature of the systems.

The prevailing "expert" model for the client-consultant relationship reinforces the client’s position as dependent upon the consultant’s expertise and leadership. This paper describes alternate approaches in which client communities develop technical and managerial expertise through collaboration, apprenticeship relationships, and team workshops with external consultants.

Introduction

Equity in telecommunities implies sufficient technical and managerial expertise to define, design, and build a system that reflects the community’s culture and supports its values. As communities gain the expertise to manage the development of their own systems, they become equitable participants in the emerging global telecommunity.

When community members decide to acquire a new telecommunications system, they often do not have sufficient technical knowledge or managerial experience to develop the system on their own. When a community recognizes the need for additional expertise, an important next step is to locate and select a consultant. It is often difficult for a community to know how to evaluate and select consultants and to determine the roles and responsibilities of both consultants and the client community. The conventional client-consultant relationship is based on a consultant-as-expert model. The client, with insufficient expertise to work independently, negotiates with an "expert" consultant to develop a computerized system in exchange for payment. In this "consultant-as-expert" model, the client community does not develop internal technical and project management expertise. With a consultant managing the entire development, the client community is often isolated from the development process.

In this paper, we will examine steps that a community may take to more effectively select and manage outside expertise. We will present three alternative models: the "Client as Apprentice;" "Consultant as Collaborator;" and "Client-Consultant Team Workshop." Each model is appropriate in some situations with specific advantages and disadvantages for the client community. We include practical guidelines for developing a contractual agreement that supports client-consultant collaboration.

When we value equity in telecommunity, the apprentice model has some unique benefits as it is designed to transfer technical and managerial expertise into the community. This paper describes a project in which the apprenticeship model was successfully used and analyzes some of issues that emerged.

We conclude this paper with final thoughts on valuing equity in telecommunity. We may not "know" many of the answers, but it is crucial that folks who strive for a more just society continue to ask the questions.

Knowing Enough To Know What To Ask For

The starting point in seeking external help is learning enough about the technical, financial, legal, and organizational aspects of telecommunities to know what you want and what you need. Managing the client-consultant relationship means knowing enough to ask the right questions.

Members of the community who will be participating in the development may start out by "visiting" some telecommunities which are now on Internet, examining "home pages," analyzing content, and discussing ways in which they meet the needs of the community. Community members can participate in focus groups that define the theme, objectives and functionality of the envisioned system.

Telecommunities are built by technical experts. Successful management of technical consultants involves understanding enough of the technology to question, to evaluate, and to monitor a consultant’s ideas and works. Many computer and telecommunications magazines are directed at the technical novice. An important component of acquiring technical knowledge is to ask questions about terms and concepts which you do not fully understand. There are no "dumb" questions as each question becomes a learning opportunity. Clients can take formal courses or self-study with these publications.

As a community develops its own leadership and expertise, it lowers its dependency on external consultants. When technological and managerial expertise resides within a community, the community has more flexibility and resources available to monitor, adjust, and improve the system.

Defining The Client-Consultant Relationship

Consultants advise and share information. Contractors do the work. Often, a single individual or firm is both a consultant and a contractor. The keys to a good client-consultant relationship are clients who understands the advice.

Information, and work that is needed and agreement on the nature of the client-consultant relationship. When a client community decides that external help is needed, it has the opportunity to define the client-consultant relationship, before selecting the external consultant. This relationship can be stated in the Request For Proposals (RFP) and can be part of the contract negotiations between client and consultant.

In this paper, we discuss four types of client-consultant relationships: "Consultant-as-Expert;" "Consultant-as-Collaborator;" "Client-as-Apprentice;" and "Client-Consultant Team Workshop."

With the conventional "Consultant-as-Expert" model, the client pays the money and the consultant does the work. The "Consultant-as-Collaborator" model requires joint ownership of the work and shared authority in the project design process. The "Client-as-Apprentice" develops client ownership and supports client decision-making authority under the guidance and tutelage of the consultant. The "Client-Consultant team workshop" approach brings together a group of external experts who share their insight, experience and expertise within the context of a workshop.

Each approach has benefits and drawbacks. It is the client’s responsibility to evaluate the community’s unique requirements and to select consultants based on these requirements.

The Conventional Consultant-as-Expert Consultant Model

The Consultant-as-Expert model prevails in most project developments. A client contracts with an "expert" consultant who assumes responsibility for satisfying specific client needs. When this model succeeds, the client pays the consultant an agreed upon amount and the consultant develops a system which satisfies the client’s expectations.

The client is relieved of most of the development’s time, skill, energy, and work while the consultant’s expertise and effort is rewarded.

The Consultant-as-Expert model is seductive. For a fee and limited time and effort involvement, a community will have an operational telecommunications system. The client does not "interfere" with the consultant’s work.

Under this model, when the project develops difficulties, the client can feel trapped. The escalation dilemma, having "too much invested to quit," has affected many organizations. Once a pattern of reliance on outside expertise is established, it is often economically and structurally difficult to switch to an alternative approach of building internal expertise.

The Consultant-as-Expert relationship may promote client dependency upon a consultant’s expertise and leadership and deny the community the opportunity to develop an equitable position in the emerging global telecommunity.

Consultant-as-Expert

Characteristics: * Consultant has needed expertise * Client’s role is to support consultant * Consultant takes ownership of project and is fully responsible for its success * Client is responsible for full and complete definition of the proposed system’s functionality before the consultant’s work begins.

Negotiables: * Cost of consultant’s services * Time available for development process * Review process * Client’s "need to know" what the consultant is doing during the development process * Process of resolving differences

Benefits: * Client relieved of daily involvement * Consultant free to work independently * Client does not need to develop expertise * Consultant able to manage development process

Shortfalls: * Client does not develop expertise and understanding * Misunderstandings of requirements emerge * Client unable to identify system problems * Consultant vulnerable to client’s dissatisfaction with results

When appropriate: * Project with clear functionality * Client does not need to develop expertise * Time requirements are critical * Consultant has solid experience in client’s field

The Popular Consultant-as-Collaborator Model

The "Consultant-as-Collaborator" is often promoted as a way of ensuring client ownership of a development. Consultant and client work together throughout the entire course of a project. This model recognizes the importance of integrating community values and priorities into the design of the system. As the system develops, small decisions will continue to be made regarding the nature of system. With clients involved in the day-to-day project development, knowledge of the community will be embedded within the system. Often, the client will retain management responsibility for the development. The roles and responsibilities on clients and consultants are negotiated with the contract, and monitored throughout the development process.

Consultant-as-Collaborator

Characteristics: * Consultant and client have needed expertise * Client and consultant support each other * Consultant and client have joint ownership of project and share responsibility for its success * Client and consultant share responsibility for definition of the proposed system’s functionality, which may be an on-going process throughout the course of the development

Negotiables: * Cost of consultant’s services * Time available for development process * Review process * Process by which client and consultant share tasks, knowledge, and management process * Process of resolving differences

Benefits: * Client gains expertise and understanding of project * Consultant and client share workload * Client can customize system * Client able to manage development process

Shortfalls: * Developing shared understanding takes time * Managing a collaborative process takes effort * Client and consultant may jointly miss system problems * Consultant vulnerable to client’s changes during development process

When appropriate: * Project with functionality that needs to closely fit the client’s unique situation * Client needs to understand and maintain system * Time requirements are flexible * Consultant has solid experience in technology but not necessarily in client’s field

The Apprentice Model

In the Apprentice Model, the client’s role is to design and build the system, under the guidance and tutelage of the consultant. The client community’s cost is lower in several ways. Because project leadership skills are being developed within the client community, the consultant’s time is reduced to "check-ins" and training sessions rather than constant attention and actually doing the development work. As the system is developed, ownership and knowledge is growing within the client community. After the system becomes operational, requested changes and enhancements are less costly as expertise exists within the client community.

In the Apprentice model the consultant’s role is to assist the client in assuming leadership and becoming a self-sufficient expert. The consultant’s value is measured by the degree to which a system is owned by the client community. In the apprentice model, a consultant’s success is rewarded when a community’s values, priorities and objectives are firmly embedded in a system.

The Apprentice model ensures that members of the community become project leaders and are full participants in the design, development and management of the communications system.

Client-as-Apprentice

Characteristics: * Consultant has needed expertise * Client’s role is to learn by doing * Client takes ownership of project * Consultant’s role is to guide, to monitor, to explain, to share technical and managerial expertise

Negotiables: * Cost of consultant’s services * Time available for development process * Review process * Consultant’s availability to client

Benefits: * Client develops technical and managerial expertise * System fully based in Client’s environment * Consultant is able to consult on multiple projects * Client manages the development process

Shortfalls: * Client’s learning curve may initially slow project * Time requirements may not be clear * Client may make mistakes which will need to be addressed - and the learning takes time * Client may perceive the consultant as "not doing very much"

When appropriate: * Client needs to develop technical and managerial expertise * System must fit client’s unique situation * Client has time and resources for the work * Consultant understands the need to share expertise

Client-Consultant Team Workshop

During the course of the design and development of a telecommunity, needs emerge for expert advice and information in a wide variety of issues. Technical needs, organizational development problems, economic challenges, educational and other content requirements need addressing in a cohesive format. Decisions in one area impact other areas. For example, educational needs impact the technical requirements.

Some telecommunity developments include workshops which bring together several consultants with expertise in different areas. The consultants and members of the community who are working on the system join together in workshops to identify critical issues, propose and analyze alternative solutions, develop action plans, and design processes to implement new ideas and decisions.

Although this model takes extra planning to coordinate, the community benefits from the interaction of consultants and community folks who work together, pool their experiences and information, and jointly create new solutions.

Consultant-Client Team Workshop

Characteristics: * Outside expertise, in several areas, is made available to client * Client’s role is to define needs * Occurs at point in project where specific expertise is needed to guide the next stages * Consultant-client team involved in brainstorming; sharing ideas, experiences and expertise; and joint planning for next steps

Negotiables: * Cost of consultants’ services * Number and type of expert consultants needed * Design of workshop process * Consulting team’s follow-through with client Benefits: * Significant benefit to client within short time * Project development is not disrupted * Client needs to identify needed expertise, and select team of consultants based on specific needs of the project at that time * Client able to manage the client-consultants team interaction throughout workshop

Shortfalls: * Limited time to address issues and share expertise * Incomplete understandings may promote inadequate recommendations * Important issues may not be identified or addressed * Client vulnerable to consultant’s quick responses

When appropriate: * Project with clear needs at a specific time * Advice from multiple types of experts needed * Team interaction supported * Client has sufficient expertise to understand, evaluate and modify consultants’ suggestions

Developing The Client-Consultant Contract Agreement

The design and development of telecommunities is a rapidly changing field. Few consultants have extensive experience. Client communities have to balance a variety of strengths and shortcomings in the selection process. Client effort and commitment is needed to transfer a consultant’s knowledge, strengths, and experiences in a way that promotes the development of strong technical and managerial leaders within the community.

An essential component of a good client-consultant relationship is a clear understanding, before the contract agreement is signed, of the nature of the relationship as is reflected in the roles and responsibilities of both client and consultant. Although few consultants may initiate this dialogue, the success of the development process may depend upon the appropriateness of the relationship to the needs of the client community. The contract agreement between client and consultant establishes responsibilities and roles.

After you understand what you need from a consultant, write it out in thorough detail. The "needs" include the functional detail of what you expect the consultant to accomplish, nature of the client-consultant relationship, the manner in which changes and unexpected problems will be resolved.

Seek out multiple bids on any proposal. Ask thorough questions about what a consultant proposes to do, how they expect to get paid, and the nature of the client-consultant relationship. Seek out references and follow through with detailed questions.

Because of the importance of selecting the strongest possible consultant, some community clients are now developing limited contracts with consultants who are responsible for helping the client find, evaluate, select and contract with the most useful consultant. This intermediate consultant would not be allowed to be a candidate for the actual consulting position.

Conventional contracts focus on "what" the consultant is to do and "how much" the client is to pay. A client-consultant contract that guides and rewards the transfer of consultant expertise into the community requires client effort and consultant agreement with the collaborative process.

Clients can require, as part of the contracted responsibilities, the requirement to "make us independent of you." This requirement can be stated in the client’s initial Request for Proposals. If full independence is not feasible, clients can develop a contract for required follow through work.

As part of the consultant-evaluation process, clients can ask consultants to describe, explicitly, how they will facilitate client independence, and over what period of time. The contract can also establish firm guidelines for client participation in the development process.

In selecting a contractor and finalizing the client-consultant agreement, there can be solid guidelines for consultant accessibility, client responsibility, and a conflict resolution process. The client can ask the consultant how she/he works and how they best interact with their clients.

Consultants may be located in many different ways. People who have developed similar telecommunity projects are valuable resources. Other resources include computer stores, consultants in related fields, universities and other institutions that offer related courses, management consulting firms, and hardware and software firms.

There are resources available on the Internet. At "misc.business.consulting," consultants discuss the business aspects of their practices. While a consultant is explicitly forbidden to seek work here, access is possible privately via their E-mail address.

There are consultants with technical, educational, multi-cultural, project management, and community-development experience who try to share their expertise, encourage community-based initiatives, and support leadership development within client communities.

A Case Study Of The Client-as-Apprentice Model

This case study summarizes an actual development in which one of the paper’s authors participated. Although Dr. Kirk is not the consultant’s "real" name, the development process is accurately described.

Dr. Kirk is a systems consultant whose practice is fully engaged with the Apprentice Model. When he contracts with an organization, he focuses on ensuring that the client fully understand the nature of the collaborative development agreement. He works with the client to develop a schedule which will decrease his hands-on involvement in the project, reflecting an expected growth in client project knowledge, skill, and self-sufficiency.

Under his guidance, the client participants become project leaders, developers and overall systems experts. Dr. Kirk begins by helping the community select and hire people (from within the community or organization) who will be the leaders of the communication systems development. The criteria used to select these people will not necessarily include solid technical experience, but may prioritize skills such as careful listening, critical analysis, and creativity. For the first month, the apprentices are responsible for understanding the community’s issues that will impact the design and development of the communication system. Dr. Kirk spends a day developing interviewing and note-taking skills and then leaves. While he is available by phone or e-mail, he is not physically present during most of the development process.

When he returns, perhaps a month later, he reviews the material and community/organizational knowledge gathered by the apprentices. The assignment for the next month is to increase the level of process detail and concrete data gathered by the apprentices. He suggests forms, tables, organizational structures and other tools for detailed data gathering. By month three, the "apprentices" have become skilled in the functional analysis that precedes systems development.

Dr. Kirk now begins the systems design phase. He spends a few days with the apprentices with intense training in systems analysis and design. He gives specific instructions for the design work that must now be accomplished. He leaves examples of the completed designs of other similar, successfully operating, systems. The community-based apprentices are then, again, left alone to develop the design of the system. Dr. Kirk is available for support and clarification, but is not the actual designer. The designers are from the community. This apprentice process continues throughout the development. By the time the system goes on-line, those "apprentices" who have functionally analyzed, designed, developed and implemented the system are now the internally-developed leaders of the system.

Challenges To The Apprentice Model

Although the apprentice model builds technical and managerial expertise within the community, issues arise during its implementation. If the consultant is successful his/her expertise will be needed less in the future. In many consulting situations, the consultant’s expertise is needed throughout the life of a system, whenever problems arise or changes are needed. It is a challenge for the consultant to ensure that the organizational managers or community leaders recognize the solid value of the apprentice approach, and the valuable contribution of the consultant. Otherwise, at the end of the development, those who have contracted with the consultant, may wonder what they are paying for! In one case, the director of a medical facility, (where Dr. Kirk was extremely successful in this apprentice approach), wondered why the organization was paying Dr. Kirk anything at all.

The system was smoothly developed on time and within budget, it was meeting the needs of the organization, it had been developed by people from within the organization, and was now fully supported by these people. The director wondered what Dr. Kirk had done!

Conclusion--Valuing Equity In Telecommunity

Awareness, skills, and access tools are prerequisites for equity on the Internet. Less obvious, but essential for global equity, is leadership emerging from within members of under-represented groups.

Equity involves more than accessing information that someone else has defined as valuable. Equity implies having a voice in the definition of information.

Power resides in setting the agenda for a dialogue, whether between two people or among nations. Those who establish and enforce the rules for communication control the openness and flexibility of the dialogue.

The Internet has the potential to bypass many of the economic, social, cultural and economic barriers that interfere with a community’s full development. But, in our world of diversity, communities have different values, priorities, and goals. The challenge is to retain that diversity which makes each of our communities unique, and still to join together as equal participants in the global circle of telecommunities.

The dilemma of internal versus external expertise affects the equity among diverse communities. There are economic implications when any group is dependent upon outside expertise. In community-based technological developments, the notion of "electronic colonization" has spurred some groups on to developing internal expertise. "Electronic colonization" refers to the power others have to determine the way a community sees and acts in the world. As we become more dependent upon electronic communication for our interaction with others locally and globally, we accept the rules, the patterns, the structure of the communication system we use.

As telecommunication systems become more pervasive in our society, we lose awareness of the degree to which they influence our values, our ways of thinking, our ways of acting. We accept the patterns of social and economic interaction embedded within the electronic systems we depend upon.

This paper has examined the relationship between the client community and the external consultant. This relationship can stall equity among communities by supporting community dependency upon external expertise. Or, the client-consultant relationship can serve to promote equity by transferring technical and managerial skills and understanding from outside experts into the client community.

We live in a very special moment in time. As the very nature of human connection is changing, we sense that our actions are influencing the nature of the emerging human condition. This new human condition that we are co-creating is influenced by the manner in which we build our systems and transfer technical and managerial expertise into communities.

About the Authors

Dr. Eastman is on the faculty at The Fielding Institute. She has extensive professional experience helping organizations develop information systems in the public and private sectors and consults with communities and organizations who are building telecommunications systems.

Dr. Mallach is chair of the information systems department at the University of Massachusetts at Lowell. He has also been working with the social and managerial uses and implications of telecommunications.

For more information, please contact:

Dr. Dottie Eastman at dartt@cadvision.com
Dr. Efrem Mallach at Mallache@woods.uml.edu


Mail your comments and questions about these web pages to rowena@softwords.bc.ca