Central Perk: Planning for Success: Three Essential Consulting Project Plans

luni, 2 septembrie 2013

Planning for Success: Three Essential Consulting Project Plans

Posted: 01 Sep 2013 04:13 PM PDT

Being a consultant can be an intense experience. Every client (and every day!) presents a new challenge. In my experience that isn't a product of the ever-changing state of affairs in SEO or inbound marketing. In fact, I don't lose sleep over every algorithm changeâ€"there are plenty of smarter people from whom I can draw that sort of information.

What keeps me awake at night is how I can shape my projects to make them successful. A lot of people work together with me every day: my clients, my teammates, and teams in other offices. Everyone needs to collaborate to even have a shot at success. How will we pull that off? How will they communicate? What do they need to do this week? Next month? Next quarter?

In short, I focus on planning, and I focus on it in three specific scopes:

Pitching (how do we estimate project size in advance?)
Strategy (how do we know what we are going to do, and when?)
Execution (how do we ensure that these things actually get done?)

Three different tasks with three different plans, each with its own unique purpose. A list of tasks to execute is not a sales pitch any more than it is a high-level summary of the course of a project that helps you decide what to do today. Each of these plans must be treated differently, and with appropriate respect. The most important thing I've discovered as a consultant is this:

You can disagree about what's in a plan, but you must agree about what the plan is intended to accomplish.

Let me walk you through these three types of plans, what the purpose of each is, and what warning signs may crop up if something isn't going smoothly in each stage. I firmly believe that a little conscious effort can improve how we handle each of them, and tune our instincts to spot when something is going wrong. On the other hand, I won't go into techniques for how to create these plansâ€"at that point I'd be writing a book instead of a blog post.

I've definitely not mastered all of this yet, so if you have any lessons of your own to share in the comments I'd love to hear them! All of these planning phases interact with each other, and I can only talk about them from my point of view. In your experience the lines may be fuzzier or more defined. You may treat them very differently. Do share!

Pitching

Why do we have a plan at this stage?

To understand the scope of a project, that we are the right choice for the client, and that the client is the right choice for us.

What should this plan do?

Address the client's needs (as far as they are understood)
Reflect the limitations of what we can offer and what the client can execute
Get the right order of magnitude for project size

What should we watch out for?

Anyone talking about scheduling deadlines for deliverablesâ€""We need the keyword deliverable week one, the technical audit week twoâ€¦"

What I've noticed:

The first time we have to deal with a plan for a new client is when we're trying to convince them to work with us. Obviously we are asking someone to trust us to help them get a good return on their investment, and part of building that trust is to let them know what sort of work we are going to be doing. A good plan during the "pitch" phase helps us do that.

An example plan for a pitch from Distilled. Activities are scheduled chronologically left to right.

You can see from the illustration I've included that for a lot of projects this plan can be quite broad. Basically it amounts to a straightforward summary of what needs to happen and in what order. It's where everything begins, before the engagement has even started.

The other piece of data that is presented concurrently with the plan shown is a budget, which is essentially the size of the project or the proposed bandwidth that Distilled will dedicate to it. To know that a budget should be X dollars per month or that a contract should last for some amount of time seems quite amazing if you think about itâ€"so many variables are involved! But while every project is different, there are a lot of things we can estimate with a good degree of accuracy. The things we have a handle on might be different from yoursâ€"there might be areas where your estimation is a lot better than ours, or vice versa. Consider:

Weekly meetings
Project management (time spent scheduling)
Monthly reports
Some common research reports (this may vary wildly, but it helps to have an average we can point to)

These are all elements which can be used to anchor an estimate. There may also be some other administrative tasks or fixed price elements (tools, copy writing) that can be leveraged as well.

But it is ambiguous. The pitches you deal with might be more or less ambiguous than ours, but there is no possible way that a proposal created in the sales process can accurately reflect what will actually happen. No one can predict the future, and the sales process is too far removed from actual work to be treated as definitive when it comes to planning.

And that's what I watch out for. It's not uncommon for leads to demand that we offer them strict calendars for delivery of reports. It's one thing to build in regular meetings and status updatesâ€"those are great, at appropriate intervalsâ€"but if we are talking about rigorously scheduling deliverables like technical audits, or are devising a content strategy, there are too many variables present to know exactly when all that is going to happen. Demands in the sales process for the abstract to be made concrete should be handled very carefully in the sales process. The needs of the client must be addressed, but acquiescing to unreasonable scheduling is likely going to hurt your relationship with a client rather than help it. In other words:

A prospective client can disagree with what is included in the proposed project, but they can't insist on a level of detail that is inappropriate.

In my own experience, there have been a couple of clients in particular who needed help with website redesigns or complete domain migrations. One insisted on an extremely delineated schedule provided in the pitch, with arbitrary deadlines for various deliverables and a project duration which would coincide with the launch of a new site. The justifications for this (on the client's end) were both to get a better understanding of the work being done and to make sure that we would be around to monitor the site's launch. Needless to say, the site didn't launch on timeâ€"few websites ever do. And because of the strict language of our arrangement, we had no flexibility to adapt our strategy or extend the duration to accommodate. I didn't feel good about that outcome.

If I were put in the same position again, working with our sales team on the pitch for this project, would I take a hard line against this style of planning? It's hard to say. But I would be very aware of the potential risks, and at the very least make sure that there were contingencies in place if the scheduling of work turned out to be inappropriate.

Fortunately, we only have to deal with this sort of ambiguity once or twice in each projectâ€"once the engagement has begun, things become more tangible. Once the project has kicked off, we don't talk at such a general level. It's time to take charge, get more information, and figure out how to make things happen. It's time for proper strategy.

Strategy

Why do we have a plan at this stage?

To figure out what work should be done and when it should be done.

What should this plan do?

Prioritize work
Defer work that can't be done within time constraints

What should we watch out for?

Big chunks of time that don't have any tasks assigned to them
Too many tasks to accomplish in the time available

What I've noticed:

Once a client has retained our services we need to figure out what we're going to do. Consider: there are a tremendous number of constraints on the work we commit to doing every day. We have a finite number of working hours in a day, week, or month. We may be dependent upon other projects finishing in a timely mannerâ€"will the client's website launch in time? Will the team working on the content finish?

In the face of that uncertainty we still manage to accomplish something. We just have to limit the scope of what we do. Estimate the amount of time various elements of the projects will take, decide what will fit into this month, and commit to executing them. It's that commitment and specificity that distinguishes this phase from the sales pitch phase. And that's why we can't start thinking at this level before we've engaged a clientâ€"we need more information from them, we need their commitment to a project, and we need to know as much as possible about our own bandwidth in a given month.

A screenshot of Distilled's internal scheduling system. The "size" of tasks is defined by how many hours they are anticipated to take. These tasks are kept fairly broad: project management, weekly meetings, etc.

This plan is the response to those needs. We know we need to do keyword research, a technical audit, and Analytics implementationâ€"how long will each take, approximately? Which will we do this month? Which have to wait for information from the client? We answer these to the best of our ability and that becomes our roadmap.

The facts and the constraints that become apparent also become the boundaries of what we can sensibly plan. It's in this boundary that I've noticed most problems crop up. Some clients will present a barrage of questions that threatens to undermine the rest of the scheduled work you're trying to do. In the worst cases, results might be demanded when what you're trying to prioritize is which work should be done. So let's adjust the axiom above for the "strategy" phase:

A client can adjust the priorities of elements within this strategy, but they can't insist that you do more work than there are hours available.

Unless they give you a bunch of money. Just kidding. Sort of.

Consider the alternative to using this sort of strategic scheduling: Every month that a client has you on retainer, you just do whatever they ask until you use up the budget in week two and just stop for the rest of the month. Or you keep working and effectively cut your hourly rate in half. Neither of these solutions sound great, do they?

It took a while for me to get the hang of this "strategy" stuff. Early on in my tenure at Distilled, this manifested in projects that were extremely productive early on. There were tons of technical things to fixâ€"so much low hanging fruit that we at Distilled seemed like miracle workers. No strategy needed, pure actionâ€"for a couple of months. But once that stuff dried up, the relationships sputtered out. I was so enthusiastic about those quick wins that I didn't establish a rapport with the client. I didn't figure out how to work together with them to make their business better. I just told them what to do.

Talking about strategy gave me a language I could speak with my clients that helped improve our relationship and has been much more effective in the long run.

Eventually, you'll work out a sequence of work that fits your schedule and addresses the needs of the client. Once you get to that point, you need to figure out how to execute the work.

Execution

Why do we have a plan at this stage?

To figure out how we're going to do the work that needs to get done.

What should this plan do?

Lay out exactly what actions need to be taken
Let everyone know who is accountable

What should we watch out for?

Tasks that aren't well-defined
Tasks that are defined by outcomes (e.g "get 10 links")

What I've noticed:

At this point we're finally we're dealing with something that actually looks like a proper scheduleâ€"a real to-do list. Tasks need to be chunked into pieces that are clearly delineated and actionable. The image below actually reflects a list of tasks for one of my clients.

An activity schedule in Google spreadsheet form from one of my projects.

The biggest problem that I've observed in working with clients in "execution" mode â€"one that consultants often bring upon themselvesâ€"is the tendency to create tasks that aren't well-defined. For instance, if I have "keyword research report" as a line item in my to-do list, I know I'm doing it wrong. Get more specific: Pull data from Searchmetrics, the Google Keyword tool, and Analytics; do analysis in Excel; and so forth.

On the other hand, the issue that has arisen through my interaction with clients is not recognizing when something is being put in this "to-do" list that is outside the scope of what we laid out in the strategy. Once you know what you are doing in a given month, and you have broken that down into individual tasks, you have to be careful about committing to other things. It's very common to field random questions from a point of contact or their teammates, and it is usually best for the relationship for you to answer them. In order to do that, it is smart to schedule extra time for this kind of ad hoc support questionâ€"and if you starting going over that time you should be seriously concerned. To wit:

A client can negotiate the tasks in this schedule to complete the work you're setting out to do, but they can't add unrelated elements (i.e. change the strategy).

There are as many methods of keeping track of to-do lists as there are people doing to dos. How you actually accomplish these tasks is up to youâ€"I prefer OmniFocus, while I know some at Moz have a bit of an Asana obsession. The important thing as that at some point, in order to go from a "strategy" phase to actually accomplishing something, you have to come up with a list of actions.

I know I've talked a lot about high-level planning in the "pitch" and "strategy" phases, but I should note that at the end of the day, getting better at scheduling the actual work is the most important element of the process. You can meditate all day on the structure of a perfect project, but unless you actually do something there is no chance for success. I consider it the Minimum Viable Plan, so to speak.

Review

Planning isn't easy, but it gets better with practice. And that will, in turn, have a positive effect on all the projects you work on. Let me say it once again:

You can disagree about what's in a plan, but you must agree about what the plan is intended to accomplish.

This rule is something I intuitively use more and more when planning a project and when issues arise over the course of a project. Once you start thinking about these things in increasingly conscious ways, their value becomes exponentially more obvious in ways you can't anticipate.

Do you think about projects in these three phases? If so, what are the warning signs that you've spotted in your experiences?

Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don't have time to hunt down but want to read!