Leading next-generation IT is about more than choosing the best technologies and methodologies. It's also about management. And if you think overhyped technologies can do some damage, they have nothing on overhyped management advice.
So allow me to introduce a new, occasional Advice Line topic: management fads I hate. First up are SMART goals, which as it turns out aren't all that smart.
[ Find out the 10 business skills every IT pro must master, beware the 9 warning signs of bad IT architecture, and steer clear of the 12 "best practices" IT should avoid at all costs. | For more of Bob Lewis' continuing IT management wisdom, check out his Advice Line newsletter. ]
According to someone (Peter Drucker is often blamed), SMART stands for "specific, measurable, attainable, relevant, and timely." Or it stands for various other, more or less similar things; there is no SMART standards body with a SMART goal of standardizing the SMART acronym.
That's OK, because whatever it's supposed to mean, it ignores both a core principle of business measurement and one of the most basic skills every first-time manager who wants to become a second-time manager quickly learns: the art of giving lip service.
The good: Where SMART gets it right
I ought to like SMART. It has properties that make it a lovely antidote to another popular management fad that will have to wait its turn to get attention in this space -- the notion that preserving ambiguity is a good idea.
Specifically, SMART goals have to be specific, which is a very good property for goals. If the nature of a goal isn't clear, whoever is supposed to achieve it won't know what "achieve it" looks like. Score one for SMART.
Attainable is a useful property as well, although it risks confusing goals with targets. In case the distinction isn't clear, goals are qualitative; targets are quantitative. For example, in a software development environment you might establish a goal of reducing the number of bugs that are passed along by developers to the testing team. That's measurable (we'll get to that) but qualitative. Setting a target -- cutting the bug count in half -- is quantitative.
There are, in some situations, advantages to setting targets. For example, targets help keep the jailhouse lawyers at bay ("We made it! We cut the bug count by 0.02 percent!").
But targets have downsides as well. The first and most obvious is that there's rarely a way to know if a target is attainable until long after the assignment has been given. Even if it's attainable in theory, it's rare that anyone will know how much investment will be needed to attain it. ("Sure, we'll cut the bug count in half. The way we'll do this is to hire a bug-spotter to work with each developer; also, we'll cut our requirements for developer productivity in half to give them more time to make sure their code is clean. One more tactic: Pizza for everyone!")
Here's the biggest downside to setting targets: Once the assignee has reached one, there's no point in going further. The target has been attained, though extra improvement would not be difficult to achieve.
How about timely -- the "T" in SMART? Timely is good. Timely is where deadlines are set, and as everyone knows, deadlines do wonders to focus the mind.
In case you need an example, there's the difference between breaking a big project into phases and breaking it into an initiative composed of multiple, small projects. In big projects with phases, if an early phase goes long, it isn't at all uncommon for project teams to explain (first to themselves, then to everyone else) that they'll make up the time in subsequent phases.
That isn't the case when you break the projects into separate, smaller projects; for a project team, the project deadline is an actual deadline and late is just late. There's no making it up in a subsequent anything because projects have only two states of completion: done and not done. Thus, timely is a keeper.