Managing product development is difficult. Especially when you don’t have a technology background and you are doing it for the first time. We have worked with many such business owners to help them develop hardware and software products. Throughout the years we have also discovered there’s a lot of inaccurate advice out there. This article will help identify 6 important topics to successfully manage product development for non-technical teams.

Project Management

The goal of Project Management is to distill the vague “build this device” type of job into a sequence of tasks with clear deliverables and short deadlines. A good plan should also break up the project into phases or milestones. As a general rule, each milestone should be scoped so that the milestone’s completion can be clearly measured–avoiding situations such as, it’s “50% done” or “making progress on” type of status reporting. Another good rule is to make the timeline for each milestone no longer than two weeks. See a good example of a proposal with a project plan at http://www.volersystems.com/v-2009/example-proposal/

Project Management is largely about managing risk. It is critical to invest time up front to accurately scope the desired function, performance, and cost of the design. Getting clear and complete specifications at the beginning of a project ensures the team will at least start on the same page. If the project has many unknowns, then doing a feasibility study or rapid prototype that targets key risks or uncertainties often makes sense. Feasibility studies can help to firm up the design idea, identify project risks, and gather information that will prevent costly problems from occurring later in the project timeline.

Communication is Key

Once the project has started, communication continues to be a key element to achieving successful project results. Here are some helpful questions to ask the engineering team:

  • Where are the risks in the project?
  • Are there important details missing (or are there areas not fully understood from the customer’s point of view)?
  • What is your plan for managing the project?
  • What is the impact of any new feature request on the budget and schedule?

Project status should be communicated at regularly scheduled intervals–at least monthly and usually weekly–as well as when issues come up. It is good practice to make adjustments to the project timeline and include updates to the cost, schedule, and performance based on what has been learned. More good questions to ask:

  • How do these changes affect the schedule?
  • What is the impact to cost?
  • How will this affect performance or function?
  • Is there new information you have learned since initiating the original plan or schedule?

Communication is not always about what’s been said, but what’s been understood by all relevant parties. To make sure there is a complete shared understanding, you may have to ask again, or repeat back what you’ve heard. This may seem like you are over-communicating, but it definitely helps to play back your understanding of situations and instructions. This technique fosters a mutual understanding of the project’s specification, the risks that have been identified, and any plans to eliminate or at least mitigate them. It is recommended to always follow up in writing.

Identify Risks at the Design Team Level

When creating something that has never been done before, there is often risk that it cannot be done or that it will not meet performance or cost estimates. For example, we worked on a talking device for medicine reminders, the functions could be implemented, but not for the cost estimates that the market would accept. In such cases, trade-offs must be made to either reduce functionality to meet the cost target, or the cost must be increased. Early on, when scoping the project, a good team should be able to tell you where the risks are in the project. At the beginning of a new project, invest enough time to reach a shared understanding of the design’s context and its constraints. Identify the important trade-offs, parameters, and risks. For each risk that has been identified, is there a plan to eliminate, reduce, or at least manage it? Address risks as early as possible in the development–using prototypes or feasibility studies where needed–and include any risks identified as part of the specifications and plans. They need to be addressed in the schedule. There may be an initial period of feasibility work needed to determine how to minimize risks before moving forward with the design. This is a short, inexpensive phase.

Despite the careful attention to detail taken at the beginning of the project, new risks may be discovered only after the project is underway. These new risks can impact design choices, the project schedule, or its budget. Solutions can range from proceeding as planned to taking a new direction. Often, additional prototyping or exploration of design options can help determine how best to meet the goals and specifications for the project. Clear, timely, ongoing communication is essential to managing risks and trade-offs based on the best available information. It’s possible that the goals for the project may need to be adjusted based on new information, or that constraints may have to be relaxed.

Legal Issues – Who Owns the Design?

The ownership of all of the intellectual property related to the design (e.g. patents, software source code, design documents, etc.) should be clearly spelled out as well as the particular ways the design will be captured (e.g. schematics, source code, assembly instructions, test plans, etc.).  Care must be taken to get all the design documents from your vendors. For example, changes cannot be made to the software if you do not have the source code.

When working with Voler, our contract ensures that the client owns all the intellectual property and we deliver all the required design documents that you need to build the product and make changes or updates. We are always available for changes and updates as you evolve your product (additional fees apply).

Debugging Process and Testing

Once the design has been built, a testing and verification phase is needed to ensure that the design specifications and implementation match the needed functionality. This verification requires testing the product in each mode of operation and can require a significant amount of time depending on the complexity of the device. Most of our development projects plan on one spin of the product to create a high-quality production ready design. Later when the product is shipping to customers, testing is performed as part of the production process.  Each device is tested to ensure that only quality products are shipped to your customers. For additional information on testing see Common Errors Transferring Products to Test.

Trust

The key to any successful collaboration is trust. Trust is built on continued investment in clear communication to achieve shared understanding and is maintained on mutual verification of goals, actions, and outcomes.

It is of utmost importance for us to partner with our clients to provide the best possible solution for the project. We want our clients to select our services based upon our reputation;not as the cheapest developer, but as the most trust-worthy and competent developer in the market. Our team manages your project based upon short milestones, so you can see traction and identify the progress of your product within the timeline and budget. To accomplish this superlative level of project development requires careful management, timely updates to our clients, and the highest quality service. Our results speak for themselves. We have delivered hundreds of projects with great success and are committed to doing what it takes to meet or exceed your expectations!

Related Articles