Project Management Institute

Partnering with your client

Concerns of Project Managers

ISSUE FOCUS: Partnering

John Schmidt, Digital Equipment Corporation, Richmond, British Columbia, Canada

Is the title of this article on oxymoron? Is it really possible to partner with your client or are these two terms in fundamental conflict? Let's take a look.

A partner usually refers to a cohort or business associate. A partnership relationship has some very significant implications in the legal sense-one in which two (or more) parties have mutual, and often equal, obligations to share risks and rewards. For our purposes, we will define partnering as the sharing of risks, rewards and responsibilities in the pursuit of a common goal.

A client on the other hand is a customer. The customer relationship is one of supplier versus buyer- which is further based on deep-seated principles of master versus slave. Every time we use the cliché “the customer is always right” we are validating the master/slave relationship. One may argue that a client relationship is not the same as customer relationship and that a client involves a closer, more personal, and more professional relationship. But the fact remains that it is still very clear who is in the driver's seat.

So a partnership relationship is founded on the tenet of equality-working together collaboratively—while a client relationship is based on inequalities, with one party clearly in control. While there are often opportunities (even requirements) to collaborate with your client, not recognizing this fundamental conflict can lead to trouble. Partnering often sounds great, but it is a much overused term and has some serious complications when applied to a customer/supplier business arrangement.

So what are some of the potential problems and pitfalls? And what can be done to avoid the problems or minimize the negative influences? These questions are addressed below.


This is one of the most common situations that occurs in varying degrees in almost every prime contracting arrangement. Here is a typical scenario: your client wants you to take responsibility for implementing a project and you agree, You also agree to have your client play a role in the project, which is important to its success. Indeed, this is often an essential ingredient since without your client's expertise, support and acceptance, the project could fail regardless of how good your deliverables are. The problem is that you have just hired your client as a supplier. This not only puts you in the middle of all the client's internal problems, it has put your client into a potential conflict of interest position. (see Figure 1).

Some of the same individuals or groups within the client organization are suppliers and customers at the same time. This puts them in a position where they may be asked to accept work to which they themselves made a major contribution. You may have experienced this directly if you have ever had a contractor or landscaper do any work on your home or yard and where you took on a portion of the work yourself (possibly to keep costs down). If you are unhappy with the final result, who can you hold accountable? Your contractor may take the position that you didn't hold up your end of the bargain, and so around it goes.

A further complication of this sort of arrangement is that the external contractor can easily be cut out of many key communications loops inside the client organization. Decisions may be made to change requirements and/or priorities, with the contractor learning of the change only after the fact. Problems may be escalated inside the client organization before the contractor becomes aware of them or has any opportunity to react. The end result? The contractor may have formal project responsibility but little control, and the client will have difficulty holding the contractor accountable.

A common approach in attempting to deal with this problem is to break the project into two separate, but interdependent projects. In this situation, you (the contractor), are responsible for only your portions of the project and your client takes responsibility for his problems. (see Figure 2). This presents some difficult issues. First, it flies in the face of the partnering concept by reducing your scope of responsibility and turning the relationship into a single customer/supplier relationship. Second, as the outsider, you will likely be blamed for problems even if they were caused by your client not effectively performing the role. Third, this approach results in having two project managers—and it isn't necessary to belabor the pitfalls of having two people trying to call the shots. So this approach is not a good solution either.

Figure 1. Your Client as Both Customer and Supplier

Your Client as Both Customer and Supplier

Figure 2. The Two-Subproject Solution

The Two-Subproject Solution

Figure 3. The Cross-Organizational Team Solution

The Cross-Organizational Team Solution

Figure 4. The Separation of Project and Business Management Responsibilities

The Separation of Project and Business Management Responsibilities


The proposed solution to this dilemma is to create a cross-functional team (or more specifically a Third Millennium Group [1]) under the direction of a single project manager. But should the project manager come from the supplier organization or from the client organization? While either scenario is possible, we would again be drifting away from the partnering concept if the client managed the project since the supplier's remaining responsibility under this approach is likely only specific products and services. So if we are talking about a & partnership in a client/supplier relationship, we are also by definition talking about the special case where the project manager comes from the supplier organization. (see Figure 3).

Building a cross-organizational team, however, is easier said than done. Some of the many complications that arise are culture clashes between organizations (for example top-down decisions versus committee consensus, or union versus non-union), different reward and recognition policies, and a potential conflict of interest position that your project manager could be in. Other questions are: Who hires and fires the project staff? Should your project manager do performance reviews for the project staff from other organizations? Who is responsible for the overall project budget? Will your client let your project manager manage their portion of the budget?

The first key to making this scenario work is to eliminate the conflict of interest problem. (see Figure 4). To accomplish this the business responsibilities (contracting, pricing, etc.) must be very clearly separated from the project delivery responsibilities. The project manager's mandate must be clearly defined and communicated-especially to your client's staff within the integrated team. The project manager must be seen by the team as being interested solely in the success of the project as viewed by the client—not in the financial success of your organization.

On the question of who manages the overall project budget (not just the contract, but also the client's internal costs associated with the project), this should be determined early on in consultation with your client. It is certainly possible, and even desirable, to make the project manager responsible and accountable for the overall budget, but some clients may not want to have an external contractor manage their internal budget. If this step is taken, then clearly a formally approved budget must be developed and monitored closely by the client. If this step is not taken, then a clearly defined project expense approval procedure must be established along with an escalation procedure in the event that the project manager cannot obtain approval for an expense deemed necessary for the success of the project.

Once the project manager has a clear mandate, a high performance team can be built. The first task in this regard is to recognize, and value, cultural and systemic differences between the various organizations (could be more than two) represented within the team. The skills and ability to classify a culture come partly from experience, partly from training (organizational development, psychology, systems thinking [2], etc.) and partly from simply being sensitive to different values and norms of behavior.

The next step is to build a common vision for the team. Everyone should know, and be committed to, a single set of project goals and objectives. This common vision is generally developed through traditional team-building exercises. Good communications tools (electronic mail, voice mail, standard PM tracking tools, etc.) are also usually mandatory ingredients to building an effective team.

Another simple but surprisingly effective technique to building a dynamic team is to simply put everyone together in the same place. This could mean uprooting both your staff and your client's project staff and moving them all into a separate facility (possibly at an off-site location) where they are physically close together. If it is impractical to move the entire team to a new location, then the second best option is for you to move into the client site. The least desirable choice is to move the client staff into your facility since it is usually more desirable to have the cultural “melting pot” of the team lean in favor of the client's culture rather than your own. In fact large conference rooms retrofitted to house a number of team members, even using makeshift facilities with less-than-standard office privacy, can work very well to quickly build a sense of intimacy, which is required in a high-performance team. Caution must be taken, however, to not make the facilities too makeshift to the point where productivity declines.

Figure 5. The Role of the Steering Committee

The Role of the Steering Committee

In terms of the questions relating to the project staff (who hires, fires, reviews performance, etc.), these need to be worked out in detail for each project as the circumstances demand. One thing is certain: the only viable option (other than possibly for long multi-year projects) is to utilize a matrix structure. While the project manager may play a very large role in managing project personnel from the client organization, the project staff still require a line manager from their home organization to deal with matters such as compensation and other human resource policies and procedures.

A final key ingredient of a successful partnering with your client project is to establish an effective steering committee [3]. (see Figure 5). To be effective, the steering committee should be as small as possible. The ideal size from my perspective is two key management individuals from your organization and two from the client organization. With less than two it's not really a committee. With more than two, the politics increase exponentially with every additional steering committee member to the point where it loses its value. Large committees may be necessary for other aspects of the project (such as gaining user consensus on requirements) but are dysfunctional in the context of a steering committee in a partnering relationship.


In summary then, a partnering relationship and a client relationship have some very different and conflicting pressures. When you attempt to combine the two a number of very difficult issues are created that could cause the project to fail if not solved. It is possible, however, by establishing clearly defined roles and responsibilities, and through proper organization, to establish an environment which will allow staff from different organizations to develop into a high-performance team under a single project manager. In this way, the risks, responsibilities, and rewards are shared and you are truly partnering with your client.


1. Kostner, Jaclyn. 1994. Why Empowerment Fails in Third Millennium Groups. PMNETwork, vol. VIII, no. 5, (May).

2. Archibald, Russell D., PMP and Steen Lichtenberg. 1994, Uncertainty and Change Require a New Management Model. PMNETwork, vol. VIII, no. 5, (May).

3. Knutson, Joan. (April), 1994. The Top Management Steering Committee (parts I through IV). PMNETwork, vol. VIII, no. 3 (March) and no. 4 (April). ❑


John Schmidt is a senior consultant and project manager at Digital Equipment Corporation. John has over 18 years experience in applying information processing solutions to address business problems in a diverse range of application and industry areas including banking, education, oil and gas, government, forestry and manufacturing. He has managed dozens of projects, some involving cross-functinal teams from different organizations, with as many as 60 full time staff.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.

PMNETwork • September 1994



Related Content

  • PM Network

    Power to Change

    By Tayel, Jess Many organizations are undergoing (or will soon undergo) a business transformation program geared toward growth and creating a competitive advantage. When successful, these programs bring about a…

  • PM Network

    Time Change

    Less might be more when it comes to workweeks. Organizations that have abandoned the standard five-day, 40-hour-a-week template in favor of an abbreviated work schedule are touting higher…

  • PM Network

    Binding Authority

    There's no denying it: Change is constant. But there's fierce debate over who's best equipped to manage it: project managers or change managers. Some insist that project managers are the ideal…

  • PM Network

    Fast Forward

    Organizations and their teams will have to adapt—and quickly—if they want to maintain their competitive advantage, according to PMI's latest Pulse of the Profession®.

  • PM Network

    Serving Up Innovation

    By Fister Gale, Sarah McDonald's has a craving for change. Decades after it turned the restaurant industry upside down by scaling fast-food convenience, the organization is on a mission to transform the customer…