0

What’s the difference between a project and a goal? A more interesting example

7 months ago

In a previous article I defined “project” and “goal” in ways that make it easier for me to use a Getting Things Done system. I used an example, “build our own house”, that one of my course attendees asked about. Another attendee asked about an example he found a little more confusing: “learn Clojure“. This sounds like a project and a goal, so what should I consider “the goal” and what should I record in my Getting Things Done system?

I recommend applying the tests I described in the other article. How would I know that I had finished learning Clojure? Can I “finish” learning Clojure? I don’t think I can, so right away I wouldn’t consider “learn Clojure” as a project. I need to record something with a definite end and to which I could apply a clear test to determine whether I’d finished it. (Conditions of satisfaction or acceptance criteria, if you prefer.) I do eventually want to learn Clojure, and so I’d likely record a project like “Learn enough Clojure to demonstrate my Point of Sale example comfortably.” I refer here to the standard example I use in my programming training courses. While the phrase “comfortably” doesn’t exactly give rise to air-tight objective acceptance criteria, I think the average audience paying money to learn Clojure from me could agree whether I demonstrated Point of Sale in Clojure comfortably, although I could strive for more lax standards by targeting conference session attendees. Perhaps I should record the project as “Learn enough Clojure to demonstrate my Point of Sale example adequately for an XP2012 tutorial”. That makes it more concrete, defines an end, and session feedback will tell me whether I succeeded. So if I don’t classify “learn Clojure” as a project, then do I classify it as a goal?

One might learn Clojure for its own sake, in which case that person would consider learning Clojure a goal unto itself. If learning Clojure does not represent pure art for you, then ask “Why?” in some of the many ways that I described last time until you find your goal. I might choose the goal “Avoid becoming technically obsolete by learning Clojure”, or perhaps, “Develop my programming skills by learning Clojure”, or perhaps, “Understand better why everyone seems so obsessed by functional programming by learning Clojure”. As you can tell, goals vary wildly by person, by situation, and change over time. If I happen to win the lottery this weekend—you never know—then “Avoid becoming technically obsolete” suddenly becomes less urgent a goal.

So if you find yourself with a “to do” item that sounds vaguely like a goal and like a project, then try this:

  1. Ask yourself, “How would I know I’d achieved this goal?” Your answer will help you better define the item as a project.
  2. Ask yourself, “Why should I do this?” You answer will help you better define the goal behind the project.
  3. Don’t be surprised if the original item disappears entirely, replaced by a better-defined project and a clearer goal.

Isn’t this all just semantics, J. B.? Not to me. When I help my clients establish clear goals, many of their problems just start to disappear. When I help my clients gain better control over their projects, similarly many of their problems just start to disappear. I think that the clearer they understand their goals and define their projects, the more easily they can handle their work. Perhaps it will work for you.

Do you have any “to do” items that you have trouble writing down as projects or understanding as goals? I’ll help as much as I can.

This entry was posted in Free Your Mind to Do Great Work. Bookmark the permalink. -