“Quality is remembered long after the price is forgotten.” -Aldo Gucci
The definition of a successful project has been drilled into us from day one: some version of “doing what you said you were going to do – on time and on budget.” Which would be fine and dandy if robots were keeping score, but in the human world the more practical measure is client satisfaction. So how do we measure such a thing?
We could ask, obviously, but it depends on when we ask. At any point in time, your client will evaluate the success of the project through two lenses:
- The present: how is the product serving them now? Do they have problems? Do they struggle with the CMS? Has it been hard to modify/expand?
- The past: their memory of the experience of getting the project done. This is where things get interesting.
The Peak-End Rule
You see, what the client remembers of the process and what actually happened are two quite different things. In his book Stumbling on Happiness, psychologist Dan Gilbert explains that because our brains have limited capacities for memory, it resorts to shortcuts. Instead of storing every detail in a perfect timeline like a movie, it captures specific, remarkable moments and uses these to represent the experience as a whole. Then it reconstructs the rest by filling in the gaps as best it can.
Another psychologist, Daniel Kahneman, takes it a step further. In Thinking, Fast and Slow, he describes a study where they measured the pain experienced by people during medical procedures. Every 60 seconds throughout the procedure, they asked the patients how much pain they were feeling on a scale of 1-10. Afterward, they asked them again to rate the experience as a whole. You would expect that some simple math would be in order: pain rating x time = overall pain. Wrong. The correct equation was the average of two points: the peak pain and the pain at the end; the duration seemed to not matter at all.
Right then. So now that we know all that, how do we take advantage of it?
Managing the Peaks
In his book Purple Cow, author Seth Godin tells a story of driving through the countryside and seeing black and white cow after black and white cow. After a while, they all just blend together. But if suddenly there was a purple cow out in the field – that one would really stand out. These are the sorts of moments that you need to inject into your project, since these will form the “peaks” that will be remembered long-term.
These can happen at just about any time and can take many forms. Here are a few ideas:
- Plan an impressive project kickoff meeting: something more polished or engaging than the client has ever seen before.
- Put on a bit of a show for the design presentation. This is an exciting moment for clients, so build on that with enthusiasm.
- Celebrate successful milestones throughout the project. It’s easy to forget the day a new feature was unveiled… unless there was cake involved.
Other peak moments will be more spontaneous – watch for opportunities and be creative.
(Side note: You won’t always be in control of the peak moments in a project, especially negative ones. What do you do if something goes wrong in a potentially memorable way? It’s time to put in the extra effort to take care of it – quickly and thoroughly. You need to make sure that the remedy you provide is recalled more vividly than the problem.)
The second part of the equation is making sure you end on a high note. In my experience, this all comes down to one thing: quality assurance testing. Do this poorly and all the hard work of the rest of the project evaporates. There are two main ways that the QA phase can ruin your life:
- QA is not thorough enough, which means leftover errors for the client to discover. And if they find one missed mistake, they will surely assume that there are more and doubt the overall quality of the project.
- QA takes too long, which pushes the schedule out right before launch.
In both cases, clients get a bad impression at the very end – exactly when you want to leave that positive memory. The solution is planning lots of time for QA. How much, exactly? Different places have different formulas and it depends on what you’re doing. Some places use 20-30% of the development schedule or budget. In Roger Brooks’ book, The Mythical Man-Month, he suggests using fully half of overall schedule for testing. It sounds extreme, but it’s worth it.
Putting it Together
The biggest bang for your memory buck will come by combining the peak and end together. This happens at project launch time and it absolutely needs to go well. Here are some tips:
- Have a thorough launch plan and execute it carefully. Checklists are great.
- If you have the time/money/energy, look for an opportunity to do a little extra at this point. Something above and beyond and unexpected.
- Put together a complete handoff package with source files, documentation, or whatever you normally provide. Maybe package it up in a special way.
- Hold a launch party of some sort. This is a time to celebrate everyone’s hard work and make a big deal about the new site (even if things didn’t go perfectly).
Everyone is probably tired of the project by now, but this is exactly when you have to sprint over the finish line. Even if you don’t feel like it – push through. This is perhaps the most important moment of the whole project and you need to get it right.
Don’t think that just because your project was on time or on budget (or both!), that all is well. Every project has highs and lows; the timing of them will determine how the client feels about it all in the long term. Manage the peaks and end on a high note in order to leave them with the best possible memories.