This time round I asked Francesca, my editor, if I could share the before and after versions of my article with the world and she said YES! I think you'll be impressed at just how cunning and devious Francesca is with words. She only makes small tweaks but they make such a difference.
Tell me what you think and I'll pass the comments on to unsung hero, Francesca.
Don’t Let tThe Engine Run Out oOf Fuel
By Clarke Ching
Summary: My Clarke Ching’s friend Gary is one of those quietly clever people who hated school., He so he left as soon as he could to go work in a factory. Nowadays, years after their school boy days in New Zealand, IClarke works in Europe as a management consultant and Gary owns and runs a small farm in New Zealand. OurTheir lives couldn’t be more different, and yet Gary taught me Clarke one of the most valuable lessons I have Clarke has learned during my his career. In this article, Clarke describes that lesson and how it has’s changed his approach towards dealing with customers and key players in developing a product.
Article Categorization: Project Management
After school, Gary worked for a small fish factoryHe learned the lesson while working on the unloading dock in a small fish factory. His job was to take the fresh catch and fed the fishsend it into the factory where they the fish were processed. Gary said that tThe factory’s owner and manager told him Gary that the business was just like a very big, expensive car and that - just like a car - the business worked best when it’s parts worked in time with each other. The owner said that tThe factory was the car’s engine. and heThen the owner told Gary that his job boiled down to one simple rule: dDon’t let the engine run out of fuel.
The factory owner’s genius was that he recognised recognized that few not all of his staff had the broad view of his business that he did, so he created simple rules that to helped his staff memebers to 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 imagineing the analysts out trawling for requirements, chucking the unwanted fish over the side, then transferring the good fish from their boats into the developer’s’ boats working in the factory to be processed. At the risk of mixing my metaphors, aAs I look back at the dozens of software development teams with which I have worked with, 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 the a shortage of quality customer input. For example, Many many iterative teams, for instance, 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, for instance, (i.e., by starting doing on development work before the analysis and design is complete). They break their rules because they don’t want to sit idle and they don’t want to delay the project. Instead, they make a bet that they can get a good chunk of the requirements right, knowing that we[f1] and – iIn my experience –, any gains made by inventing “pretty good” requirements early in the project are lost, and then some, 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 and insist on having committed, and competent and available customer’s being 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 – otherwise we would do it as a matter of course.
– (in credible, ball park dollars –) what they he are is losing by not providing adequate customer involvement. Keep in mind that your customer’s are probably not aware of just how devastating their lack of engagement is. Not that they’ll Customers won’t often admit it, but one of the reasons why they disengage is that they see IT is seen as a black art thatwhich they’ll never understand. It’s easy to imagine how my friend Gary - one person - 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 them tocustomer understand the cost of their disengagement in their own language.
Their The customer’s language usually involves money, time, or and uncertainty. For instance, earlier this year, three weeks into a nine- month- long project, I had to have a grown upserious conversation with our project’s sponsor, in which I told telling him that the following day I had no choice but to submit a new project schedule which that finished twelve weeks later than the ourwe had originally committedment to. I said that tThe 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 provided the extra budget to cover the increased duration. But, that cost was dwarfed compared to the revenue which that would be lost due to a three- month delay. The software was a key component in a business initiative which 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 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 customer’s a pleasant experience . Ask yourself, “Would you like to be a customer on this project?” then Then ask, “Why not?”. While we try to accommodate for our customer’s lack of understanding forof what we do, we inevitably intimidate them. We IT folks speak in a funny language, and draw a lots of complex diagrams., and while we try to accommodate our customer’s to make it easier for our customers we inevitably intimidate them. We also ask them to answer very difficult questions, and we expect them to get everything right up frontfrom the beginning. Their The customer’s reward is that they don’t should get software for ages,<<<I’m not sure what this means>>> but tThe truly lucky ones and when they do get - if they are lucky -get the software that does what they asked for. Unfortunately, what they asked for often isn’t want they want. Plus we’re smelly.
First, think of your customers as if they were guests in your home –, so be hospitable. Make them feel welcome. Provide them with comfortable seats – treat Treat them as if they’re part of the your work team. Use Speak their language where when you can. Offer them a cup of coffee – eat with them! Listen to their concerns, and share your own. At the end of the day, it all boils down to making make it easy for them to collaborate with you.
If you are working on a 12 twelve- month project, don’t make your customers wait eight months until they canto get their hands on the software. Instead, break the project down into several smaller serial sub-projects or increments. That way, the customers can get their hands on good, quality software early on, and gain confidence in your work. Not only that but the customer will, 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’re willing to forego other features in order to change what you’ve built.
The two biggest benefits of working in smaller chunks, like this, though is are that (a) the customers (and the whole team really) 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 which that relieves a lot of the pressure they’re[f2] under, and (b) the customery [f3] can spread their its time commitments across the duration of the project.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, if things aren’t working, to renegotiate-- if things aren’t working. Too often, in IT, we make commitments we can’t keep. Instead we cross our fingers and hope that we can keep our customers happy. But we don’t do our, which isn’t a service to our customers or our bosses a service by doing this. If things aren’t’ working, then tell them –, and ask them for help. The customery hasve 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.
[f1]Who’s “we”?
[f2]Who’s “they”?
[f3]Is this edit correct?
