This article originally appeared on our sister site, TechRepublic.

Most managers who are reading this column have wrapped up their annual review process by now; in fact, you probably finished the paperwork about a month ago. You’ve reviewed the past year’s accomplishments, issued the appropriate annual raises, and set goals for the coming year.

In fact, you’re probably just about due to start on the truly meaningful part of the review cycle—following up with your team members to see how they are coming along with those goals.

In this column, I’ve constantly harped on the importance of making the annual review process more than an irksome formality that’s dreaded by everyone, manager and employee alike. And I always argue that the most important aspect of the review process is keeping employees’ formal goals up to date and relevant to the company’s changing objectives.

Before I just started repeating myself this year, I thought I’d get a little backup. So I sent an informal questionnaire to a list serve of developers, admins, and other IT pros who tolerate my eavesdropping and occasional brain-picking. The comments that ensued reflected general disappointment in the review process, and in particular with formal goals that seem to evaporate the first time a dev queue gets shuffled.

One veteran developer wrote: “I have never found reviews to be useful. I’ve always found setting goals to an OK practice, but unless you review them frequently (once a month) they always get out of date.”

Another veteran developer, who now works as a manager, wrote: “[Long-range] goal planning is usually a waste of time; the needs of the business change too frequently. If the kind of work you do is project-oriented, then your current project is your goal.”

Pretty bleak assessments, primarily because they are also pretty accurate in many shops. But the discussion also yielded this little pearl of wisdom:

“Why can’t you set some goals that are not project-related?”

That’s about the single-most lucid bit of advice I’ve ever heard about setting review goals.

As my manager colleague notes, the goals of any business—and particularly ones driven by high-end IT—are likely to change from quarter to quarter. If an employee’s goals are tied to the launch of an e-commerce portal that gets nixed because a business partnership goes under, how do you evaluate that employee’s success or failure in 12 months?

I’ve always tried to set goals that describe a role I want the employee to tackle in the coming year, or a skill I hope the team member can improve upon over the next six months or so. So, instead of citing a review goal as “Build user data-capture pages for a commerce portal,” cite the more extensible long-term goal, “Write data-capture pages in ASP.NET for a business process improvement project.”

The latter goal focuses on a skill that the employee probably needs to develop, and it’s not hitched to a specific project. If the e-commerce portal collapses, you’ll have plenty of other chances to cover this base.

Note that I’m assuming the employee in this scenario needs to learn or polish skills related to ASP.NET. If the developer already knows the language backward and forward, this goal loses relevance across projects. Which brings me to my second point about extensible review goals: They should focus on areas of professional growth or skill development, not on routine tasks that an employee has already mastered. That’s what job descriptions are for.

Based on these little nuggets of wisdom, take a second look at the goals you set for your employees and make at least a few adjustments, if needed, to meet some of these objectives:

Make sure each employee learns some new technical skill in the coming year. Whether it’s .NET or J2EE, there’s enough new stuff out there to find an opportunity. Each team member doesn’t necessarily have to use a new skill on a project—they can take an online course or run through a self-instruction manual.

Give each employee a goal that focuses on organizational and teamwork skills. Even your junior reports can take notes or help organize project status reports. In tough times, employers’ focus has shifted from raw technological skills to applied professionalism, so you’ll be doing your guys a favor by setting these kinds of expectations.

Involve your team members in a project review. Metrics are king these days, and involving your team members in a postmortem of some project will give them some much-needed business case insight.

There’s little chance that any of these three goals will be impossible to accomplish, even if every project on your current plate falls through. Just be sure to revisit these items at least once every quarter (once a month, as one of the list members suggested, is probably just a little too aggressive) to make sure that your employees are working toward something more than the current project deadline.