“No IT projects”? A practical take

If you follow the news, it’s quite clear that we’re in the “silly season” of politics, that time when people eagerly grab hold of any questionable statement of their opponent and use it to extrapolate rank incompetence or dastardly intentions (or worse). Language is frequently quoted out of context, definitions become blurred, things get inappropriately juxtaposed. We’ve all seen it.

That’s why they call it silly season. And that behavior isn’t just true of politics, but also can appear in normal business life, on Twitter, and (often) in IT matters as well. When I run across items I disagree with, though, I try to remember that rather than expressing categorical disagreement (let alone outrage), it’s far more useful to look first for common ground, then aim to identify the areas of contention or difference in perspective. That struck me recently when I read Todd Williams’ (@BackFromRed) recent blog post with the title “Stop All IT Projects!” and recalled that another esteemed colleague, Steve Romero (@itgEvangelist), has expressed views along the same lines.

Todd and Steve are both smart, experienced IT professionals whom I highly respect. In Todd’s case, we’ve met in person; in Steve’s, we’ve exchanged numerous emails and blog posts over recent years. Both of them unquestionably “get it” when it comes to IT matters. I generally agree with what they post or tweet; they’ve each written books that I recommend to others. In fact, I even agree with much of what Todd writes in this particular post. But still, with consummate respect, I think these colleagues (and others) are picking the wrong battle when they insist so staunchly on “no IT projects”. Here’s why.

First, let’s look at what I think we have in common in our views.

  • Todd writes, every project’s goal must be “to deliver to the operational needs of the company—selling product—not to the whims and desires of the IT group.”  This is inarguable. “Selling product” is probably an unnecessary oversimplification of the multiple factors that influence whether information technology can and should be leveraged in a given situation, but let’s accept it as a reasonable shorthand for the end mission of any company.
  • Per Todd, “if a project fails to address the needs of the customer (directly or indirectly), then it should never see a penny of funding. This seems such an elementary concept, but it is routinely violated by techno-bigots trying to implement the latest toy or tool.” Again, quite true, although I probably wouldn’t use the word “routinely,” because I feel that such IT toy-mongering is getting much rarer. But yes, I’ve encountered it: I’ve written before about my CTO predecessor at one job, who had spent company money purchasing a robot whose purpose was intended to be walking the halls, talking to the executives, and “making people feel more comfortable with technology.” No joke.
  • “A business case must be present that improves the top line or bottom line.”  Yes, of course: yet this is somewhat overstated, as I cover below. Again, this insistence seems more like a reaction to the potential “techies gone wild” bugaboo, where technologies get implemented without business justification, simply due to IT “whims and desires.”

My disagreements with this “No IT Projects” meme are rooted in my view of the need to balance pragmatism and idealism. So let’s look at the meme through the lens of practical considerations.

Todd writes, “If the business is not fully engaged with the [“IT project”] change, trouble is on the horizon…. If the business does not upgrade and they are caught not having support it is their problem, not IT’s.”  No, not at all. It’s understandable to feel that way (along the lines of “hey, it’s their funeral”), but that’s really just a species of the very “us versus them” attitude we need to eliminate. In fact, if the business is “caught not having support”, it’s very much everyone’s collective problem (we’re all part of the business, after all!). Similarly, imagine different business elements deciding to sign contracts without review by the company’s legal department. “It’s their problem” if things go awry? Maybe, but the whole enterprise can be impacted. It’s perfectly reasonable to expect that players will “play their position”, without worrying that doing so creates unwanted “silos”.

Business involvement in IT-intensive projects

Additionally, there’s a lot of work that takes place in any company that paves the way for product sales and engineering, but which doesn’t strictly, obviously, directly contribute to these. Some of this stuff won’t ever have a definitive, obvious ROI, unless you count some artificial set of numbers that are often ginned up with the desired answer already in mind. Such projects can range from pushing out the latest version of Office, to a “forklift upgrade” or other “roof project”, to even HR events like the company picnic. There are certainly plentiful scenarios where these are desirable projects for a company, but whether there’s a clear ROI isn’t always immediately obvious for them, and the need/desire for direct business involvement in each can also differ drastically.

Here’s my experience: business people’s involvement in any IT-intensive project is typically a fragile, precious thing. It’s just not enough for them to understand intellectually that a given project will benefit them: they have to live it, feel it, breathe it. Without feeling that visceral commitment, they can often succumb to a kind of lip service: nominal participation, usually just for the sake of appearance. And particularly if a lot of the important issues and details are arcane and tedious and incredibly detailed, they’ll tune out. Yes, they may want a great and usable UI for a system, for example, but sitting in a room for hours debating edge-case logic flow scenarios or screen placement of fields can often tax their patience and commitment.

Getting proper participation incentives in place for the non-IT business folks may seem like an obvious solution, yet it’s a facile answer, as anyone knows who’s tried getting salespeople (for example) to play a truly meaningful role in a project that doesn’t immediately and obviously affect their own personal bottom line (i.e., their quota or bonus, etc). Face it, they’d rather be selling, and the corporate incentives set for them are usually (and properly) heavily weighted towards having them do that.

Balance and leadership

With some (perhaps most, even) IT-intensive projects, getting direct non-IT business involvement is absolutely critical for success: any ERP or CRM implementation, for example. But all such projects, of whatever nature? Not so much. My view is that the CIO should pick his or her battles. If you overdo it, and idealistically push for active business involvement on projects where the non-IT value-add is nominal at best, you’re not leveraging the time of the non-IT business people wisely, and they will in fact know it and resent it. You’re overplanting the field; you’re going to the well too often. The metaphors may be running away from me here like bulls in Pamplona, but my point is that business involvement can’t be molded into a “one size fits all” approach.

For me, “No IT projects” is fine when it serves to underscore how all projects need to have business value firmly in mind. But overemphasizing the slogan swings the pendulum back too far the other way.The slogan’s main genesis seems to be the perceived ongoing need to fight an old battle (worrying about techies run amok, in other words) that may indeed still be lingering around the edges of our industry but on which there is little real disagreement. Yet, when it becomes a constant battle cry, with its (usual) accompanying assertion that business people must drive all projects, it dismisses basic business realities about the reluctance and ability of non-IT business folks to engage, in many IT-intensive projects, at a level of detail that is akin to mixing oil and water. Ask the business: they’ll typically tell you they want some things just handled, correctly and swiftly, without them always needing to be deeply involved throughout. It makes a lot more sense to go for targeted, effective participation in selected projects than to insist on it across the board.

In other words, the practical view is that IT needs to both know its place and yet set the pace for the company in IT-related areas, instead of reflexively pushing for direct business participation in all areas. This practical view recognizes and accepts that IT has a twofold deep responsibility and obligation:

  • generally doing the right business-focused thing (no arbitrary hallway robots, in other words) for a business constituency that has its own full-time areas of intense focus; and
  • making sure to get the right kind of help and buy-in from that constituency when it matters most.

In the end, I believe that my colleagues Todd and Steve probably know all this. We simply choose to emphasize different aspects: for them, it’s about always getting the necessary business buy-in and participation above all. Steve, for example, argues forcefully and cogently (and quite correctly) for how important it is for business to step up to its fundamental obligation to spearhead IT governance.  All three of us would doubtlessly and easily agree that, as Todd writes, “the project’s goal is value,” value which “comes from delivering a product that meets the customer’s needs.”

So, back to my comparison with current events: flatly put, silly season shouldn’t apply here. Even though I disagree with them on this one issue, I’m confident that neither Todd nor Steve will now assume in any way that I’ve therefore thrown in my lot with what Todd called the “whims and desires” of the “techno-bigots.” Indeed, I think we all value the same basic world of IT-business collaboration, with the same fundamental goals, but merely through different lenses and perspectives. And there’s nothing silly about that.



  1. Amen Peter.

    A project to implement a large scale VMWare farm capable of replacing 500 obsolete servers is an IT project. Of course it is *also* a business project, and should be held accountable for ROI & execution, but it is markedly different from a new CRM system deployment. The latter requires ongoing participation of business thought leadership. The former, not so much.


  2. Great article. While hyperbole can be memorable, ultimately it smacks of salesmanship. A sober, balanced approach will inspire more confidence in the long run. Involving business units in “dial tone” projects (apart from the budgeting process) will likely only lead to annoyance. As you say, pick your battles and save your demands on their time for those things that directly impact the business.

  3. I think you raise some valid issues. The way IT is done today, there are certainly going to be projects the business doesn’t care about. One example might be a corporate wide database. The Business doesn’t have any particular opinion on how this should be done.

    However I think we are seeing a shift in projects from large to small, from complex to simple, and horizontal in focus to vertical in focus. At the same time, the Cloud is slowly removing infrastructure issues.

    With these shifts, it becomes more practical to see each project as a business initiative. And if the business doesn’t care enough about the project to lead it, then we may well ask, why bother?

  4. Roger,
    You make a very telling point: I agree that much of this may be shifting in the manner you describe, and the role of the cloud certainly reduces (although doesn’t utterly eliminate, counter to some claims!) the specific projects spawned to address infrastructure issues. So yes, many more projects will fall under the umbrella of business-affecting, which is/should be the goal, after all.

    But as I indicated, there will always likely remain certain “roof projects” that are both crucial to the firm’s overall success but which evoke nothing but yawns on the part of non-IT folks. At one site, we changed out the underlying database technology used for a given system, without affecting the basic functionality. The business cared about the result, indeed, and they were (and needed to be) bought in on the solid reasons why we were doing it, but leading the project or even being regularly involved? A non-starter. Just “get ‘er done” is the attitude in cases like that.

    Thanks for commenting.

  5. Fantastic post Peter. You’ve done a masterful job of applying the realities of the IT/business relationship to my admittedly idealist view of “no IT projects.” It is easy for me to see how you agree with the spirit of the concept while offering a practical alternative to its potentially all-or-nothing appearance.

    I actually don’t think our positions are contrary at all. I believe I could easily follow all of your sage advice while still maintaining my position of “no IT projects.” I agree that it is a mistake for IT to sit in a room with their business counterparts “debating edge-case logic flow scenarios or screen placement of fields” – but a conversation must take place. This conversation is only possible if IT understands how the business defines value and the enterprise has the governance and process in place to translate those “roof projects” into business value terms (note how I am avoiding using the ROI term here).

    I don’t mind the characterization of “it projects” in and of itself. What I lament is the inability of an enterprise to translate those IT projects into business value terms. Failure to do so mandates the need for IT-funding that can only be justified with yawn-inducing technical explanation.

    Thanks for an awesome post Peter. I am certain I will refer to it every time I engage somebody in my “no IT projects” conversation.

  6. I have to confess to being one of those who promotes “No IT projects” and variations on this meme (e.g. blog link at the end). I think you present great arguments for establishing the right governance and appropriately engaging stakeholders. This is good advice for any kind of project. I have no issue with the CIO or other IT leaders sponsoring and driving some projects in the portfolio. Since the CIO and IT leadership team are business people (they are, aren’t they?) these projects still qualify as being driven by the business. However, I am going to continue to positively discriminate against projects being categorised as IT. In my business I am still seeing too many organisations splitting potentially great initiatives into two ineffective projects (IT and non-IT parts) or creating projects that are only partially thought through (e.g. software package implementation, big bang infrastructure transformation or application rationalisation). In the future the balance may shift but, today, I still find nearly all IT projects deserve to be treated with suspicion.

    Related blog: http://cioportfolio.blogspot.co.uk/2012/05/start-dismantling-you-it-project.html

  7. Richard, thanks for your thoughtful response. I certainly can see, potentially in some organizations where (it sounds like) there has been a long-standing pattern of distrust of IT’s business orientation (i.e., their tendency towards launching pet projects), that “No IT Projects” might be a more suitable mantra than I otherwise hope is the case.

    As for IT-led projects “qualifying as being driven by the business,” well, that’s tautologically true as you point out, but that is not what is typically meant when I hear someone insist that “every project has to have a business driver.” Rather, usually they mean they want it to be required that NON-IT people lead the project, with IT in a supportive position.

  8. How do you bridge then the gap between IT and leadership, of technical vs non-technical folks? I think that there’s still this huge divide somewhere and this is why we often see resistance to change whenever something new arises and business goals are not met. Do you think that the best way to resolve it is through implementation of the agile process?

  9. No, I don’t. These issues go above and beyond what is addressed by Agile, in my view; Agile should never be viewed as a cure-all, since it comes with its own set of challenges. Thanks for commenting!

  10. I’m curious if this ‘No IT Projects’ meme will take off; makes for a nice shock value. I thought silos are for corns though.. Seriously, I’ve seen a huge divide between management (non-IT business folks) and those in IT. Bridging this gap is still a work-in-progress for many and things may not always have a happy ending. Your insights make sense.

Speak Your Mind


This site uses Akismet to reduce spam. Learn how your comment data is processed.