The 2009 Standish CHAOS report states that only 32% of software projects are delivered on time, on budget and with the required features and functions. A staggering 44% are late, over budget or with less-than-desired features and functions. At the same time, 24% are cancelled prior to completion or delivered and never used. So what makes a project successful?
Alan MacCormack, a professor at Harvard Business School, asked a software firm to identify a “good” and a “bad” project. The firm’s executives said that their “good” project was one where the specs were completed up-front, the design was optimized, it was executed efficiently and on-time, and the final product was very close to the initial specs. Alternately, the “bad” project went through constant change as the development team struggled to understand what the customer really wanted. The team had to respond to frequent changes, and the final results were very different from the initial specs.
MacCormack then rated the products from both “good” and “bad” projects based on market acceptance, quality and productivity. He found that the “good” product was a market failure while the “bad” product was a market success. It’s not surprising that the iterative development process created a better product. The real eye-opener was that the company’s managers thought that learning about the market and then building a product to satisfy it was “bad.”
Based on this experiment, MacCormack identified four software product development practices that spell SUCCESS:
- An early release of the evolving product to the customer with a minimum set of features
- Getting early feedback from the customer and improvising the design
- An experienced team able to make the right decisions
- A modular architecture that is optimized for change rather than maximum performance
Another equally important measure of success is your customer’s delight with the product. We see plenty of average software products all around us, but we seldom see a valuable and elegant product that truly catches our attention. In 1984, Dr. Noriaki Kano published a paper on “Attractive Quality and Must-Be Quality,” in which he presented the Kano Model – a tool to identify how to create products that will delight the customer.
The Kano model showed that the threshold (or “must have”) features are those that must be present in the product for it to be successful. Improving the performance or amount of a threshold feature beyond a certain point would have little impact on customer satisfaction. After this, there are two options: either increase performance by adding new features or discover needs that the customer isn’t even aware of and meet those needs.
There is no substitute for developing a deep understanding of what customers actually value once they start using the software. Great products emerge from a team that truly understands both the business and the technology requirements.
Agile teams work in collaboration with customers towards a single, customer-perceived goal. They ask important questions outside of the requirements spec: why develop the product, who is the end user, why and how a particular feature will benefit the customer, how they work, etc. This collaboration occurs throughout the partnership.
At the same time, Agile teams continuously strive to reduce waste from the value chain: delays, extra features, extra code, partially done work, defect queues, etc. The team works in an iterative and incremental mode and seeks customer feedback on completed features at the end of each iteration. Such a collaborative environment eliminates the risk of misunderstanding the customer’s needs and business requirements.
You cannot simply assume that a project was successful because it was delivered on time and conformed to the spec. Agile teams, through close and effective collaboration with the customer, remain concerned for the overall market success of their products – not just for the successful delivery.
So how can you tell if your latest project was successful? Simple: ask your customer. It is the customer’s delight with the product – and the delight of their customers –that truly reflects the success of your project.
References:
1: Please look at Alan MacCormack’s work at http://agile2003.agilealliance.org/files/AlanAgileSoftwareJun03.ppt. This story is also covered in “Implementing Lean Software Development (Book)” by Tom and Mary Poppendieck
2: Kano model (April 1984): “Attractive quality and must-be quality” (in Japanese). Journal of the Japanese Society for Quality Control 14 (2): 39–48
This Post was an Agile collaboration between Peter Harrison & Mayank Gupta of GlobalLogic
Popularity: 82% [?]


April 22nd, 2010 at 5:36 am
Nice and informative article.
Beautifully written around its subject line. I particularly love the definitions of “good” and “bad” project and there correlation with project success.