GOOOOAAAAAALLLLLLLL!!!!!!

Let's talk about the process for setting up goals for your team. In this context, a goal is a statement of some work to be performed. Examples of goals might be to change a process, get a project completed according to some basic parameters, or perform a reorganization.

Commitment to those goals is the key factor to success. Sure, you can impose them on your folks if you wish. As Captain Ramius told his staff in The Hunt for Red October, “When he reached the new world, Cortez burned his ships. As a result, his men were well motivated.” Throwing a commitment like that to your team is a guaranteed failure. But probably a better way to handle things is to talk to your staff about the goals.  It is critical that the team determine what they are able to do, and then commit that back to you.

But what should a goal look like? Answer: unless absolutely necessary, write goals around projects, not processes.

In general, goals created for the completion of projects will be the most useful, allowing other changes to happen as needed in support of that objective. For instance, you may write two different goals, one for a project, and one to overhaul some process in some way. However, you might find that the two goals are in conflict with each other. What if the project team determines that the most efficient way of completing the project is to leave that particular process alone or change it some other way than you specified? The overall project is what’s key, so leaving more options to the team for dealing with their own processes and tools is much preferred.

How specific should the goals be? Answer: keep them general!

So, we want to create this year’s goals. We know the big projects we’ll be working on, but we don’t know the exact requirements, much less have any estimates for how long the work will actually take. Doesn’t matter. Especially if you work in an environment where the requirements can continually change during the project execution, you’ll never have them done.

I have seen so many goals written with such specificity that they never get met. Once the project is underway, somebody will change something than diverges from the overly-specific project goal. What do you do now? Rewrite everyone’s goal sheets to match? I’m sure you can imagine the hassle in dealing with that every time a change occurs. You could leave them alone, but now your people are working towards goals that are wrong. Is that better than simply not having goals anyway?

So maybe you just periodically review goals to see if they still reflect reality. How often? Monthly? Weekly? Hourly? What a waste of time! When you write your goals, don’t sweat the small stuff! Cover the basics, and leave the specifics out. Written properly, goals should clarify the intent and major parameters of the project. The unwritten details will be filled in as the project progresses. That doesn’t make them “bad” goals, it makes them “realistic” ones.

Take this example:

“Complete version 3 of the XXXX product, with major business value features included, no later than end of 3rd quarter, requiring no major corrections by the end of the year.”

Yes, that’s written fairly loosely – we don’t know what the “major business value features” are yet. Even if we did, you might change one or more of them before the project is actually completed – maybe adjusting for customer demand, and hopefully an accompanying increase in revenue. We don’t want to impede change simply because the goals were written too strictly. And we don’t want to have to go rewrite them, either.

How hard should the goals be to achieve? Answer: a good chance of success

Nothing will destroy motivation faster than a task that is simply impossible. You have to stay within “reasonable” parameters. Folks need to see the job as having a good chance of success. Sure, you need to press a little on some goals and make a small number of them very challenging. Despite sometimes thinking so, we are not omniscient. Just because we don’t know how to accomplish something, doesn’t mean that nobody knows. Entrepreneurial leaders are the kings of this technique. “I need this completely new product developed in 2 weeks.” You, personally, might not think it’s doable in that timeframe, but maybe you’re wrong. Maybe some creative guy can dream up a totally new way to get across the finish line in world-record time. Maybe, for him, it’s actually old hat, and that 2 weeks is twice as much time as he needs.

Just remember that because you think something is impossible doesn’t necessarily make it so. I’m not advocating impossible goals, but it’s OK to give the team a challenge. They will press back as much as they need to until you can all find a happy medium.

Objective or subjective goals? Answer: Mostly objective

Don’t fall into the trap of creating goals that are only subjectively measured. As much as possible, all milestones need to be absolutely demonstrable. You can either see it, or you can’t. Period. A goal like, “Be 50% complete with development” is a farce. There are so many ways of measuring “completeness,” and so many different opinions, you’ll never get anyone to agree. And that usually means that the goal will be completed “by default,” because you won’t want to spoil someone’s day with a failing grade. Keep it objective so that anyone can make the call. Demonstrable goals and milestones drive real performance and progress.

And don’t give credit for anything less than 100% completion. The goal didn’t say “almost”, it said “done”. As soon as you say “good enough” on 99%, or 95%, soon they’ll be expecting it on 90% or even lower. Stick to the goal.

How do I write all these goals for so many different people? Answer: DON'T!!!

Create YOUR OWN goals first. Do this in consultation with your teams to know what's reasonable. Once you have created your list of major goals for the year, they should be adopted downward throughout your organization. In this way, the goals for each of your own managers and for their people will all directly support your own goals. Each worker who has responsibility for any portion of one of the top goals should have that goal transcribed onto his own goals for the year – verbatim. That means that his goal will be the same as everyone else’s contributing to that project.

He will, of course, have a particular area of expertise. But, if something falls a little outside his direct area, having the more generic goal will entice him to help out. The message you are sending him is that just being successful at his own job isn’t enough. The project must succeed. He needs to do whatever is necessary to make that happen, and everyone wins or loses as a team.

On that note, if you have your own direct management team, you can send an even stronger message to them. They should each have every one of your goals as one of their own, even if their particular team is not involved in one of those goals. This will force them to play together better, help out whenever they can, and generally not play politics with their people or other resources.

Again, they all win or lose together. If you have the ability, you can adjust the relative weights of the goals to compensate for those items they truly have within their scope of control. Just don’t take any of them all the way down to 0%.

Setting goals can be a dumb, useless, exercise in irrelevance, or they can be useful. You pick.