The "Consulting" Contract

A Primer for Consultants
Knowledge Workers

Are you a consultant? You just might be, even if you have never thought of yourself that way. You may be a consultant even if you do all your work inside the boundaries of your employer’s company. And if you are a consultant, you might want to think about having a consulting contract with your clients, even if it contains nothing about the exchange of money, is not formally signed, and has no legal ramifications whatever.

Curious? Well, let’s unpack the role of a typical IT knowledge worker within a familiar system development scenario, then follow the action as work begins. Along the way, we will examine the elements of contracting with clients (whether internal or external) and the importance of beginning an engagement with a designed relationship. Our goal is to create stellar results for the client while working in a manner that adheres to our values and preferences - for example, preferring to have a balanced work life and a highly collaborative work environment, or for technical excellence and achievement.

The Story

Our knowledge worker, Hans, works with a software development team. Hans’ team is slated to build a computerized system for the Research business unit of Applied Genetics. Whether Hans works for Applied Genetics or not (we’ll leave that ambiguous since it is not central), he does not work within the Research group. From the point of view of someone in that business unit, Hans thus brings in “foreign” or outside expertise, is not well-versed in Research’s social norms, is not directly subject to Research’s job expectations or managers, and is therefore a "consultant".

As his team begins work for Research, Hans hopes to create a clear agreement--a ‘designed relationship’ if you will--with clear expectations of what each party expects from the work, what each will provide (their shared responsibility), how they will engage with each other, and how their shared work culture will operate. Hans is going to partner with his teammates and client to create a Designed Partnership Contract.
 

What is a Designed Partnership Contract?

In order to understand this new term, let’s break it apart. First, we have the concept of a Designed Partnership Alliance (DPA). The DPA comes from the new field of relationship systems coaching¹. A Designed Partnership Alliance is the first step in creating a really good relationship - what the Center for Right Relationship² calls a "conscious intentional relationship" - between two or more partners, or within a team. To begin, the partners/team discuss how they want the relationship to be - the "climate" of the relationship. For instance a team might want their partnership with each other to have open communication, to provide honest but constructive feedback, and to be intellectually challenging. Another team might want to work very hard but also have time for fun and celebration of their successes. When it comes to the inevitable conflicts, the team might envision holding each other first and foremost as decent human beings, worthy of respect. This will aid them in moving rapidly to resolution of conflicts without resorting to blame or personal criticism. The DPA embodies the team members' values and preferences for being in relationship, both individually and collectively as a team. Some software teams do this by listing Team Norms when they start a project.

The second concept - the "consulting contract" - comes from Peter Block and his book Flawless Consulting³. The consulting contract is first and foremost meant to be a social contract, providing “explicit agreement of what the consultant and client expect from each other and how they are going to work together.”

Block identifies contracting as one of the major phases of a consulting engagement, the point where the consultant has maximal leverage (if you’ve tried to negotiate these factors after work begins, you know it is often highly frustrating and potentially ineffectual). Coming to a clear agreement between all parties will maximize the likelihood of a successful working relationship. Engaging in this type of contracting is rarely done when engaging for internal work and is often not done - or not done completely - when engaging in external work. In the latter case, the contract is often merely a legal document focused on money and deliverables and handled by contracting experts, not face to face between consultant and client.

Integrating the Designed Partnership Alliance⁴ approach supercharges the contracting process to create a synergistic, highly positive work ‘atmosphere.’ The resulting Designed Partnership Contract offers numerous benefits: it solidifies an environment of high positivity for the working relationship, it anticipates (and even may inoculate against) typical problems that occur when working with others, and explicitly defines the who, what, where, when and why of the engagement. Let’s see how the Designed Partnership Contract is developed between Hans’ team and its client.

Designing the Engagement

The Vice President of Research, Maryellen, had agreed with Hans’ boss that work should begin on the Research Tracking System (RTS) as soon as possible. Hans had been asked to phone Maryellen and set up a meeting. Hans was on his way, having asked two other members of the team to join him: a developer and a tester.

Maryellen began the meeting by emphasizing how crucial the RTS was to Applied Genetics’ competitive positioning, as shown recently when Applied Genetics stumbled because executives did not know precisely which products they had in the research pipeline. Setting the right tone and positioning from the start, Hans offered a genuine thank you to Maryellen for the opportunity to help out the Research group.

“Before we go too far, we’d like to spend a few minutes getting to know you better and talking about some agreements for working together. Is that OK with you?" Hans was beginning his work of Designing the Partnership Alliance by gaining consensus before proceeding, already modeling the collaboration-based approach the team preferred.

After gaining agreement, he proceeded. “We’d like to understand how you prefer working with teams, your values around collaboration and reporting relationships, that sort of thing. We also want to share what has worked well for us as a team when serving our clients.”

Twenty minutes later, the group had agreed on several points regarding open sharing of concerns, maintaining a collaborative spirit, and honoring a work-life balance. The team knew that such “fair words” were easy enough to agree to in the relatively stress-free atmosphere before the project had actually begun. So they tested the agreements with some hard examples: what happens, they asked, when the project is running late and Maryellen is under pressure from the business? What happens to work-life balance then? This provoked a sometimes heated debate about relative priorities and what truly was best for one’s family in the long run (time off vs. maturing stock options!) Another example concerned the possibility of code quality and time-to-market coming into conflict near the release date? Or what if the Research business unit’s needs seemed to contradict the architectural standards of Applied Genetics?

These discussions got the group to add an additional agreement: when conflict came up, they would regard each other with respect both as persons and as professionals. This principle had emerged in real time during the discussion. (Hans could have suggested this one up front, but he had learned that presenting a canned list usually short-circuited the team and kept each new client from discovering what was really important to them.) A brief moment of mutual anxiety during the debate gave way to deeper mutual regard and respect following some positive words from the developer. Hans felt good, believing that they were forging a real partnership. They were now ready to move into the Contracting portion of the work.

Contract Elements

Similar to legal contracts, a consulting contract addresses two major items: mutual consent and consideration. Consent means that both parties (or all three or four parties, depending on the situation) must enter into the agreement freely. As a knowledge worker consultant, you may have been in the position of feeling coerced by organizational expectations (or economic concerns, if you are external) to take whatever is given you in the way of projects, and under whatever terms suit the client. This negotiating the Contract phase from a “bent over” position, as Block quips, teaches the client that you work in a bent over position! “Negotiating” from this position contaminates the contract (and the engagement) from the outset!

At the other extreme, we have all seen people who militantly defend their approach - even against paying clients with understandable, often fairly reasonable, needs - based on a quasi-religious methodological position. Skillful disagreement without being disagreeable is a skill worth learning for the knowledge worker consultant. Generally, most situations lend themselves to quietly but assertively taking issue with a colleague or client while still conveying respect for their position, and your own, as we will see below.

The other element of a contract is consideration: both (or all three/four) parties need to receive something of value. For the client, this is obviously the services the consultant is offering, but might be other things as well. For consultants, this clearly includes money, but also what Block calls “other needs and wants.” For instance, it may be important to you as the consultant to feel a sense of professional integrity through being allowed to make an honest reporting of progress rather than according to organizational expectations, or to maximize the likelihood of success by full participation of the client group, or to have your work valued by - and shown to - upper management. To see these principles in action, let’s watch.

Getting Real

Back in the Research conference room, the group is discussing the overall scope of the project and who will be involved from Maryellen’s group. The tester, Joseph, asks who the team’s main client contact will be. Maryellen lets them know that a research analyst named Charlie will fill this role. “But don’t take too much of his time. He’s on a key project with a 'can’t move' deadline right now.”

There was a tense pause. Hans knew he would need to interrupt this discussion before it went much further. “Maryellen, we agreed we would openly share concerns as they came up, right? Well, to be honest, I wasn’t expecting to be in this position so soon in the project, but I need to raise an issue about the availability of Charlie. What I hear from you is that Charlie is working on a critical project and can’t be interrupted. I understand that and don’t want to interfere with his priorities.

“At the same time, our team has found that our work with clients does not go well without a primary client contact who is dedicated at least half time to the development work and can be reached virtually whenever the team has a question. It’s best if they actually sit with the team at least some portion of each day. I am wondering if someone else fits that bill, or if Charlie’s priorities could perhaps be shifted before we get started?”

Hans is leveraging an agreement from the designed alliance concerning open communication. Rather than taking the easy course and letting the issue fester, Hans acts on the agreements they have just made. In the process, Hans likely has to master his own anxiety when the client states an expectation that violates his own team’s expectations and agreements of working only with dedicated clients. He begins by acknowledging that he heard Maryellen’s priorities. This conveys a sense of respect and careful listening. Hans does not deliver ultimatums or veiled threats (such as, “I don’t know if that will really work,” without further clarification). Instead, he firmly states his own (and the team’s) position and looks for different possible solutions in a spirit of collaboration. He has disagreed without being disagreeable.

“Oh my gosh, I wasn’t expecting our group would have to spend this much time on the project,” Maryellen sighs with exasperation. Again, Hans controls his knee jerk reaction to throw up his hands, saying instead: “I understand your concern. How can we resolve this issue in the interests of both our groups? How about we give you a chance to think about it further and talk to your staff. When you have figured the appropriate person, we will want to meet with you and that person to update our common understanding and agreements.”

Hans is engaging in a 'soft startup' to conflict by first acknowledging the difficulty without reacting negatively, neither caving in nor pushing forward in a harsh manner. Then he offers Maryellen an out—recess and regroup regarding her expectations. Finally, he expands the contract to include another party to it, the primary client contact. This is the beginning of a three-way consulting contract. Hans knows what Block states, “you can’t contract with someone who is out of the room.” This point is easily stepped over in larger organizations, where managers assume they can make detailed commitments for their subordinates. This is rarely how the real world works, however, and such agreements do not pan out.

Maryellen agrees to discuss the situation with Charlie and her staff and get back with Hans the following week. At this point, the developer, Sara, begins a new line of questions relating to scope, especially whether user documentation is in or out. The team also asks whether anyone in Research needs to be mentored in some of the systems or process engineering disciplines (a Roles question), and how often the team can meet with Maryellen as RTS sponsor to get her feedback.

“Before we end, I want to make a final request. Assuming you think the project is as big a success as we believe it will be, would you would be willing to write a recommendation for our work?” This was Hans’ final consultant "want". Maryellen smiled. “Assuming I do, you bet I will!”

Following the meeting, Hans writes a brief email outlining what had been discussed, what agreements had been made and what the team understood about scope, deliverables, roles and success criteria. By reducing the agreements to writing, Hans must be very clear, both with himself and with his client. He ends the email with an invitation to Maryellen to correct any misunderstandings he and the team have. In this case, Hans does not need to ask for a signature on the "contract," though he does expect a return acknowledgement of the email and will follow-up if he does not receive this within a few days. By putting their agreements in writing and inviting comment back, a powerful bond has been formed. Hans has successfully completed the Contracting phase with Maryellen, knowing that when the client will be officially named, he or she will still have to be brought up to speed, and Hans will need to see if any additional agreements need to be made.

A summary of steps

1. Clearly acknowledge that you have been asked to help
2. Together, design the Team/Partnership Alliance - work atmosphere, dealing with conflict, etc.
3. Ensure that all parties offer their consent
4. Clarify client wants and offers, negotiate as necessary
5. Clarify consultant wants and offers, negotiate as necessary
6. Adjourn if stuck, and reconvene after some time and/or further research and/or new agreements or terms
7. Summarize agreements for all parties

Conclusion

Many knowledge workers, whether working internally for their employer or externally for a client, act in the role of consultant. As such, forming a Designed Partnership Contract with their client can create great relationships and great results.

A few key takeaways are:

• The Contract phase is the highest leverage time to negotiate how the work will unfold
• Designing together how you want a partnering relationship to go can help make good relationships turn into great ones
• Watch out for multiparty contracts. You cannot contract with someone who is not in the room.
• The knowledge-worker consultant has a right to have wants and to make requests, just as the client does
• Learn how to disagree while conveying respect for all positions: carefully tread the razor’s edge between attacking and retreating, holding the tension of honoring the other person’s position and its validity (at least for them), as well as your own.

Notes

 

About the Author

Michael Spayd is a coach and advisor who works with partnerships, teams and organizations to help them maximize their results within a high positivity/high fulfillment environment. He frequently works in large-scale enterprise transformation efforts, helping leaders and change agents understand the process of change and their role in it. Michael is trained as a relationship systems coach, a Co-Active individual coach, and is a Certified Professional Facilitator and a Certified Scrum Master. He is President & Chief Sage of Collective Edge Consulting, llc (www.collective-edge.com) and can be contacted at michael@Collective-Edge.com.