Speeding Up Product Development

Does it ever seem like the last 10% of the project takes 90% of the time? If you have had this experience, you are not alone. It happens all too frequently when trying to develop technology products in a small company.

Managing a project with several different engineers, all with their unique areas of expertise, can be a daunting task. Here are a few tricks of the trade to make things go a little smoother.

We always start the beginning of the Detail Design phase with a drawing tree. If you are not familiar with this type of drawing, it is a tree that shows all the sub-assemblies that will make up the final product and their relationship to each other. A box represents each assembly, and lines connecting the boxes show the relationship between the assemblies. Having this drawing is a good way to communicate with all members of the development team the structure of the product, how all the pieces connect, and what processes will be used in its manufacture. It is also an excellent method of tracking the progress of the project and identifying areas that need more resources.

It is a good idea to decide what tasks are on the critical path and which are not. Tasks on the critical path are the ones that define how long the project will take and are generally the ones that need to be done in sequence. Identifying these tasks will allow the team to focus on those tasks that will shorten the time needed to complete the project.

Sometimes projects take longer because what is assumed to be product development is really technology development. This mistake can trip up even the best scheduling efforts. For more information on this topic, see our white paper here.

We often get asked, “When will you be done?” which begs the question, “What is the definition of ‘done?’” The output of Detail Design is a master book of drawings that contain all the information necessary to manufacture a product that will meet the requirements defined in the Requirements Document. Of course, the prototype must then go through some form of Design Verification Testing, but the goal is the drawings, not the prototype (assuming we are making a product and not an MVP). Having a clear definition of “done” focuses the team on achieving a goal that is well communicated and understood. Pressuring the team to produce a prototype irrespective of the master book or requirements can cause delays in the project.

Because product development, if done correctly, is mainly about creating intellectual property, it is sometimes tricky for outside stakeholders to “see” progress. Most of the early work, mere pieces of paper, can only be understood by subject matter experts. This dynamic can sometimes create pressure to produce work that can be seen by laypeople to generate a perception of progress, which can slow the project down. Clearly communicating milestones at the beginning of the project, even if all stakeholders cannot fully understand them, can go a long way to helping to reduce the pressure to skip steps to show progress in a form all stakeholders can understand.