Jez Humble, author of Continuous Delivery and principal consultant at Thoughtworks, a software company that focuses on software design and delivery, believes there is an inherent flaw in this type of thinking. He says businesses are trying to predict what customers or users want--instead of asking them. "When IT thinks of all their wonderful IT projects, they think of all the ways in which they can make each of them as perfect as possible. The reality is no one cares. It's sad but true. People want to solve their own problems. It's not about the fabulous products you can build, it's about how you can solve a customer's problems," he says.
He has a point: Customer predictions are extremely hard and can often be counter-intuitive. Neither are detailed requirement documents the answer, because if they were, IT projects wouldn't suffer from scope creep.
Desisting from guessing what gets people is a lesson President Obama's campaigners learnt. When the team was tasked to send out e-mails asking for donations, the big question was: What do we put in the subject line? They experimented with hundreds of subject lines but, to their surprise, the one that really worked was: 'Hey'. In an interview with Bloomberg Businessweek, Amelia Showalter, director of digital analytics, said: "We were so bad at predicting what would win that it only reinforced the need to keep testing."
"That's totally counter-intuitive," says Humble talking about the campaign. "While sending out these e-mails, the team would never have been able to guess what people would respond to. The truth is, guesswork in IT is lethal. Imagining what the business needs or the customer wants is a collective waste of time and effort--especially in waterfall models where you deliver the product to the customer or business only at the end of project completion."
The smarter thing to do is to put a prototype out there quickly for customers and let them tell you where to go--what Showalter called testing. To do that, companies need to break down large projects into bite-sized pieces and prioritize them. It's what Humble did when he built a commercial release management system for a Fortune 500 company.
"We built it in such a way that the very first feature was a simple status page showing that the application was live," he says. "The whole idea of continuous delivery, which is a subset of the agile methodology, is to say that software is production ready from day one."
But how do you define what the smallest unit is? For instance, could Mehta from Anand Rathi have attempted just one of the three projects, instead of all three? The answer, says Humble, is to focus on the customer. "If you know the smallest amount of work that you need to do to solve a customer's problem, then, you can solve a customer's problems in less than 90 days."
Sign up for CIO Asia eNewsletters.