Effective IT Steering Committees

A board of directors for an organization can be a liability – or they can be a serious asset. They can connect the organization to other organizations. They can bring insight into the organization and steer the organization away from potential disasters. A strong IT steering committee can do the same for an IT organization. However, getting a steering committee to be effective isn’t as easy as it sounds. The Indy CIO Network tackled the challenge of effective steering committees at the May 2017 meeting, and here’s what the group said (from my point of view).

Steering or Status

Getting the appropriate people involved in the steering committee is essential. If you don’t get anyone engaged, the meetings become little (or nothing) more than IT reporting status on its projects. It becomes a monologue of what IT thinks should be done, with passive listeners yawning, writing notes, or answering emails from their phone.

An effective steering committee isn’t getting status updates from their IT team members, it’s participating in an active discussion by asking questions – including questions that are sometimes difficult and uncomfortable. That’s the value of a steering committee. Just like a board of directors, it’s important for the CIO to get pushed out of their comfort zone – in a generative and safe way.

Looking for Trouble

If you’ve ever had kids, there are times you know that they’re just looking for trouble. They’re trying to get in trouble – generally for inexplicable reasons. However, good IT organizations aren’t looking to create trouble as our children sometimes are, they’re looking to find trouble before it becomes something bigger.

Like going to the mechanic when the check engine light comes on in the car instead of ignoring it, steering committees can provide valuable diagnostic information about how the IT organization is doing. While the feedback may not always feel good, it’s much better to solve a problem when it’s small and can be easily addressed than when it’s become a systemic problem that’s taken hold.

Sometimes trouble comes in the form of the opposite problem from the disengaged steering committee that won’t interact. It comes in the form of another master that the CIO must serve.

Too Many Masters

Sometimes the steering committee puffs up and becomes another master for the CIO to serve. Instead of advising, informing, and suggesting, the committee tries to assert its power to instruct – rather than guide – the CIO in what needs to be done. Many a CEO has had to manage this with a board of directors. On the one hand, the board of directors in an organization is the ultimate authority, but on the other, they’re only effective when they allow the CEO to make the calls they need to make and only intervene when it is appropriate.

IT steering committees don’t have the power of a board of directors, but even so they try to assert a level of control that would be inappropriate. Here the CIO must acknowledge the feedback but ultimately explain that the steering committee’s recommendations aren’t the final word. Ultimately the CIO reports to the CEO, not the steering committee.

In the end, the effective steering committee is like a board of directors in that it supports the CIO and the IT mission out to the organization. They’re bought in like a board of directors is when it has invested in the success of the organization.

Buy In

While the feedback and advice from the steering committee is valuable, the real value is in helping to build buy-in for the priorities of IT – and that not everything can be a priority. Building the buy-in that IT only has so many resources, and that those resources need to be allocated to the business areas based on need, is an important step to building sustainable relationships between IT and the business.

In a strange twist of fate, one business division thought that the CIO was trying to dictate their priorities with the steering committee. When the word “priorities” was swapped out for “capacity management,” the division leader joined in the conversation to make sure that IT knew about their needs and how IT could help.

Partners

When you can get the right people in the organization on the IT steering committee, the whole tenor of the conversations can change. Instead of IT being an order taker from the business – or dictating what the organization can and can’t do – IT becomes a key enabler for the business. Few IT organizations really dictate what the organization can and can’t do – but it can feel this way at times when IT conveys what it can and can’t support.

When the IT organization is already seen as a partner, there may not be a need for a steering committee.

Alternative Steering

Sometimes a steering committee isn’t even a steering committee. In effective organizations, the feedback needed to guide the IT department comes in the form of an agenda item for existing operational and strategic meetings. There’s no need to have something separate for IT if it can fit into the existing organizational management approaches.

It’s not that these CIOs get a free pass to do anything they want – or at least avoid getting feedback. It’s that the feedback they get comes directly as a part of normal operations rather than needing yet another meeting. This level of integration is healthy inoculation against “shadow” IT.

Shadow IT

In most large organizations, there’s some level of information technology work going on outside the IT department. Some level of this is right and appropriate. The business hires technically savvy people and they handle some of their own problems. It creates challenges, however, when these technically savvy people don’t work with centralized IT. That is, instead of viewing central IT as the partners that provide the core services that the business unit IT needs, they see centralized IT as a competitor, an enemy, or an impediment.

When the business and IT are in partnership, there’s no need to be competitive. IT does some core functions and business unit IT builds on those platforms. When there’s a solution to be created, or purchased for the business unit, all the parties sit down at the table and find the best solution for the organization. One of the best ways to do this is to align the mission and values.

Mission and Values

Almost every organization has a corporate mission statement. Whether it’s posted on the walls or buried in the employee handbook, it’s there. However, very few organizations live out their mission and values. Very few are able to build partnerships based on a shared understanding of what the organization is on this Earth to do – and not to do.

Powerful organizations build coalitions based on the idea that we’re all in this together, and so there’s no need for competition. Once there’s a mission and values in place, it’s possible to create a roadmap that’s effective for everyone.

Roadmap

IT, like the rest of the organization, can’t be all things to all people. There are fixed resources, and therefore a fixed capacity for new projects. By establishing a roadmap – and getting steering committee buy in – the friction is shifted from the gap between IT and the business to the gap between different areas of the business. By establishing a roadmap, everyone knows when their projects will get done – and what is ahead of them in line. Instead of arguing with IT about getting a better position, they can negotiate with other business units to get a better spot on the roadmap.

They can also become advocates for additional IT capacity so that their projects can be done sooner. By allowing the business to drive the roadmap, there’s the ability to have the business itself be champions for temporary or permanent changes in funding.

The challenge with this roadmap process is that sometimes it leaves internal cost optimization projects in IT under-appreciated and under-funded.

Managing the Mix

Every IT budget includes operational line items and developmental line items. The operational line items change when you implement cost reduction programs, switch vendors, or find a better way to buy the resource. However, all of these are projects that – if IT doesn’t get an appropriate voice at, the steering committee will die – can represent real cost savings to the organization over the long term.

Managing the mix of operational costs, investments in new solutions, and investments in cost optimization is a real challenge. If you optimize costs, you’re not delivering new functionality to the business. If you’re always focused on getting the business features, then you’ll have high operating costs. The reality is the mix of projects is dictated by the organization and what it needs to keep IT effective.

In the end, the steering committee is designed to help surface the business and IT operational issues in a way that the entire committee can design a roadmap that everyone can live with. If you can get that, then you know you’ve got an effective IT steering committee.

IT as the Catalyst for Organizational Change

In the April 2017 lunch meeting for the Indy CIO Network, we took up the topic of organizational change and how IT often gets thrust into the position of being organizational change agents with neither support nor training. However, instead of lamenting about the position we’re in, we discussed ways for our organizations and our IT organizations to be successful.

Not an IT Project, a Change Project

By far the most challenging issue we confronted was the idea that many organizational change projects are running around like a wolf in sheep’s clothing. Projects to upgrade systems or install new systems are often times moved to change the way the organization operates; but despite efforts to the contrary, the projects often get labeled with the name of the new system or version of the system.

The easy and tangible part of the system – the technology – becomes the moniker for the entire effort. As a result, people think that this is an IT project to change technology when that may be an afterthought or just the result of changing the business.

The need to clearly articulate the “real” project isn’t enough. This is a people problem, where everyone needs to hear in tangible terms how things will change and what it will mean to them.

80% People

Organizational change initiatives do have a technology component, however, that technology component of the project may only represent 20% of the overall work of the project. After all, changing the technology is the easy part. The hard part is changing people. Murry Gell-Mann once said “Think how hard physics would be if particles could think.” Instead of following the straightforward rules of ones and zeros they would be free to make up their own minds – just like people are.

People’s feelings aren’t even just a factor in their behavior. They’re THE factor. We like to believe that we’re rational decision makers but, as Gary Klein points out in Sources of Power, we make recognition-primed decisions – not rational ones. The Happiness Hypothesis (and Switch) take this further to speak of Jonathan Haidt’s model of the Rider-Elephant-Path. In this, our rationality is sitting on top of a massive elephant that is really in control. Thinking, Fast and Slow and Incognito both point out that our emotions – or System 1 – can lie to our rational selves. Whatever the lies are, they’re always lies about how change will impact us personally.

WIII-FM

What Is In It For Me (WIII-FM) is everyone’s favorite radio station. It’s the radio station that plays in our head all the time. We’re always considering what we’re experiencing based on the idea that it may – or may not – impact us. So whatever change we propose to the organization, we have to remember that it has impact to people – and that impact to people will always be personal.

In a discussion about a mainframe elimination project, we asserted that we had to be honest that there were some jobs that were going to go away. Because even though the truth is hard, it is the truth that everyone knows. By sugar-coating the message, we run the risk of eroding trust – and it’s trust that is the lubricant to getting change done.

The Lubrication of Trust

One of the reasons that organizational change initiatives fail is that there is a growing lack of trust. John Kotter, a Harvard professor emeritus says that about 70% of organizational change projects fail. (See Leading Change and The Heart of Change.) At least some of that is due to the lack of trust that an organization’s employee has for the organization and it’s getting worse. America’s Generations reports that, starting at Generation X, there has been a building skepticism towards large organizations.

Trust: Human Nature and the Reconstitution of Social Order spends a great deal of time exploring the impact of trust on organizations and nations – including how trust in one area can reduce trust in another area. Trust lubricates an economy and an organization by reducing the amount of effort that must be put into protecting ourselves.

Building Trust and Making Change Work

Rebuilding trust and making change work function in the same way. You build trust by making and meeting small commitments until you can make larger ones. In the same way, we make changes by breaking them down into small, incremental steps so that they don’t seem daunting.

While leadership maybe thoroughly entrenched in the vision of the future, the everyday worker in the organization lives in the world of now. Without a path between the now and the future, they’ll keep doing what they’re doing – or worse, they’ll freeze. Often, we get into the valley of despair in a change, when productivity is low and things aren’t quite working yet, and people freeze and end up not able to move forward to accomplish the productivity that everyone wants.

In the end, we need our business leaders to join us – and lead the charge – in changing the organization. IT can be the catalyst, but the business has to start the reaction to change.

What’s Your Cloud Strategy?

I love learning how people come from different places based on their perspectives. The March 2017 meeting of the Indy CIO Network took up the topic of cloud strategy and the conversation was remarkable.

What Kind of Cloud?

As a pilot, I was trained to identify different kinds of clouds so that I could avoid getting caught in weather that either the pilot (me) or the plane couldn’t handle. I came to appreciate the number of different kinds of cloud formations there were and how knowing what they were could keep me safe.

When we’re talking about technology clouds, there are a few options:

  • Infrastructure as a Service (Iaas) – Virtualized machines that you can manage as if they are on premises.
  • Platform as a Service (Paas) – Containers that you can deploy your solutions into to take advantage of larger data centers and other resources that may not be practical to deploy yourself.
  • Software as a Service (SaaS) – A software package licensed with hosting of the application included. This bypasses the hidden maintenance costs of running a server and managing a software package.

With flying, the challenge was always safety; with the technical cloud, it comes down to security.

Security – Better or Worse

On the one hand the availability of cloud-hosted resources would seem to have a worse security profile than something locked away in our respective data centers. After all, availability and security have been natural-born enemies since the beginning of time. It intuitively makes sense that if it’s more available then it’s got to be less secure.

On the other hand, the cloud service vendors generally have better resources than a small- or even medium-sized company might have to purchase intrusion detection and pay security analysts to continuously monitor what’s happening on the systems. So they’re a bigger target in aggregate, but they’re also bringing substantially more resources to bear than we could if we had the services in our network.

From a practical point of view, the surface area – or availability – isn’t all that different between a server hosted in the cloud platform vs. one that’s on your local network. Most organizations recognize the need for employees to work while traveling. As a result, virtual private networks (VPNs) have become common, so most employees really have availability to get to information no matter where they are on the planet – or in the air.

In the end, the kind of security technology being deployed and the rigor of the security policies – including checks and balances – generally means that cloud-hosted systems are more secure, even if this seems at times to be counter-intuitive.

Goals

The group agreed that cloud hosting doesn’t save you direct costs – or at least not much. What the cloud services give you are features that you can’t afford to implement on your own. Whether it’s a service level agreement (SLA) that includes a lot of 9s or elasticity, cloud isn’t about cost savings. It’s about mindshare and capital savings.

In some scenarios, the goal is to increase uptime and geographic diversity to handle outages in a way that just isn’t practical to do internally.

Very High Availability

Some systems just can’t be down. The business cost of being down, both directly and in terms of the brand damage, are just not tolerable. Even when the primary operations are on your environment locally because of proximity or other needs, having the ability to switch to a cloud backup when you’re not able to service customers is essential.

While there are very high profile outages at Microsoft, Amazon, and others, these outages are, generally speaking, quite rare. The amount of redundancy that exists in their environments simply isn’t practical for the mid-sized organization to buy.

The Real Risk and Opportunity

It seems that the real risk and opportunity with developing a cloud strategy is scaring your IT professionals with not having a job. My observation, and those of some of my national peers, has been that it isn’t IT professionals losing their jobs – it’s that their jobs are changing to be more customer-focused and interactive.

So while the fear of being replaced is there, the real opportunity is for our IT staff to become more closely aligned and embedded in the organization, so that IT isn’t seen as something distant and far away, but is instead seen as a partner trying to help the business get things done.

Understanding Bimodal IT

Gartner’s model for bimodal IT has both its zealots and its detractors. However, as a CIO how does one cut through the noise and leverage an understanding of the model to help optimize IT operations in their organization? At this Indy CIO event, I shared a table with some CIOs and explored the concepts in bimodal IT while listening to our host’s perspective and checking in with the rest of the room periodically.

Join me for a quick synopsis of what we came to know about how IT has two modes, how to harness that, and where things can go awry.

A Tale of Two Modes

The two modes in the Gartner model are:

  • Mode 1 – “Optimized for areas that are more predictable and well understood.”
    • Repeatability over Agility
    • Low Risk Tolerance
  • Mode 2 – “Exploratory, experimenting to solve new problems and optimized for areas of uncertainty.”
    • Agility over Repeatability
    • High Risk Tolerance

The most common misconception was that everyone should want to move from Mode 1 to Mode 2 IT. Inherent in the Gartner model is that you should be using both modes of operation. That is, some of the functions inside of IT should be operating in Mode 1. Other functions inside of IT should be operating in Mode 2.

You can’t treat an exploratory area, like telemedicine, like you treat the core electronic medical record (EMR) system. In telemedicine, the need for rapid adaptation and velocity of change exceeds the need to not fail. For an EMR, you need repeatability and low probability of failure more than you need adaptability and velocity of change.

Managing the Mixture and Match

Managing effectively in a bimodal IT paradigm isn’t about which mode you’re operating in, but rather is assessing the mixture of areas where Mode 1 is optimal and those areas where Mode 2 is optimal – and aligning the way that you address them to the way that they are best handled. As one participant noted, it’s not that the bimodal model is really all that different from what we’ve done in IT for a long time, but it’s giving a language to the differences so that we can clearly articulate what we’re doing.

It gives us a shared language to speak about the fact that, in some areas, we’re going to tolerate failure, because the impact of failure is low and the need for adaptability or velocity of change is high. We aren’t going to “throw out the baby with the bathwater” and pick only one way of operating, we’re going to develop a ratio of delivery in our organization that matches the needs.

Beyond matching the mode to the area, there’s the need to match the mode to the person, so that their natural talents, behaviors, and dispositions align. We spoke of the challenge of small IT shops where individual contributors and managers may need to work on both Mode 1 and Mode 2 areas. We acknowledged that there are some behavior/psychological assessment models like DISC that can be effective at helping us identify which mode team members might be better at. Those with D or an I focus are more action-oriented and are more suited for Mode 2-type areas, where professionals who are more S- or C-focused have the diligence necessary to continue to advance Mode 1 areas.

Iterative and Agile

An area of confusion in our discussion was exactly what characterized Mode 2 activities and what characterized Mode 1. Despite Gartner’s definitions, it wasn’t always clear what Mode 2 was, though it was clear that it didn’t mean traditional agile development or DevOps or any of the new methodologies for development and continuous improvement.

In fact, we discovered that either mode could be delivered with either agile or traditional waterfall development. The secret seems to live in the iteration cycles. That is, the cycles of development, integration, testing, and deployment are happening faster in Mode 2 – where the cycle costs are lower. Mode 1 cycle costs are much higher due to the much more extensive testing cycles.

So it’s not that you have to pick a delivery approach based on Mode 1 or Mode 2 – it’s that you have to attenuate the cycle times based on the cost per cycle.

Preplanning, Waterfalls, and Staying Agile

Mode 1 is the hallmark of the traditional IT department, where the risks are well-known and are relatively large and the area itself is well-known. Operating a phone system, managing connectivity to the Internet, and managing mission critical systems fit in to this category. There’s the need to have a governance process that reduces the frequency of changes and improves the opportunity to catch errors before they reach the consumer.

In Mode 1 systems, there are many knowns, and so the relative degree of predictability is higher than in new and uncharted areas, where there aren’t established patterns for service delivery. Because of the greater degree of predictability, it’s possible to do better planning and structuring of Mode 1 systems. Mode 2 systems, by contrast, are generally chaotic and don’t follow established rules of how things should be done. Because of these Mode 2 characteristics, planning work and rules are generally less effective.

The velocity of iterations – whether you’re in a waterfall methodology or an agile methodology – is driven by the factors of ability to preplan, tolerance for risk and impact, and urgency of need. A low risk ofimpact tolerance slows cycle times and places a greater burden on each cycle to be “right.” This is convenient when it’s possible to predict and plan the operations – as in a well-established system. A low ability to preplan and a low degree of tolerance for risk and impact means that the costs will be high. This is particularly the case if there’s also an urgency of need.

Scenarios where there are a low (true) need for urgency, low risk and impact tolerance, and a high ability to preplan slow systems into Mode 1 operation. Increasing the tolerance for risk and impact – making failure ok – can move a system from a more Mode 1-like operation to more Mode 2-like operation. Even the “distinct” modes in the model aren’t distinct – they’re points on a continuum.

Our goal in IT is to continue to support responsiveness to the organization while balancing the needs of risk tolerance and impact avoidance. We classically have done that through breaking dependencies, minimizing coordination, and reducing batch sizes.

Breaking Dependencies

When you have complicated systems, you have complicated interactions between them. Systems with well-defined boundaries and contracts look like Lego building blocks. One system can be swapped out with another with minimal – if any – impact on the other systems in the organization. Unfortunately, this is rarely the case in practice, as organizations have connected systems in ad hoc ways. The need for standardization gave rise to the enterprise application integration (EAI) platforms in the 1990s. By defining the EAI or the even more grandiose services bus, the relationships between systems were supposed to be well-known.

Few organizations completed the massive work of deploying an EAI solution or a services bus before they ran out of energy. The work to plan for systems to be changed later and to optimize the interface between the systems was crushed by the realities of needing to deliver something to the organization today.

One of the CIOs I was talking to in this period told me that my project – a SharePoint Intranet project – was the only way that he could demonstrate any tangible value to his efforts for a services bus. For all the work he was doing breaking up dependencies, there was very little to show for it.

When the dependencies are reduced, it becomes possible to reduce the testing scope when you make changes to a system, and this substantially reduces the cost of delivering an update. The heart of reducing dependencies is defining the contracts between systems – whether you implement an EAI tool or not.

Minimizing Coordination

The three-legged race is a famous coordination problem. Friends, classmates, teammates, or members of the same group are paired. Two people each have one leg bound to the other’s. The result is a three-legged competitor. It’s amazingly hard to race in this configuration, as you realize the small differences between the way that you run and the way that the other person runs often leads to falling and tumbling over one another – rather than racing to the finish. This is the essence of the coordination problem.

In IT, we seek to minimize the coordination between systems so that we don’t have to take the cost of coordinating with other systems. Here, too, contracts are the answer. By contracting how the dependency and coordination should happen, you can identify those times when coordination will – and won’t – be necessary. This results in a lower cost of coordination and higher velocity.

Reducing Batch Sizes

Left to the pressures of low risk and impact tolerance, the natural bias of IT is to reduce the frequency that you cycle at. After all, you can absorb the extra testing costs if you only must do it once or maybe twice a year. However, this forgets that the business needs their changes now. To be responsive to the needs of the organization requires delivering more frequently. However, this is in conflict with the need to minimize risk and impact from changes.

Ultimately, this is pressure the CIO must apply to continue to maintain velocity while managing the risk.

Technical Debt

Sometimes the best way to improve velocity is to “buy down” debt. That is, to reduce the number of friction points which make it difficult to operate in shorter cycles. This might be improving the automated or unit testing coverage of an application to reduce the need for manual testing, or it can be retiring old systems which have high maintenance costs and are unnecessarily coupled to other systems.

“Technical debt”, the term often used to describe shortcuts which were taken but never properly addressed, can have a substantial impact on the velocity of the IT department.

Like Clockwork

Looking at a bimodal IT with slower-moving, more risk-sensitive projects and smaller, faster, less risk-sensitive projects is like clockwork. The pieces of the puzzle fit together and work together to provide a time-keeping instrument, even though not all the pieces move at the same speed. The use of different pieces for different needs, knowing where the gears will mesh, and accepting that some pieces will move fast and some will move slow if things are to work properly is like understanding how bimodal IT works. Some things should be Mode 1 and some things should be Mode 2.

Marketing Information Technology to the Organization

I recently had the opportunity to join the Indy CIO network as they meet each month to talk about issues facing CIOs. Recently the topic of marketing IT to the organization came up. It was a great conversation. What follows is one part notes from the meeting and one part my reflection on the conversation.

How IT is perceived in the organization is critical to its relationship to the rest of the organization. While it would be ideal if the organization would instinctively understand the value that IT can bring to the organization and view us that way, the reality is that it’s not that simple. It starts with the way that IT seeks to understand its broader context in the business.

Understanding the Business

If I had to pick one master theme that resonated through the statements of the members of this merry band, it would be that you must understand what’s important to the business. In my own world, I run into too many technologists that are in it for the technology. They want the cool toys and the shiny new objects. I’ll admit my own fascination with new toys (including the Microsoft HoloLens sitting on my desk for a project). However, I think that we sometimes get wrapped up into the newness of a SAN, a virtual environment, or a firewall and forget that none of these things matter to the business.

For most businesses, the IT function is a means to an end. FedEx doesn’t sell information technology, they sell information access to where your packages are. Starbucks isn’t selling their app, they’re not even selling coffee. They’re selling an experience. The organization doesn’t want an app. They want a way to increase the relationship with their customers.

Understanding that the goal is to enable and facilitate whatever the business does – and then learn what the business does – is critical to changing the relationship that IT has with the organization.

Taking Orders and Seats at the Table

It seems like some organizations have an IT function that is stuck in an order-taking mode. The business comes in the door complete with the solution they want, and it is IT’s job to deliver to that order. That’s quite obviously not the best place to be, since the business can’t know everything that the IT function knows. In this scenario, the organization isn’t valuing the experience and wisdom that the IT group is bringing to the table.

On the other end of the spectrum is a place at the table where the organization is defining new missions, objectives, and directions. Obviously, this is the spot that the CIO desires. It represents the business leadership’s respect for the CIO and the IT function. It means that the IT function can be prepared for impending organizational changes. However, few CIOs get this coveted seat at the table whether they are deserving of the honor and respect or not.

Along the path from order taker to table sitter are stops like being a problem solver, where the business comes and asks IT for a solution. In this case, the tables are reversed: IT comes up with the solution and offers it back to the business for acceptance. The problem is that this isn’t where you want to be, because it ultimately isn’t healthy for either IT or the business alone to create the solution.

A better approach is where the business and IT collaborate on a solution. The problem is laid out and the capabilities discussed. Solutions aren’t the domain of either the IT department or the business coming to them, the solutions emerge from the combination of perspectives and capabilities.

Earning your Seat

Strangely, you can’t get your seat at the table by asking for it. You can’t get your seat at the table, you earn it. You can’t earn your seat by helping with the direction, you have to earn it by nailing the fundamentals. Once you’ve resolved reliability issues, and reduced service times, and delivered projects successfully, then you can start to work your way into the position of earning your seat.

The skills that you need to be successful when you’re working with the organization as a valued partner in the business are strategy. The way to earn that position is in tactical operational execution excellence.

Spend Money to Make Money

Knowing the business means more than understanding the industry or even the organization’s niche within the industry. It means recognizing the personal preferences of the key leadership. Consider, for instance, the difference between an operational excellence-based leader who is interested in supporting the programs that reduce operational costs. Return on investment (ROI) is the mantra, and the projects that reduce operating costs are welcomed.

Conversely, in a sales-driven or innovation-driven company, operational excellence projects aren’t important. Saving on operational costs isn’t the name of the game, growing the top line revenue is. In those cases, IT organizations do well by positioning projects in terms of their potential to help grow the revenue of the organization, rather than how they’ll save the organization money.

It’s not that either approach is “right” or “wrong” – they’re just different.

IT Capacity Not Cost

Sometimes, the way to market IT to the organization is some subtle language shifts that drive a subtle change in view. In too many organizations, IT is viewed as an administrative department. As such, IT is overhead – a cost that reduces the profitability of the organization. Rarely is the IT department considered an IT function; even rarer is IT considered a capacity. Manufacturing organizations know that they have a maximum capacity for product production. Professional service organizations are aware that there are only so many hours in a day.

The capacity of the organization to leverage technology to reduce costs, increase throughput, and to improve customer satisfaction aren’t so easily measured. Shifting the language from department to function or cost to capacity may seem like something small and subtle, but these small changes can have profound results.

Marketing vs. Communication

At the end of our time together, it became clearer that the problem with IT wasn’t marketing; it was – and is – communication. We’re not trying to get the organization to buy IT, they’ve already done that. Our goal is to communicate the value that we are and can be delivering as an IT capacity so that the organization can better leverage the hard work that we’re doing.

We’re trying to connect to the rest of the organization through our communication, not persuade them to do something that may – or may not – be in their best interests.

We realized that sometimes the thing that CIOs don’t do is communicate the value of what they’re doing. But that has the potential to change.