February 11, 2008 – Did You Get What You Wanted?

It was the perfect gift. Our daughter’s CD / Cassette player stopped functioning in time to add it to the Christmas list. We found just the right one on line for about $60. Unfortunately by mid-January it quit. It didn’t start skipping or playing songs backward, it simply refused to turn on. We contacted the company and sent it back: $19 shipping and $6 handling fee. Within two weeks a new one arrived on our doorstep. Unfortunately it was the $30 model. She was willing to live with it until it ate the first cassette tape she tried to play. Did I mention it was a book on tape from the library and it was completely destroyed, resulting in a $10 fine? So by now I have invested $105 and own a tape hungry paperweight.

Do end-users ever feel that way? They’ve gone over budget and ended up with a product that vaguely resembles what they asked for but isn’t anything they could possibly use. How can we avoid disappointing them?

Involvement. There are two sides to involvement: (1) Getting committed users to participate and (2) Using them effectively. Sell the concept that their participation is essential to building a successful product. Let them know the effort involved and timeframes they will be needed. Get buy in from their management to dedicate a percentage of their time to the project.

In order to maximize their availability, plan in advance when and how you will use them. Invite them to a kickoff meeting and lay out the plan. The tendency is to only use them a bit up front for requirements and then again for User Acceptance Testing. Send your designer and even your lead developers to sit with the users for a couple hours at a time to see what they do. The more your team understand what they are creating the better they can design and build it. Every week (two at most) touch base with the end user. Re-confirm the schedule. Bounce the latest design off them. Keep them involved.

Bite sized chunks. Agile methods use the concept of frequent releases, as often as every two weeks. The concept is not new, only the implementation. If you are not in an agile environment, instead of workable code, aim to have something tangible every 2 – 6 weeks. It may be the draft requirements or prototype, but it should be something that confirms the project direction and gains the confidence of and buy in from the sponsor and key stakeholders.

Picture it. Graphic illustrations and mock ups help people visualize the direction of the product. Use Case Models was one of my recent blog entry topics. This is a great way to drill out requirements with minimal effort.

Get Touchy. Nothing peaks the interest of end users like a demo. Moving to a screen version that mimics the final product sparks the memory, too. All too often you begin to hear, "oh, yeah, we forgot to tell you about ." Try to keep your patience and remember that the goal is a usable product that meets their needs.

As a side note, make sure they understand what they are seeing. I used to program handheld inventory machines. We made the mistake of giving the sales people a PC based tool that allowed the client to view a mocked up version of the application. It was great for developing the requirements, but their assumption was that once it was on the computer screen we just had to download it to the scanner and ship it. I’m convinced some of the sales guys thought so, too.

Keep Control. In addition to controlling your patience, it is important to control the direction and duration of the project. Too many directional changes and the product will be outdated before it ever goes live. The best way to deal with this is by starting with a core functionality release and building on to it. When an enhancement or change is raised, define it, estimate its impact to the project and have the sponsor prioritize it. Agree on which release it should be part of and what gets bumped for it. Then get back to the current release.

Remain Flexible. It may sound contrary to keeping control, but flexibility is your ally. In the end it will be the users of the system that define if the resulting product is a success. Regularly verify the critical success factors of the project and align with them. When presenting the impact of a change, explain it in terms of the success factors. If the go-live date is vital, show how the request will impact the delivery. If functionality is key, reference the priority list and ask how the change fits into the bigger picture. Communicate the trade off and get their informed direction...in writing.

If all else fails, charge them a $6 handling fee and tell them to expect a box in about 2 weeks.