Keys to Setting Achievable Goals

Have you heard this story? A man loses his keys along a rainy, dark street. A police officer, happening upon the man crawling around underneath a streetlamp, offers to help. After a fruitless half hour, the frustrated deputy questions the man. "Where, exactly, were you when you noticed your keys were missing?"

"Over there," the man replies, pointing to a dark storefront down the block and across the street.

"Then why are you looking for them over here?" fumes the exasperated cop.

"The light's better here," replies the man.

Have you had this sort of experience when trying to achieve goals? I have. It seems silly that we find ourselves in either the role of the foolish man or the helpful cop, but I've seen this too often in software projects. How do we find ourselves in this dilemma as goal setters and goal achievers? Our conception of our goal is much more likely to be believable to ourselves than to others-and others' conceptions are naturally more believable to them. This article is about finding a common point of view that will increase a goal's achievability. Why?

• Believable goals are more achievable. 
• Achieving takes more than simply believing. (We will only find our keys under the lamppost if they are there.) 
• We make our goals less achievable when we don't share meaning.

Meaningless Goals
I remember a vice president confidently announcing, "We're going to produce bug-free software with this release of the system." How many of you have had someone else's meaningless goal foisted upon you as if it should be motivating? What was your reaction?

You may have felt embarrassed, as if you really should be motivated to achieve it. Perhaps you avoided all eye contact, counting the peas on your plate. If you're at all like me, embracing this meaningless target robbed you of some of the abilities you could have invested in achieving the goal. This sort of goal setting transforms milestones into millstones, and pilfers proficiency. It might be correct in form, but it's useless in application.

My primary qualification for writing this article is my experience with the damaging effects of meaningless objectives. To help you get beyond them, I want to do two things:

1. Remind you of the unavoidable chaos between you and your goals, and 
2. Share a way of looking at goals that might enhance your project community members' ability to conceive, believe, and (as a result) achieve them.

This story started last year when a colleague called me asking for my help. She and some associates had just finished one of those whirlwind off-site meetings in which they had helped several management teams define goals as a part of an enthusiastic balanced scorecard effort. Describing the resulting pile of goals, she reported that these teams had no experience in managing projects, and the effort to achieve these goals looked like project work to her. Since she knew me as a project management consultant, she thought that I might be able to help. I asked her to send me a sample of the goals, and these are a few of the ones on her list:

• Minimize reported problems 
• Maximize the efficiency of programming resources 
• Decrease error reports by 10%

I didn't really need to look at the goals to know they would be weak. All projects start with what I call a "Bright Idea." This one was starting with a flurry of them. A Bright Idea is the first approximation of a software project's real goal. They are, as a class, vacuous, shifty, and impossible to manage. Bright Ideas are the absolutely necessary