OK We’ll be honest. As consultants we often fall in love with the constructs and solutions we derive on your behalf. We will explain the beauty of our solution in intricate detail to anyone who will listen (and many that don’t want to be listening!) Generally, in order to get paid, we transcribe these solutions into large complex written reports (we’ve all heard the jokes about “paid by the pound”). Most of the time these documents end up sitting on a shelf collecting dust. No one ever reads them. The results are never used.

From a consultant’s perspective it’s much easier to write a long complicated document than a concise one. Simplicity is hard. But by providing clear, concise, and short reports we’ve found the odds of adopting and implementing the results of a consultants work significantly improve. It’s a sign your consultant really understands the material they are presenting (it’s easy to hide flaws in a big complex document) and you are getting a well thought out solution. Further, a report written clearly and concisely can be shared with broad audiences without a lot of accompanying explanation.

The take away here is pretty simple. Sit down with your consultant and discuss your expectations for written reports. Think about who will be reading the report. Will it be the Governor, legislature, governing council members, senior or mid level agency executives? Will they read a 300-page document? Doubtful. Simple and concise will win the day here.

Should every report be simple and short? Of course not. System requirements or design documents will tend to be long and fairly complex (though they should be as clear and concise as possible). But a greater level of detail is expected by and required for the audience of these types of documents.

This is part of a series of articles designed to help clients and their consultants have more effective and efficient engagements.

No one likes to show off their warts. However, on a project, it’s critical to get the warts on the table so they can be managed. Take time before your consultant starts a project and think about all the factors that might be a barrier to the success of the project. Write these down and share them with the consultant as soon as they come on board. Together you can identify how you’ll deal with these barriers.

How do you define “barriers?”. Barriers are anything that could impact the scope, cause the schedule to change, effect resources, or impact the successful outcome of the project. To spur your thoughts on barriers here are some questions you might ask yourself:

• Do we clearly know all individuals or groups that have an interest in the outcome of the project?
• Do we know the “scope” of the project?
• Are there any individuals or groups that are problematic (unsupportive)?;
• Are we communicating adequately with everyone?
• Is the schedule realistic (or do you know)?
• Do we clearly know what defines “done” on the project?
• Are there funding issues?
• Is the project organization clearly defined?
• Are project team roles and responsibilities clearly defined?

Most people know the top barriers facing their project but often feel awkward about discussing them – particularly with a consultant new to the project. Likewise your consultant may notice things that they are reluctant to bring up (being the new kid on the block). But doing so (discussing the barriers) will open up the relationship with your consultant and allow you to mutually identify solutions. This, while not eliminating the warts, allows you to manage them.

If you only take away one piece of advice from our Client Survival Guide make it this: make sure you are communicating regularly with your consultant. If you feel you aren’t, STOP your project and call the consultant in for a face to face meeting to discuss how and when you’re going to meet face to face in the future. After having conducted hundreds of project post-mortems we can tell you the single thing most often responsible for a project failing is lack of communications between client and consultant.

We’re not talking about written communication (emails, status reports, consulting deliverables etc) but face to face interaction that occurs in both formal (status meetings) and informal (water cooler talk) settings.

Formal (in person) status meetings should occur regularly and always include discussions of:

• Project risks and issues;
• Status;
• Resources;
• Scope;
• Mutual expectations; and
• Consultant performance.

Informal communication should occur more frequently. We’re not necessarily talking about an hour long conversation. A 5 minute clarification (“hey I was thinking about this…what do you think”) can suffice. Informal talks serve to strengthen the relationship with your consultant, establish an atmosphere of trust, set an expectation that regular informal communication will occur, and provide minor course corrections that keep the project on track with your expectations. You can hold informal conversation via telephone (or video conference) too but these are not always a substitute for face to face conversations.

How frequently should you meet? Well that depends on the size and pace of your project. With very large projects where things move very fast (e.g. IV&V on a Medicaid system during the testing phase) formal status meetings should occur weekly and two to five informal contacts per day. On smaller project spread out over time (e.g. executive coaching projects) perhaps a monthly status meeting is sufficient and expect a few informal contacts a week. There’s no hard and fast rule except you, as the client, should never feel out of the loop regarding your project.

Don’t ever be afraid to “bother” your consultant with requests to talk. You should have several ways to contact them and know when the next formal meeting will be (if you don’t time to call them in).

Good consultants want lots of communication with you because they know it helps make a project successful. They will hound you for time. If you have a consultant that doesn’t want to meet or you find communication occurs only at your repeated request, honestly, you’ve hired the wrong people – throw them out.

This is part of a series of articles designed to help clients and their consultants have more effective and efficient engagements.

Consulting engagements that don’t end (that is, they don’t have clearly defined end criteria) are not consulting engagements but on going operations. Consultants that don’t have a clear end to their project are employees not consultants.

Having a set of criteria that defines when your consultant’s work is done is crucial to a successful project. It helps provide you with a sense of progress against plan, assess the performance of your consultant, and offers the psychological relief that you will indeed one day have accomplished something in collaboration with your consultant.

What should mark the end? We can think of at least 4 kinds of criteria that are used to define the “end” of a project. Three for successful projects and one for unsuccessful projects:

• The project end might be tied to a certain date. An example of this type of project is the year 2000 enhancements that had to happen to many computer systems. All work had to be completed by December 31, 1999. Projects with date certain endings do exist but are less common (and beneficial to you) than you might think. Typically having a specific end date benefits consultants more than clients. I’m sorry to say consultants will focus on getting whatever they need to get done to get paid rather than results that benefit you. Quality can suffer.
• The end might be based on the consultant completing some set of “deliverables” (end products). This might be a report or study of some kind, a computer system, or a building. This is some product resulting from the the consulting engagement that you can see, listen to, or touch. Typically you are the judge of quality on this deliverable and approve that it meets your needs. While better than a date certain project, deliverables based projects may have downsides as well. Consultants can get so focused completing deliverables that they ignore your needs and expectations. In some cases (constructing a road for example) this probably doesn’t matter. In other cases (assessing if you have adequate staff to do your work) it does. Overall the burden is placed on you, the client, to assess if the quality of end results meets your expectations.
• There is also a performance based end to projects. More specifically, the project ends when something measurable and agreed upon is accomplished (claims back log decreases by 10% or toll road revenues rise by $100,000). This is generally the most beneficial to you as a client because it defines the end in terms of benefits you want to see. However this is often difficult to operationalize (for example how do you measure a study of the use of WIC funds in your state?).
• Unsuccessful projects end because you or your consultant come to the conclusion the work cannot be finished by a certain date, deliverables of acceptable quality cannot be produced, or one or more performance measures cannot be met. This is obviously not optimal. I’ll mention there’s a version of this that isn’t necessarily “unsuccessful”, a project ends because the original purpose of the project no longer exists (e.g. on a personnel review the individual under review quits).

Successful end criteria can be combined as well. For example a certain report (deliverable of acceptable quality) must be completed by the beginning of the legislative session (a certain date).

Do you know when your project is over? If not sit down with your consultant and hammer out the criteria that defines the end of your project. You and your project will be better off for the effort.

This is part of a series of articles designed to help clients and their consultants have more effective and efficient engagements.

A simple fact: you need someone to manage consultants to get your money’s worth out of them.  We have seen, and been in, situations where no one was in charge of consultants.  These projects were chaotic from both the perspective of the consultant and the client – and clients didn’t get much value out of their hired consultants.  Some consultants will even take advantage of this situation.  They unilaterally expand the scope of their work and run up excessive bills.  In most cases unmanaged consultants leave clients with a bad feeling about consultants and consultants with a bad reputation.

It significantly benefits both client and consultant if a single individual, from the client, is responsible for overseeing the consultant.  Typically this “client manager”:

• Gets regular status updates from the consultant;
• Coordinates the consultant activities within the client organization;
• Ensure any products the consultant delivers meets agreed upon timeframes, standards, and need;
• Communicates relevant information to the consultant and within the client organization;
• Handles any issues and problems that occur during the consulting engagement;
• Reviews and approves consultant invoices and manages financial issues;
• Handles contractual issues (or takes issues to the contract manager); and
• Fires the consultant if they are not performing.

Who this individual is depends on the nature of the engagement.  Sensitive organizational assessments or reorganization projects might report to the head of HR or the agency director.  On our QA projects we typically report to the project sponsor.  For coding projects it makes sense to have your consultants report to the development or project manager.  One way to think about this is to think about who will pay the price if the consultant (or project) fails – that is the person that should be in charge of the consultant.

Some common mistakes we see in setting up a client manager include:

• The client manager is him/herself a consultant rather than an agency employee;
• Consultants report to a “committee” of some kind (we’ve found this has the same result as having no one in charge); and
• The client manager is a low level staff person with little or nothing riding on the engagement outcome.

So the question for you is who is in charge of the consultants around your organization?

This is part of a series of articles designed to help clients and their consultants have more effective and efficient engagements.