Clarke Ching's friend Gary is one of those quietly clever people who hated school, so he left as soon as he could to go work in a factory. Nowadays, years after their schoolboy days in New Zealand, Clarke works in Europe as a management consultant and Gary owns and runs a small farm in New Zealand. Their lives couldn't be more different, yet Gary taught Clarke one of the most valuable lessons Clarke has learned during his career. In this article, Clarke describes that lesson and how it has changed his approach toward dealing with customers and key players in developing a product.
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 (in credible, 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