9 Ways IT Can Ruin Its Relationship With The Business- Valutrics
Aligning IT and business units sounds fantastic in theory. But when the rubber meets the road, IT leaders face unique challenges as they strive to engage and collaborate with business-side colleagues. InformationWeek surveyed 100 IT leaders about their biggest mistakes. Here’s what they revealed about the ever-evolving relationship between business and IT.
IT leaders at large enterprises, government agencies, and healthcare organizations are all facing pressure to become agents of digital transformation. In fact, Gartner recently issued a call to public-sector CIOs to promote a compelling vision for digital transformation and make change inclusive across the business.
This is a call to arms that private-sector IT leaders have been hearing for some time as well, and thought leaders have even started referring to this unprecedented intersection of IT and business as “the new IT.”
It all sounds fantastic in theory, but when the rubber meets the road IT leaders face unique challenges as they strive to engage and collaborate with their business-side colleagues.
When we polled IT leaders about their biggest mistakes in the past 12 months, challenges in working with the business emerged as a major source of pain. Here we take a look at nine mistakes IT leaders said they’ve made in their efforts to align technology goals with business needs.
These include the usual faux pas, such as failing to involve business stakeholders early enough in a project. But the list also reveals many unintended consequences of letting the business get too involved in the process of technology decision-making and implementation.
The mistakes we’re highlighting here are drawn from responses to our annual InformationWeek Elite 100 Executive Research Survey and have been anonymized to protect the innocent — or the guilty, as the case may be.
Every year, InformationWeek releases the Elite 100 — a ranking of the nation’s most innovative users of business technology. As part of the process, we also conduct the survey, which offers a unique glimpse into the strategies of these 100 large, leading-edge IT organizations.
The survey, which is open only to Elite 100 applicants, polled US-based companies and higher education institutions that have $250 million or more in revenue. Subsidiaries with revenues below $250 million may apply for the Elite 100 if their parent company has qualifying revenue and their parent company did not apply. Federal, state, county, and local or municipal US agencies are also eligible to apply.
Too Much, Too Late
Communicating the value of a major IT project can be tricky. How often do you update business stakeholders? Is it ever best to wait until the end of a project before communicating business benefits?
The IT organization at a large healthcare organization learned the hard way that more communication is generally a good idea.
This organization was working with a single consultancy firm to implement an important new initiative. As part of the deployment plan, users were going to see several new capabilities delivered all at once at the end of a waterfall development effort.
However, this created an issue among users and project stakeholders, who were expecting to see value in increments throughout the process. According to the implementation plans laid out in advance with the consultancy firm, the value of the project was scheduled to be demonstrated several months after it started — a lengthy time frame for the stakeholders.
The organization learned its lesson. All future initiatives have factored in the release of demonstrable value to internal customers in smaller increments, which allowed for business assimilation and readiness, as well for justifying the expenditure on the initiative.
Missing The Big Picture
The selection and failed implementation of a human resources analytics solution taught one IT organization some important lessons.
For starters, the process team in HR drove the selection of the preferred technology. The selling point for the proposed solution was “out of the box” HR metrics reporting. As the project unfolded, these metrics failed to meet the organization’s needs. It also became clear that additional data repositories — contained in other analytics apps used in the organization — needed to be replicated into the HR analytics solution.
The end result? The organization got a siloed HR solution and technology that doesn’t meet the long-term needs of the organization.
Lesson learned. According to this survey respondent: “We should have worked closer with the HR team to look at other data areas outside of HR that they may need in the future, and provided a more strategic view of alternative solutions.”
Lack Of Alignment
Alignment with the business side of the house is practically a mantra in forward-thinking IT organizations these days. One IT organization undertook a project to build a global, company-wide billing system, all while adopting new agile processes at the same time.
The project cut across the finance, IT, and business sides of the company. There was only one small problem: All these players were not fully aligned at the outset. As a result, there were differing opinions about methodology and key objectives, which slowed down the process.
The lesson? Make sure you’re aware of all the stakeholders involved. Something that may appear to affect only one department could have far-reaching consequences. Do your due diligence at the outset to make sure you’re accounting for all the players who may have a voice in the outcome of your project.
Some of them may not be obvious at first glance. Once you’ve identified the key stakeholders, get everyone involved as early as possible to manage expectations and account for unforeseen demands.
Letting The Business Take Over
We all want to play nice with our business-side colleagues. But sometimes things can go too far.
Such was the case for the IT organization at a large government agency, which allowed a business unit to maintain the primary relationship with a critical enterprise IT system. This created a lack of boundaries, with the business unit taking on technical issues best handled by IT.
Ultimately, the business unit couldn’t deliver the change management and overall product management required to roll out the solution to all stakeholders.
While much has been written about the need for IT to align with the business, this is a perfect example of a good idea gone wrong. Alignment does not mean relinquishing all power. IT needs to constantly communicate the value and experience it offers in handling change management and product management. Leaving these factors up to business colleagues who may not be prepared to handle them can be at best a recipe for extreme disgruntlement and at worst an utter disaster.
A Rigid, Time-Consuming Rollout
Here’s an example of what happens when flexibility is ignored.
One organization undertook an enterprise ERP implementation program in order to streamline business processes and tools across the enterprise. Implementing one technology solution across global operations required significant cost and time in the design phase.
However, business processes continued to evolve throughout the company, even as IT proceeded with the lengthy, corporation-wide initiative. As a result, when the solution finally was ready, various business groups were not prepared to implement the single global process. This meant the implementation had to be put on hold after considerable expenditures.
Organizational readiness and managing continuous change are the most important lessons learned for this respondent. The organization plans to avoid similar problems in the future by pursuing a flexible and agile approach to design and rollout for large and long-duration programs.
Bad Forecasting
It’s far too easy to overlook the details when forecasting the anticipated expenditures involved in your IT roadmap. This enterprise IT organization thought all the bases were covered in its forecasts for operation and management (O&M) spending related to IT projects for the year ahead. While the broad forecast certainly accounted for many associated capital expenditures, it left out certain key O&M projects. This meant important project elements hadn’t been budgeted for in advance, and the existing budget was stretched thin to cover more than originally intended.
The group learned its lesson. For the next IT budgeting cycle, this team partnered with controllers and business units, and conducted separate education and cultural reinforcement to ensure discrete forecasted funding for individual O&M projects.
Making An M&A Mess
Most IT professionals who have been through a corporate merger or acquisition probably need treatment for post-traumatic stress disorder. There’s nothing easy about mashing up the IT infrastructure, applications, and processes of two distinct business.
During a major acquisition, one survey respondent said there was pressure from the business side to slow the IT integration process. Business leaders believed taking things slower than originally planned would mitigate any potential ill effects of the changes on employees in both companies.
While the IT organization complied, in retrospect this respondent said they should have done more to explain the negative business impact of a protracted integration process. By not acting, the IT organization was delayed in rolling out systems-based financial controls and other critical systems.
Fortunately, the group was later able to expedite the integration with strong support. Still, the experience will influence future planning at this company. For example, IT will be more assertive about communicating the business effects of various IT scenarios before agreeing to any scheduling changes.
Overestimating Your Business Resources
In an ideal world we’d have IT and business colleagues working side by side on important technology initiatives. Often overlooked in that scenario is a realistic assessment of the workload involved for each group.
One organization had the best of intentions in inviting business units to participate in the project life cycle for new technology initiatives. Unfortunately, the IT group overestimated the capacity of the business units to participate in an ongoing way. As a result, project schedules had to be reworked, ultimately leading to delays to progress.
The lesson for IT? It’s important to be aware of the time constraints and other resource limitations your business colleagues may have before engaging them in project life cycle. Have honest conversations with your business stakeholders about what’s possible — and what’s not — given their other workplace commitments.
Believing The Budget Story
One IT organization was forced by the business to delay the critical rollout of its e-commerce portal by six months. The delay was due to perceived opex budget constraints, even though the capital cash investment for the project had already been made.
As a result, customers and sales teams were unable to take advantage of significant functional and performance enhancements built into the new platform and solution — improvements that would have helped the company’s bottom line. Instead, six months of potential benefits were wasted.
Budgets are a tricky topic for IT professionals. It’s often difficult to push back when the business forces budget decisions upon your team. At the same time, a delayed project could ultimately mean lost revenues for your company. When faced with such a dilemma, IT leaders can consult peers at other companies, read case studies on similar projects, and apply past experience to explain the value of a project — and the potential losses caused by a delay.
Taking the time to prepare a case that illustrates why a delay would be detrimental could free up the dollars you need. If not, at least you know you tried — and you’ve laid the groundwork for the next time you’re confronted with such an issue.