Express yourself

I’ve just spent two hours talking with my developer about his understanding of The System for a new project. It was an excellent learning experience. I was given a lesson in technical writing for someone else. Where I thought I was being detailed, I was confusing the issues.

Now I have a better understanding of what is a good descriptive method for him. With this information I’ll be updating the existing requirements document, for my internal use. It’s an iterative process that will never end, but well worth the trip.

Expectations, I’ve had a few…

I’m am getting a little involved with this article at Joyent about sticking up for your team, even if that means saying no to a customer. It’s a topic close to my heart, especially as I start up a new project.

The crux of the problem is that a client who doesn’t understand what they are paying for needs to be educated; and that education actually costs the provider money, one way or another. If the cost of educating that client is more than that client is worth to the business when do you cut your losses?

Do you hope to have 99 easy clients for each hard one and have the many pay for the few (the typical approach) or do you show the hard one the door? What if the ratio was 999:1? 9999:1?

What’s the break even level? Is it worth it?

I don’t think there is a simple solution, each situation has to be evaluated individually. Before you go in the room, you need to know what you are willing to spend on educating the client. What proportion of the project is going to be invested in managing the client’s expectations. Who’s going to do it? How will it be done?

Joyent has massive archives of forum posts that deal with almost all the crazy things that can happen in their hosting services, they even have a wiki. Is it enough? For me, Yes. For others?

Even 499:1 is probably worth it…

Scoping meeting

After several years of “pie in the sky” conversations and two months of pre-development work I have finally been able to hold the first Scope Meeting for the development of a client’s customer self-serve website. It’s been a long time coming, but now we can start building the crowning glory to their business’ IT systems.

The first session is very important because it allows me to find out how big they want the final product. From there the process of winding back the scope for the first version can begin. Sure, the client can have everything they want, but the pathway to getting it needs to be clearly defined and well maintained right from the start.

While the answer to “Can we do that?” is almost always “Yes!”, the most important part of the reply is “Which version would you like that to be available in?”. The trick to getting it done (and paid for) is to manage the clients expectations. If they want something NOW that’s fine, what is the client willing to delay so it can happen?. If they are willing to make that trade, great, let’s do that. If not, well, sorry, that’s not possible under the current conditions.

I don’t have to hide anything. I’m educating the client so that eventually they start asking these questions before I do. Suddenly the hard part of dealing with the client evaporates.

Post-Implementation Review

After the Initial Specification; Development; Testing and first Live Deployment (Implementation) many companies forget the next step.

Post-Implementation Review.

This can be as short as a five minute meeting to pat everyone on the back for a job well done. The point is this; Is the business happy with the results?

Once the process has been live tested there will be new insight into how things work:

• Were the various steps actually performed in the expected way?
• What was different?
• Did the differences have an impact on the overall process?
• Is it worth trying to improve the results?

IS IT WORTH IMPROVING THE PROCESS?

If there are legitimate complaints about the process, then it needs to be changed and the development cycle starts again. If those complaints aren’t worth resolving then the people involved need to be notified of the decision. That way, when the process is run again, everyone knows what to expect and the process will proceed as smoothly as possible (because you’ll know what areas are going to cause issues and the people involved can adjust their expectations of the outcome). This is how good business processes are developed.

If the outcome isn’t what you expected you have two choices: Change the Process or Change your Expectations.