Don't Let the Engine Run Out of Fuel

language.

The customer's language usually involves money, time, and uncertainty. For instance, earlier this year, three weeks into a nine-month-long project, I had a serious conversation with our project's sponsor, in which I told him I had no choice but to submit a new project schedule that finished twelve weeks later than our original commitment. The delay was necessary in order to absorb the rework we hadn't originally planned for but would now have to do since a promised subject matter expert (SME) had not yet joined the team. The sponsor would have to provide the extra budget to cover the increased duration. But, that cost was dwarfed compared to the revenue that would be lost due to a three-month delay. The software was a key component in a business initiative that would return tens of millions of dollars in extra revenue each year. The biggest cost to the sponsor, though, was that our delay would throw out the sponsor's larger plans, and he would not be able to meet the commitments he had made to his bosses. As a result of this conversation, the SME was on board the following day.

Once you or your bosses have figured out how to push the key decision maker's buttons, you need to then figure out how to give the customers a pleasant experience . Ask yourself, "Would you like to be a customer on this project?" Then ask, "Why not?" While we try to accommodate our customer's lack of understanding of what we do, we inevitably intimidate them. We IT folk speak a funny language and draw a lot of complex diagrams. We also ask them to answer very difficult questions, and we expect them to get everything right from the beginning. The truly lucky ones get software that does what they asked for. Unfortunately, what they asked for often isn't want they want.

First, think of your customers as if they were guests in your home, so be hospitable. Make them feel welcome. Treat them as if they're part of your work team. Speak their language when you can. Listen to their concerns, and share your own. At the end of the day, make it easy for them to collaborate with you.

If you are working on a twelve-month project, don't make your customers wait eight months to get their hands on the software. Instead, break the project down into several smaller serial subprojects or increments. That way, the customers can get their hands on good, quality software early on, gain confidence in your work , and get a small buzz of satisfaction at having actually achieved something real from collaborating with your team. If they're not happy with what they get, then perhaps they might be willing to forego other features in order to change what you've built.

The two biggest benefits of working in smaller chunks are that (a) the customers and the whole team can focus on getting a small part of the requirements right at a time, which is far easier than trying to get everything right at once and (b) the demands made on the customer's time are spread evenly across the duration of the project rather than being heavily loaded to the start and end of the project.

Finally, don't be afraid to negotiate-and renegotiate-if things aren't working . Too often in IT we make commitments we can't keep. Instead we cross our fingers and hope we can keep our customers happy, which isn't a service to our customers or our bosses. If things aren't working, tell them, and ask them for help. The