We like the title Random Acts of Product Development. It often appears that product development is a collection of ill-conceived and poorly executed tasks. Those planning refuse to recognize dependencies between groups and tasks and are unable or unwilling to acknowledge they are really working within a system – blinded by the solely important launch […]
One under or ineffectively used tool is the specification or requirements review, which is a form of design review. In this case we are reviewing the design while it is still easy and cheap to make adjustments. Experience suggests, if we do not just forget to do this activity, it is a hastily arranged activity […]
You need not been so technically skilled to be able to see how many project fail due to requirements. We provide a brief list of the failings below: Requirements control Insufficient time Did not include the sponsor or customer Late delivery of requirements Requirements traceability We will not write any more on requirements control that […]
The initial product requirements provide the product baseline. Our project planning will be focused upon delivering meeting these requirements. In a phased development process, we will prioritize the requirements (shown earlier) and deliver iterations. This staged delivery allows us to gain additional insight into the product. We may learn things that necessitate changes to the […]
We now have linked our scope through to the various levels of requirements. We are then able to prioritize the delivery of the various project obligations. The prioritization may be based, for example upon: Technical need Customer need Regulatory requirements Complexity and Risk Technical needs are the dependencies to getting the product features working, for […]
Our configuration management is borne out of our requirements. In our earlier blog post, we discussed how the project scope must be traceable to the requirements. In the case we present below, the project scope is a particular function or need to be met, for example a new feature or function for an automobile. We […]
This may sound difficult, but there are some rules for good requirements. According to the International Council on Systems Engineering (INCOSE http://www.incose.org/chicagoland/docs/Writing%20Effective%20Requirements.pdf), requirements should have the attributes below (similarly can be found at IEEE): Necessary – driven by the objective of the project and business Verifiable – ability to objectively confirmed that the requirement is […]
Requirements are fundamental to project success as the scope definition. Additionally, there are dependencies that impact the ability to produce suitable requirements. A few of those things are: Well defined scope of the work Sponsor and customer involvement Capability of the requirements authors Prioritized functions or abilities The needs or objectives of the customers or […]
We have been on a bit a tear (or rant) about FMEAs. We suggest the FMEA documentation is part of the core of a design process. The ultimate approach we have seen is that of Michael Anleitner (The Power of Deduction: Failure Modes and Effects Analysis for Design, Quality Press, 2010), which uses functional analysis […]
A project comes to an end and now we are in a position to really critique or learn how things went. Ideally, we were learning all along, and now we have the final opportunity to review the project. If our organization has heavy project management influences, we may have a “white book” that captures the […]