Is It A Goal, or Is It A Wish?

By Christopher Hawkins •  Updated: 01/28/05 •  5 min read

In my self-appointed role as an effectiveness fanatic, I often ponder the process of setting goals for a project, or for my personal life.  Setting goals is tough.

“Wait a minute” you think.  “What’s tough about goal setting?  You state a desired outcome, and BAM!  You have your goal.  Right?”

Wrong.  If all you have is a stated outcome, you have a wish.  Not a goal.

Let’s think about this from (surprise!) a software development standpoint.  Suppose a client calls me up and asks for an application that will manage their bonus compensation process.  Since I’ve done that sort of work before, I could plop right down and put together a pretty handy application that does just that.  But will the application I put together be the same application the client saw in his head when he asked for it?  Probably not.  The reason is that simply stating that you want a bonus compensation management system does mean that getting a bonus compensation management system is a goal of yours.  At this point, it is simply a desire – a wish.

How do we move this client request closer to the realm of “goal” and farther from the realm of “wish?”  Well, for starters we can clarify the request – what exactly IS a bonus compensation management system, anyway?  Does it need to store stock grants?  Will it be storing full employee information about each person receiving bonuses, or just their SSNs?  Will it print checks, or will it need to export the financial data to Great Plains?  I can think of at least 100 questions that could be used to clarify the original request.  The problem with a client asking a developer for a “bonus compensation management system” is that it is not measurable – you have no mutually agreed-upon way to tell if you’ve built a management system for a bonus compensation process or a balloon ranch on Mars.  So the first step in having a goal is to make sure it is well-defined enough to be measurable.  In software terms, this would be a requirements document.

Now that we’ve got a measurable desired outcome, the next thing to do is figure out when it can/should be accomplished.  Features dictate dates.  Hopefully the process of clarifying things into measurable terms has provided sufficient detail to make an estimate – if not, more analysis can be done to determine a deadline.  If you’re working on one of those projects that was promised for delivery on x date before anybody even knew what they were actually building, then I feel for you.  I’ve been there and it’s not fun.  Luckily, this item is being written based on a “perfect world” assumption, and in a perfect world you could look at what is required of you first, THEN provide a realistic completion date.  So the next step toward a goal is a deadline.  How much time is needed to make your measurable stated outcome a reality?

Now it’s time to drill down a little deeper.  We know what we want to accomplish, and we know enough to set a realistic date for accomplishing it.  The final piece of the puzzle is to figure out how to pull it off.  What things need to happen – and in what order – in order to go from having what we have now to having what we want to have, within the set time frame?  In software terms, we need a project plan.  Part of this will be taken care of by the analysis done to make sure we can measure our relative success or failure – it’s nice to have that kind of overlap.  More work will need to be done to plot it all out like a project schedule.  Step 1:  Gnarfle the garthok.  Step 2: Foo the bar.  Step 3 . . . And so on.  What actions have to be taken to move us closer to the goal each day, arriving (more or less) precisely at our goal on (more or less) precisely the date we wanted to arrive there?

This is nothing groundbreaking, but it IS frequently overlooked.  Everyone states desires – in fact, we do it institutionally in the form of New Year Resolutions.  But to take your desire – whether it is to write a bonus management system or to lose 100 pounds – and turn it into a goal, it must:

Think about your projects.  Think about your life in general, for that matter.  Are you putting sufficient thought into things to make them concrete goals?  I can tell you from experience that wishes do not translate into good software, a slimmer waistline, more money, etc.  But goals do.

While you’re thinking about it, head over to and publicly commit to some resolutions for 2005.  Make them specific and give them dates!  😉