Deliverables by the Pound→

I did some freelance work once, as a sub-contractor to an agency, and joked that what I was hired to do was produce deliverables by the pound.

I never met the clients, had only the most rudimentary information about the larger context of the project, but had specific documents (content inventories and taxonomies, mostly) to create. The agency was happy with my work, presumably the documents I created were acceptable to the clients, and I got paid, but the experience was less than satisfying professionally.

Early on in my content strategy career, I created a set of questions when asked to create any project deliverables: 

1. Who is the audience?

2. What is the context into which this fits? and

3. What decisions are going to be made based on this?

Essentially, these address the users and context pieces of the content/context/users triangle. If I couldn't answer all three of those questions, I didn't start work until I knew.

Too often, we embark on a project with our set list of deliverables (particularly true in consulting environments), often put into a project plan by a project manager who may or may not know what purpose they serve, we create them, hand them off, and hope that they are useful to someone.

I am a firm believer in the value of the kinds of deliverables we create as content strategists—content inventories, audits, content matrices—but not every project requires every one of them and I know I'd rather spend my time adding extra value to the ones that will truly inform the recipients and help answer the critical questions involved in the creation of a great user experience. Definitely beats creating deliverables by the pound.

Lead, Follow, Or...→

So your company has decided to hire a consultant. Somewhere in your organization, the people with the power to make these decisions have recognized that you need help. You're probably taking on a big project--a redesign, a site replatforming, the implementation of a big new enterprise software package--and you either don't have the skill set in-house or need additional resources to make it happen. 

So now what? Now, you need to let the experts do what you hired them to do. Too often, between the time when the decision was made to bring in outside help and the actual arrival of the outside help, a feeling arises in the organization. A feeling that's maybe a little bit resentment ("Look at how much we're paying these people!") or a little bit defensiveness ("It may be a mess, but it's our mess"), but in any case, a feeling that can subtly pervade the project and over time undermine the working relationships between the in-house project team members and the consultants. 

It may be hard to accept that the consultants work a different way than you do ("But as an organization, we've embraced the X methodology") and maybe the deliverables are in a different format ("We always put that kind of document in Excel"), but stepping outside your comfort zone, taking a little leap of faith (after all, you did carefully vet this company before you hired them, right?), and opening up to shared learning will go a long way to helping ensure a successful project.

Consultant, Diplomat, Therapist→

Of all the skills a consultant brings to the table, sometimes the actual discipline for which you've been hired is the least important.

I have been a consultant, first in an agency, then on my own, for five years. In that time, I've worked in a number of companies, from non-profits to Fortune 100s. When a company brings in an agency or consultant, it's usually because they don't have the available resources or the skills in-house. What may surprise though, is how often that skill gap is not in technical skills or design skills or project management and delivery—or is not only in those, anyway—but in communication. Often I have been in the position of introducing one member of a company to another member of a company—literally being the liaison who makes the connections between organizationally separated (and sometimes even geographically separated) teams with common interests and need for shared outcomes but no organizational structure or incentives for collaboration.

Sometimes those distances are enforced by the virtual walls that silo different areas of an organization—IT from marketing is a typical example. Take a legacy of non-communication, add a failed project or two (refer back to that non-communication), and an ever-widening gap of mistrust opens up within the organization and the consultant ends up being the diplomat who helps the factions reach a successful resolution.

When one area of an organization feels under-represented at the table and is stuck working with outdated tools and processes, another important role a consultant can play is to simply listen. I have spent many hours with employees who are just grateful to have someone to describe their situation to and finally feel as though they've found a sympathetic ear. My job, of course, is not just to listen, but to document and plan and work with the other side as well as my consulting colleagues to create solutions that address not just the technical or procedural issues but the communication issues within their companies. When a client cries to see you leave at the end of a project, you know that consulting is as much about organizational psychology as it is about implementing new features, tools, or websites.