A new developer quits after two weeks. A three-year veteran leaves the company after receiving a 5% raise at his annual review. A project is delivered according to developer estimates but the project manager is fired. An application is built to approved specifications but the client is unhappy. What do all of these situations have in common?
Expectations. We all have expectations: water will come out of the shower in the morning, the car will start, the gas pedal will make the car accelerate, the office will still be there, etc…
When they aren’t met it can send your life into a tailspin. It’s shocking to push the gas pedal and get no response from the car; have you ever experienced this feeling? It feels like reality disconnects for a moment because something you hold as fact becomes false. This has always worked, why doesn’t it work now?
Daily life involves thousands of expectations; so much so that we get used to having them constantly met. This is one reason that building software is so difficult.
Case In Point
I developed a web-based a content management system (CMS) back in 2001.
I talked in great detail with the client about things the application would and would not do. I wrote a spec, submitted it for approval (I don’t think he ever read it), and built the CMS. My boss and co-worker thought it was solid. I showed it to some developer friends of mine and they were thoroughly impressed with the navigation, the usability, and the HTML editing capabilities; this was before things like FreeTextBox, and it took some major JavaScript work to get a usable HTML editor from an HTML text area.
When the client saw it he absolutely lost it. This is one of the few times when I actually had to hold the phone away from my ear because he was yelling so loud, like in a cartoon. He kept saying it was too complicated. In fact, at one point I told him to click on a directory to display the pages contained inside, and he asked “What’s a directory?” How do you answer a question like that knowing that he needs to understand concepts 10 times more complicated in order to work the application?
The problem boiled down to this: he expected it to be like Microsoft Word. He was non-technical and had never used custom web-based software, so his only reference was the Microsoft Office suite. I had a hard time convincing him that custom software is more like a car built by hand than one that rolls off an assembly line – it’s expensive, it’s going to do exactly what you want, but it’s not going to have all the bells and whistles you’re used to (in this case things like real-time spell checking, right-click support, and a few others). His expectations were too high for this type of application, and the bottom line is that I hadn’t done a good job of correcting them in advance.
The happy ending is that after the initial learning curve he had a lot of positive things to say about the CMS, and the project was considered a success (it’s still in use today, as far as I know).
After this experience I came up with some rules about setting expectations:
Rule #1: Put them in writing
Memories fade with time and verbal agreements are worth the paper they’re printed on. Having something in writing makes it easy to refer back to a year down the line, whether it’s a software specification or an evaluation of an employee’s performance.
Although having my specification in writing didn’t ease the initial launch anxiety it allowed us to prove that we had built the applications to an approved design, and ensured that we were paid for our work. It’s been said before, but I’ll say it again: write it down, even if it’s a quick email to confirm something said in a meeting. If you get in the habit of following up phone calls and meetings with “Per our phone conversation…” emails you will be much more successful in the long run.
Rule #2: Insist on feedback
You will often find yourself doing all the talking. Whether this means you’re the only one sending emails or creating specs, or the only one speaking during a one on one meeting, open the door for the other person’s opinion by asking for it. Someone can listen for hours but never really hear what you’re trying to communicate.
The application’s initial failure had a lot to do with the fact that the client never read the spec. When you submit a spec, include a note that says “Please include feedback with your signature.” and mention this verbally, as well. If you receive the spec without feedback ask some specific questions about a piece of the application such as “What do you think about how we’re going to handle the directory structuring?” and see what kind of response you receive. It’s not about tricking the client, it’s about being aware and being prepared for their expectations.
Insist, demand, or beg for it…but one way or another get some feedback.
Rule #3: Meet face to face
55% of communication is non-verbal, which means more than half of communication is tone and body language. Emails and conference calls are great tools, but nothing beats looking someone in the eye. Not only will you have an easier time getting your message across, but people will tend to remember it longer.
In retrospect, I got this one half right. I did schedule at least one meeting with the project owner to explain the application in plain English, but he was so busy hat I had about five minutes to explain the application to him and that’s not enough time to go into the necessary detail to shape expectations. Since then I’ve made it a point to put an emphasis on describing an application’s limitations – what it won’t do. People often spend too much time selling the application during these meetings by saying how great it’s going to be, but by this point you already have the contract so step into reality and be forthright about its capabilities. On launch day you’ll be glad you did. If you’re ultimately responsible for the success of the application be sure you meet early on with those who will determine the success of the application.
Rule #4: Don’t build in a vacuum
This one is specific to software development, but don’t write a specification and then go away for four months to build it. Call it a cyclical development process, agile, xp, or whatever, but plan to release a piece of the app once a month so users can see how the application looks and get some experience playing around with it. Even if you’re using the waterfall model where you spec an application up front and then build, give them something they can experience. Most users don’t have much contact with custom software so making this extra effort is a huge step towards easing launch-day anxiety.
Back to the Intro
So how do expectations tie into the four scenarios from the introduction?
The new developer quit after two weeks because he expected the company was building state of the art products, as he was told during his interview. After realizing he would be building basic CRUD (create, read, update, delete) web forms for years to come he opted to move on.
The three-year veteran who left the company after receiving a 5% raise had worked hundreds of hours of overtime during the past year, and was the main reason several of the most profitable project succeeded. He expected a nice bonus or a healthy raise, something more than the standard 5%.
The project manager who was fired for delivering the project according to developer estimates wasn’t able to communicate these estimates to executive management. Instead, someone else was in charge of setting the expectations and from day one the project was due before it could possibly be delivered.
And the fourth example was the subject of this article.
Setting expectations can be a difficult and time consuming process, but it’s one area that you want to be part of. This article is a reminder that you can nail the technical aspect of an application, but missing the human side can just as easily lead to failure.
