For the last 15 years, I have focused on identifying and building new solutions that solve unique problems for public and private sector organizations. In that time, I have come across many obstacles causes gaps and finger-pointing between business and IT teams. Many of these gaps have delayed or impeded progress, thus causing quite a bit of pain for team members, stakeholders, executives and even customers as progress isn’t being made on the tasks at hand. Below I outline the six reasons I believe are the top contributors to the ever growing gap between business operations and IT that are possibly holding back you and your company’s digital transformation goals.
Conflicting Objectives and Strategies
In most large organizations, IT and other company business groups evolve in separate but necessary directions in order to accomplish what that division is tasked to. The IT group focuses more on the basic IT hierarchy as it relates to the needs on the overall business (network, security, email, hardware, software, back and front office, etc.). Business groups evolve to solve the needs the customers (marketing, products, services – e.g. consumer value). Based on this simple description, it would seem that both groups work together in a sort of layered or tiered model, with IT supporting the business and business supporting the customers. In reality, this is usually not the case. What you often find are siloes where everyone is working on their own projects with little collaboration with other groups.
Business teams normally look for an opportunity in the market to increase revenue, decrease costs, or improve performance. This can take the form of a new or improved product or service. It can take the form of automating previously manual processes, or it could simply be to phase out redundant or legacy solutions.
IT teams normally look to balance IT stability with incremental improvements to their tech stack. This is where the divergence rears its ugly head and we begin to hear rumblings about IT holding the business back from its digital dreams. This stability is necessary in a functioning organization and without it there would be chaos and constant executive escalations.
Business and IT inherently have different priorities given their perspective with the organization. IT’s basic function is tech stability whereas the business is focused on bringing new revenue and even disrupting current tech to make way for innovative ways to serve customers. This is where we typically see conflicts with the organization with finger-pointing on failed or delayed initiatives (“IT is holding us back” or “the business needs to understand this IT program is a critical initiative”). So how do we bridge the divide with not only different, but also conflicting priorities?
This is where strong digital project managers (PMs) can provide the most value as they have the deep technical experience and strong understanding of the needs of the business come in handy. Digital PMs are able to accomplish this through hands-on working sessions using the “post-it note” process to digital portfolio reviews that include stakeholders from both the business and IT to ensure priorities are aligned. There are many are tools that are available to digital transformation teams to bridge the gap which I plan to discuss in future posts.
Different Definitions of Measurement
Having spent a number of years in IT before moving on to management consulting and digital marketing of enterprise retail, I understand that different groups across an organization will define and measure success based on their own objectives within the organization. The IT team normally measure success in terms of the technology (uptime, page speed, bps) or project implementation (time, budget, scope). The business teams attempt to measure success in terms of business drivers cost reduction, revenue, leads, and profit. However, when IT and business groups come together to achieve a common goal such as digital transformation, their needs to be common criteria to define and measure success. From cloud migration to API implementation, success lies in the initial rounds of communication can ensure that end goals and KPIs are met.
In order to achieve communication success, the best approach is to properly onboard all necessary teams to the project so that they understand the business drivers of the project and can define IT metrics that can be tracked and support the overall initiative. For example, if the business driver is to increase customer account registrations by 50 percent over the next six months, IT would be expected to deliver a solution that removes a friction to the sign-up process (showing an increase in sign-up completions) and has been deployed to production (well before six months). Too often we see IT teams come to the table with a solution that takes six to nine months for implementation and is not focused on the business value (increased sign-ups in this example). By using an onboarding approach, both business and IT can have alignment on what is important (KPIs related to what should be tracked and measured).
Lack of Customer Understanding
Have you ever filled out an online survey or given feedback on the user experience on a website? If so, there is a very high probability that your feedback was presented to a few stakeholders in marketing, but never made it past that single presentation. When the planning for the next redesign or product iteration begins, all of that valuable customer feedback is either forgotten or deprioritized in favor of other stakeholder requests (executives, senior managers, and more). What is needed to solve this problem is a simple process to ensure that customer feedback flows into the release planning for the future enhancements. If these are paying customers, then their feedback should get pushed to the top of the list at least for a proper review.
Too Many Silos and “Fiefdoms”
Maybe it is my background of working with the military and law enforcement throughout my career, but I found myself accustomed to always have a senior officer, commander, or even civilian manager that could resolve disputes between two different but equal groups. In the private sector, this is a luxury that I sometimes miss dearly. The many siloed organizations; the fiefdoms that spring up to protect a manager or executive’s personal priorities are the very obstacles that block true digital transformation as these fiefdoms fight progress for the whole in favor of the status quo for the few. Until these silos are knocked down, true progress cannot be made to bring an organization into a digital 21st century. In many cases, the only option is to spin out a “tiger team” that is completely separate from the larger organization to is then capable of delivering the true promise of digital transformation.
Access to Data and Services via Easy-to-Use APIs
In looking at the success digital and tech projects that I have led and been at part of throughout my career, I can see a common thread across all of them: access to data via easy, simple APIs. This allowed our teams to quickly prototype ideas throwing out the bad and keeping what works for continual improvement. The APIs were available with simple web-based documentation, there was no need to set up a project to access the API, and there were no “gatekeepers” exercising an API tax (this is more common in larger organizations and one of the main causes of failed integration projects).
There are quite a few API solutions that are available that make this digital transition APIs to easier. But first there needs to be a top-down directive that all data within the organization will be accessible via API and there will be no “walled gardens” or project “taxes” to access these APIs. Amazon took this approach in early 2002and we see the results. I am ended this post on this topic and the outline of the Jeff Bezos’ directive because I believe this is most critical point to digital success:
- All teams will henceforth expose their data and functionality through service interfaces.
- Teams must communicate with each other through these interfaces.
- There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
- It does not matter what technology they use.
- All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
- Anyone who doesn’t do this will be fired.
I will add one final bullet from Steve Yegge’s Google platform rant that I believe is critical for anyone that reads this post, works in an organization that has not begun its digital transformation (or in the midst of transformation), and does not feel a sense of urgency: