Improving Time-to-Market through Planning and Resource Management


Rapid time-to-market is important for the competitive success of many companies for the following reasons.

  • Competitive advantage of getting to market sooner;
  • Premium prices early in life cycle;
  • Faster breakeven on development investment and lower financial risk;
  • Longer market life cycle; and
  • Greater overall profits and higher return on investment.

The key process requirements for rapid time-to-market are:

  • Clear understanding of customer needs at the start of the project and stability in product requirements or specifications;
  • A characterized, optimized product development process;
  • A realistic project plan based on this process;
  • Availability of needed resources to support the project and use of full-time, dedicated personnel;
  • Early involvement and rapid staffing build-up to support the parallel design of product and process;
  • Virtual product development including digital assembly modeling and early analysis and simulation to minimize time consuming physical mock-ups and testing; and
  • Design re-use and standardization to minimize the design content of a project.

Recent studies as well as our own experience have identified that in many companies, development projects are often started at the beginning of a fiscal year or based on Marketing needs without regard to priorities or resources. Further, there is often little or no project planning and little or no consideration of risks or project uncertainty. This has resulted in development personnel being over committed on average by 75%. Further, over 75% of development project cost and schedule estimates are inaccurate by 10% or more. Finally, less than 25% of companies have adequate resources to undertake all their planned development projects.

Benchmarking best practices has enabled us to identify a number of key issues related to project and resource planning and management that have a major affect on rapid time-to-market. These best practices and an approach to benchmarking and assessing an organization’s product development process in order to develop an action plan for improvement will be covered in the balance of this paper.


There are two types of product development environments. The first is a company that undertakes a relatively small number of major projects involving complex products. In this type of environment, product planning involves the consideration of each product development project, to a large extent, independently of other development projects. The decision to go ahead with the project implies that it is the highest priority program for investment by the company and that whatever resources are required, will be obtained to support the development effort.

The second situation involves companies with small- or moderate-sized development projects (e.g., less than 50 people). In many of these organizations, development budgets and headcounts are planned on a fiscal year basis at a nominal and relatively constant level. There are often a number of product lines and many competing needs for development projects. In this situation, a product plan is critical to:

  • Define an overall strategy for products to guide selection of development projects;
  • Define customers, markets and competitive strengths;
  • Rationalize these competing development projects and establish priorities for development projects;
  • Estimate development resources;
  • Provide a high-level schedule of various development projects; and
  • Balance project resource requirements with a budget in the overall business plan.

In the simplest terms, the product plan can be viewed as the equivalent of the production plan used to used to guide manufacturing activities. While a product plan is generally prepared on an annual basis, it should be reviewed and updated at least quarterly, if not monthly. Market conditions will change, new product opportunities will be identified, new product technology will emerge, all causing a potential impact on the product plan. These opportunities need to be evaluated and the product plan changed if needed. This changes may result in re-prioritizing development projects or making a decision to hire additional development personnel to undertake a new development opportunity.


The product plan embodies an overall strategy and the critical success factors of the business. As a general rule, lean product development practices (LPD) suggest concentrating resources at any one point in time on fewer projects in order to get those projects done as quickly as possible. As these projects are more rapidly finished, resources are assigned to the next highest priority project.

A second strategy issue involves the level of development resources. If the company’s objective is time-to-market, this would imply that development activities are a high priority and that the organization must maintain a sufficient level of resources to support requirements, even though the resources may not be highly utilized at all times. The benefits of time-to-market in this case can outweigh the cost impact of having a higher level of development resources. If the organization’s objectives are to develop a low cost product (where the per unit development cost is a relatively large portion of product cost) or to develop a product within a tight development budget, this would imply that development resources be staffed at a minimum level to insure high utilization and little downtime, even if it delays performing a development activity.


As an organization establishes a more mature product development process, one of the steps in this evolution will be to fully characterize and understand the process. This would include defining and understanding the process steps including the inputs (information & resources) and outputs. Of course, this process should be as standardized as possible. Defining the development process is important in order to have a basis for planning a development project.

With a standard development process, it becomes possible to establish a standard project plan template (including resource estimates, task precedence, and task duration) which further eases the effort in developing a project plan. Even with a standard process, it is appropriate to tailor the process to the unique requirements of the development project. For example, a product upgrade is a less complex project than developing an entirely new product for a new market. Therefore, this standard planning template will need to be tailored to address these unique project requirements.


Who develops the project plan? Often, this was done by a program manager or a product line manager and then given to the team. This approach resulted in the team members not developing a good understanding of the plan, not clearly understanding the critical path and task interactions, and not being fully committed to the plan.

Empowering development personnel to create a project plan enhances their understanding of the plan and increases their commitment to the plan. When all disciplines are involved in the project early and included in the planning process, a sounder, more comprehensive, better integrated plan results. The plan should be reviewed in a team meeting so that each product development team member clearly understands his or her responsibilities. Since project conditions change and performance doesn’t always go according to plan, the plan needs to be periodically maintained and revisions reviewed with team members.


There are several key staffing strategies to facilitate rapid time-to-market. These include:

  • Plan based on early involvement of functional disciplines to support the parallel design of the product and the process.
  • Use full-time, dedicated personnel where possible. Part-time personnel and task-switching affect productivity and slow down development activities.
  • Support rapid staffing build-up to insure the project gets off to a good start.
  • Consider delaying the start of the project if needed personnel and resources are not available.
  • Maintain the core integrated product team into production to resolve transition problems until stable production is achieved. This provides resources to quickly solve problems and it provides direct feedback to development personnel on lessons learned.


The timely development of a new product requires that all required personnel resources to support the development effort are available when needed. This requires planning resource requirements by developing a realistic development plan which includes a time-phased schedule of manpower requirements (by discipline and position/skill level). Other indirect activities need to be included in the resource planning to properly project all requirements. The earlier this resource planning occurs prior to the start of a development project, the greater the flexibility to respond to resource constraints.

Since development projects can be affected by unanticipated issues and tasks that take longer than planned, this resource plan needs to be maintained on a regular basis. While an earned value system will recognize potential task overruns, most commercial organizations with small and moderate-size projects do not have earned value systems in place and rely on feedback from product development teams to adjust project resource requirements.

The resource plan is the basis for obtaining personnel commitments to support the product development effort and extending or changing personnel commitments. It is a basis, along with other departmental requirements, to plan overall manpower requirements (see resource planning example)

With a product development team’s need for resources from different departments, it is likely that resources from one or more departments will be constrained and unable to respond to the project’s requirements in a timely way. While resource planning should provide some higher level visibility to take action to alleviate significant resource constraints (bottlenecks), it is difficult for an organization to always balance its resource requirements with its available personnel in the short term.

There are a number of actions that can mitigate these resource conflicts in an integrated product development environment. One action to alleviate these likely resource constraints is to maximize the flexibility of development personnel so that they can perform tasks that are not normally their responsibility. As people become broader generalists through exposure to other disciplines on teams, through training, and through team member collaboration, a balancing of work loads will occur naturally. When a “can-do” environment is created, people understand the importance of stepping in to perform tasks normally outside their responsibility. By allowing engineers and designers to operate equipment in a lab, this avoids having to wait for a lab technician who is backlogged with work. When flexible, easy-to-use design and analytic tools (e.g., FEA) are provided, this may mitigate the need for an analyst or specialist who may not be available. It is important to emphasize training and personnel development to create this type of broadly skilled workforce.

However, when the development projects planned or underway create a significant overload on development resources, all projects are stretched out, affecting time to market. Further, individual development personnel make decisions on project priorities which are not necessarily in line with enterprise priorities. Finally, this overload causes development personnel to take shortcuts, undermining the desired process. When this overload situation is indicated, the organization must take one of two actions: add resources, whether permanent hires, contract labor, or subcontracting; or change the resource requirements by deferring project starts.


Another common issue is consideration of project risks in project planning. Human nature being what it is, most projects are planned assuming everything will happen as intended. Except for large projects with sophisticated program management processes, most companies do no adequately consider or address project risks. As a result, projects are often unprepared for risks that arise, delaying development, increasing costs, and impacting customer satisfaction.

Development processes needs to include process steps to identify, track, and manage risks. This is a product development team’s responsibility. As the team is involved in planning the project and includes the needed functional disciplines to support an IPD approach, it will be in a better position to assess and monitor these risks. In addition to identifying these risks, the team needs to take steps to mitigate these risks. This is an area that management may be needed to support the teams efforts. When risk tracking and risk reduction are subjects of phase gate and design reviews, it will force the team to pay attention to these factors. This risk management process need not be cumbersome nor complicated (see risk managment).

From a project planning and resource management perspective, it is important to recognize that higher risk projects increase volatility of planning and the potential need for additional resources and additional schedule. This should be factored into the project plan and a risk reserve provided in the form of budget and the resources to address risk issues.


Another factor affecting the project plan, the resource requirements and time-to-market is the ability to manage customer requirements and the product specification. It is important to establish a complete set of requirements at the start of the project and avoid proceeding into development before requirements are completely defined. Further, requirements need to be tightly managed to avoid creeping elegance and its impact on time-to-market. While rapidly evolving market needs may cause consideration of changes to requirements after the project is underway, these changes need to be carefully evaluated with a formal process to fully assess the impact on the development project’s cost and the impact on time-to-market before a change is made.


In its effort to improve time-to-market, there are many potential steps for a company to consider. Where should it start? What are the most important actions for a company to take to improve its development process? What best practices should be adopted? To answer these questions, a company should start by assessing its strengths and weaknesses. Next it needs to consider its critical success factors – what is important to be successful in its market. Then by focusing on the “gap” between where a company is and where it needs to be, priorities can be set for making improvements.

The Product Development Assessment methodology and the supporting Product Development Best Practices and Assessment (PDBPA) software developed by DRM Associates provides a thorough review of the development process based on approximately 250 best practices that have been identified from studying companies’ product development activities around the world. This level of detail allows identification of specific strategy, organizational, process, methodology and technology issues to address as part of an improvement program. These best practices are organized into categories for summarization and reporting purposes.

Associated with each of these best practices is a set of questions to aid in this assessment process. A company’s product development activities are evaluated with respect to each of these best practices, and a quantitative rating is developed. This evaluation is supported by a verbal description of the characteristics of the organization’s product development approach as it evolves toward a world class approach to IPD.

In addition to the performance rating against each best practice and for each higher level category, an overall performance rating is developed by again assigning a weighting factor to each category based on their importance given the nature of the business and the product. This performance rating, when compared to that of other companies, gives an indication of the urgency of improving the development process.

Gap analysis is then employed to focus attention on the improvement opportunities that will yield the highest payoff. The categories with high weighting factors (indicating their importance to your product development success) and relatively low performance ratings yield the largest gaps between what is important to the organization and what it does well. These are the areas that require the highest priority in improving the development process and will likely have the largest payoff. On the other hand, categories with low importance ratings and relatively high performance ratings indicate low priority areas not deserving as much attention.

This gap analysis becomes the basis for identifying implementation actions and priorities. The concept is to pick a manageable number of improvement initiatives to focus your attention on. Once the large gap categories are identified, an examination of the individual best practices with lower performance ratings will help identify the specific areas that require attention. This then becomes the basis for developing priorities and, eventually, an improvement or implementation plan.


While formal project and resource planning and management processes may be in place for larger product development projects, many companies do not adequately use these tools and suffer the consequences. Even when formal project and resource planning and management systems are in place, management often avoids the hard decisions regarding overloaded resources. Significant opportunities exist to reduce time-to-market by a better focus on product planning, project planning and resource management. Specific steps and strategies include:

  • Align project requirements with budgets and establish priorities in a product plan
  • Focus on fewer projects at any point and concentrate resources on these projects
  • Realistically plan projects based on the tailored development process
  • Involve team members in project planning to enhance their understanding & commitment
  • Assign people full-time to the project and build-up staffing rapidly
  • Plan and manage resources; don’t overload personnel
  • Address risks and recognize the potential need for additional resources

Product Development Forum Home Page