It is necessary for organizations to standardize and maintain a product development process. It is has been proven over and over again that by doing this will allow for more creative action to take place, not hinder it.
A quote from Plato: “The beginning is the most important part of the work.”
A project needs to be planned, controlled, and monitored from its inception to its completion. In fact, all projects use a methodology of processes, procedures, and templates. If you don’t think you have one, it really means that you have a poor and informal one. Do not confuse scheduling software with project planning! If you need a project plan, there are three basic ways to go about it:
- Build one yourself. You can build a custom campaign that perfectly reflects the philosophy and best practices of your organization. Many companies try this.
- Buy one. You might be surprised to learn that your plan when finished ultimately looks similar to most others that people use. That is why many consultants can help without having the intimate knowledge of your industry. However, you may think that you spend as much time with the consultant as you would have doing it yourself. I know I have, I been on both sides!
- The hybrid option of purchasing a methodology and then customizing it to meet the specific needs of your organization. This gives you some of the benefits of option 1, while also taking less time, which is the major benefit of option 2. Many companies are choosing this option as a “Best of Both.” These pre-built methodologies can have many of your organization needs to be successful.
An existing methodology allows you to deliver an effective option practically immediately. I recommend the use of the hybrid option, which enables you to spend your time on the application versus building the plan to achieve the result. The simplicity of a single flexible model will create clarity for your staff and as a result better execution.
Using PDCA:
Starting with PDCA as an outline for your development process may seem a little cumbersome to many. However, the approach is actually very similar to The Lean Startup method that is seen as the latest and most current methodology for entrepreneurs. The Lean Startup is based on an approach that is called Build – Measure – Learn. At first glance, this looks like the cycle of PDCA without the planning. However, many have found that the Build – Measure – Learn struggled without a pre-planning stage, or in fact, started with Learn as the first step.
This is not a new phenomenon. I have 3 books that I have used for many years on Lean Product Development and one of them, Step-by-Step QFD taught me to use the PDCA process in design but start with the cycle of CAPD. Looking and Thinking corresponds to Checking and Acting.
Paraphrased from the book:
The CAPD cycle can be used to identify the first-level tasks needed in design. The critical process for planning the design is contained in the branches of the tree (see below). Within the CAPD cycle, there are several tasks that must be completed. Each elment of CAPD must have at least one task. For instance, the Plan portion should include defining technology and concept requirements.
The CAPD cycle is used to identify the critical tasks for each of the major tasks in the critical process. These first-level tasks in the CAPD cycle require at least one second-level task. For example, there are five tasks for the first major task in the critical process:
- C – Identify target market
- C – Identify customer needs and expectations
- A – Select performance measures
- P – Design technical benchmarking
- D – Evaluate competition
Depending upon the steps in the critical process, the critical tasks can be different. For more complex design processes, it may be necessary to use the CAPD cycle again to identify critical subtasks.
Responsibilities must be assigned to the appropriate organizational functions. A responsibility matrix is useful for summarizing these responsibilities. The functional group which has the primary responsibility for a task determines when to move on to the next step in the critical process. The functional group which has secondary responsibility provides support to the group shouldering the primary responsibility. Job position or task description identifies who is responsible for which tasks. According to the developed critical process, an organization may need to acquire new responsibilities and to divide these among the functional units.
A product design process chart (project charter) should also be utilized to clearly define the team and the process. During product development, the design team needs many documents, such as market analysis, customer requirements, and specifications. These documents arc normally regarded as reports within the design process. This process chart should provide the roadmap for managing your product. The more visual you make the process, the better. There is nothing wrong thinking of your process charter as a storyboard – something I encourage.
Go to the next page Design/Explore
Additional Comment:
Making incremental steps allow you to measure results very easily and actually build a repeatable process that can be used over and over again. Though, we all recognize that no product launch is the same, having a template for your company will allow you to make the minor changes necessary for each launch and build upon what works well over time. An e-myth article discusses incremental release plan.
Strategic Work: One Step At a Time by Susan Weber
Rolling out Product Innovations : Updating, enhancing or otherwise changing your products or services can be scary, but when done correctly, product innovation can truly revolutionize your business. The important thing to remember is that you needn’t tackle everything at once. Strategic product innovation work can be done incrementally.
For example, when I was working for a large financial services company here in the United States, I worked on a key strategic initiative: the implementation of a new bank. This was a huge project and very important to the company. So how did we approach it? We decided that implementation of this bank, including the hefty technology pieces, should be broken down into monthly releases. This turned a seemingly overwhelming and complex project into a manageable and far less daunting assignment. This approach also helped to mitigate risk, because it was easier to assess impacts (and recover if necessary) with smaller changes.
In the end, the bank was implemented on time and on budget. Although this approach requires more planning on the front-end, it greatly increases the chances of success. Plus, it’s much easier to measure and quantify the results of smaller changes.