How to Master Cross-Departmental Collaboration in 5 Steps?

Cross-departmental collaboration is one of the biggest challenges for project managers implementing Lean and Agile practices. No doubt about it.

The literature on the topic, however, often prescribes intangible and impractical ways to deal with this challenge. You will read about "eliminating dependencies", "forming cross-functional teams", "getting rid of silos," and so on.

While these are somewhat viable solutions, we believe there is a better way. We think so because breaking your entire organization all at once, with the hopes that it will be better someday, sounds too risky and hard to justify. We prefer the path to continuous improvement and the "take one step at a time" mentality.

This is exactly what we offer with this article - a step-by-step journey to improving your cross-department collaboration.

Step 1: Get People to See People

You hear so much "trash talk" about silos that you may actually believe they're inherently bad. In fact, there's nothing wrong with silos, as they allow a business unit to operate efficiently and somewhat independently from the rest of the organization.

The challenge with silos is how you integrate them so that collaboration is not hindered too much. It's a trade-off: too much integration means less efficiency and independence; too much efficiency leads to bad collaboration. It's a fine balance!

The very first thing you can do about this is to make sure the people from the various silos (departments) know each other. This is the most trivial advice ever, but it's a fundamental one.

You may run a series of team buildings, special all-hands events, or find other creative ways to bring people together, but the goal is clear: get people to care about each other. Communication does not equal collaboration, but people will usually default to helping their colleagues if they know them. Besides, there's no collaboration when a person sees an object on the other side of the line.

Step 2: Create a Map of Your Services, Including Cross-Department Ones

When people see people, things are a bit easier, but frankly, the journey is just beginning.

Let's take a look at a typical restaurant. They have a capable team of chefs, waiters, delivery people, and so on. However, you must have had a cold dish at least once in your life, haven't you?

Going back to the previous topic, the problems with silos start when the kitchen, the service, and the delivery need to work together. Everyone is doing great on their own, but when you need an integrated product that results in high-quality, warm food on the table, it gets tough.

And that's a restaurant we're talking about. It's not an easy business, but what can we say about complex multi-million projects? That's where things get really ugly real quick.

So, what can we do about it?

Create a Map of Your Services

A service may be anything that a customer (external or internal) is willing to trade, usually for money or time. Taking the restaurant example again, popular services would be "food delivery", "takeaway", etc.

If the service language is not making too much sense for you, this article might help: How To Identify Types of Services on a Kanban Board.

Always start with the customer-facing services first and work backward. Each customer-facing service is most likely comprised of multiple internal services. Delivering food to your door requires someone taking the order, someone preparing it, someone delivering it, and so on.

It's always a good idea to have an eye on the separate sub-services, but what's important is the whole - what the customer sees. In the project management space, this results in services spanning multiple departments or silos.

Creating such a map (which can also be called a "value stream") in the knowledge work domain has been the subject of many technical and process solutions, but one method that has stood out in the last few years is Kanban.

In only ten years of existence, Kanban has managed to dominate the software industry, and it's quickly spreading across others. That is why, from here onwards, we assume the usage of the Kanban method and a professional project portfolio management platform such as Businessmap (formerly Kanbanize).

In Kanban, the definition of a service is the combination of one or more workflows and work types. For example, if your service is a car wash, the map would look like this:

There's a workflow with steps showing where each job is and a card representing that job. It's quite easy to see that there's a car going through an "OUTSIDE WASH" and a truck going through "DRYING".

If you manage a large industrial project, the map would obviously be a hundred times more complex. However, let's leave that conversation for later, as we've just arrived at the first important discovery:

• When you create a map of your service, you make it very easy for the workers to see what's going on and take action accordingly. If John is the worker responsible for the INSIDE CLEANING, he won't take a break right now, as the card "Car" is about to get out of the previous stage and his assistance will be needed.

Another benefit is that seeing what the status of all vehicles is, will likely prevent blaming the other stations for the delays that happen once in a while. It will be very clear where the delay was coming from. Moreover, if DRYING has nothing to do, they can give the other two stations a hand and prevent delays.

Isn't that a great example of cross-departmental collaboration?

Step 3: Scale the Service Maps (Value Streams) Across the Organization

The Kanban method treats organizations as a network of interconnected services. As Businessmap was first designed with the Kanban method in mind, implementing such value streams is possible, even if they span multiple teams or departments.

The idea is straightforward:

1. You create Kanban boards for all teams in the organization
2. You define rules that route work from one team to another based on certain criteria
3. For each service, you define the available capacity to address requests from other services
4. Where and as necessary, you add additional layers on top of the team boards so that you can allow sophisticated project management activities

The first step doesn't need a lot of explanation. Just go ahead and create a Kanban board for each team.

Define Rules that Route Work

The second step is a bit more interesting. When we know that certain teams need to collaborate, we designate a column on the board and label it "For Other Teams". Then, below this main column, we stack all the sub-columns that correspond to the teams we need to request work from. You can achieve this same behavior with a single column, if you prefer, this is just an example.

It's always a good idea to explain when cards shall be pulled to the corresponding column. This is a great way to visualize your process policies in general and thus make them accessible to all team members? The description is available on hover of the column name and could look like this:

When a card is moved to one of these columns, it is automatically rerouted to the responsible team via a business rule. In this case, the rule looks like this:

The rule does the following: when a card is pulled to column "For Sales", it labels the card with the corresponding tag, sets a three-day deadline (we will talk about SLAs shortly), and moves it to the Business Development board.

Pro-tip:

You may have scenarios where a card on your board depends on a service delivered by a shared service team, e.g. procurement. In that case, you would create a linked card (relative) on the board of the procurement team.

A neat way to do this is using the "Related Boards" feature in Businessmap. It allows you to peek at other boards and locate your request's position without having to ask for status or bugging the other team.

Define Available Capacity

As a third step, we recommend using designated columns and/or lanes that indicate work requested by other teams/services. This is not mandatory, but it's a good idea because you will instantly know that other teams expect something from you. Apart from that, you can allocate a certain capacity for external requests and control how much time is invested in them vs. your regular planned work. This is configured using a work-in-progress limit (WIP) per lane, column, or even a particular cell.

It is highly recommended that you define the SLA (Service Level Agreement) for all work items flowing through your boards. This provides guidance on prioritization and makes your service more predictable for the people requesting work from it.

Apart from that, it is recommended to have a service owner who gets notified about new requests and is able to dispatch them accordingly. Such custom notifications can be achieved with the business rules engine using the "Card is Created" trigger and the "Send Notification" action.

"Scale-up" Your Boards

Businessmap has a unique feature called "Management Boards". It is a special board that allows you to connect multiple other boards to it. This allows you to see multiple workflows stacked one below the other.

Management boards can connect not only team boards but also other management boards. That way, you can create a hierarchy with unlimited layers so that you connect your strategic portfolio with the actual work being done on the team level.

Step 4: Establish Fit-for-Purpose Criteria

The last step to completing our guide to cross-department collaboration is creating systems that ensure our service is actually delivering the right products with the right quality and speed.

It is important to define fit-for-purpose criteria for two reasons:

• You can monitor the health of your service and address deviations
• You can run continuous improvement initiatives

We can't tell you what criteria you should define, as they are heavily dependent on the type of business and the whole business environment. Still, a few criteria that we use are:

• Service Level Agreement compliance (how much time each work item shall take based on the work type)
• Throughput (how much can we deliver on a weekly/monthly basis)
• Fit-for-purpose score for customer-facing services (e.g. customer support)
• Number of defects per release

As you can see, we track both internal and external services. This is the recommended approach.

Step 5: Implement the Right Compensation Program

The last step we would like to suggest is a bit of an art. How do you compensate the people across various functions so that you stimulate cross-departmental collaboration?

It's ironic that most compensation schemes out there stimulate working in silos, and that's a challenge. One metric that we see often is "utilization", meaning how many hours a day someone is working on a project. It doesn't take too much imagination to see that a person who's incentivized to work on a project full-time is unlikely to help other projects. Generally speaking, utilization is a metric you should be wary of.

The best advice we can give on this topic is to read Six Simple Rules by Yves Morieux and Peter Tollman. It will be worth your time!