Scott Barrett, director at Axon Global, says getting business and IT teams to work together effectively is a challenge for many of his clients.

“I am surprised at how consistently I run into this problem from client to client. I keep thinking these are isolated problems, but they are really widespread,” says Barrett.

Over a 12-year career spanning operations, IT, and consulting, Barrett has accumulated a number of tips for getting the business and IT units to work together. In this article, he shares nine keys for managing that relationship in SAP projects.

Key #1 — Identify and Map Key Stakeholders

Under ideal circumstances, project managers would select their own stakeholders for a given project. Unfortunately, that just about never happens.

SAP projects in particular draw extra attention, according to Barrett.

“There’s a lot of money and a lot of people involved with big SAP projects, which means project managers end up having more stakeholders and review committees and steering committees,” says Barrett. “As a project manager, you want those people involved, but the key is how you communicate with and manage that group.”

Barrett suggests grouping stakeholders into three categories: influential stakeholders, high- maintenance stakeholders, and those who simply need to be kept in the loop of the project’s progress. Project managers should then formulate plans for dealing with stakeholders in each group and initiate one-on-one meetings with influential and high-maintenance stakeholders to formally address a working model.

“Ask them what their expectations of you are. You have these general project management expectations, and that’s great, but each stakeholder will have his own version of what that means,” says Barrett. “I think this step gets ignored a lot. People just take it for granted and assume they can work with each stakeholder the same way.”

Key #2 — Establish Goals for Business and IT Teams

It is often easy to get business and IT teams to agree on a high-level goal for a given project, Barrett says. Project managers, however, often fail to identify that team members will have goals within the project that may conflict.

“You could walk into any meeting and ask what our goal is, and everyone will agree that the goal is to get this project done in nine months. And everyone nods their heads. But then you have to lift the hood up and try to figure out what ‘get this done’ means and define some specific goals so when we are in the depths of integrated testing and find things we want to change, you know how to bounce those priorities off a specific goal,” says Barrett.

For example, the business team may be looking for a solution that will solve every pain point for a particular business task, while the IT team has to carefully consider the amount of customization necessary to solve every issue.

Barrett says many project managers identify these conflicts but do little or nothing to address them. Simply acknowledging potential conflicts — out loud — during the project’s kickoff meetings will go a long way toward designing team and individual goals for a project.

From there, a project manager can work with stakeholders to formalize individual goals for team members.

Key #3 — Create Shared Metrics

Once individual and team goals are created, project managers can use them to create shared metrics that will allow the team to track the progress of the project. These shared metrics should be clear to team members at every level — from upper management to ABAP developers working off-site.

The goal, Barrett says, is to avoid falling into the trap of using the overall project timeline as a shared metric.

“The metric is why we started this project. We didn’t start this project to finish in nine months — we started it to solve a business problem. You’ve got to get everybody bought in to how your work is going to impact that number,” he says.

For example, Barrett worked with one high-tech company on a $10 million SAP and business transformation project. Beyond the project milestones and other goals, an overriding metric was defined to measure the project’s success: Will this help us reduce our customer response time to one day? Each subsequent conflict was resolved by project leadership asking which decision would best help achieve that metric.

Key #4 — Keep the Project Team Small

Because of their scope and importance, SAP projects are notoriously daunting. Barrett says many project managers make the mistake of equating the enormity of the task with the necessity of a huge project team.

In fact, he says, small groups are often responsible for completing the most successful projects.

“The mistake I see people make is to say they need 40 people to make this project happen, and then they just divide all those tasks between the people and have everybody work together in one large bandwidth activity,” says Barrett.

A better approach is to divide the team into smaller groups of three or four people and assign them smaller tasks that may only take a few weeks. Barrett calls this approach “massive parallel processing.”

“It allows them much more freedom and speed to quickly iterate through their piece of the project,” he says.

In order for this approach to be successful, however, the project must be one that can be divided into digestible chunks.

“The trick is to make sure you can break it up into pieces that don’t get siloed. You don’t want to set teams off for the duration of the project. You do it in stages,” says Barrett.

Key #5 — Co-locate the Team Whenever Possible

It is more difficult to resolve conflicts when the business and IT teams are scattered across multiple sites. In some cases, even being in the same time zone or city isn’t enough, according to Barrett.

At one of Barrett’s client sites, the business and IT teams were physically separated in buildings only a mile apart, yet that distance was enough to stall the project. The teams had not seen each other face to face in four months. Moving the IT team into the same physical space as the business team solved the problem almost immediately.

“When we suggested moving the IT people to business cubes, all of a sudden the IT people felt more empowered, and they learned more about the business,” says Barrett. “The business team felt it was easier to get answers.”

Co-location isn’t always possible for the entire duration of the project, but Barrett recommends face-to-face interactions at critical times such as the project kickoff, design reviews, and integrated testing, as noted in Figure 1.

Figure 1

Co-locating business and IT teams at key points in the project

Key #6 — Avoiding Getting Trapped by the “Partial Headcount”

Project managers have a number of tools and methods at their disposal to assess the number of team members that will be required for a project. However, many projects suffer from what Barrett calls the “fallacy of the partial headcount.”

The central mistake, Barrett says, is attempting to replace one full-time business (or technical) resource with two half-time resources, or otherwise attempting to create full-time equivalents out of part-time work.

Because the demands placed on these resources from their existing jobs are never reduced, they simply cannot devote enough energy to the SAP project to match their expected productivity.

“That’s just reality,” says Barrett. “My message to project managers is that the sum of the parts does not equal a whole. Four half heads does not equal two heads.”

Barrett suggests that project managers weigh this reality when requesting resources for a project. If the business or IT teams cannot spare resources full-time, project managers should adjust their calculations up-front. For example, if there are not two full-time resources available, the project manager may request six part-time resources as an appropriate equivalent or plan for a slightly longer timeline or higher assumed risk.

Key #7 — Manage Outsourcing Better

As the use of outsourcing has increased, many project managers find it difficult to manage the relationship between in-house business resources and off-site technical teams. Barrett says business teams understand the advantage of keeping costs down with offshore help, but often have difficulty communicating with offshore resources.

The best way to deal with the issue, Barrett suggests, is to push for so-called “near- shore” options from outsourcing vendors. Resources at the home site suffer burn-out if forced to adjust their schedules to work with technical support teams in far-flung locales.

“We’ve seen that people who outsource for cost savings, and can find options close to their time zones, see much bigger productivity improvements,” says Barrett.

Key #8 — Craft Your Communication Plan

It’s become a cliché that communication is critical to the success of a project, but Barrett warns that simply communicating often isn’t enough. Project managers must tailor their communications to fit the audience, including developing different communication plans for executive management and stakeholders.

“You have to identify and figure out what these people want. Do your weekly status update as usual, but that shouldn’t be the only thing you do,” he says. “An SAP project might have 40 or 50 people at different sites, and they want to be included. They don’t want to feel like they’ve just been copied on an email to a senior manager.”

See Figures 2 and 3 for examples of ineffective and effective status reports.

Figure 2

An example of an ineffective weekly status report, which contains poorly-defined color items at top, redundant references to “achieved milestones,” and is too wordy for most senior managers

Figure 3

A clearer, more concise version of a weekly status report

Many project managers, for the sake of efficiency, default to a single communication method for all involved in a project — such as a weekly email. Barrett suggests diversifying this by delegating team leads to rotate sending emails to the project team.

“It’s not only a step for communication, it’s an inclusion activity,” he says.

Key #9 — Streamline the Tracking Process

Even the process of keeping up with a project can cause friction between the business and IT teams. Finding a common ground for tracking the project will help the project run more smoothly, says Barrett.

“Most of the companies I work with spend way too much time managing the project plan — none of which helps you deliver what you’re trying to deliver,” he says.

For example, project tracking software like Microsoft Project may appeal to IT project managers, but those on the business side may find it confusing or may not even have the program installed. Too often, the business side simply ignores project tracking tools that are too cumbersome or difficult to maintain, Barrett says.

To streamline the tracking process, Barrett suggests relying on the more commonly understood Microsoft Excel as much as possible.

Davin Wilfrid

Davin Wilfrid was a writer and editor for SAPinsider and SAP Experts. He contributed case studies and research projects aimed at helping the SAP ecosystem get the most out of their existing technology investments.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.