I really enjoyed [this interview](http://www.networkworld.com/community/blog/tony-fadell-unique-nature-apples-design-process) with Tony Fadell on the unique nature of Apple's design process. The discussion about project abandonment percentages is incredibly important, and often overlooked in large companies. In many cases abandonment is a financial decision related to either real or opportunity costs associated with launching a product. People who have never worked for a large consumer products company likely have no idea how many products are cancelled just before launch because of the incredible cost in launching a product into the market. Tony makes an amazing point about the toll such high cancellation rates have on employees at a company, and on the quality of the products the company ships. The inverse is that high commitment to ship products that pass key milestones leads to better employee commitment. > "When you’re in a culture that has a point of view, and drives to launch everything it does, you know you’re on the hook and you better bring your best game every time," Fadell explained. Tony contrasts his experience at Apple with his experience at Philips: > Fadell explained that a key and yet often overlooked difference between Apple and other tech companies is that Apple ships 99% of the products that pass certain internal milestones. By way of contrast, during Fadell's tenure at Philips - where he was charged with overseeing the company's audio strategy - the iPod guru noted that Philips would axe 9 projects out of 10, even if a particular product was about to ship. I don't think large companies have a metric for tracking the number and impact of cancelled projects. In my experience executive teams wanted to forget cancellations as quickly as possible and move on. They considered the cost to be in the past, and by having cancelled the project they had cut any ongoing cost. But as Tony points out, there are ongoing costs, just not costs that have their own column on a balance sheet or scorecard. In my experience it was clear ... the impact of cancellations were cumulative and devastating. The importance of commitment is actually one of the 3 c's I use when evaluating a project: _Clarity_, _Competency_, and _Commitment_. Over the years I have found these to be the key pieces of early stage information that will best predict the success of a project. Tony's pont about commitment is that it isn't only about commitment to a project, it is about the culture of commitment in an organization. I like this point, and I imagine there is a corollary for organizational clarity and competency. Below are a few notes related to project level evaluation of the 3 c's **Clarity** Clarity is an evaluation of how clear the goals are for the product, and how well understood the product is. For example: * A project to enhance a successful existing product with incremental features likely has very high clarity. * A project to move a successful product through a major transition will likely have medium clarity, but in some cases will have low clarity if the product manager and the team have different ideas about product direction. * A project to improve an unsuccessful product is usually medium to low clarity. If you are lucky you understand what went wrong, but lack of clarity is often the reason it failed in the first place. * A new product is usually low clarity, but if you have a great product manager it may be medium clarity to high clarity. * A new product in a new market is often low clarity and may even be disguised as medium to high clarity because the teams reviewing the product have little experience in the market. By this I mean the product brief will use language that sounds high clarity, but market experts would easily identify the brief as too vague. This is where competency and clarity overlap early in a project. My first task was always to make sure there was a plan in place to address any clarity issues immediately. From my experience without such a plan and milestones for high clarity, teams often started to build the wrong product, or multiple wrong products. If the team cannot agree on what the product really is, it will certainly fail. New products could achieve medium to high clarity. The key step is to identify clarity as an issue and put a plan in place to provide good clarity early in the project. I have seen many product requirements documents that were very detailed, but no two team members would describe the same product when asked what the product was. Providing detail is not the same as providing clarity. **Competency** One of the other key issues in the success of a project is competency. In a large company design, and engineering _resources_ tend to be plugged in to a project primarily based on their availability. There is an idea of a performance band with some people regularly performing better than others, but rarely a deep understanding of the individual competencies of team members. Having directed both engineering and design teams, and worked closely with product management for many years I have come to see that individual competencies play a key role in project success; a role that is rarely reflected in evaluations or performance rankings. Evaluations rarely measure competency. For an interesting take on the fallacy of skills in success see [The Success Equation: Untangling Skill and Luck in Business, Sports, and Investing](http://www.amazon.com/The-Success-Equation-Untangling-Investing/dp/1422184234) Here I look for a match in competency for the product needs, but also for how well the team works in the particular product context. How much experience does this team have defining and launching a new product? Has the lead engineer designed anything at this scale before? Many projects fail because a key competency is lacking on the product team. **Commitment** This is what Tony is referring to in his interview, how much commitment is there for this product? This refers to team commitment as well as executive commitment. In my experience, commitment issues fall into a few categories. *Market Issues* It is sometimes the case, especially in technology, where the market is moving so fast projects become obsolete before they are completed. This leads to high cancellation rates. These cases are about risk management, and understanding that the market evolution rate is a key issue. For example having a 24 month product cycle in a rapid innovation market may be taking on a lot of risk. If you can't move faster, maybe find a market that better matches your organizational delivery capabilities. *Structural Commitment Issues* In some cases a company is trying to do too many things, and commitment is a structural issue. I suspect Tony's characterization of Philips false into the structural definition. In these cases it is important to force prioritization and work with executives to understand that doing fewer things better will actually result in shipping not only better products, but more products. It can seem counter-intuitive, but I think Tony's description above shows how this has been proven at Apple. Less SKU's more volume. *Project Commitment Issues* I often found that when project comitment was low, it was low in very specific ways. Here are a few examples: * Low hanging fruit - Many projects came across my desk as the so-called low-hanging fruit project. These are projects that are so low cost and high value that they seem obviously high-commitment on the surface; they often originate in an executive review meeting. The main issue here is that no one questions them, so their clarity is usually quite low, and their commitment falsely high. Usually as clarity rises even a small amount, commitment collapses because the actual project could never deliver on the low hanging fruit mirage that came out of a thirty minute executive discussion. * The magic mirror - Another class of projects with commitment issues were the magic mirror projects. These are projects where whomever is looking at the projects sees what they want to see, and ignores everything else. These types of projects are the most dangerous because they are usually multi-headed beasts that are trying to simultaneously serve many masters. Their commitment is based in company politics and thus commitment can shift or disintegrate very quickly. Given my team's success was based solely on shipping successful products my most important task was usually at the early phase of projects, and mostly making sure that projects scored high on their combined CCC levels.
