A program director will call a consultant easy to work with even if they can’t explain what they mean by it. Pushed to define the phrase, most reach for something vague: pleasant, low-drama, a safe pair of hands. That vagueness has led to treating “easy” as a synonym for agreeable.

Barrick and Mount’s 1991 meta-analysis across five occupational groups found conscientiousness was the one Big Five trait that predicted job performance consistently across every group studied, more reliably than agreeableness did.

Reliability and follow-through align with getting the work done well, and that, looks like what a program director actually means by the phrase.

Pressed further, most describe something closer to this: a consultant who catches a design gap in Explore rather than Realize, settles what can be settled without using up a steering committee slot on it, and leaves the client’s own team more capable for having worked alongside them.

Six behaviors contribute to it, taken roughly in the order they occur on a program: catching problems early, resolving or escalating them well, communicating clearly as both an individual, and as part of a combined team, supporting colleagues along with  a personal workload, and keeping the client’s own people engaged from Explore through to hypercare.

Recognizing Gaps Before They Become a Problem

Suppose a gap surfaces in a fit-to-standard workshop somewhere in the middle of Explore: the client’s process doesn’t map cleanly onto the standard flow, and saying so out loud risks turning a productive session into an argument about scope. So it gets parked. Six weeks later the same gap resurfaces in integration testing, costing far more to fix than it would have in week one, with the client asking why nobody mentioned it. This happens on many programs, and it is one of a series of common early issues that can be alleviated by recognizing them first.

Attendance at key-user sessions is one signal worth watching: a room full in week one and half-empty by week four says something about how much the design actually matters to the people who’ll have to live with it. This indicates that user adoption needs support.

Data quality problems are another. They tend to be revealed during legacy profiling, get logged, and then sit untouched because nobody wants to be the one telling a business owner their master data is a mess, though the cutover forces the conversation anyway.

Then there’s the backlog itself: the pile of open items nobody has closed because “we’ll firm that up later” has become the default answer to anything uncomfortable. That is scope creep which can dramatically slow down delivery.

Before a major design decision or a cutover mock run, give the team twenty minutes to imagine the thing has already failed, then work backward to explain why. Decision researchers have found that imagining a failure has already happened, rather than asking whether it might happen, measurably improves a team’s ability to name the real causes. Psychologist Gary Klein built the technique into a twenty-minute exercise he calls the pre-mortem. It gives people permission to say the awkward thing out loud instead of waiting for someone else to say it first.

Consultants can be wary of raising an issue early because they don’t want the association with that problem in the organization, but on a team that’s actually functioning well, it makes a consultant look more competent, not less, to bring to light things which can slow the project down, as long as others are willing to accept that truth.

The Difference Between Quiet and Buried

Finding the problem is half the job. What happens next decides how a consultant’s actions are interpreted, and this is the part people are confused by most often.

Here is an example scenario: a business lead wants a custom development that makes their process easier now but breaks the standard upgrade path the client signed up for.

Waving it through keeps the workshop friendly and buries the cost until the client’s own technical team discovers it at the next major release, whenever that lands. Escalating it straight to a design authority meeting causes a different problem: a conversation that could have happened over coffee becomes a formal dispute, with the business lead now defending a position in front of their own manager.

What works is a compromise: a private conversation with the process owner, where the issue is clearly laid out, covering what the custom build costs to maintain and what it risks down the line, with the conversation taking place before the decision is “settled”.

The same logic also works at the personal level. Disagreeing with a colleague on the technical team about an authorization design, or pushing back on a project manager’s estimate, goes better when handled directly and discreetly with that person first. Going straight past them, even when the underlying point is correct, tends to cost more credibility with the individual or team than it earns with the client.

This requires agreement in advance about what earns a formal escalation and what gets handled peer to peer.

A client hearing about an issue for the first time in a steering committee, with nothing said informally beforehand, wonders what else has gone unmentioned. A client who was given the outline of the problem a week earlier sees the formal confirmation as the process working as intended.

That’s being easy to work with: being trusted to say the true thing, at the right volume, to the right person, without turning a disagreement into either a buried problem or a public one.

Honest Views, Regardless of Who’s Asking

A consultant can handle disagreement well and still not be trusted, if the opinion they give changes depending on who’s in the room. Fairness, regardless of hierarchy, is a separate type of trust from diplomacy, and it gets tested before any disagreement even exists.

A client sponsor’s pet feature usually gets an easier ride through design review than a junior consultant’s proposal would, purely because challenging the former carries a social cost. Waving it through is a small decision that gets noticed by everyone at the table.

Consistency, applied the same way regardless of audience, earns something more durable than diplomacy: standing as the person both sides of a dispute are willing to bring their case to, because each side can expect the same standard applied.

That authority survives contact with the one client stakeholder or colleague a consultant doesn’t get along with. That’s the real test of fairness, rather than just being easy on people already easy to like.

Types of Communication

Communication is an essential part of collaboration as an SAP consultant and recognizing what type of formally structured or informal communication is relevant in each scenario is a big part of making things easier for everyone. 

For example, a functional spec written for a developer and a status update written for a steering committee serve two different readers, and confusing the two is a common way for a well-meaning consultant to lose trust.

The spec needs to be precise enough that nobody has to guess at intent before building the right thing. The steering committee update needs plain language describing what’s actually happening, not a status color and a phrase vague enough to survive scrutiny.

This also means going back to confirm an agreed action actually happened, which turns out to be one of the more reliable ways to earn trust with harder decisions later.

The second communication job runs at the level of the whole delivery team, consultancy and client staff combined, and gets far less attention than it deserves.

A program works better when both sides read the same project documentation like RAID log (Risks, Assumptions, Issues, Dependencies) rather than one side updating it for the other’s benefit. Communication needs to be a two-way street. 

Retrospectives held at the end of each phase catch problems while there’s still time to change course. Arriving at steering committee with one position, even after real disagreement getting there, matters more than either side usually realizes: the disagreement gets worked through beforehand, and not performed in front of the client.

The Reputation the Client Never Sees You Earn

How a consultant treats the people working beside them rarely reaches the client directly, and somehow the client always seems to know about it anyway.

Pairing a junior developer with an experienced consultant during a design workshop, rather than handing over a spec and leaving them to interpret it alone, costs the senior person very little time and changes how much the junior understands six months later, because they will have talked through the principles and assumptions behind specific decisions.

The same logic applies to the fairly new hire sent into a steering committee update. Prepared and briefed beforehand, they hold their own in the room. Left to fend for themselves they either freeze or improvise something the client remembers for the wrong reasons.

Covering for a colleague after a rough cutover weekend, quietly and without turning it into a story told about them afterward, works the same way in a different context.

Holding onto configuration knowledge as a way of staying indispensable is another bad habit. It might feel like security. To colleagues, it reads as insecurity, and putting oneself before the team.

Adam Grant’s research on workplace reciprocity found that people who help colleagues without keeping score (givers, in his terminology) are overrepresented not just among the weakest performers but among the strongest ones too, outperforming those who track every favor owed. For anyone employed permanently by a consultancy, this is part of what a practice lead notices when deciding who gets staffed, or whose name gets put forward when a client asks for someone specific.

When Client Engagement Gets Lost

Designing a process with business owners in the room changes how it gets received months later. A key user who helped define a decision defends it to their own colleagues afterward. One handed a finished decision tends to resent it if the reasoning is not made clear, and that resentment usually surfaces during testing, at the least convenient moment.

Super-user networks work on the same principle. Naming client-side people to the role on a RACI chart accomplishes very little by itself; coaching them and testing messages through them before a wider rollout is what actually makes the network function, and on a multi-country program that coaching has to happen separately in each country, since one central network does not usually reach the people using the system day to day.

User testing carries the same logic further. Change management practitioners consistently report faster, fuller adoption after go-live when users have been hands-on in testing, rather than trained on a system they’re seeing for the first time as a finished product, compared with training delivered on a system users see for the first time as a finished product. Letting people test the thing themselves builds a familiarity no training deck replicates.

Engagement typically breaks down in the quiet stretch after design work ends and before testing intensifies, when visible progress slows and the client’s own attention drifts toward other priorities. That’s the phase most consultants stop actively being responsible, and also the phase where holding it matters most.

The Metric Nobody Measures

Word of mouth and reference quality decide who gets kept on a strategic account, who gets pulled onto the next phase of a rollout by name, and whose case for promotion writes itself: more reliably than a utilization report or a fresh certification.

Every client and program director making that judgment is informally scoring exactly these things, even though the only language most of them reach for is “easy to work with.” The phrase was always about being dependable enough to trust with the truth, early enough for the truth to still be useful: not about being pleasant to engage in conversation.

If you are an SAP professional looking for a new role in the SAP ecosystem our team of dedicated recruitment consultants can match you with your ideal employer and negotiate a competitive compensation package for your extremely valuable skills, so join our exclusive community at IgniteSAP.