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.

February 4, 2008 – When the Plan Fails

In an on-shore / off-shore set up you need to expect the unexpected. Half you your team is in a foreign country, half way around the world. You’re never quite sure what time it is where you live, let alone where ever they are. Languages, especially English, can lead to confusion. Names are redundant (there are four Toms where I now work). I’m not sure how you could possibly have seen the following surprise coming, though.

Picture yourself sitting at your desk on Monday morning, pulling together reports from the weekend and getting ready for the week. Fred comes by with a new face and introduces you to Gupta . The name sounds familiar. "I have a team member by that name, where are you from?" you ask.

"That is me," is the reply.

"What are you doing here? Don’t you normally work from India?" you ask, bewildered.

"Yes, but I am going to be the project manager on a different project here on-shore now."

True story. Talk about putting a crimp in your plans.

Resources quit. Scope gets breached. Bugs happen. Systems go down. Priorities change. So what do you do when life throws you a curve ball? Hang on for the ride and follow these steps.

Take a deep breath. Before you react, take a moment to calm your blood pressure before you say or do something you might regret. It might save your health as well as your job.

Confirm it. I hate it when I start yelling about something only to find out I have the facts wrong. Take it to the source and, calmly, get some answers.

Assess the impact. If the issue is scope related, determine the gap factor. Resources can be difficult to replace. Is there a more junior member of the team that might be easier backfill? Can she step up to the role?

Check the schedule and budget to determine what the damage will be.

Identify Options. Don’t work in a vacuum to figure out what to do. Invite your team and other stakeholders to help develop strategies to stay on track.

Present Options. Take your findings and options to the Sponsor or Steering Committee. Explain the challenge facing the project and ask them how we, as a group, should resolve it. One of the things I stress is that the project manager does not own all of the problems. They are "our" problems and "we" have to take steps to resolve them.

Get approval. If a Change Request is necessary, file it and get it approved. Get the go ahead to make the resource changes. Confirm commitment by getting approval.

Learn. Figure out the root cause and take actions to keep it from happening again. You can’t keep a team member from taking a better job offer, but you can make the current position better. Scope is drawn to determine when it does change, not if it will. You can take steps to manage it better.

Move on. It is better to get beyond the issue than to dwell on how things should have been. Once you have taken steps to keep it from happening again get on with successfully completing your project.

Stuff happens. You can’t control the surprises but you can control your reaction. If it were simple, anyone could do it, right?