A Business Technology Place

Cross Departmental Teamwork 101

Information Technology departments are often criticized for their lack of collaboration with other business departments. Is IT needed since technology equipment and software is a commodity? Everyone has access to buy equipment and software in the open market to help run their business electronically. But what you can’t buy in the open market is teamwork and collaboration. That comes from within the organization with people not with bits and bytes.

Mike Stiles, from Oracle, blogged about 5 Secrets to Marketing and IT Collaboration. The list includes “understanding the perspective of your peers” which is not something you can buy. Robert Thomas, of The Harvard Business review, calls collaboration an intangible asset.

For some workers collaboration comes natural. For others, it’s like pulling teeth! In my career I’ve learned three simple things about working together with others. I consider it a list of basics although it contains concepts that were not always apparent to me.

1. It’s not what you say, but how you say it that makes all the difference.

My goal is to talk in terms of ‘we’ and ‘us’ instead of “you’ and “I’ when working with others. Create a team feel from the onset of a conversation. Stay consistent.

About 16 years ago, during my first week of a new job, I sent an email to my new team members with some requests for information. I was working on a task from my new manager so it seemed harmless. But the email was not received well with others because it was filled with statements like “I need”, “I’ve been asked”, and “I will”.  That’s not team friendly! Thankfully, a team member worked with me offline to explain how the message was received. Lesson learned.

2. When reporting a problem, communicate with the person directly before sending an email and copying multiple people.

An easy way to put co-workers on the defensive and irritate them is by copying their manager and several other people on a communication to complain about something that needs attention. I’ve seen this approach repeated hundreds of times in my career. I’ve been an observer, a reader, and an initiator.

About a year ago I errored by replying-all to an email that did this very thing with me. Someone was complaining about services not given to them from the team and copied several executives. By me replying to all and acting a little defensive I only exacerbated the problem.  The good news is that I knew I had made a mistake as soon as I sent it. I called the recipient directly and apologized. It made a huge difference in reaching a solution.

In the book of Matthew (18:15) we find it written this way “”If your brother or sister sins, go and point out their fault, just between the two of you. If they listen to you, you have won them over.”

3.  Do you want to be part of the problem or part of the solution?

It’s easy to complain about something you see. But it takes a different level of commitment to offer solution ideas and to help solve the problem. A collaborative approach builds unity and teamwork, so offer to participate. Mike Stiles from Oracle recommends in his blog post, “Be the role model”. Be the one who reaches out to start communication. Be the one who offers to be part of the solution.

Here’s a good example: “We noticed that X is happening, can you help us to find out why” rather than “X is happening and your process to fix problems needs to change.”

Classic IT Challenges – Technology outside of IT

This is the seventh and final post in a series of writings to discuss issues facing Information Technology (IT) departments. If you have not read any of the first six challenges you can find them under project work vs production support, prioritizing work, operations vs innovation, estimating work, understanding complexity, and reducing costs.

IT shops vary in size, budget, and processes. But all IT shops share a common set of challenges that shape how they interact with their inter-company customer base as well as the clients of their organization. There isn’t a single answer to these common challenges and they don’t disappear after a process is put in place to address them. The manner in which IT management chooses to respond to the challenges is interwoven in the culture, processes, and services of the group. My thoughts are more around framing the problem than presenting solutions.

Challenge #7- Technology outside of IT

It’s not uncommon in a business environment for departments outside of IT to make their own technology decisions. This might include the purchase of desktop software or subscription to a software service platform. The IT department, with priorities to take care of the day-to-day operations of the business, may not have the capacity to handle new growth initiatives on a timeline that is acceptable to the business stakeholder.  Additionally, IT may not really be qualified to evaluate the business processes contained within new solutions. How many team members in IT are qualified to evaluate software that automates marketing campaigns?

One challenge for IT is if they are asked to support the new technology in some capacity. It’s a tough position to be in because the new technology may require a new skill set or training. Business stakeholders want support work completed as quickly as possible and without prior knowledge of the tool the IT staff is not positioned optimally.

Another challenge is if the new technology creates a duplicate solution within the organization. An extreme example could be the Marketing department purchases a tool to help them with customer list management for campaigns. But the Sales department has already purchased a different tool for this same function. That increases costs in total spend for everyone and increases the support complexity for IT.

Perhaps the biggest challenge associated with the introduction of new technology into an environment without IT input is integrating the new technology with existing systems. One of the primary goals of IT is to drive out costs in the organization through automation. One way to do this is to integrate systems so that information flows between the two without requiring manual touches. Integration usually requires programming and configuration.

Example

The operations department looks for a way to automate their quotes and job estimates to customers. The existing process they follow requires manual labor to deliver simple quotes for standard products. Management would like to eliminate this manual with a solution that allows the customer to find a price quote online. While the customer has to do work to find the quote themselves, the solution would greatly reduce the turn-around time of the quote. Operations purchases a solution in the marketplace and it does not integrate with any existing workflow programs within the company. Ultimately new project requests are created to integrate the quoting tool with the order management system.

The real challenge in all this.

Businesses must move forward to survive. For their part, IT departments must realize they have a finite capacity to produce work over a given time period and that often business leaders from other areas need to find solutions outside the IT service portfolio. On the flip-side, management should also understand that choosing technology without the input from IT can lead to difficult situations on the backside of the decision such as support, maintenance, and integration requests.

A technology solution is a means to an end, not the end. What’s the ultimate goal? It is to make money by providing a service that some customer is willing to buy. All departments share that goal. So the real challenge is creating a partnership to involve all departments during the selection process of new technology such that everyone supports the same objective.

Cast the bully out

We have a love-hate relationship with steering committees.

Do committees provide value that pays for the amount of overhead they create in workflows? If you are a committee member with voting privileges then the tendency is to support and agree with the both the decisions and procedural steps the committee follows. If you are a project requestor then your attitude about a steering committee is influenced by the amount of steps involved to get decisions as well as the amount of time it takes to reach a decision.

I have experience as both a committee member and a work requestor. I’ve observed both the value of a committee and the hindrance a committee can insert into workflow. A steering committee creates value when it buffers the amount of work that is given to a technology team to implement. The result of buffering work is protecting the downstream resources from becoming overburdened with too many concurrent tasks. Buffering work also prioritizes the backlog and technology team members want to work on what the business leaders designate as top priorities.

There is usually a bully, or two, that receives all of the attention of the committee.

But you’ve undoubtedly observed a myopic committee as well. There are usually one or two platforms/customers that usually receive top priority or seem get automatic approval. There is usually a direct correlation to the amount of revenue generated by the platform or customer and the committee decision.

Conflict arises when these projects take all available resources such that other projects or customers begin to starve for attention. A significant challenge exists for the employees who represent the smaller platforms and customers to be able to get work done. That’s not a good situation for the anyone. But the committee members feel justified because they have allocated resources to the work that tied to the most revenue.

Cast the bully out.

One way to remove the platform/customer that usually plays trump in the committee is to organize that work team around a hybrid technology model. In the hybrid model the business owner (product manager/customer manager) has day-to-day direction on setting priorities for the technology team. A centralized project management office can track the work backlog and work-in-progress (WIP). The business owner then reviews the WIP at the steering committee meeting to bring visibility and accountability to the direction and decisions of their group. So while the steering committee is not prioritizing work for the decentralized group, they do have visibility and the ability to influence work if needed.

This approach doesn’t work for all platforms and customers because that would mean that there are enough resources to have a dedicated technology team for each platform/customer. It does align the platform/customer work with the business line to promote a more agile approach to work. The business owners that used shared resources no longer get trumped by the bully projects. The bully projects are able to move more quickly because they don’t have the overhead of committee processing. It’s a win-win-win.

Steering Committee Bully

Getting IT outside the box

I think it’s safe to say that direct interaction between IT and Operations doesn’t happen enough. I’m talking about IT programmers, analysts, and project managers sitting with Operations and Manufacturing to understand their daily workflow with the intention of providing technology solutions to automate workflow and make it more efficient. Making that type of conversation happen isn’t easy. Team members are busy with tasks in their work areas. Many employees, by nature, seek solitude during the work day. Just look around your office and see how many of your co-workers eat lunch at their desk. (Are you one of them?)

It’s a good thing if the company IT group is close enough to the Manufacturing and Operations areas to make frequent interaction possible. Proximity provides opportunity, but it does not guarantee interaction among team members. Interaction requires initiative. Interaction requires boldness. Interaction requires an inquisitive nature. Interaction requires a desire to make the bigger whole succeed.

I recently organized a tour of the Operations Center with the VP of Operations for all new IT members. The objective was to show IT team members where and how their work output is consumed by the business. There’s only so much that we could cover in an hour, but I’d like to think that the participants found value in the hour. Many of them asked questions to the tour guide. A few of them made comments to me like “I never knew all this was here”.

But this tour isn’t enough. It needs to be the start of an ongoing communication and dialogue not just an event on the calendar. One of my objectives as a department leader is to bring people together to find solutions that benefit everyone. IT and Operations is one example. But the concept really applies to all cross-departmental relationships.

Note to self: Bring people together to find solutions to problems that make people successful and make the business successful at the same time.

The thought for a rover employee

The Big Picture
One of the main functions of a technology officer is to align the organization to grow revenue while at the same time reducing expenses and providing customer service. Thinking about the big picture of profitability and operating efficiencies is like looking at a pile of legos and having the vision to know what an organization can build with them. A popular business idea is to “build with the end in mind.” That’s the big picture. It is more of a journey than a destination. .

Painting the Big Picture
But what about the day-to-day activities in a technology environment? How do organizations do the work to paint the big picture one stroke at a time? I don’t believe in a one set answer or script for operational activities. I do believe that as with the marketing, technology processes and steps have an element of try, measure, and adjust in them. In practice, we want to align the activities with the greater goals of revenue growth and cost efficiencies.

Helping the people behind the technology
This past week I met with team members in my company to understand how work flows into, through, and out of their departments. As each team member shared the work flow with me they pointed out areas where technology solutions could help to make their jobs more efficient. I couldn’t help but see that it is on the front line where small changes can help make big differences in customer service and work throughput. Good customer service ultimately yields repeat customers which then yields the bigger goal of increased revenue. Increasing work throughput creates efficiencies which helps the bigger goal to reduce costs.

The challenge is that the bigger projects and tasks often compete and win the time-share with technology team members. So how do we align and justify shared technology resources with smaller process oriented projects? How do we align shared technology resources with other employees in the organization that are on the front line with customers or that need help making their work areas more efficient?

What about a rover employee?Rover
In my professional experience I have seen some organizations solve this through time allocation. For example try to align technology team members with 70% of their time on projects, 20% on smaller tasks, and 10% administrative activities. In theory this type of resource allocation helps to keep some areas from starving while at the same time spending the greatest effort on the most impactful activities. What usually happens is the larger projects become resource hogs and almost 100% of the team’s time.

In softball with 10 players, the defense will use the 10th fielder as a rover. The rover positions themselves in a different location of the field depending on the batter. So they become a flexible player that helps the defense by working in multiple areas.

What would happen if organizations could create a rover employee with the job assignment to meet with inter-company departments to help identify, solve, or champion projects that create automated workflows? Could a position like this pay for itself by creating enough efficiencies that it drives more cost out of the organization than it costs to fund the position? Could the position identify many activities that could be solved without custom programming or large projects?

What would happen if an employee could spend two weeks in each department learning their processes and then working with them to automate those processes. How knowledgeable of the business would this employee be at the end of moving through each department and what type of leadership would this employee now be able to offer?

Could it work? Would it work?