Advice for Managing a difficult client.

Question

We are agile software developers, and we have a client Pm who will not accept any drop in functionality when we do a delivery. It’s a key requirement in agile software development to deliver to timelines not functionality.

It seems impossible to manage his expectations - he seems a bully and will not see that his actions are already damaging the project.

We tell our clients about agile at the start of the project, it seems impossible to manage his expectations.

Any advice? Has anyone else had similar issues?

Answer 1

If he's a friendly enough guy and willing to learn, you could point him to a little bit of the research that's been done that show's how fixing both time and scope for unknown projects leads to disaster.

In the book "Implementing Lean Software Development: From Concept to Cash, Mary Poppendieck writes about various ways to implement more agile / lean contracts with clients. It's worth a read. As all of my agile clients are internal (product management, who are very on-board with agile), I haven't run into this particular problem myself.

Answer 2

These situations are tricky (obviously), but here are a few things to try:

• Explain things to him. If a piece of functionality needs to be changed or removed, tell him why this is the case and what the specific areas of impact will be. Do so in plain english.
• Understand that, in his mind, the methodology with which you approach software development is unimportant minutiae. He only cares that his project gets done and isn't interested in the nuts and bolts of it (I'm assuming).
• Try to highlight changes that are a direct result of his input. If he feels like he's having a direct impact on the direction of the project, he might be a little more willing to be flexible in other areas.
• Accept that sometimes clients are just dicks and, at the end of the day, there isn't a whole lot you can do about it other than try to do your best to meet their requirements. If he sets unreasonable expectations and is disappointed when they aren't met, then maybe it's time he's removed from your list of clients.

Good luck and remember - it's just a job :)

Answer 3

There are several solutions that I can think of right out of my head.

1 - Scope the project as much as possible from the beginning. Get the client to understand that anything outside the scope will cost extra. It's not because you're agile that you're free! He will then think more before asking to add new features. Of course stay agile and don't lock the project too much.

2 - Get the project manager to set realistic milestones. Each deliverable must be possible. Agile is about iteration, so define better your iterations: what need to be ready and so on. Communicate with the client about this schedule and see if he's ok with this. Then it's up to you to get things done on time. If an iteration is unrealistic, make sure to communicate with the pm so that it doesn't happen again. In other word: make better, more realistic estimates and communicate with the client.

3 - Don't be agile. Some clients jsut don't get it. I worked with clients who didn't want to get involved in the process at all... or said they would but then never had time. We had to manage these people with a big ugly V cycle because there was no other way

4 - Drop the client. If it's possible and this client is causing trouble (developers annoyed <=> down in productivity, losing time, losing money...), it can be the best move for you

Answer 4

If you've agreed to certain functionality by a certain date for a certain price, it's your responsibility to meet those goals. If you are unable to do so, you need to meet with the client as early as possible to determine what approach best meets his needs. He may rather let the date slip than drop functionality.

Remember that he's the customer. What he wants is more important than your project management ideals.

Answer 5

I'd argue that you have this wrong "It’s a key requirement in agile software development to deliver to timelines not functionality." The key requirement is rather to deliver functionality in portions to allow client interaction in evolving the design (as often they don't know everything up front).

To me timelines (sprints) provide known points where various project related tasks can be addressed, such as change of client needs, tracking what speed the team is working at. How much of a feature is possible to fit into the next sprint is the planning effort. Having these points gives the developers some stability in not changing the goals from hour to hour, but still allows for changes in the goals before 'the end of the project'.

A purpose of having the client in the sprint planning is so that they can provide input on what they want to come next.

Sometimes you have to break things on the way to making them better, and unfortunately that may happen across sprints. The client will need to be aware that features are related and that testing will be involved. It seems quite reasonable that they should be able to have input on inclusion of incomplete work within the deliverables of a sprint, and should manageable from a code/VCS perspective. Perhaps some sprints just don't have any valid deliverable.

Answer 6

A bit of worldly advice from the consulting trenches: Nobody cares how "agile" you are or how great your "process" is or how "configurable" your architecture is. Your clients care about RESULTS. Deliver those, and you'll have happy clients. Sometimes people are understanding with scope adjustment, other times they are not. This is part of the business.

I'm sorry that you need to deal with this guy, really I am, I have had crappy clients too. At the end of the day, you took on the business, and he is your client. Suck it up and make him happy by any means necessary and at best you'll get more business out of it (if you want it), or at worse you'll still have your integrity and knowing that you did everything you could have done. As my dad told me once, part of life is dealing with assholes.

Answer 7

I take it your client is asking for certain functionality to be delivered at certain times, and that when you refer to dropped functionality, you mean functionality that didn't get into that release.

Your client is probably trying to make business plans that rely on the schedules he gets. It's a legitimate point of view, and he's giving you money based on it. Most people who are not in software don't understand that software is a design process, not a strictly manufacturing process. Many software people don't understand that the cash customers are often making plans based on software schedules. There's a big potential for misunderstanding here.

You have to know what the client really wants. Frequently, the client needs predictability. He needs to know a time at which he can count on certain functionality. The client will want it as fast as possible (and most non-software people don't realize the problems with trying to reduce the calendar time needed for development), but in many cases what the client needs, and is willing to settle for, is predictability.

The client doesn't care about your methodology. The client cares about deliverables. It's up to you to provide them, or you don't get paid. It's your job to deal with the special nature of software development.

It may be that you've been over-promising. Software people are notoriously optimistic about deadlines. It may be that you've been presenting expected dates, rather than confident deadlines. You may be accurately estimating functionality at three to five weeks, and saying four weeks. You should tell the client when you're confident you can get things done by, and then inform the client that this isn't exact, and it might be done earlier.

This is, of course, assuming good faith on all sides. If you've been providing the client with delivery dates you have no confidence in, or if you've been ignoring agreed-on dates, then you need to clean up your act. I have little sympathy with people who promise the impossible and complain when they're expected to do it. (I have a lot of sympathy with people who have the impossible promised for them.) It's also possible that the client is a jerk and a bully, those being unfortunately common traits in independent business people. In that case, you have to learn to manage the client. In this case, it's quite likely that the client has a history of being unsatisfied with software work, and you may be able to convince him that backing off some, and accepting more realistic estimates, might work better. Or not.

Answer 8

There seems to be a problem here in the client understanding the process, how it works, and what role he has in things. I'm assuming that the drop in functionality means things that didn't get finished in a sprint and thus are to get done later. How many sprints have been done and how well are things being estimated? That would be one place I'd look as the key here is to understand expectations from each side and that while he may think X will be completely done, that may not end up being the case. While some things may be fixed like time, the other variables can be adjusted to some degree, those being scope and people.

• Do you need more people trying to help?
• Is the scope too big or stories too vague to give proper estimates?

Answer 9

It's very hard to resolve the situtation you describe - It's evident that the client/PM was never thoroughly edudcated on the Agile approach from the begining.

My best advice would be to run a one or two day workshop with the client to re-explain the Agile approach, going right back to the basics such as the Iron Triangle etc (it's amazing how few PMs even understand the basics). Focus on the fact that you both want the best outcome, but that can't be done by rushing features/sacrificing quality. 9 Women can't have a baby in a month etc.

I can sympathize though. So many PMs I have met are clueless and dogmatic in their approach to PM. Their minds are set in the old world where schedules are what reality conforms to, not the other way around.

Does the contract/invoicing scheme reflect the Agile approach? If so then PM should not be able to bully very effectively. If the PM feels they are not getting value, they can just not pay for another iteration, and you can part company no?

Now for the root cause analysis:

How did you end up with a client PM who does not understand or accept Agile delivery?

If you want to run Agile projects when you take on new customers its imperative they understand exactly what they are signing up for, even if that means spending days tutoring them.

The point is: there is no point being "agile software developers" if your clients don't buy into Agile too. They have to be partners with you working for the best project outcome, not the traditional adversarial buyer/seller relationship.

Also ensure the contracts/incremental payment reflect the Agile approach so the client can see exactly what they are paying for.

Answer 10

I agree 100% with slf's answer, but wanted to add a little.

I always warn others in this industry that we shouldn't be so zealous about anything (including not being so damned zealous). Using scrum or being agile, design patterns, standards, and hell, even maintainable code don't mean anything if you're losing business or pissing of your client.

It's not the responsibility of the client to understand software development methodologies, or anything else for that matter. As long as they understand how to pay, we should deliver what is promised.

Using agile, scrum, waterfall or whatever should be a purely internal process and need not be exposed to our clients (with perhaps the except of business-to-business co-ops). To draw the obvious analogy, this is the same as data encapsultation: the most important thing is that the object works as it says it does and not necessarily how it does it. Agile provides structure within development teams and projects. Clients don't care how we manage our teams or projects, they just care about what they payed for: results.

Whether we realize it or not, we're in the service industry: start serving.

---

Edit: As far as the client is concerned, results are getting what they were promised and getting what they payed for. Managing client expectations is one of the most important things to do with your client, and as the third link says, "The middle of delivering a service or project deliverable is too late to begin managing a client’s expectations."

My business is in websites. We try our best to educate our clients on the process, making sure that they know ahead of time what they're getting into and what to expect. We even have a formal "client education" packet in the works. When clients are surprised by new information half way through the project or later, it sounds like an excuse.

I fully concede that there will always be the belligerent, naive, uncompromising, rude, micromanaging, and just plain bully clients. We've been burned by them before, but you have a choice. Either stick to your guns and maintain your ideologies but piss of your client, compromise and deliver a product that is below your standards but makes the client happy, or drop the client.

Answer 11

if it is the customer thats the 'unhelpful' part of the equation, how do you know this until its to late?

sure you may not want to take another project from them in future. but the reality is that they will most likely get maintenance work done from you in future - so you may be stuck with them for awhile.

is there a way to know before-hand if a client is going to be not worth taking on board?

-- LM

Answer 12

I agree with Schneider and most of the rest written here, there are lots of things to make and an having people badly involved is one of them. I've been doing Scrum for some years and I use Agile whenever possible, but Agile does not fit to all projects. In my current project we're in the process of dropping Scrum completely (and I'm the one who wants to axe it), because it gradually became a burden, and one of the reasons for that is a Product Owner not doing his role properly.

Maybe you shouldn't tell your clients about Agile, because it sounds you "force" Agile to them, maybe you should see if Agile fits in your project and your clients and their product, which means also having a Product Manager commited to the process. If not why don't you drop Agile entirely or adapt it to a smaller scale, and transparent to the client?

On a footnote I'd suggest to watch this: http://www.infoq.com/presentations/Fail-Scrum-Henrik-Kniberg