As I promised last time, there’s one more key way, the biggest way of all, not to get what you want from your IT organization. This is, in fact, the trap I have seen virtually every entity I’ve ever worked for fall into to some degree, some to the point of actually destroying the company.
The trap is perhaps best communicated first via parable (no religious implications here, mind you!), and then I’ll give some concrete examples and some brief advice on how to avoid (or at least mitigate) it.
Few people realize how well many of Aesop’s Fables apply to IT situations: after all, as Apollonius of Tyana noted, Aesop “made use of humble incidents to teach great truths.” One of my favorites along these lines is Aesop’s fable about the boy and the nuts in the jar.
THE BOY AND THE NUTS
A boy put his hand into a jar of nuts, and grasped as many as his fist could possibly hold. But when he tried to pull it out again, he found he couldn’t do so, for the neck of the jar was too small to allow the passage of so large a handful. Unwilling to lose his nuts but unable to withdraw his hand, he burst into tears. A bystander, who saw where the trouble lay, said to him, “Come, my boy, don’t be so greedy: be content with half the amount, and you’ll be able to get your hand out without difficulty.”
Do not attempt too much at once.
So, if it’s not at this point overwhelmingly obvious after the above, what’s the trap that I’ve seen quite literally take down small to medium-sized companies? It’s when business stakeholders insist that IT, no matter what the staffing and budget realities may be, take on multiple, simultaneous major projects. That way IT will deliver more, right?
Wrong. In fact, almost never. By pushing for doing more more more, you typically get effects such as the following:
- a failure on almost all fronts, with everything from sloppy work to rework to absolute crisis, due to having been stretched too thin;
- a systematic neglect of all-important sustainment and maintenance activities external to the project but often with overlapping personnel: since no one seems to be asking about these activities very much, they represent a great place to cut corners when being pressed on more visible projects;
- a chronic and ever-spreading feeling throughout the company that “IT never delivers,” because if you ask for everything all at once, there will always be something that isn’t delivered on time or to expectations
- a demoralized staff that wants to do great work but knows that it isn’t. And everyone on your staff starts to feel that if they speak up about the reasons why, they risk being branded as “no can do” kind of people.
I’ve seen small to medium-sized companies engage in major systems replatforming, while simultaneously launching new products, going international, upgrading or even replacing their ERP, and initiating a significant data warehousing effort. Oh, and doing all this while keeping a tight lid on, or even reducing, the staff available to work on these efforts. Any seasoned IT professional would tend to counsel such a company to focus on at most two major efforts of this nature a year, but somehow, a sort of testosterone frenzy seems to set in, a mass euphoria, and people barrel ahead no matter what.
The hardest part of managing IT expectations in a company is knowing when and how to say no to fervent desires. To put one’s foot down and say “enough”. To draw a line in the sand. To insist on a sober prioritization of the many pressing needs. And yet, to survive in a climate where influential people really (and forcefully) want what they want and don’t like hearing that they won’t get it anytime soon. And who then, often, look at you as if you’re the problem, you’re the one stopping it. What? they seem to say, or even say directly: you don’t want to set aggressive goals? You don’t want to be audacious and assertive?
It’s not, or shouldn’t be, a source of shame for an IT executive to insist that projects be right-sized to the capabilities and the staffing that are actually available. It doesn’t, or shouldn’t, mark anyone as unwilling to be aggressive or hard-working when taking on projects if they simply make sure that they will have what they need to make the project a success. Somehow, though, in many companies, it’s become normal and acceptable to squeeze and squeeze IT, with IT’s stated needs (time, resources) somehow regarded as overstated, and then to complain about the end results when projects don’t come off.
Your principal defense against this unrelenting pressure is to make sure, for each project you take on, that you carefully and visibly outline the probable time frame, holistic resource needs (including necessary participation from business stakeholders), and the full expense (taking all costs into account, as I’m so fond of saying). Too often, despite having gotten this careful “full disclosure” approach in advance, I’ve seen executives panic about a third of the way into a major project, simply because the project was costing so much in time and treasure, even though those costs were actually completely in line with the planned expenses.
To be fair, this kind of chronic “Boy and the Nuts” behavior at such companies often isn’t limited to dealing with IT matters: it usually ripples into product development, sales office expansion, splintered and ultimately wasteful marketing initiatives, and other areas. It’s well-meant, of course, with the idea being to do as much as possible, and get big fast, as the mantra of the Internet once had it. Well, we all need to be a voice not so much for “get big fast”, but for “get realistic soon.” Otherwise, we’ll all go, well, NUTS.
Awesome post Peter. Project and Portfolio Management (PPM) is the KEY to grabbing just the right amount of nuts.
Steve Romero, IT Governance Evangelist
http://community.ca.com/blogs/theitgovernanceevangelist/
The seductive thing about quoting software projects is that software is infintely malleable, and it takes practically no time to go from “blueprint” (source code) to finished product (deliverable). So the question of “how long will it take to develop feature X?” feels like very nearly the same thing as “how fast can you figure out problem X?”
Since software developers are selected and self-selected for problem-solving skills and confidence in same, it is so so so easy to give a “Yes We Can!” kind of answer no matter the size of the request. In fields where you manipulate physical things, in which delays are built in, not so much.
So first you’ve got I.T. Development with its built-in optimism. Then you’ve got Management looking for some way to condense the time and money required to achieve corporate goals, and every other department is up against hard limits: personnel, shipping time, regulations, the tax calendar, whatever. And Development’s got nothing but soft limits, so that’s what gets pushed.
It’s not surprising that the software people get overscheduled.
Peter, I thought a little more about the “too many nuts” problem, recast it as the “single nut too big” problem from the developers’ point of view, and blogged about it this morning at http://blog.criticalresults.com/2009/11/04/optimism-death-march/
Thanks for the prompt!
Yes; your blog post is excellent. The amusing part that came to mind as I read it was that the very same people (typically) who say “programmers are such optimists” when a project is running late are the ones who battered down the original longer estimates from those same programmers at the beginning of the project, saying that oh, programmers are always such pessimists. Or essentially, anyway.
Thanks for contributing. I enjoy your blog.