Sometimes the best way to convey the challenges in product development, is to show some of the reasons things can go wrong. To that end I am going to regale you with a tale of requirements gone astray.
Wearing Many Hats
I worked at a small company a long time ago. I am glad I did, as I wore many hats and learned something new every day while having this job at this small company. This particular instance, we were to design and build an embedded control system for a large manufacturer, and the requirements were listed on a short sheet of paper as a bulleted list of the objective the constraints, and the general performance expected.
Product Development Input
The primary source of contact and the requirement was the head of marketing. This company generally had short communication and hierarchy chains. However, the marketing person was essentially a customer advocate and not really an engineer. In … Continue reading
Learning and Product Development
By now, we should all understand the need for speed when it comes to product development, but not just any speed, it is the need for speed of learning. This is one of the benefits of an agile approach, but this benefit is not restricted to a development methodology, unless of course, the development methodology precludes or runs contrary to fast learning cycles.
You might think that this learning is only associated with complicated or complex systems, perhaps categories of projects that we have no familiarity. It is true that learning is especially required when we are working on things we have little or no experience. However, in product development, we can ill afford to believe we know things that are simply not true or follow unvetted assumptions. For example, we can model and simulate, but neither of these are true parts. If we do this methodically, we can certainly reduce the need for some … Continue reading
We have written much on requirements in other blog posts. We have been maintaining this blog for years, admittedly sometimes more fervently than others. We have created a schedule for our blog posts and other events by Value Transformation personnel available either on the event location on the website or as a downloadable from the website.
There seems to be a myth that “waterfall” development requires ALL of one step in the delivery sequence before the next step can begin. For example, all requirements must be written before work commences on the development work. I have worked in what I would call traditional development approaches that some would refer to as waterfall, and at no time did we believe or act as if all requirements must be known and documented before we moved to the next stage, the actual development. Even PMI recognizes the need work with the level of detail that can be known from where the … Continue reading
Requirements and Benchmarking
One of the things we can do to understand and develop our own requirements is to explore other products that are similar to our proposed product or that solve the same or similar customer problem. Where there are similar needs met, benchmarking is a way for us to understand how other suppliers have met the specific challenge, or more importantly, how we can develop the product in an even better way. Benchmarking can provide us with performance metrics for the product. Knowing this, we can establish the performance expectations from our product which will show up in the requirements for the product.
Requirements and Teardowns
Teardowns are also useful when it comes to requirements generation. We can learn what drives the cost in at least one incarnation of the product, which is how the competition has chosen to meet the customer demand. We then are able to gain some measure of understanding of at least one possible incarnation … Continue reading
The customer can seldom articulate the technical details of the product. The customer may define the product or need in terms of function and performance, but building the product from these documents will be extremely difficult or perhaps impossible. We will need some type of document to begin describing in technical terms the product that acts as a bridge from customer language to technical language.
One of the companies at which I have worked had a document that described the subsystem interactions. This was called a cross-functional specification. The cross-function refers to the interactions of the many electronic control units on the vehicle that were networked together. The document described how the system would achieve the goals of the project, identifying specific signals, particular communications requirements and performance expectations from the numerous components on the vehicle network. This essentially apportioned the function (distributing specific responsibility) across the numerous components of the network. However, this homegrown document filled a very necessary role … Continue reading
In keeping with our requirements work, we will start by identifying the attributes of a good requirement. We start our project off with the requirements, so it stands to reason if we start off poorly or in the wrong direction, we will not make the objective. This situation will get worse the longer we spend time with poor requirements.
Requirements are not loose; these are tangible statements of the product that are able to be refuted or confirmed. As we have seen, requirements are part of our project contract closure, but it is also part of our product testing. To be able to effectively do either of these means we must have requirements that fit the attributes defined below:
Cohesive Complete Consistent Correct Observable Feasible Unambiguous Required Verifiable Traceable Requirements Failures
Requirements not written in a way that meets the attributes defined above poses some level of risk to the endeavor or the project outcome. For … Continue reading
Continuous Deliver and Embedded Automotive
I have worked on projects that employed continuous delivery for embedded products. The embedded product was an automotive component. The core of the software (the operating system) was specified using conventional approach. This operating system consisted of the maximum model requirements for this globally used component. The component looked and acted differently depending upon market segment and geographic location, for example, there were two different European incarnations and more than two for the markets of the United States. This was not just some parameter setting or configuration differences, but whole scale differences in feature content and manner of execution.
As we indicated, the operating system, though we called it an execution engine, was specified and developed using an incremental approach. This incremental approach was based upon a prioritized set of features. That prioritization was based on what it would take to produce a vehicle that would operate safely allowing for testing of key features. In the … Continue reading
Documentation and Rework
Once, a long time ago, I worked at a company that was having some difficulty coordinating their development work. The product that was produced was a complex arrangement of mechanical and electrical / electronic systems. The company was ISO certified and had documentation describing how they would work, including configuration and change management. Funny thing, though this company shows major signs of a configuration and change managements system that routinely does not work. For example, a previously agreed upon solution iteration constituent parts show up, and the parts are then put together to make the product. However, the parts do not fit together and obstruct other parts in the system. The typical symptoms look like:
extensive and costly rework over the interfaces represented by the departments extensive and costly rework at supplier at the last minute inability to put sub-systems together to make the entire system function Documentation and Organization Performance
When we take this to the person in charge of … Continue reading
In the purchasing contract with a tier one supplier, the expected the “0-kilometer” quality or failure rate is not to exceed 500 parts per million (ppm). These are failures seen before the product leaves the OEM manufacturing floor requiring product rework on the assembly line or as the vehicle rolled off the end of the assembly line. The contract is signed and the development staff sets about developing the product. The design is set, there are trial production runs and run at rates and 18-24 months later the product is coming off the end of the OEM manufacturing line at production volumes.
Shortly after production start, the OEM notices the quality is not consistent with contractual obligations of 500 ppm. A dissection of the product and conversation with the supplier finds that there is one component, had a failure rate of 500 ppm, and there are at least two of these components and sometimes three in the product. Meaning the … Continue reading