PD101 is our series on insights and advice into the less common elements of the Product Development Process. Today we talk the Requirements Document.
We’re lucky to work on a lot of projects. So we’re well placed to make the following statement.
Projects with clear goals, requirements, budgets and timelines are hands down, the most successful.
By a long way. A mile. A country mile. Yet it’s surprising (or perhaps not) how often we are asked to quote or commence a project, without being clear on what we’re to be doing, let alone what will make it a successful stage or project; which is important for us, so we can tick it off as complete, and bill for the work. And importantly for the client, so they can manufacture and sell the product. Because, well, business. So today in PD101, we’re going to look at the Requirements document.
Discovery, Planning & Research. Learning Your Project.
The first stage of any project we undertake is called Discovery, Planning & Research. It’s in place to help understand the requirements of the project, to investigate materials or technologies, trends, users and behaviour, costs and timing, safety standards and intellectual property.
It’s such an important part of the process because the exploratory work undertaken here can save a significant amount of time and money down the track from heading down the wrong path early on. Particularly if we find patents or technology limitations in place that can’t be circumnavigated.
Quite often when discussing a new project, we’ll flesh out what that project might be and develop a scope of work to suit that will achieve the desired outcomes. Once the proposal has been accepted and the onboarding process is complete, we run a session with our development team, in order for you to bring them up to speed on what the project is about. At this point, you or your team may have been thinking about the project for months or even years, but this may be our team’s first exposure to it. So it’s important to convey a lot of information, and to be able to document it in a method that will allow us to revert back to the information throughout the project.
- Key Stakeholders
- Key Documents.
- Project Description.
- Background.
- Description Of System.
- Key Requirements.
- Function.
- Architecture.
- Control System.
- Components.
- Construction.
- Sizing.
- Environmental.
- Manufacturing.
- Installation.
- Service & Maintenance.
- Target Market.
- General Statement.
- Demographics.
- Cost Targets.
- Summary of Business Case.
- Target Price Point.
- Proposed Costings.
- BOM.
- Preliminary BOM.
- Product Usage Environment.
- Physical Environment.
- Chemical requirements.
- Compliance
- Applicable Standards And Regulations.
- Product Labelling.
- Testing.
- Prototype Test program (Alpha I & II).
- Field Test Program (Beta I & II).
- Regulatory & Compliance planning.
- Product Packaging.
- Manufacturing packaging.
- Bulk shipping configuration.
- Individual packaging.
- Intellectual Property.
- Applicable Patents.
- Other Known Relevant IP.
- Reference Products.
- Industrial Design Requirements.
- Branding.
- Appearance.
- Colour.
- Material.
- Finish.
- Ergonomics & Human Factors.
- Timing Targets.
- Development Phases.
- Testing Allocation.
- Production Setup And Tooling.
It’s not critical to have the answers to all of these headings before starting the project, as we’ll flesh them out with you, but most of these headings are common to every project, and the Requirements Document will address all of these items to ensure they are included in the Development Plan.
Sharing Information Efficiently.
Having answers to all of these Requirements within the one shared document, ensures that all stakeholders are aligned on the requirements and deliverables for the project. Further, particularly on large projects, when the development team consists of a number of Designers, Engineers, Project and Account Managers, and other support and manufacturing resources, ensures that everyone can refer to the same requirements document, so that information is not having to be repeated, and everyone has the latest Project information at their fingertips.
Is completing the requirements a quick process? It’s not difficult, but it does take some time to do it properly. Circling back to the start of this piece, ensuring that all this information is captured in as much completeness as possible at the start of the project, guarantees that we will have a product that meets the requirements of our clients business, at the end of the project.
If we are all singing from the same hymn book, with a clear understanding of the project’s goals, requirements, budgets and timelines, it’s hard to go wrong.
Let The Expert Team At Whistle Help You Get Your Project To Market.
Considering working with us? Make sure to have your Requirements Document underway. Need help putting it together? Get in touch.