Outsourcing best practices: How to manage agile collaborations with challenging clients

Let me begin by saying this: in outsourcing partnerships, it’s not the clients that present a challenge, but communication. Which is quite tough to master in general.

This article is based on a presentation I gave at Agile Warsaw where I presented some best practices we have implemented at Sunscrapers to deal with communication issues in client collaborations. You can watch a video recording of my talk here (note: it’s in Polish):

Communication problems are something every IT project manager gets to deal with at one point or another. Acting as the bridge between the development team and the client is full of challenges.

And while adopting the agile methodology helps to solve some of them, it brings forth many other communication issues.

Here are some common communication problems I encountered in when serving our clients as a project manager - and how to solve them.

Let’s start with the traditional vs. agile approach

We all know how the traditional (waterfall) and agile approach differ at the high-level: we know the time and budget, our approach to quality never changes (no compromises in terms of quality), and the only variable is the range of functionalities that we deliver.

Not understanding these foundations correctly may cause problems in cooperating with clients. And it doesn’t matter whether we’re talking about an internal client (where the primary stakeholder is inside the organization) or an external client (customer in the traditional sense of the word).

We’re all probably familiar with these stages in the project life cycle according to the AgilePM standard:

• pre-project phase,

• feasibility (feasibility study),

• foundations and regular development,

• deployment,

• post-project phase.

Here’s the trap:

Problems in cooperation with the client may appear at each of these stages in the project’s life cycle.

Find out more about traditional and agile approaches here: Agile vs. waterfall – what’s better for my business?

Communication issues

Clients may ask you challenging questions. Just to give you an idea, here are a few examples of questions I got from clients:

• Why is evaluating the project difficult?
• How come you have no idea what you’ll be doing after 6 weeks of working on the project?
• I understand you work in agile, but why do you need so many meetings? Focus on development instead!
• How did you prepare the quote when now the project exceeds the budget?
• I get it, you work in agile - but why can’t you provide me with an accurate work schedule?

But that’s not everything.

Here are some more problems that arise in collaborations based on agile:

• Overengineering - teams following the agile methodology should never compromise on quality. But that may stand in conflict with another agile principle, "Focus on the business needs," and often lead to overengineering.

• Dealing with a client who refuses to prioritize features into “must have,” “should have” and “could have.” The client claims that everything is a must have. Once the team starts working, the client asks why they started with that particular feature. Well, if there are no priorities, it means that all tasks are equally important and it doesn’t matter where we start, right? Wrong!

• The business sponsor has not been involved for a long time in the project. And when they enter the project at the final stages, it turns out that the original idea was completely different. The business priorities of the organization have changed, and despite the project’s agility, it didn’t meet the organization's expectations.

Read also: 7 Agile best practices you should know

Let’s go back to agile now

When building software and managing development teams, we place:

"people and interactions over processes and tools,

operating software over extensive documentation,

cooperation with the client over formal arrangements,

responding to changes over following a plan.”

(As per the Agile Manifesto)

All of them have one common denominator: communication.

It’s all about needs analysis, discussion, definition, confirmation, redefinition, and conclusion - all of these elements are part of interpersonal communication in projects.

The Agile Snowman shows us the many parties involved in the work of the Solution Development Team. But the scheme misses a few other roles that are part of the process. In fact, we often forget to consider stakeholders such as clients, end users, or the management board.

And that’s the origin of our problem.

You’re probably wondering:

Ok, so what am I supposed to do when collaborating with a challenging client?

My answer is:

Examine your communication style.

Perhaps all these problems arise because we fail to communicate effectively? Maybe we just prevent the team from interacting correctly with the client?

Perhaps we stopped cooperating and instead we started treating the client like an enemy (for instance, by becoming defensive, or offensive - which is even worse)? Maybe we were ignorant about the organizational culture of the client?

Don’t forget that many of our reactions are processed unconsciously at the level of our reptilian brain that tells us how to survive and deal with problems - whether to confront them or escape.

Once we become of aware of that, we can control our reptilian brains.

Solution

This method helps me a lot:
Empathy & Acceptance Mechanism

Acceptance is a process that allows making our interlocutor feel accepted. They need to feel comfortable during the conversation. Acceptance isn’t just one sentence we say to them. It’s a process that can last throughout the entire conversation or even all communication stages during the project lifecycle.

Here are some handy acceptance tools:

• paraphrase
• admitting that someone is right,
• giving someone a right,
• apology,
• identification with emotions,
• social proof of being right.

In my experience as a project manager, I found that these tactics help to eliminate the problems I’ve mentioned before:

• Engaging relevant stakeholders at the right time during the project.
• Encouraging the active participation of business representatives.
• Building a team unity culture, creating an atmosphere conducive to taking responsibility for the work (we take responsibility = we start thinking from the product perspective).
• Decision-making in the team and competencies appropriate to represent people (the agile team can decide on its own to avoid waiting for input from others).
• Before we begin the cooperation, we need to define expectations regarding quality. That’s how we ensure that quality doesn’t become a project variable. It’s good to explain to stakeholders what project variables are in agile.
• Formal assessment of priorities after each product growth (after every sprint) - that’s something we often forget about it.
• Construction of the first critical path (because we want to deliver a working MVP).
• Feedback is essential after each growth phase, especially from the business side. Involving business stakeholders in the high-level sprint review process is smart.
• Being transparent in communicating the process/progress of the project (both inside and outside the project).
• Avoiding antagonizing communication.

Conclusion

There are no problematic clients, only communication challenges. But project managers can address them using the communication tools and practices I presented above.

Agile is an excellent methodology for organizing software development projects, but it comes with its fair share of challenges too. Ultimately, we can address them by paying more attention to how and when we communicate with the client.

Looking for a new challenge? Join our team as an IT Project Manager - we’re hiring!

Read other articles in our series Outsourcing best practices

• 6 tips for coordinating internal and external development
• How to outsource R&D projects
• How to manage agile collaborations with challenging clients

Do you want to know the pros of using an external service provider for your software project? Be sure to read this: Benefits of outsourcing IT services.