Nuts: the biggest trap of all for IT stakeholders

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.


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:

  1. a failure on almost all fronts, with everything from sloppy work to rework to absolute crisis, due to having been stretched too thin;
  2. 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;
  3. 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
  4. 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.


  1. Steve Romero, IT Governance Evangelist says:

    Awesome post Peter. Project and Portfolio Management (PPM) is the KEY to grabbing just the right amount of nuts.

    Steve Romero, IT Governance Evangelist

  2. 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.

  3. 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

    Thanks for the prompt!

  4. 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.


  1. […] spots at the same time.  Trying to do it all together, and all at the same time, is just plain nuts. Any assessment of quality will agree on that […]

  2. […] The process must recognize that there will still be a judgment-based component to project selection, and focus on standardizing the input information to ensure that judgment is maximally informed.  Recognize that biases and politics will play some role in project selection, and seek actively at all times to mitigate the effects of such bias.  Again, the most important check and balance? Not to take on too much, despite whatever urgency, politics, or potential ROI may exist: that would be nuts. […]

  3. […] Projects are begun one-by-one. Estimates, if done at all, are unrelated to actual resource allocation. Without a project portfolio […]

  4. Social comments and analytics for this post…

    This post was mentioned on Twitter by PeterKretzman: It’s not a silver bullet, but neglecting to do Project Portfolio Management is a sure path to IT failure. #itfail #cio…

  5. […] isn’t late because developers are braggarts. It’s because management has assigned them too much to do, which, as Peter Kretzman warns is the best way to not get what you want from your I.T. […]

  6. […] sticking point in launching information technology projects.  In essence, we’ve fallen into the “nuts” dilemma, both in large and small ways.  We want so much, and attempt so much, that we increase our risk of […]

  7. […] de proyectos de tecnología de la información. En esencia, hemos caído en el dilema de las “nueces“, tanto en formas grandes y pequeñas. Queremos tanto, y tratamos tanto, que hemos aumentado […]

  8. […] dimension, it is absolutely critical that you achieve success with them. A key way to fail is to take on more than you have resources to do; doing so casts into doubt the success of all projects in the […]

Speak Your Mind