Bridging the Gap Between IT and Business

Usually, people who are successfully able to straddle both business and IT worlds are the ones who have a technical background, but have developed an understanding of business through experience. Someone who has worked on a particular set of applications for a period of time will tend to naturally gain an understanding of the business implications of their work. That’s a good starting point for you to easily apply your knowledge in the business world.

It is considerably more challenging for someone to transition from a more business-specific background to IT, which may require specialised technical knowledge. Gone are the days when IT was purely managing applications and Infrastructure. With new roles such as ‘Chief Digital Officer’ becoming increasingly common, the industry is looking for people who can translate the capabilities of IT into driving the business. The new “digital” approach focuses on customer experience, a user-centric approach, and decoupled architecture to name a few. Some companies are even merging CIO (Chief Information Officer) and CDO (Chief Digital Officer) roles, because nowadays the IT that’s relevant to a business is more digital than technical.

To get a deeper understanding of the IT systems, you’d need to invest around three to five years into working closely with internal IT teams. While you can continue to be part of the business teams, you could start getting involved in IT project management, where you could try your hand at overseeing a project from start to finish.

Weekly and monthly governance meetings can help you understand the intricacies of the technology work and the way it is getting executed. Keep an eye out for potential pitfalls along the way, as well as the timelines for delivery. Your perspective will add in hordes of value in making sure the project meets the company’s stated business goals through this project.

I spent about 10 years in core IT before transitioning to a more business-related role. I started by managing different projects and understanding the overall project life cycle. This included translating the vision of the project into IT components, planning and executing the delivery, and ensuring that the project is delivered on time. I was also involved in budgeting, meeting (or even beating) the defined KPIs, and managing the people who were executing the project.

From a few projects, I gradually moved on to managing clients and portfolios. Given my deeper understanding of technology, the transition was smooth and successful.

Understanding the context in which the technical product or services that you’re delivering is very important for you to go from good to great. All businesses have a few baseline functions: Sales, Marketing, Operations, HR, Finance, and IT. Together, all of these teams work to bring a product or service to the market. As an IT person, knowing how you fit into the bigger business goals Is an important element to be successful.

Core Principles

Broadly, companies look at implementing new systems to achieve one of two objectives: cost optimisation or driving growth. If you’re brand new to business, looking at IT’s role in fulfilling either of those objectives for the business would be a great starting point

Any IT professional knows that there are three main parameters with which to measure the success of a project execution: Cost, Quality, and Timeline. For any project that is executed ,there is a cost for the services provided, an agreed upon timeline for delivery, and the expected quality of the deliverables.

The key thing about this model is that it isn’t restricted just to IT. As an IT professional, all you need to do is to take this familiar paradigm and apply it to the company’s larger business goals. The core principles remain the same! For instance, If you don’t keep to timelines, from a business perspective, it could impact how soon a product or service can be released to the market, which directly affects revenue. Similarly, poor quality products and services generate nothing but bad press, a bad reputation, and unsatisfied customers – never desirable in a business.

Let’s look at a few examples. We’ve all seen the news – certain mobile phone models with battery problems causing fire hazards. In this case, the product had to be recalled and brand image took a big hit. This is a case where poor quality control led to a fault that impacted the business in a big way.

Now take the example of a retailer that is slated to launch their first ever ecommerce website. Let’s say this brand and its physical retail stores are only available in Singapore, but with the launch of the online store, markets can be expanded significantly There’s a lot of social media buzz and customers are excited to explore the online store. However, imagine if, on the launch date, the website can’t go online because of some technical issues. Not only will this hamper the growth plans of the brand, but it could also affect the image of the brand. Customers’ trust, which takes a great deal of effort to build up, can be easily lost.

In one of my previous projects, we were helping a client in transforming their legacy systems to new technologies. Project delays pushed the timelines multiple times. As a result, the entire team had to race against time to get the new system ready, as the legacy system would not be supported beyond a certain date.

The moral of the story in each of these cases: treat an IT project like an IT project and you risk losing sight of the larger impact the project has – on your company, its growth plans, your clients, their customers, and the cost impact. Take your blinders off and look at your work in the context of the business. Just because you’re in IT doesn’t mean you have to exist in silos.

Getting Involved

Oftentimes, the real impact of delayed projects is not assessed holistically. Why is this so? It’s a two-pronged problem. On one hand, people in IT need to develop a better understanding of the business by getting closely involved with the business teams. On the other hand, people representing the business functions task IT with projects but don’t actively participate during the execution phase.

As an IT professional, you can start by thinking about how you’re engaging with your colleagues who are involved in the business functions. Get them on board much earlier on in the cycle. Agile methodology is quite a popular technique nowadays, where a tech solution is built feature by feature and the business can get a sense of how the product is shaping up and it can be tested at each stage by users and stakeholders.

The more you open up channels for feedback at earlier stages, the better you’ll be able to understand how business people think and how the product features are matching up to their business requirements. This will also help in reducing the need to rework what you’ve built at a later stage.

Early intervention is the new norm. Gone are the days where IT projects are built for longer duration on a typical waterfall model and the users can get to see the output only after the entire product is built.

Mindsets

All of this links back to mindsets. Do you, as an IT person, understand the end objectives of the projects you’re working on beyond just getting a technology solution up and running? How does the work you’re doing help your business, clients and employees achieve certain goals? To understand this, you must have a mindset of curiosity – to ask the right questions, and the willingness to get Into details.

Nowadays, before they start building a tech solution, you’ll find that IT teams are asking their business users to gather and explain the business process to them. They would then use service design concepts to design their solution such that it actually solves real problems that users are facing.

For example, let’s say you’re building a customer relationship management system. First you’d have to talk to your key stakeholders, for example, your sales teams. Then, you should look at asking your salespeople what their pain points are, and what would help them do their job more effectively.

“Unless you understand why your end user is using the product in the way they’re using it, you won’t be able to build a solution that actually helps them. ”

Don’t hesitate to walk a mile in your user’s shoes. If you’re working in a pharma company where your salespeople need to go to hospitals and meet with doctors, why not join them to understand the sales process? If you’re building a tech solution for a production line, spend some time on the shop floor. Being able to see your user’s journey for yourself will put you in a better position to understand how to solve their problems.

Now on to timelines: try to proactively understand what business timelines you’re working with in addition to IT project delivery schedules. For example, you might be asked to complete a project by a certain date, but it doesn’t end there. Maybe there are some supply chain models need to be changed based on what you’ve delivered. Maybe online promotions or other such marketing activities have been planned, that assume that IT will deliver the project on time. Context is everything, and only when you make an effort to communicate with your business teams will you be able to make sense of what is at stake.

Rethinking Service Level Agreements (SLAs)

A chemical manufacturing company needs to ship their products to their customers within a very specific set of timings, and at a particular temperature. Imagine that, as part of the process, someone need to authorize the shipment in the system. There’s a problem in the system which is preventing the user from successfully logging in.

What can a user do? They call the IT support staff, and a ticket is raised. It’s a priority 1 ticket, which means that the IT staff should work towards resolving the issue as soon as possible. The applications support team resolves the issue within the Service Level deadline, but the issue also needs a fix on other components that are part of the application.

Since the SLAs are not treated at an overall ticket level, but by the type of support , the overall time to solve the ticket takes longer than the Service Levels, though individual teams did their part within the SLAs. As a result of this delay, the materials are damaged and losses are incurred. It’s no wonder that a lot of users feel that IT support staff aren’t actually helping them.

There’s a situation in IT we call the ‘Watermelon Effect’, wherein everything looks green from the outside, but when you crack it open, it’s all red. What does it mean?

IT systems have various components that work together: the application that a user sees, software, hardware, network, operating systems and so on. When a user reports that something isn’t working, the problem could exist in any of these components. A simple example: you aren’t able to connect to the wifi. This could be due to a problem with your laptop, the network, your router or the service provider.

To isolate the problem, you’ll need to go through each component and raise tickets at every stage. Each of these various teams have their own SLAs. So even if each team is hitting their SLA targets, the end user is not getting what they expect. So instead of looking at SLAs for your various IT components, think about looking at business-level SLAs instead.

What is a business SLA? Suppose you have technology to facilitate an invoice reconciliation process that happens every month. Instead of telling an IT person that they have 4 hours for a Priority 1 incident, take a broader approach and try to think from a business’s perspective. What does the user need? To reconcile invoices by a particular time at the end of the month. A business SLA would span across various IT systems, be it hardware, software, or applications. That means that if the system is down, all teams have to resolve the issue within a specific timing that serves the end user’s needs. In this case, your business SLA could be a percentage of invoices need to be reconciled each month without errors.

With Artificial Intelligence (AI) and Robotic Process Automation (RPA), you can now even use technology to move these tasks away from IT teams so that they can focus more on complex and strategic objectives. Look at the kinds of support that your customers are seeking. Are they largely non-critical, instruction based tasks? If so, are the solutions also fairly standard? If your answer to these questions is yes, then consider using AI or RPA to automate these functions.

Ask The Right Questions

Similarly, a big frustration for most people supporting IT applications is that all the incidents that come their way are Priority 1. Users always want to have immediate attention to their incidents, hence they feel that raising a Priority 1 incident is the best way.

Business users need to understand that the IT resources are finite and they need to be used efficiently and effectively. In order to address this problem, IT and Business need to sit together and have a common understanding of the classification process. Again, this needs to be tied back to the business criticality to make it effective.

So when you’re building an IT system, make sure you’re asking critical questions such as:

• How important is the process?
• How many end users are involved?
• What is the peak user load?
• Are there specific days/times that the system should not be down, at all?
• What would “good” looks like from a user’s point of view?
• What items would have maximum impact on the process, both positively and negatively?

For example, making sure that month end ledger closing should be of a higher priority that an intranet portal that is only used sometimes by internal staff.

Most clients will tell you they want 24/7 support for an IT system. But everything comes at a cost. Use your IT know-how to advise clients on how they can optimise their spend while providing stellar service to their users. Ask them why they think 24/7 support is crucial. Ask them how long their users can live with a tech issue before it becomes a serious impediment to the business.

If you find that most of their users are accessing the system during office hours, perhaps you could suggest IT support around those timings. You’d then need to ask who the key stakeholders are so you can help clarify service level protocols.

The salesperson at the pharma company example we talked about earlier? They would be visiting clients from 10am to 8pm, so you can isolate support to those hours. Compare this with the grocery e-commerce website, which needs to run smoothly at any given point in time, and therefore 24/7 support is of paramount importance.

As an IT person, you are in the best position to ask these questions and understand the business case. But don’t stop there. From this place of understanding, you can add your expertise to suggest ways in which to use IT to make the business even better. IT has to be at the center of business processes to truly add value. For an online store, you could suggest providing additional support for the relevant holiday seasons or even during specific sales as the usage of the systems are much higher than other times. Take a user-centric approach rather than treating it as just another IT implementation project.

If you’re looking to add value to the business, there are many ways for you to do so. It all starts with asking questions, communicating clearly, and understanding the business context of the solution that you are building.

1. Take Point on Projects

As a person responsible for executing IT projects, expand your understanding to business environments. Think of the solution from a user-centric approach and ask how it is adding value to the business.

2. Ask Questions to Make Technology the Centre of the Business

Ask your business users what problems they need solved. What are their pain points? How and when do they need most tech support? Who are their VIP users? How does the IT system fit into the larger business context?

3. Understand Cost, Quality, Timeline From a Business Perspective

Every IT professional is familiar with the Cost, Quality, and Timeline parameters. Take what you know and apply it to the business. You will figure out the gaps your IT systems to fill, and thus contribute effectively to the larger objectives of the organisation.