Does anyone have experience with a difficult customer?

Question

We have a reoccurring conflict with one of our larger and strategically important customers. The company (let's call them "C" for now) sells and distributes technical articles, everything from hardware components to hairdryers, and has more than 400000 products in their catalog.

The product owner, who is also the head of product documentation and internal software at "C", has at some point in the 90's taken a course in software testing, and is now writing "Requirement specifications" as user tests. These are often contradictory and error prone, but she maintains that what she writes is what she want's, until she writes something else (in same imperative but ambiguous and abstract format). Furthermore, she demands a final budget for the project, and is unwilling to work in smaller iterations of budgeting.

I'm looking for hints on how to control the development-process (and our own economy) and still provide the customer with a product that gives the company most value-for-money. Normally, I'd start a project by identifying goals of the project and business use-cases of the organization - and then deriving scope from those goals, using User-stories. The details (specifications) of how user-stories should be implemented, is decided at specifications prior to the sprint including the respective user-stories. This has repeatedly proven to result in better products and greater ROI for the customers.

Does anyone have experience of knowledge of techniques that can be used to "Reverse engineer" imperative user-tests, or any other input on how to handle the situation?

Historically, she has been allowed to completely dominate the development process, which has blown our budgets and taught her that she is in control of our process. Our management has now asked me to control (and defend) the development process. They told "C" that there will be used no more hours than the agreed budget, regardless of how "done" she (the product owner) feels that we are, which of course will be my leverage. She will become defensive, even aggressive to get things her way - any sound arguments based on professional reference or experience would be of help.

---

Follow up:

I thought I'd follow up in case anyone stumbled across this post with similar problems:

We have turned the communication around, and are expecting to deliver the next project within budget and on time (I'll edit this post again if hell breaks loose later on).

Initially, I focused on creating trust between me and the Product Owner. That meant choosing the relevant battles, and presenting myself as her tool to get most value for her money. Requirements are still expressed in more or less the same way (although she is open for input about syntax, she is firm about the format: Word Documents and Emails), but we are slowly trading control with visibility regarding the development process.

I managed to persuade her to participate in weekly meetings for project status, backlog grooming and prioritization. Between each meeting, she gets the chance to test the newest revision, which makes her test-feedback what used to be an object for discussion, the most valuable feedback for the backlog grooming and prioritization. By having a head-to-head talk about the feedback from the tests, we're able to "weed out" misunderstandings, contradictions and scope creep before it leaks into development.

The trust between us enabled us to have a constructive talk about each others organizations and the processes and intentions of these, which opened my eyes to quite a big part of the problems being our lack of capacity (professionally, theoretically, and methodically).

The product owner has called management to personally compliment the progress we are making, so I'm calling success on these first steps - but constantly watching the scope and progress, as to not "rest on ones laurels"

Answer 1

This sounds like your agile system of working with the stakeholder is almost-but-not-quite working.

Firstly, imperative user stories (you should give an example) are simply more detailed, so you can generate better tests from it. Taking this example shows that they do work, but are brittle in the face of changing customer requirements. If the customer has very hard requirements though, then they are more appropriate. You need to highlight this difference to the customer and decide upon which is the most appropriate for their circumstances.

Second, I guess the problem is the person who writes the requirements is the person who accepts the delivery. There doesn't seem to be a mediating stage to this if the original requirements changed during development (which it appears they do). Now in an agile environment changing requirements are the norm - hence agile! - but the customer needs to understand that you deliver what they asked for, and if they continually change their mind, the overall delivery will not contain much result, seeing as you've spent all your time re-working.

Final budget is obviously something that both sides want, so you need to budget in terms of time - you work for them as much as they want and you will bill them per day. When the budget runs out, that's it, you stop. To make this happen you need to get the customer and your management in a budget meeting to agree this. Its not an uncommon means of limiting budgets, but they need to understand the time limits involved, which in turn should focus their minds on actual delivery rather than the continual keep-working-until-I'm-happy.

Lastly, the big problem you have is really one of habit, people have become used to the statue quo and just need to be brought together to re-establish the boundaries of your collaboration. You must drop the attitude where she is the enemy, or is incompetent. You must work with her, and no doubt she is much more competent than you realise, possibly you've ended up in the state you are because of built-up failings on both sides of the process. So whatever you do, start with a clean slate and an open mind, and you should succeed in fixing this problem.

Answer 2

Rather than thinking of this customer as 'difficult' which is negative, how about seeing that just they want to be really involved in the process? Perhaps their experience with working with other suppliers has benefited from a close working relationship?

Historically, she has been allowed to completely dominate the development process

Do you have internal processes/guidance for managing customer relationships? if so, are they being used? If this customer is managing to 'dominate' in any way, it strikes me they're either missing, not being used or are lacking somehow.

Also, are you the best person to do this? If you're in a predominantly technical role, it seems that your company may want to bring in someone who has a more people-focused role to help build the relationship while you build the product. This is not necessarily going to be another layer through which you need to work - it should be a double-act between you and them.

In my experience, keeping all customers involved and engaged to best manage their expectations is the way forward. There are a number of techniques and strategies you could employ here:

Clear and Open Communication

So the customer wants to change a requirement in some way - as they're paying, they're entitled to do this, but let's make sure that:

1. You/someone acknowledges their request in a timely manner and give them an ETA for the next update. i.e. "Thanks for your email, we're discussing the work required to implement this change this afternoon. I'll come back to you with the outcome after that/tomorrow AM". and make sure you get back to them when you said you would.
2. Be open and transparent about progress. If a feature is going to be late, tell them as soon as you know - don't wait until you've missed the delivery date.
3. When problems arise, get their input. If the requirements are ambiguous/vague/contradictory, schedule a conference call or meeting to clarify. Be sure to convey that work cannot continue until this is resolved.

Regular Updates

So the communication shouldn't all be event-driven, you should schedule frequent updates - whether this is a [video]conference call, on-site or in-house meeting. Being able to regularly review progress with you will fill them with confidence that you're being straight with them, i.e. not hiding anything. Over time, they'll relax as they see that your team delivers per the updates you give them and that their requests are heard, managed and integrated.

Over my (long) career, I have had many meetings where we just talk through project progress, they ask a couple of questions and we're done, in under 10 minutes.

I've also had to tell customers with high expectations that we've made no progress at all for a week as we'd had a break-in in the office and equipment was stolen. We expected anger but they sympathised and fully understood our setback. One customer even loaned us some equipment (128mb DRAM sticks in ~1993).

Lightweight Change Management process

So if one of the issues you're having is them changing their mind (which they are perfectly entitled to do, being the 'customer' who is paying your bills), it may be a good idea to use a lightweight change management process. The worst thing you can do here is get them to sign some legal-looking document as they'll feel threatened, but you could do the following:

1. When they request a change, first estimate/plan the impact of that change. Clearly communicate the effect on budget/schedule of this change. Be sure to point out if this effectively undoes work they've already paid for.
2. Agree a time by which the change will be either accepted or rejected.
3. Ask for the acceptance or rejection in writing. Email is fine, but make sure it is clear.

When to get help

So there are some occasions where all the best intentions in the world still don't seem to get through to the customer. These are the ones I've experienced:

1. Customer hounds you on instruction from their management, to the point where the hounding is preventing you getting anything done. This needs a [video]conference call with your manager and their management to discuss why they are using this 'crack the whip' strategy. It may required that your company employs a Customer Relationship Manager who can buffer the interaction between them and you.
2. Customer keeps changing their mind. In this case, you need to have the confidence to halt the project until they decide which is the most important thing that you should be working on/delivering. Be very clear in your communication that the project must halt and that it's your concerns about the changing priorities that have required it. Book a face-to-face meeting with your management, them and their management to discuss. Their management will likely be more cross with them for causing this than you for having to take the actions.

Answer 3

There are a lot of red flags jumping out here:

• "...larger and strategically important customers"
• "These are often contradictory and error prone, but she maintains that what she writes is what she want's"
• "They told "C" that there will be used no more hours than the agreed budget, regardless of how "done""

If you have someone who is that unwilling to change AND they are so important a client, you only have a few options:

• You could include a massive percentage on your estimates as a contingency (20%? 50%)
• You could implement strict change requests where items not originally in the requirements are costed separately.

If these things don't or won't work, then I'm not entirely sure what else you can do.