This paper examines the intersection of the project management (PM) body of knowledge with new product development (NYPD). The area under examination is development of consumer products (e. G. Dishwashers) that have a significant engineering production content. It is concluded that the PM method, with its structured task definition and software tools, is generally useful for managing NYPD projects. However, in some areas PM incompletely meets the needs of NYPD.
Specifically, NYPD is characterized by complex interrelated activities and large uncertainties about precisely which solution path will be taken, such that the full scope of the project can often not be anticipated beforehand. The paper identifies that more research is required to validate the stage-gate and lean project management methods, and to clarify which areas in particular they benefit and how to reliably achieve those benefits. Whereas cost is the primary focus in PM (because conventional projects tend to only spend money), with NYPD there is a need to consider both cost and income (from product sales) in making strategic decisions.
Communication and human resource management are important factors in NYPD success, but existing project management perspectives have little to say about the social and behavioral aspects, such as organizational culture, team dynamics, and leaderships styles, especially not for NYPD. There is also likely to exist an intersection, as yet poorly understood, between PM and knowledge management, particularly for innovation processes such as NYPD. For practitioners the main message is that the PM method provides a basic, but imperfect, tool for managing NYPD.
Practicing managers might benefit from adopting new PM ideas as they appear, but need to do so with an pen mind. Several places are identified where further research is required to (a) better understand the causality between factors (e. G. Human resource management) and project success, and (b) adapt PM methods to better serve the NYPD process. Introduction provides future business opportunity for the organization. However NYPD involves technical, marketing, and financial risks. It therefore requires that senior executives make decisions under uncertainty, and this is helped by having adequate information before (and during) the NYPD project.
Thus effective project planning and intro are valuable for decision-making. Furthermore, at times the organization may have multiple NYPD candidates to consider. Since organizational resources are limited, it will have to select some candidates for further development, and abandon others. This is the problem of capital rationing. It is assisted by having estimates of life-cycle costs and risks, which again requires effective project planning. Definition of the problem scope Thus there is a need for project management (PM) methods that can handle NYPD.
The problem of course is that some forms of NYPD, especially those involving a high agree of innovation, are notoriously difficult to manage. Many NYPD projects use project management tools, at least elements thereof. However these are not always fully satisfactory, and the formal PM method in its entirety is not a complete solution for the management of all NYPD projects. Some ascribe this to lack of diligence: that the PM principles were not applied thoroughly, or the staff had a motivational reason not to do so (e. G. To avoid accountability).
It may also be that the uncertain outcomes of NYPD defeat even the most diligent project management. Conventional project management requires elatedly complete initial definition of outcomes and scope, which can be problematic for NYPD: the uncertain outcomes cause the scope of work to be dynamic. This is especially the case when research is involved. Other ways in which NYPD differs from other forms of project management, e. G. The construction industry, are the ongoing effort (long life cycle, product families, ongoing team working relationships), and complex work (conditional on other tasks, parallel activities).
Description of process and results The area under examination is development of consumer products (e. G. Domestic appliances) that have a significant engineering production content. Representative case study data are used in the analysis, simulating the issues that are faced by a typical organization that designs, manufactures and sells dishwashers. Case study component A project was developed for the life cycle of a dishwasher (taking the producers perspective rather than the customers).
Producing a project of this magnitude is a challenging task, because of the extended durations and the large uncertainties. There are several phases to the project, including design, testing, production, market Roth, and provision for eventual withdrawal of the product. This list formed the basis of the high-level work breakdown structure (WEBS). This was compiled from several AND projects, and is representative rather than comprehensive. Thus no individuals, and indeed such detail would vary considerably depending on the type of NYPD undertaken.
We have taken a 10 year frame from 2005 to 2015. By comparison the Project Management Institute (PM) approach to project development also offers a high-level work breakdown, in the form of five stages: initiating, planning, executing, monitoring & control, closing. However, these stages are too general for the NYPD case under examination, hence the development of a custom list of activities was required. These activities are broadly based on the extant models of the engineering design process, such as the linear (or systematic) model .
III these models are broad representations of the design process, and seek to descriptively capture the complex interconnected activities that occur in design. The models are also mostly graphical, and therefore the challenge is to translate them into a form, I. E. A WEBS, that can be recognized by the project management method. The model shown is therefore proposed translation of those design theories into a project plan, informed by experience and observation of actual practice. Like any WEBS, it is likely that there are many different but equally valid representations, I. . Alternative WEBS, but this one is sufficient for the present purposes. The high-level activities provided are necessarily a simplification, and many activities are tacitly included but only become explicitly evident in lower levels of detail which are not included here. Thus the conceptual design stages involve marketing (as do he later stages of the life cycle) but is not detailed here. Likewise several possible strategies for treating the risk of market decline are provided but not elaborated here. These activities were modeled with MS Projects software.
Other representative information, such as resources, was included, and finally several reports were produced. Sample progress and performance measures were also determined. MS Project was selected as the software tool since it is one of the most common and accessible to practitioners. MAMBO component The case study was then analyses with the Project Management Institute (UP) Body f Knowledge (MAMBO). This document describes all the activities that a professional project manager might have to consider for a general project.
The MAMBO identifies nine knowledge areas where management is necessary: Project Integration, Scope, Time, Cost, Quality, Human Resource, Communications, Risk, and Procurement. Thus the analysis was structured into these nine facets. The MAMBO is not the only way of structuring the PM knowledge and process, but it is one of the more common approaches, hence its inclusion. AAA Idea generation Identify customer needs Evaluate quality of existing products Define objectives of new product (e. G. National, aesthetic, quality, cost) AAA Concept design Creative idea generation Refine concepts AAA Feasibility study Retrieve past design intent Check strategic feasibility (e. G. SOOT) Check market Check technology capability Check financial feasibility Check schedule feasibility Check for resources available Make decision to proceed (or not) AAA Detailed design Set the specifications Design key characteristics Produce drawings Produce prototype AAA Test product Test product for user satisfaction Test key characteristics (e. G. Gingering) AAA Finalize design Bal Set up production 82 Arrange marketing 83 Arrange distribution Board approval Revise design Freeze the design Procure manufacturing capability Design the tooling Build the tools Modify building Obtain equipment Obtain manufacturing staff capability Start up production Get first parts from production Test parts Verify quality tolerances Produce in volume Identify key benefits of product Identify potential users Plan marketing strategy Produce brochures, adverts Produce ‘Rainforest’s’ campaign Establish sales chain Find local representatives
Establish business procedures for ordering, shipping, accounting, repair Set up technical support capability Write user manual Write service manual Decide on warranty conditions Obtain staff capability CLC Market growth CO Market maturation CO Market decline Ca Declining sales CB Refresh product ICC Launch derivative product CD Differentiate service Ice Launch new product CO Product withdrawal Decision to withdraw Produce lifetime spares requirement Decommission production Archive documentation Project closure High-level work breakdown structure for a representative NYPD project, for dishwasher development.
Project Integration Management is simply the overall project management task that keeps the whole project together. This activity occurs throughout the project and includes planning, control and closure. Research has shown that the intensity of project management efforts in NYPD varies with the development stages, being low during the conceptual stages and higher during development. In many organizations product development occurs on multiple different projects simultaneously, and since development resources are typically limited, it may be necessary for the project manager to coordinate resources between ultimate projects.
Recent developments in project management software have actively pursued this functionality, by permitting multiple projects to be integrated using one resource pool. Further, those resources, at least the people component, may be extracted from organizational email address books, and the task allocation and monitoring also done via email. Even so, the management of multiple projects is problematic for the project management methodology. Scope Management Scope management is about defining the scope and creating the work breakdown structure (WEBS) down to the level of work packages.
Many product development projects aim for a particular window of opportunity in the market, especially if the product life cycle is fast. Consequently, robust estimates of duration are valuable. However, this is particularly difficult to achieve when the product is innovative and experience is lacking. Existing methods such as project evaluation and review technique (PERT) and critical path method (CPM) provide some accommodate the uncertainty in project formulation. A popular approach to managing the uncertainty inherent in product development is to have a check point or decision gate at the end of major stages.
This approach fits well with conventional project management methods, such as the Giant chart, in which the gates may be represented as milestones. The stage-gate methodology applies concurrent engineering, and sets mandatory activities for various stages. These stages might include preliminary investigation, business case, develop, test, and launch. There will be one or more decision gates at the end of each stage. It is a prescriptive approach that produces a road-map for the project. However, not everyone believes that the stage-gate approach is necessarily the best for NYPD, because it tends to be risk-averse.
Furthermore, there is surprisingly little literature about the actual effectiveness of the stage-gate approach, and most of the claimed benefits are conjectural rather than substantiated. However, these theories along with stage-gate are built on the implicit premise that design is deterministic: that it proceeds in known stages towards predictable outcomes under rational decision-making. This can sometimes be problematic when it does not capture the full complexity of design, especially innovative design.
The decisions surrounding design, both management and technical, are dynamic, complex and risky. The complexity arises because the causality between work and successful outcomes is uncertain. Circumstances change and this is difficult for project management. Thus there may be rework activities, multiple partial solutions, dead-ends, changed scope, and different stakeholder views of what constitutes success. Decision-making is seldom a fully rational process Thus the universality of the stage-gate method is doubtful.
Product development projects often have complex interrelated activities Project management, and indeed several of the engineering design theories, require that the robber be decomposed into smaller sub problems (activities and functions respectively). The PM and design mechanisms then seek to find solutions to these sub-problems. For this to be successful it is necessary that the sub-problems are sufficiently independent of each other that solving one does not disturb another. In practice the sub problems are seldom completely independent and this is termed distributed design or ill-structured design.
In these problems the solution decision for one part of the problem affects that for another part. Distributed design problems may be intractable with the above approaches, or compromised in terms of efficiency. To force independence on a problem when it does not really exist, for the purposes of fitting into a management tool, is to make sweeping simplifications that manifest as divergence from the tool. This may be one reason why PM methods have sometimes struggled with highly innovative projects, e. G. Research, and why rule- breaking may be necessary.
Furthermore, design projects may large uncertainties about precisely which solution path will be taken. The full scope of the project can often not be anticipated beforehand, especially with novel projects. This imposes challenges on project management, which tends to prescribe complete scope definition because it materially affects the work breakdown structure. With product development projects stable or risk poor team motivation. Against this must be balanced the need for managers to avoid unrealistic expectations as to the certainty of the process, e. G. E accommodating of changes to the work breakdown structure as the project unfolds. Time Management Time management covers the definition of detailed activities, estimating their duration, and linking (sequencing) them together. It also includes allocation of sources and a number of other matters. The biggest problem with estimating time (and cost) is the intrusion of bias. Bias refers to a person’s inability to see something impartially. Projects may be affected by bias in various ways. At the activity level this might be someone underestimating (or overestimating) the time required to complete the activity.
Many people are usually involved in providing the information that goes into a project plan. Therefore the project manager has to be vigilant about bias, not only self-bias, but also that of others. Different types of bias are: representatives (stereotyping) availability (vividness of experience) over/under confidence motivational (comply with group expectations, management requirements, personal ambitions) anchoring (can conceive the possible range) During the control phase of NYPD it is necessary to monitor the degree to which the work is completed and according to schedule.
Unfortunately, there is no reliable way of determining percent-complete. The conservative approach is to set it as either 0% or 100%, but this is unhelpful when the tasks have durations longer that the minimum financial period (causes large inaccuracies in cash flow analysis). It only works when the WEBS can be extended down into such small tasks that no accuracy is lost by following the 0% or 100% approach. In other cases it will be necessary to estimate a value from the range 0% to 100%, which may rely on the worker=s own perceptions of completeness of tasks (and any associated biases).
There does not appear to be any research on the accuracy of self-reported percent-complete, and this might be a useful future area of investigation. By comparison there is a substantial body of literature on human error cognition, in which there may be some common concepts. Cost management covers the estimate of costs, production of a baseline, and then the cost control activities that arise when the project is under way. Deterministic project paths are typically assumed, although this may result in inaccurate cost estimates.
The strategy taken towards cost management on NYPD may be important, since research suggests that a focus on target costing may be inappropriate when the product is differentiated not on cost but on technology, time-to-market, or customer satisfaction. Thus a single-minded cost focus may distract designers away from creating other value in the product. Primary cost categories are fixed, labor, and consumables. Fixed costs are relatively straight-forward since they represent the work that is subcontracted, or plant and equipment.
However the labor costs in NYPD can be ambiguous since some organizational facilities, perhaps specialist engineering designers, may be shared organizational overhead. In the case under examination such costs were nonetheless included, since the objective was to provide information about the total project cost and to potentially compare that to other candidate NYPD projects. Even so the project Lana only includes the time that staff are budgeted to work on the project: their slack time is not coated to the project although in reality it may be.
There is a work-around, which is to assign the staff to a single task that runs the full duration of their expected involvement. However, while this would fix the cost ambiguity, it would make it more difficult to determine workload, and for this reason it is not a particularly viable option. We conclude that the costing of slack time could be better handled by the software (MS Project in this case). From the project management perspective the NYPD case under examination has the unusual characteristic of involving both expenses and income.
Conventional projects tend to only spend money, and thus cost is the primary focus in the MAMBO, and also in the MS Project software. In the present case there was also income because the project included the entire life cycle. It is unfortunate that the sign conventions for project management and accounting are in conflict because this increases the risk of confusion and error when integrating project management into life cycle considerations. The overall cash flow implications for the sample project were determined by data processing of the cash flow report using a spreadsheet.
