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

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.

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.

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.

Thanks so much Christie I appreciate the advice!

Love the sit down with the client and get back on track - or cut losses, will do. Thanks!

Thanks Mark. I'm going with the charge a bucket of money and end the relationship. Everyone's comments were very helpful and I really appreciate the time you all took to reply!

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.

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.

Thanks David, we actually did that and they signed off on the designs.
Marie

Sent from my iPhone

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.

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?

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.

I agree Bob. Certainly in my mind the flat screen design stage that I was discussing would come after the structure and content had been signed off. 

It varies depending on the client but I usually give them a storyboard Either in Word or PowerPoint that shows the instructional design and visual design. I also provide a functional prototype so they can see how the course will function.