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 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.
- Mark McDonald, “There are no IT projects, only business projects”. July 17, 2011.
- Mark McDonald, “Managing the returns on non-business projects”, July 16, 2009.
- Bob Lewis, “Bad news for traditional techies: There are no IT projects”, July 6, 2011
- Project Pre-Check, “There are no IT Projects”, September 7, 2011.
- Colin Beveridge, “Biggest IT Myth of all time?”