Don't Let the Engine Run out of Fuel

After school, Gary worked for a small fish factory. His job was to take the fresh catch and send it into the factory where the fish were processed. The factory's owner and manager told Gary that the business was like a big, expensive car that worked best when its parts worked in time with each other. The factory was the car's engine. Then the owner told Gary that his job boiled down to one simple rule: Don't let the engine run out of fuel.

The factory owner's genius was that he recognized that not all of his staff had the broad view of his business that he did, so he created simple rules to help staff members run their parts of the "car" in a way that was optimal for the business as a whole. Over the years, I've taught myself to look at software development teams in much the same way as Gary's boss looked at his business: I imagine the analysts out trawling for requirements, chucking the unwanted fish over the side, then transferring the good fish from their boats into the developers' boats working in the factory to be processed. As I look back at the dozens of software development teams with which I have worked, the majority of these software development projects have been "starved of fuel."

What is horrifying and unintuitive is that it is much worse in software development than in a factory, because, unlike factory workers who can't chop up fish that doesn't exist, we can still create pretty good requirements—despite a shortage of quality customer input. For example, many iterative teams will break their methodology's rules and start development work without a fully engaged and committed customer on board. Likewise, many waterfall teams break their rules, too (i.e., by starting on development work before the analysis and design is complete). They break their rules because they don't want to sit idle and delay the project. Instead, they make a bet that they can get a good chunk of the requirements right, knowing that they can safely rework the software if needed. Unfortunately, it takes considerably more effort to rework a poor requirement than it does to create it in the first place. In my experience, any gains made by inventing "pretty good" requirements early in the project are lost later in the project. Oftentimes the software is not reworked and the customer is given an inferior product.

A better but far harder approach is for IT management to focus on solving the root cause of the problem. One should insist on having committed and competent customers onboard from the start of the project. Sadly, this isn't as straightforward as making sure the fish get off the boat and into the factory as quickly as possible.

The key to achieving this turnaround is to start with the person who has the most to gain or lose from the project, then figure out (incredible, ballpark dollars) what he is losing by not providing adequate customer involvement. Keep in mind that your customers are probably not aware of just how devastating their lack of engagement is. Customers won't often admit it, but one of the reasons why they disengage is that IT is seen as a black art that they'll never understand. It's easy to imagine how my friend Gary alone could starve an entire fish factory of fuel, but it's much harder to see the costs in a software project where the fish are invisible. Our job is to help customer understand the cost of their disengagement in their own 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 customer has more to lose than we do, and more power to change things for the better.

From a fish factory to a software development team, developers and key stakeholders can all learn to speak and communicate in a similar language that will help the engine of business run smoothly.