Getting IT out of the dogma business

Forget alignment, Agile, or DevOps; one of the biggest challenges to effective IT is its often-dogmatic approach.

Video: How collaboration helps the business community solve cybersecurity challenges

For more than a decade IT leaders have been concerned with how they relate to and are perceived by other parts of the business. Whole movements and entire vocabularies have sprung up around IT trying to improve this relationship and demonstrate its value, and perhaps the most direct evidence that this process has largely failed is that we're still having similar conversations.

It's not that most IT organizations are incompetent or incapable; rather, in many cases we've entered an increasingly complex era that demands flexibility of thought and approach. For many IT organizations, the response to this increased complexity is an attempt to bring order to the chaos and create processes and structures to mitigate this growing uncertainty. While a noble effort, it's often taken to an unhelpful extreme.

SEE: Quick glossary: Project management (Tech Pro Research)

Dogmatic IT

One of my favorite manifestations of this phenomenon was at a large organization that invested heavily in its IT management process, with well-defined project intake procedures that mandated business cases, certain financial returns, approvals, and stage gates. An approved project would be executed via a rigorous delivery methodology, and everything rolled into a top-of-the-line PMO. IT leaders in the company were flabbergasted that their colleagues outside IT often engaged outside firms to execute technology projects at a significant expense and to detrimental long-term effect. Digging a little deeper, when I asked how long the intake process took, the IT executive mentioned with complete deadpan: "It's running about 18 months at this point before we start work."

Take a moment to rewind your memory 18 months into the past, and consider the massive economic, political, social, and personal changes you've encountered. Pick nearly any economic indicator from oil prices to job numbers and note how they've shifted drastically in ways that were unpredictable over that period of time, and now imagine asking someone to commit to a budget, objective, timeline, and financial returns over that same period.

While an extreme example, the IT organization at this company was so committed to its process that it rendered itself completely irrelevant to much of the organization. Sure, it still had a full slate of long-term infrastructure and core systems projects, but anything that was experimental, critical to a changing market, or subject to consumer tastes was directed to outside organizations. In short, IT was where you went for the boring and big stuff.

SEE: IT leader's guide to achieving digital transformation (Tech Pro Research)

Less dramatic versions of this scenario play out every day. From the organization that's a "single vendor shop" and immediately dismisses talk of a different toolkit, to organizations that create a near-religion around a particular methodology and end up not-too-infrequently violently banging the proverbial square peg into a round hole, it's easy to lose sight of the fact that we're around to enable our companies to succeed in the market rather than demand adherence to our dogma.

Breaking free of dogmatic IT

The first step in breaking free from dogmatic IT is approaching each challenge brought to you by your peers outside IT with a beginner's mind. As painful as it might be, leave your knowledge of your current systems, backlog, methodologies, and technology platform out of initial discussions and seek to understand the business objective, timeline, and market criticality of what's being requested. There might be a half dozen technical ways to get to the objective, and the timeline and importance can guide you to the right approach. Just as a true craftsperson might select different materials, tools, and techniques to build a workbench for a garage versus a formal dining room table, so, too, should you adapt your approach. Discuss the tradeoffs to different approaches--too often we strive for the "perfect" solution that ends up being inferior since it took longer than the "good enough" solution.

Adopting this approach allows you to co-develop a solution to the business problem with your colleague, rather than presenting a "take it or leave it" proposition that's just as likely to end up driving your peer into the willing arms of an outside vendor that will ultimately create something you'll end up supporting anyway.

As you transition into execution, regardless of whether you're using a waterfall approach or newer agile-style delivery methodology, constantly revisit the objectives of the project and market criticality. Markets are never stagnant, and part of eliminating dogma is taking the time to question and validate your assumptions on a recurring basis.

Dogma and process can be comforting in uncertain times. However, just as you're likely uncomfortable around friends and colleagues who lack even an iota of flexibility in their beliefs, your colleagues outside of IT are just as suspicious when you attempt to preach the wonders of your latest IT dogma.

See also