Contents
Product Development Processes
- quality assurance: specifies phases the project needs to pass through and checkpoints along the way. When chosen wisely, following the process can be used to assure quality of the resulting product
- coordination: a clearly articulated development process acts as a master plan that defines roles for each member of the development team. This plan informs team members when their contributions will be needed and with whom they will need to exchange info and details
- planning: a development process includes milestones corresponding to the completion of each phase. The timing of these milestones anchors the schedule of the overall development project.
- management: a development process is the benchmark for assessing the performance of an ongoing development effort. By comparing the actual events to the established process, a manager can identify possible problem areas.
- improvement: the careful documentation and ongoing review of an organisation’s development process and its results may help to identify opportunities for improvement.
Product development processes can be thought of as:
- the process of generating then narrowing of alternative concepts and increasing specification of the product until the product can reliably and repeatedly produced
- an information- processing system, with inputs (corporate objectives, strategic opportunities, available technologies, product platforms and production systems) then various activities process the development information, formulating specifications, concepts, and design details. The process concludes when all the information required to support production and sales has been created and communicated.
- a risk management system: in early phases, various risks are identified and prioritised. As the process progresses, risks are reduced as the key uncertainties are eliminated and the functions of the product are validated. When the process is completed, the team should have substantial confidence that the product will work correctly and be well received by the market.
For some further details and some examples of generic or specific development processes see the following slides which summarise the product development processes from chapter 2 from Product Design and Development (Ulrich & Eppinger, 2012).
For some further reading, this paper by Krishnan and Ulrich (2001) is a review of research in product development providing insight into what kinds of decisions are made right throughout in the product development process, and how these affect the overall outcome of the product.
Managing projects
- treat your design projects like a full time professional job (ie 40 hours a week). Attend all your lectures and tutorials. Work in the studio, workshops, library all day, every day.
- take lots of notes and record everything you do. Take pictures, audio, video. You can always delete things later, but you can never go back to the moment itself. In class take copius notes. In meetings/tutorials ALWAYS agree actions (i.e. who is doing what, and when) at the end of a meeting. Your own notes are your guide to what happened. Reading other peoples notes is much less evocative for your memory.
- always bring in your work or have quick access to it (possibly in a different format, e.g. images of it on your phone or laptop).
- have a formal plan written down and use it to guide your project. It should have tasks, timings and milestones to help you evaluate progress as you go. Review the plan constantly, update it and change it by all means (this is called managing!), but make sure changes are rational and justified.
- aim to over deliver on what’s expected of you. If you do this you’ll be better than everyone else. You’ll be seen as keen, capable and you’ll get repeat business every time!
- understand what’s expected of you. Don’t ever assume. Constantly evaluate how to impress your audience/tutor/client etc. Know the criteria, brief or guidelines intimately – be able to regurgitate this back to someone if they asked you what you’re trying to achieve. Try to see it from their perspective, what would they want to see/know? what is their background? what is it that they think will be important? if in doubt, do some background research into them. Think carefully about this, discuss it with others, ask the peop
- find out when you work best in the day/week and exploit that by making sure you’re running on all cylinders then!…ie not hungover, not doing a paid job, not at the cinema etc.
- work collaboratively with your peers as much as possible (the studio is perfect for this!). Learn from everyone around you.
Our students ought to be able to login with their University credentials. If you are unable to do so, please contact our student Help Desk in the Watts Computer Suite (level 2).
Here is quite a useful guide to creating a project plan and a Gantt chart.
Product Design Specifications (PDS)
Product design specifications (PDS) spell out in precise, measurable detail what the product has to do. The initial priority in developing a PDS should be a direct response to the list of user requirements. Ultimately a PDS is intended as a means to control and evaluate the direction of the design solution from an early stage, as such they form a key part of the control documentation. The PDS does not describe how to address the user requirements, but does represent an unambiguous set of short statements that the development team agree will satisfy the user requirements…they do describe the what. Since the PDS is such a clear and comprehensive coverage or product requirements, it is used as a basis for material for handbooks as well as sales and technical literature. There is a great deal of evidence demonstrating that a poor PDS is a common cause for designs to fail.
An initial version of the PDS is generated by responding to each item on the list of user requirements and preparing a corresponding list of metrics. Ideally the metrics should reflect the extent to which the design satisfies the list of user requirements, since that will to some degree define the success of the product. For each of these metrics, it is ideal to determine benchmark values from competing products. In some cases such data can be difficult or impossible to obtain, and generally speaking this is a very costly, time consuming exercise, requiring the acquisition and testing of a range of competitor’s products. After gathering the benchmark data, target values should be set for each of the metrics, including the specification of ideal and acceptable target values. Such metrics can be presented as at least or at most values, as a range between two values, an exact value, or as a collection of discrete values often corresponding to some standard value.
This initial PDS document can then be extended into a more comprehensive PDS, covering other requirements for the product that may not be directly linked to the list of user requirements. This can be achieved working through each the specification categories and responding to the prompts provided in the section below. Note that not all categories may be relevant for every product, and in these cases they can be ignored. Some categories may not require consideration until later in the development process and hence may be put on hold. PDS documents should be headed up with the title of the product, the creator of the PDS or person responsible for it, the date of last issue and the issue number. It is also good practice to annotated and log any revisions that are made to make it clear how the PDS has evolved. This is also a good learning exercise in particular for a new product line, so the same mistakes with metric estimates (which might be too ambitious or conservative) can be avoided when developing future specifications.
There are two great resources for understanding product design specifications:
- Total Design: integrated methods for successful product engineering (Pugh, 1990) by our old friend Stuart Pugh (remember the Pugh’s matrix in ideation?). Chapter 3 (Design Core: The Product Design Specification) is the one you want,
- Product Design and Development (Ulrich & Eppinger, 2012). Chapter 6 (Product Design Specifications) is the one you’re after here.
For a brief summary of both methods, see the slides below:
Here is some other interesting reading, including ways to improve the development of product requirements, outlining some common problems that companies face when developing product requirements and some useful tips when developing these. 3DCADworld also produce these tips to writing a better functional specification (also called a PDS).
Other reading in the form of some very common and useful standards to be found in our British Standards Online (BSOL) site in the online library:
- BS 5750-1 1987, EN 29001-1987,ISO 9001-1987 Quality systems. Specification for design-development, production, installation and servicing
- BS 5760-3 1982. Reliability of systems, equipment and components. Guide to reliability practices- examples
- BS EN ISO 9001 2008 Quality management systems. Requirements
Failure Mode Effects Analysis (FMEA)
Risk assessments
Risk assessments are an important part of project work. The key stages for risk assessment are:
- identify what the hazards are (e.g. tripping over cables).
- identify who (or what) might be harmed and what the severity of this is, and how likely it is (e.g. hitting head – medium severity, quite likely)
- state your actions to respond to this hazard (e.g. tape all cables to floor).
Note that it is always good to discuss and compare your risk assessments with others, and you need to get these signed off by a tutor or safety officer.
Here are the relevant risk assessment forms:
