Many years ago, I was doing work for GE Aircraft Engine. We had been engaged to help them re-engineer the process by which they overhauled jet engines. Because of the cost of a jet engine, GE’s clients were interested in shortening the time that their engines were in the shop and out of service. A significant reduction in turnaround time could provide a real competitive advantage.
But, that is not what this post is about. This post is about a method I designed to evaluate packaged software that GE might procure to support their efforts to reduce the cycle time of the overhaul of a jet engine. I developed a checklist against which we could score software. There were 7 attributes that we measured:
- Fit for Purpose (functionally complete)
- High Quality (defect free)
- Good Value
It turns out that the list is more generally useful than I thought when I put it together. These attributes, when applied to: maximizing customer satisfaction; and balanced against the need to minimize costs (you have to be able to make a profit) provide a powerful tool that if applied correctly, all but guarantees the success of the product. And, I have this list many times over: any time I am developing a (work) product.
Let’s spend some time with each of the members of the list:
- Fit for Purpose: This attribute confirms that the product addresses the list of functional requirements as understood by the product designer. This is not necessarily the list of requirements that you might get from your customer, if you were to ask. It is the job of the product designer to understand what the customer wants and the really good designers spend the time to observe their customers (I’ve talked about this before—Product Strategy —A case Study) and understand what they really need, and not what they want.
- High Quality: I define this as being “defect free”. The pickiest of you will probably note that traditional definitions of quality include the requirement that the product be “fit for purpose”. And, while I agree with you on that point, there are two reasons that I choose not to include it in the quality attribute:
- Fit for purpose is so important and so big that trying to bury it under quality demotes its importance to the success of a product and a product that is fit for purpose is 90% the way there.
- The “defect free” attribute of quality is also big and important and I like the idea of focusing quality on the tasks that ensure a defect free work product.
- Maintainable: I am a fan of products that are durable and can be extended (see Extensible below) and products that are designed without thought to being able to keep them in service are unlikely to keep the customer happy or the product profitable. Even the highest quality products require maintenance as the world around it, e,g. operating systems or other related systems that they interface to, change. If the products are not designed to make this easy and promote good outcomes (a product that continues to be relevant) as the world change the cost of ownership rises and the level of frustration, as initially well working products become increasingly unreliable, mean that the product will lose customers and ruin the reputation of the company that offers it.
- Scalable: I don’t know how many products are designed without accounting for even moderate growth in demand whether that is number of users or numbers of transactions processed. A well-designed system should be designed to account for growth. There is a bit of an art to deciding what constitutes reasonable growth, but it is well worth investing some serious resources to answering this question.
- Efficient: This attribute is often overlooked with devastating results. I used to be surprised by how little technical designers know about algorithms and how they consistently choose the least efficient method of processing transactions. This item could probably be included under scalable, but it is so often an issue that I pulled it out to make sure it gets the attention it deserves.
- Extensible: I have never seen a system that was finished and stayed finished. Every system goes through an evolution which almost always means that the product will undergo extensive updates. And, products that require extensive architectural modifications to prepare them for the functional updates are expensive to maintain and require significantly more labor (and time) to update.
- Good Value: This one is important. If the customer doesn’t find the product valuable, they won’t pay for it and you won’t be in business. Enough said!
- Buildable: This item wasn’t on my original list since we were evaluating products that were already built, but when you sit at the drawing board and reviewing the design for your shiny new product and are trying to decide whether to move forward, it is never a good sign if you are looking to use technologies that aren’t yet ready for prime time. This usually involves enabling technologies, like the Internet or AI (capability), or it can be related to throughput or storage (capacity), but no matter which (or both) is involved, betting on some not as yet developed technology is usually a losing proposition.
The title of this post is “A short Checklist…”. I didn’t say that it was an easy checklist or that the work associated with working it is inconsequential. So, if you want good outcomes, pay attention to the list and put the work in to make sure that its principles are incorporated into your product. You will find doing so results in higher success rates. So, maybe I exaggerated slightly in the title.