Dealing with client from hell - need some advice and maybe a better sign off template

Dec 22, 2015

Hello ELearning friends, 

I'm dealing with this client from hell who has asked for a project to be completely redesigned several times over a process of three years, never says what they like and are so slow with feedback that it takes months to find out what they want. When they do give feedback it is always very critical and expressed in a condescending tone. Usually it is completely off the mark too and attempts to get the tool or the program to do things it was never intended to do. We have never had to deal with a client like this before because we have ongoing communication and specifics we request from our SMEs with sign off points, and they respect the process. Does anyone have a really good sign off template (for design, content, functionality and no further changes benchmarks, etc) they could share with me? I need something that encourages the client to tell us what they like and then what specifically what they can comment on so they don't go way off track. 

Any good ideas or advice would also be welcome. 

Thanks everyone! Marie

14 Replies
Christy Tucker

My SOW lists what kind of changes are allowed at each stage of development. For example, script changes have to be made before sending to voice over recording. When I send content for review, I remind them what I'm looking for.

I specify that 2 rounds of revision are allowed at each stage and clarify that in most cases the second round is just verifying that the requested changes from the first round were made.

My SOW and agreement also state that I'm not responsible for delays caused by the client, and delays at their end will cause me to shift my timeline as resources are available. In some cases I provide the example that a 1 week delay in feedback could result in a 3 week delay in delivery based on the availability of voice over talent.

I often do email sign offs, but when I do an actual formal sign off sheet (like I absolutely would with a client like yours) I include a line that says if I don't receive feedback within 2 weeks that the content is assumed to be approved and I'm moving forward with development. That sign off sheet also reiterates the points from the SOW about what kind of content is being reviewed at that stage. I include a line that says signing this means I can continue to the next stage of development.

For the most part, that has worked for me. I've only had that process completely break once since I implemented those steps. Even in that situation, the client agreed that the changes were outside the original scope and paid additional to have the course change direction.

There's not much you can do about condescending tone. I would focus on trying to get them to give you the right kind of feedback, even if the tone is unpleasant. I'd probably choose not to work with a client like that again, but no template can fix that problem.

I will say that I never assume it's the client's job to know the capabilities of the tool. That's our job as experts. You're always going to get clients who have great vision for a course but not the budget for it. I usually respond to those kind of requests by pricing out what it would cost to do what they want in whatever tool is necessary, even if it would require subcontracting multimedia specialists, programmers, or whatever. Give them two options: "I can do your request X for additional budget $####. As an alternative, I can do Y for no additional charge."

Honestly, 3 years into a nightmare client like that I would seriously consider cutting my losses and handing off the source files for them to work with someone else. I realize that isn't always easy, but if it's possible you may just want to end the relationship.

Mark Shepherd

Hi Marie:

TOTALLY agree with Christy's take on this.

One "trick" I use to ensure that my clients do not mis-understand or (unintentionally) torpedo the business relationship is that I put a TON of Caveats up front about e-Learning development, so that their expectations are tempered as much as possible.

Most of my caveats are about iterative development, timing of project features, a little flexibility regarding results (If the project delivers/achieves the desired result, then this should be enough.  How I do it is none of the client's business), and a communications/progress process.

If the client starts giving me static before even so much as barely having a coffee, I will usually take a few more minutes to explain things to them, and also, to give them a chance to dial their attitude back a little.  I'm judging them as much as they are judging me.

If my potential client is still giving me warning signs of argumentativeness or a poor attitude, I will usually just end the meeting and drop the proposed project right then and there before I waste a single dime of my time on it. 

If the client asks why, I will usually tell them that I only work with clients who can understand and accommodate basic business politeness, and that my own business model does not have time for people who can't understand or accommodate basic principles of programming and project development. 

It's a complex area, and it's not everyone's cup of tea.  This is my way of giving them a graceful exit.  Most take it, because they are either stubborn, or difficult, or some combination of both.

A few perservere and ask me to help them to change how they handle that side of their business.  Those people often become my best clients, because they are open to change and are willing to accept a few compromises if their larger goals are being met.  It's a win-win, but keep in mind that situations such as the one I just described are very rare and unusual.

That being said, I do understand and yes, even respect, those who operate differently. 

I just don't work with them, is all.

If people can find a developer who can tolerate all of the extra "stuff", do the work, and also somehow not charge a BUCKET of money (read: extra) for it, then more power to them.

At the end of the day, I can't afford to pour out money into a relationship that shows no signs of bearing fruit.  Every day I work on a project means money spent from my business, and if I have no way to get it back, then that stops me from doing other things.

In situations such as the one you've described, I've almost always cut my losses by handing over what I've done and dropping the project. 

By up-fronting my expectations, I try to nip these problems in the bud as soon as possible, because if they aren't handled early, this scenario may happen again.

Hope this helps.




Nancy Woinoski

We always want to do the best for our clients but sometimes regardless of our  intentions things do not work out. In situations like this I don't think it matters how good your SOW is - they will still be unreasonable. So there are a number of things you can do: 

  1. Charge them. Every time they ask for something that is out of scope, create a change request to document the changes you are going to make, the time it will take to complete the work, and  the additional cost for the work - get the client to sign it before doing the work. If they don't sign then don't do the work.
  2. Invite the client to sit down with you and walk through the  project with an aim at to find out what is and is not working for them. Try to find out what is motivating the attitude and the delays. Be upfront with them about the reason for the meeting and do not shy away from the issues you are having.  Sometimes people don't realize they are treating you like crap until you point it out. Have suggestions for a better way to work together
  3. Cut your loses and fire them - there are a lot of really good clients out there so don't put up with the bad ones.


Mark Shepherd

Outstanding advice, Nancy!

However, given my own experience, not everyone is amenable to change requests in the way that you have describe them.

I've actually had some clients quit on me very early into a project when I've put a change request form across their desk.

But I do agree that sign-offs on functionality are key. 

I frequently go so far as to insist that the client help to WRITE/BUILD the Learning Project work contract document, what its goals are, what it entails, functionality/features etc.

By making the project a joint effort, they often tend to respect my work more right from the get go.  Also, by having them co-author and sign on the dotted line, it gives me a lot of breathing room if there is ever a problem, because BOTH of us have vetted it, not just me or them.

David Tait

Part of our usual process is to create a set of static designs to put to the client for approval, prior to any programming work taking place.

To start with we'll design a selection of key screens to show the client. Once they're happy with the style we'll set about designing every screen, right down to the last detail. We also provide a detailed description of any animation and interaction that we're proposing.

This obviously takes a little more time at the outset but it is always easier to amend static layouts than it is to re-build something in Storyline (or whichever tool we're using at the time),  you can make some of the time back during the build stage.

You can speed this process up by treating PowerPoint as a desktop publishing package. Lay your screens out in ppt and once they've been approved you can import them directly in to Storyline. You'd have to lay them out at some point so it might aswell be before you build anything. We used to use the same method when we developed in Adobe Flash but we'd import our Illustrator files instead.

We find that this process helps as not everyone can visualise a concept without seeing it and it creates a clear distinction between design and build. Effectively, by the time you get to the build stage any design amends are out of scope.

Nancy Woinoski

Static designs are fine for people who have used them before and understand how they are then translated into an interactive experience, but I find most people can't visualize how the course will really work from a static design. They sign off on the design but once they see it in action will require a whole bunch of changes.

David Tait

We all have processes that work for our own circumstances so I'm only speaking from my own experience.

Personally, in relation to a client requesting changes to actual designs I'd always expect static designs and their subsequent review prior to build to eliminate the vast majority of design-related feedback post-build. 

Nancy, what is your process, is the first time the client sees the design the same time they see the fully-functional course?

Bob S

For my part, I've found it most helpful to focus stakeholders on prioritizing content over look & feel or functionality; they are after all business people. Build up the "yes's" along the way by providing detailed drafts of the content pieces (think detailed outlines) until all agree.   Include specific phrasing only where necessary at these stages. 

This buys you credibility (ie leeway) with the stakeholders as they come to understand you really "get" their business needs and goals. Once you have SOLID agreement here, you are likely find you have far fewer issues/concerns regarding the visual design and navigation elements. And if you do, you can always bring them back to the touchstone......"Mrs Stakeholder, are we still talking about the right things the right way for your business?  Ok good, then sure we can tweak colors or layout as needed to satisfy everyone" ........What you've done here is remind them of what's really important and minimized the likelihood they are going to want endless versions visual changes that have little to do with the important business content.

NOTE:  Please understand I am not minimizing the importance of a visually pleasing course. We all love to be creative and the right look and feel can certainly enhance learner engagement.  But in the end, if you aren't providing the learner proper relevant content in a well organized way they can assimilate....what's the point.

This discussion is closed. You can start a new discussion or contact Articulate Support.