IT Governance: Get Back to the Basics

A lack of foundational elements for IT governance can lead to a bunch of problems, including siloed operations, business disconnects and redundant applications.

Guest Commentary, Guest Commentary

April 25, 2019

5 Min Read

IT teams struggle to create tools, architectures and applications to keep up with evolving customer demands and mountains of data. In the fast-paced world of IT and the never-ending emerging trends, the answer to complexity is often more complexity. Practical thinking and application of fundamental rules to govern IT often fall by the wayside.  It’s time to review some traps that are easy to fall into that might be weakening your grasp on IT governance.  

Not syncing up with the business side

Despite years of effort to create strong links between business and IT operations, there are still gaps between what the business is looking for and what IT is providing. The need to move quickly to address customer demand hasn’t helped matters, and the emergence of agile methods has not wholly solved the issue. Evidence of this is the emergence of shadow IT where business entities are simply creating their own solutions, largely independent of their technology function. This may work on a small scale, but over time, it leads to disjointed operations. While it can be frustrating and time consuming, it is critical to focus on strong business cases during the initial stages of any IT project, even if delays are caused in the initial stages of the project. Getting the business needs nailed down at the onset of the project will pay dividends later.  

Wasting time on ‘religious’ debates

One of the greatest wasters of time, energy and emotion are debates over product decisions that often don’t matter.  It’s analogous to a “Ford vs. Chevy” debate. Despite manufacturers’ rhetoric and religious devotion to one brand or the other, either will get the job done. Nuances of payload rarely matter. Similarly, the top three contenders in a product evaluation are often all capable of meeting your needs. Success often depends more on execution, governance, regional availability of vendor support, etc.  In fact, for these reasons, sometimes the market leader may not even be the best choice. To maximize the chances of a perfect selection, use a structured and disciplined approach for software and product selection and ensure a strong linkage to well defined decision criteria.

Right sizing, done wrong

Another trap is the notion that big is better. However, you wouldn’t take a 747 between downtown Los Angeles and Hollywood or between New York and New Jersey. Yet every day, people oversize their IT solutions because there is a sense that big is better. Large-scale solutions typically only work for large-scale operations. They do not scale well for smaller applications. It’s important not to take comfort in large-scale solutions simply because they are a recognizable brand. Conversely, small-scale solutions do not scale well for large applications. Have the confidence to select a solution that you can manage and that can deliver on your expectations.

Thinking that tools will solve (all) your problems.  

Tools solve certain problems. For example, tools that assist with data analytics and data mining have aided immensely in data management. Similarly, CRMs have aided in customer management. However, none of those tools will live up to their potential if supporting fundamentals are absent. For example, lack of strong human analytical skills can still be the bane of data governance. If the right questions aren’t asked or data is poorly organized, data mining tools won’t mine anything. Business processes, training and/or data organization must all be optimized before you can benefit from a tool upgrade. In other words, don’t put technology before process.

Boiling the ocean 

It is rarely advisable or feasible to embark on massive, enterprise-wide simultaneous change. There are exceptions, of course. For example, if you are forced to respond to consumer demand, there may be no choice but to engage in a wholesale revamp of your IT programs. However, in most cases, a phased approach is more practical. Everything from the design of data models to the development of new software benefit from a modular approach. One reason is that it is simply too complex to effectively integrate all the elements of a grandiose design. The second is time. On a large-scale initiative, many of the design requirements will be obsolete by the time the project is half complete. Instead, select initiatives of smaller scope that hit directly at a compelling problem. The probability of success will be much greater, and the smaller project will serve as a proof of concept and model for enterprise-wide implementation. 

Working in isolation

Too often, important decisions are made in isolation of a greater context. For example, the supportability of products, and interoperability with other corporate solutions must be taken into context. When selecting a path forward, it’s wise to consider the full range of criteria that you may encounter over an extended period. For example, a software package may meet all your business needs and fit well with your technical architecture. However, peripheral requirements like the availability of skilled resources, or the cost of available resources may work against your decision. 

Chasing shiny things

Some technologists are evangelists who will fight to the death for their preferred solution, often because it’s new and novel. It may also further their marketability. Conversely, sometimes their solutions create valid disruptive technologies that secure a leadership position for their company. However, there are more misses than hits, and shiny things often lose their luster. Be careful not to embrace technology solely for the sake of technology. The art of the game is to have the wisdom and critical thinking that illustrates when technology innovation is, in fact, the core competence of the organization. However, for mainstream businesses, it’s always wise to tie all technology activity to a business objective.  In other words, ask the question, “what problem are you trying to solve”?

Fundamental methods are at the heart of almost everything that needs to be done well. None of it is magic. Modest guidelines can provide a framework to help simplify something that can be complex – especially for IT governance.

John Krpan is a partner with Focal Pointe Group  located in Bellevue, Washington. He is a leader who focuses on creating solutions and paths forward in complex situations. As well as honing these skills in a consulting capacity, John has held professional roles as CIO, CEO and COO in a broad range of industries. He has served in an advisory capacity on several boards and often speaks on the topics of transformation and the linkage of technology with business.

About the Author(s)

Guest Commentary

Guest Commentary

The InformationWeek community brings together IT practitioners and industry experts with IT advice, education, and opinions. We strive to highlight technology executives and subject matter experts and use their knowledge and experiences to help our audience of IT professionals in a meaningful way. We publish Guest Commentaries from IT practitioners, industry analysts, technology evangelists, and researchers in the field. We are focusing on four main topics: cloud computing; DevOps; data and analytics; and IT leadership and career development. We aim to offer objective, practical advice to our audience on those topics from people who have deep experience in these topics and know the ropes. Guest Commentaries must be vendor neutral. We don't publish articles that promote the writer's company or product.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like

More Insights