Part 2 covered the management of the five functions: scope, organization, quality, cost, and time, and the risk inherent in them. We now turn to the second dimension of project management, the management process. In Chap. 1, I suggested that because projects are transient, they have a life cycle, going through several stages of development from germination of the idea, to commissioning of the facility, and finally, the metamorphosis into a successful operation. During this life cycle, management emphasise changes; the definition of the project evolves in a controlled way, so the best solution to the owner's requirement is achieved, and money and resources are committed only as uncertainty is reduced. In this part, I consider the management of the project life cycle. In Chaps. 12, 13, and 14, I describe what is done at each of three stages of a simple form of the life cycle: project start-up, execution and control, and closeout.
In this chapter, I start by revisiting the project life cycle and setting it within the context of the product life cycle. I show that projects may run over several stages of the product life cycle, or some projects may be undertaken to deliver individual stages. I then describe two specific stages of the life cycle: feasibility and design, not covered by the Chaps. 12, 13, and 14 of this part. I then consider versions of the life cycle for different types of project, new product development, concurrent engineering, and information systems projects.
11.1 THE PROJECT AND PRODUCT LIFE CYCLE
There is a hierarchy of life cycles, or management processes consisting of:
The product life cycle
The project life cycle
The management processes
In Chap. 1, I introduced two versions of the management process:
1. The one I derived from the work of Henri Fayol:1 plan, organize, implement, and control.
2. The other from the process recommended by Project Management Institute (PMI) in their PMBoK:2 initiate, plan, organize, execute, control, and close.
In Chap. 1, I also introduced a generic version of the project life cycle: concept, feasibility, design, execute, and close, which has formed the basis for much of the discussion of this book. In this chapter, I give several other versions of the project life cycle. I also suggested in Chap. 1 that on small projects, especially ones that are part of a program
FIGURE 11.1 Wearne's life cycle for industrial projects.
(Chap. 16), there is very little difference between the management process and project life cycle, but on larger projects the two are quite distinct with the management getting repeated at each stage of the life cycle (Fig. 1.8).
In Chaps. 12, 13, and 14, I describe three stages of the life cycle: start-up, execution, and closeout. In reality, the first two relate more to the management process, and the third more to the last stage of the life cycle. In the next two sections, I describe the two stages of the life cycle not covered by these: feasibility and design. (Concept is covered by Chaps. 2 and 12.)
Several versions of the project life cycle set the project within the life cycle of the product made by the facility or asset the project delivers. Stephen Wearne3 proposed a model (Fig. 11.1), which is essentially a life cycle of the new asset, and is reminiscent of the problem-solving cycle (Fig. 1.6). It starts with a survey of demand for the product produced by the facility. That part of the cycle on or within the circumference describes the life of the facility. The six steps from study to commissioning relate to the three steps of the project life cycle used in the Chaps. 12, 13, and 14. The next three steps extend the life beyond the project to the use of the facility, its maintenance, and monitoring of its performance. The World Bank has a version of the life cycle that is very similar (Table 11.1), as does the European Construction Institute (ECI) (Table 11.2). The World Bank is concerned about the pre- and postproject stages, ensuring the investment decision is sound and the project delivers the benefit postproject. They are not so concerned with the actual construction of the facility which is the responsibility of others. Therefore their version of the life cycle does not detail the actual implementation stages. The ECI's life cycle on the other hand details the pre- and postproject stages, but also details implementation, and is very close to Stephen Wearne's.
Harold Kerzner4 proposes a model addressing the life cycle of the product produced by the new asset. It is the classic marketing view,5 (Fig. 11.2). This is the view of projects filling the planning gap (Fig. 2.1) and draws very little distinction between the project and
TABLE 11.1 Project Life Cycle Used by the World Bank
|
Stage |
|
Identification of project concepts Preparation of data Appraisal of data and selection of project solution Negotiation and mobilisation of project organization Implementation including detail design and construction Operation Postproject review |
|
TABLE 11.2 Life Cycle Proposed by the European Construction Institute
|
Stage |
|
Concept Feasibility Front-end design Project plan Specification Tender and evaluation Manufacturing Construction Commission Operation and maintenance Decommission Disposal |
|
FIGURE 11.2 Classical marketing view of the life cycle of the product.
the product. Some people differentiate between the project and the product life cycles saying the project is the period up to and including commercialization and the product life is the period from introduction of the product until its decline (Fig. 11.2). The project period can last anything from three months in the electronics industry, to ten years in the pharmaceutical industry, to a hundred years for the major infrastructure projects.
There are several implications in Figs. 11.1 and 11.2 which need qualifying:
a. First is an assumption that the facility is an engineering plant that will make a product or perhaps provide a service through its operation, as with an airport for instance. In this book, I have taken a wider view of projects and the facilities delivered. Like an engineering plant, the facility may be a computer system, a design, trained managers, or a set of procedures. With this view, projects can occur at any step in the product life cycle. There are projects to conduct a marketing survey, research and development, and maintenance. From the marketing model, there are projects to launch the new product (Sec. 11.4) and to relaunch the product at deterioration (Fig. 11.3). Projects therefore occur throughout the product life cycle or at any stage in the strategic development of organizations (Sec. 2.5). I describe several of these projects in the following sections.
b. Coupled with this is an assumption that the project is a large engineering endeavour. The project may be a small project taking place as part of a program or portfolio of projects. I discuss program and portfolio management further in Chap. 16. Many change initiatives actually take place as a program comprising several projects, and indeed the life cycles in Figs. 11.1 and 11.2, can be viewed as showing a program of projects (Chap. 16).
c. Finally is the implication that we are talking about the private sector. The Office of Government Commerce (OGC) in the UK has proposed a life cycle for large projects in the public sector, as part of their gateway review process. This shows the project nested within a program, which itself is nested within the formation and implementation of government policy. Again the life cycle tends to focus on the pre- and postproject stages. The assumption with large projects is that the work will be done by external contractors, and so the life cycle does not focus so much on the implementation stage, unlike PRINCE2. OGC's gateway review process has been adopted by the Department of Homeland Security in the United States for the monitoring of information systems projects, and by the federal government in Australia.
FIGURE 11.3 Life-cycle for government policy.
After the initial concept stage, it is necessary to develop the definition further, and refine estimates to the level of the second row in Table 8.4, to be able to commit resources to design. This is done through a feasibility study. At the concept stage, several solutions may have been proposed. We now assess their technical, commercial, and managerial feasibility, and choose one to take forward to design (assuming at least one is feasible).
Aims of the Feasibility Study
Feasibility studies involve time and money, so it is essential they are well managed, and for this it is important to understand the aims of the study.
Exploring All Possible Options for Implementing the Project. As many ideas as possible should be explored. Each option must be thoroughly reviewed to see whether it can be improved within the limitations of market and technical conditions. The original specification can act as a guide to the study, but it should not stifle imagination and creativity.
Achieving a Clear Understanding of the Issues Involved. The feasibility study must give a clear understanding of the issues. In particular, associated with each option still being considered should be: estimates of costs and revenues; an understanding of the views and objectives of the various sponsors and institutions involved; confirmation of both technical and financial viability; and estimates of the likely economic and financial returns, as described above.
Producing Enough Information to be Able to Rank the Options. The study should produce enough information to rank options. The criteria used are based on the strategic factors described above. Their weighting in the overall ranking of options depends on the sponsor's goals; the public sector will usually give more weight to social and environmental factors than the private sector.
Obtaining a Clear Picture of the Way Forward. The study should result in a clear idea of future stages. It helps to think of the feasibility study as a funnelling and filtering exercise, directing a wide range of possible ideas into a much narrower range of options, with those which clearly fail to meet objectives sifted out. The study should aim to provide a refined specification and a work plan for the next stage, design. It may also result in a draft plan for the design or execution stages (Example 11.1).
Example 11.1 Producing a clear definition of the way forward
I worked on a three-month feasibility study to assess the efficacy of a new process. We launched the study with a two-week workshop. At the end of the workshop, we had a clear objective for the feasibility study but we had produced no plan, not even at the strategic level. Nor did we produce a plan in the yearlong systems design stage which followed. The first plan produced was at the end that year, for the detailed design of the plant.
The Factors Addressed
The study must provide an understanding of factors influencing success, and assess the advantages and disadvantages of each option to enable them to be ranked. These include
Market Conditions. Expectation of returns depends on satisfying demand for the project's product at a certain price level. Usually neither future demand nor future prices can be predicted accurately. If there is a limited portfolio of potential buyers, or the market is volatile, or demand is price-sensitive, as with commodity products, the project is vulnerable to many adverse influences. However, the existing market environment provides a wealth of information on which to base sales forecasts, establish price structures, understand potential purchasers and consumers, evaluate expected trends in demand and the actions of potential competitors, and learn about the expected quality of the product or service.
Supply Considerations. Existing supply conditions are also important sources of information. The feasibility study should assess the cost, quality, and availability of capital equipment, raw materials, and labour. Different technical options should also be explored and specialist technical advice obtained on their feasibility.
Financial Prospects. The profitability of the project can be analyzed by applying evaluation techniques (Sec. 2.4).6 The financial feasibility also depends on whether the expected return from a project is sufficient to finance debt and provide shareholders with an adequate return to compensate for their risk. Financial feasibility is influenced by economic conditions such as interest and exchange rates prevailing when costs are incurred and income received. The approach differs for projects in the private or public sector. The latter often takes account of nonmonetary benefits and costs, and factors such as environmental impact. Shadow prices are used where the market price is considered not to reflect the economic cost or benefit of a project input or output. The private sector usually places more weight on purely monetary return, although legislation, tax benefits or subsidy, and public relations considerations may encourage it to place value on nonmonetary factors. Adequate consideration must be given to risk and uncertainty (Chap. 10). Risk and uncertainty cannot be eliminated, but they can be managed and reduced by prudent project design and management. You should also remember that the shareholders' evaluation of the project, and hence the share price of the company, depends on their assessment of the risk.
Planning the Study
Appoint an Experienced Manager and Core Team. Their makeup depends on the nature of the project. For the feasibility study, it should include technical, financial, and marketing expertise, and for larger projects may also have economists, legal, and environmental experts, human resources experts, and so on. It is essential that a good balance is struck between specialists, as assessment of the options may be biased if one specialism dominates. For example, if technical experts dominate, they may emphasise technically exciting options, which may not provide the required financial return. It is often helpful to limit the size of the core management team. Compact teams are easier to organize and coordinate than larger groups. The manager of the study will usually not be the project manager for subsequent stages. However, it is usually a good idea for the latter to be a member of the management team for the study, as they will then have greater ownership and commitment to the results of the study, the decisions made and the strategy set.
Scope the Study. Examine the scope of the study to assess the work involved and any constraints imposed. The manager must determine exactly what the decision-makers require to guide them in their choice of the project options, and in what form the information is needed. A work plan with the delivery time and content of interim and final reports should as far as possible be agreed in advance with decision-makers. Remember, project management is fractal management; the study needs planning as much as the implementation of the project.
Plan the Study. Draw up a plan for the study, including a milestone plan and responsibility chart. The milestone plan should identify key stages for the study: interim and final reports, meetings, data collection, and so on. The plan can highlight different lines of enquiry involved and their interdependence, enabling the different aspects of the study to be coordinated. It should be robust, but sufficiently flexible to cope with any unexpected changes. Adequate allowance should be made for the time required to request and collect data as well as processing and interpreting results.
Schedule the Study. Set the timetable and budget for the study. These must be sufficient to enable options to be properly explored and refined, without endangering the feasibility of the whole project. It is important to budget for an adequate exploration of the options without going to the depth of investigation required for the design and appraisal stage.
Managing the Study
Once feasibility study has been planned, we follow the remainder of the management process.
Organization. This involves the adoption of a clearly focused but flexible structure based around the milestone plan. The team should be aware of what is expected, and by when. They should understand how they fit into the study framework, and to whom they should report. Hence, roles and responsibilities must be clearly defined. The responsibility chart is the tool which effectively achieves this.
Implementation. This requires efficient communication within the team. The manager should maintain frequent contact with sponsors to ensure the study remains on target, and any change in requirements is identified. The team should maintain good internal communications to ensure delays are reported, to minimise knock-on effects, to avoid duplication, and to confirm that all information received has been made available to all members of the team. It is particularly important that good communication is maintained between team members in different fields of expertise to ensure any interdependencies are taken into account.
Control. This is the responsibility of the manager who must ensure that milestones are being reached on time, and that the milestones adopted lead to punctual report delivery. Likewise, costs should be monitored to ensure the study remains within budget. Control involves both monitoring of timing and budgets, and rapid and effective corrective action when targets are not met, either by revising targets, or by restructuring present plans within the existing targets.
Completing the Study and Transition to the Next Stage
The feasibility study acts as a spring board for design. The end product should comprise a clear, concise report, the project definition report (Sec. 12.3), which presents the original specification and objectives, with the conclusions and recommendations for use in the next stage. The report should highlight advantages and disadvantages: cost, revenue, strategic considerations, economic benefits, and so on for each of the options which deserve further consideration and the proposed solutions to issues confronting the project. Furthermore, the report should indicate sensitivities to variations from the assumed base case.
The next stage of the life cycle is design. The primary emphasis of this stage is the development of the project model. The original outline requirements as expressed by the client in the feasibility study are subjected to more rigorous examination to define exactly what is to be done to achieve the project's objectives. A systems design is developed for the new asset, the product it will produce, and the method of building it. This helps define the work (Chap. 5). The project organization is developed, and roles and responsibilities of departments, functions, disciplines, or their managers are described (Chap. 6). The quality specification, cost, time-scale, and risk are all planned and estimated (Chaps. 7, 8, 9, and 10). From this information we determine whether or not the project is viable and represents a good investment at the accuracy of the third line ("Control") in Table 8.4. This appraisal process is vital, as it is the last chance the sponsor has to decide whether to proceed with the project before committing scarce resources to execution. Many of the issues investigated in design are the same as feasibility, but at a greater level of detail.
The design is developed at several levels of the project and stages of the life cycle, Table 11.3 corresponds to different levels of accuracy listed in Table 8.4. It is common to show the life cycle as a serial process, beginning with concept and continuing through feasibility design and execution, until the facility is commissioned and producing the desired output. However, the reality of many projects is different. Design in particular is an iterative process, proceeding through these levels, as our understanding is refined. At each level, the design is checked back to the assumptions set in the project's strategy. Even at one level, there may be several iterations as the design proceeds through several formats. In shipbuilding, the paper design is converted into a plastic model, then into a wooden model from which fabrication jigs are made, before the first vessel of class is made. The ship is thus made four times before it is completed: in paper, plastic, and wood; before being made in metal. The design process is therefore not a single activity, but a set of activities ranging from the outline requirements to the detail design, and these cover all the stages of the life cycle. The computer industry has developed a spiral model of the life cycle (Sec. 11.6), which reflects the reality of the design process, and perhaps has applications elsewhere.
Managing the Design Process
Design involves the production of information to enable a solution to be selected from a series of options and to allow one to be manufactured or constructed. The target for a
TABLE 11.3 Life Cycle of the Design Process
| ||
Design stage | Design name | Activities |
| ||
Definition | Customer requirement | Appointment and problem definition |
Feasibility | Functional design | Evolution of alternative solutions |
Detailed design | Detail design | Detailed design of selected solution |
| ||
good design manager is to produce the right amount of information, using the right people, at the right time, to budget, and to the client's satisfaction, while making a profit for their employer. This balance is not easy to achieve. Engineers are notorious for trying to satisfy the client's requirements, while forgetting the need of their own company to make a profit! The application of good project management procedures to the design process can help to ensure the balance is achieved. It can make the process more flexible, allowing the design to proceed efficiently within a framework of gentle control, in which all designers know what they are doing, why, when it is needed, and what to do if the answer they come up with is not the one originally envisaged. This is not easy. The project manager not only has to deal with the vagaries of their company's management structure but that of the client as well. In a busy commercial environment, they rarely have exclusive use of all the experienced designers they require, competing for the expertise they need. They also often have to deal with heavy pressure from the client to produce action and results. The need for careful planning before quantifiable results are produced is often not understood.
A good design project manager needs to tailor their management style to suit the project. Some projects may be large enough for a task force to be developed with a good working relationship, making communication and management easier. Others may be multidisciplinary, involving short-term input from many different parts of the company which have to be very highly controlled to ensure that the correct product is produced. Yet other projects may be small with very swift programs which have to be fitted in between the longer running projects cutting across other deadlines. The busy project manager will normally have to deal with all these types of project all at the same time and for different clients.
The design process has five stages, Table 11.3. Prior to starting work on any of the stages, the design project manager should consider how the project will be planned and controlled. There are those who say that design as a creative process cannot be controlled. However, to be of value the facility must be obtained by a certain time, Fig. 9.2, and so the process must be managed. Tables 11.4 and 11.5 contain checklists for planning and controlling the design process. The design manager has to be a juggler of resources, costs, and time. In some ways the problem is more complex because the "product" is unique and can change many times before completion. The manager must strike a balance between too much planning and not enough control and too much control and not enough planning.
Managing the Urgency
There is often a tendency to try to shorten the design process to begin work on a project. When discussing the problem-solving cycle, Fig. 1.6, I said people tend to jump from perceiving a problem to selecting a solution, or worse to implementing one. They then never truly determine the cause of the problem and the best method of solving it; they just paper over cracks. It is always important to put adequate time and effort into the design process, and the way to ensure this is to have a proper project plan for the design stage, which measures the progress of the design towards completion against a series of milestones.
There can also be a tendency to overlap implementation and design to make better use of available skilled resources. This is what I described in Sec. 3.4 as fast build, fast track, or concurrency, which are associated with increasing risk. I cannot stress enough the importance of allowing the design stage to take its course. However, we shall now see that the project manager must guard against the opposing risk, namely the desire of the designers to develop the ideal solution or prolong the design period because of the inherent job interest it offers.
TABLE 11.4 Planning the Design Process
| |
P1: | Examine the problem carefully with the client and if possible with their advisers. Establish what the task is and agree to a fee structure for the work covering various stages of design, taking note of the often highly variable nature of the initial design studies. |
P2: | The fee arrangement may also include a collateral warranty. This is commonplace in the construction as a result of case law on the question of latent liabilities. This must also be recognized and dealt with as a milestone because clients frequently cannot get funding released from their backers until the document is signed and completed. The time necessary to complete these procedures is often underestimated, which can cause delays. |
P3: | Establish the basis of a planning network, identifying key milestones in design. Plan to do the detailed planning of each phase only when it is necessary, that is, on a rolling basis. |
P4: | Confirm the work breakdown and identify packages of design work. Seek for use of the appropriate work package managers and teams from within your company. Select the right people for the right job, and match personalities to the nature of the task. A careful meticulous detailer cannot drive a high-pressured fast-track project forward, but should be used to give support to the innovators and strong managers. |
P5: | Assess time and resource requirements for each phase of design work (at the appropriate time) using your own experience combined with that of the work package managers. |
P6: | Check each stage of resource allocation against fee available prior to undertaking work. If fee is too small, reevaluate the amount of design and reduce or delay applying resource or renegotiate fee arrangement. Aim to do the right work at the right time. |
P7: | Establish that resources available for each stage are sufficient to meet the program, using your master design plan as a basis. Introduce contingency allowances at a fairly high level in the plan so that you can control slippage. Try not to build contingency at each level or else you will never create a workable program. |
P8: | Establish, jointly with the department managers in your company, whether your use of their staff (particularly when the project is multidisciplinary) is compatible with their other commitments and schedule resources accordingly. Tie this back to the basic network and evaluate any overall program effect. As far as possible smooth out resource peaks to enable overall company staff planning to be easier and seek to adjust project priorities to suit. A balance always has to be struck. |
P9: | Establish work packages, and if possible write down a brief for their managers as clearly as possible. This is often difficult to achieve but is very important because it establishes a firm criteria against which success can be measured in each design package. Ensure this brief is a living document, and that it is continually referred to and updated by mutual agreement of project manager and work package manager as the design evolves. |
P10: | Establish the critical path. In theory, your critical path should be determined from the outset by the production of a stable network plan within which variations can take place. In practice this may not be so easy to achieve as there are usually many unforeseeable events which erode your contingency and cause the path to shift. These key activities always dictate whether or not the project is completed on time. |
P11: | Information and resource needed is the key to the well being of the project. It is suggested that 80 percent of design problems come from 20 percent of the activities. However an over-preoccupation with activities currently identified as critical can backfire by reducing your awareness of noncritical areas which can become critical. A balance has to be achieved and progress on each facet of the network must be regularly monitored and controlled. |
| |
Managing the Users
Throughout design, designer, client, and end user must remain in close dialogue, so the design meets the user's needs. However, it is important that designers and users are not allowed to change the requirements so frequently that no progress is made. Managing the users is vital. The challenge is to ensure essential changes are made, but "nice to haves"
TABLE 11.5 Controlling the Design Process
| |
C1: | Establish communication systems. Decide which level of designer should talk to which level in the client. Ensure you are always in the picture as to progress. Ensure work package managers are aware of their responsibility to control communication. Only correct considered information should be released to avoid incorrect action by outside bodies which destroys confidence in the design team's abilities. |
C2: | Establish a Design Review Procedure. Regular (fortnightly) design reviews should take place to ensure the whole package is moving towards its target. An open forum in which package managers can discuss problems should be encouraged. People must not hide major problems but discuss them and to seek help before they get out of hand. |
C3: | Establish a design checking procedure to interface the review process. Some projects need a full quality assurance (QA) system. This must be identified at the outset to ensure a quality plan is written and implemented incorporating project management systems. Some projects (eg, bridges designed for the Department of Transport) have checking procedures established for each stage. These may include formal checks by other firms. |
C4: | The checks and consequential alterations must be programmed at each stage of the design, and adequate resources and time allowed. If QA is required, you must remember this is only an aid to sound design office procedures and not a substitute. |
C5: | Establish regular meetings to interface with client/consultant design team meetings. These meetings may be held instead of or as well as design reviews, depending on the complexity of the job, and should bring together internal design issues and a review of external influences on the design. Following these reviews, a short statement of progress addressing key issues and problems should be prepared for issue to the client. Areas where information is required or where instruction is needed should be identified. |
C6: | As changes occur ensure the reasons are communicated if appropriate down to draughtsmen. There is nothing more demoralizing to a draughtsman than facets of the design being repeated when the reason is unclear. Although this may be tedious for the work package managers, the project manager must encourage the team to keep communication lines open. One must always be conscious of the needs and desires of the individual as well the objectives of the project or else neither will be achieved. |
C7: | Check expenditure against forecast costs and fee income. Often delays cause an increase in resources to recover the program. Delays may require you to move staff from one project to another to avoid overloading one and under-resourcing another. While plan and control systems should accommodate this, the financial side of your company must not be forgotten. Computerized monthly job cost summaries are out of date before you receive them so ensure you know what the projected cost effects are before they occur. |
C8: | Changes to the design brief may be made by the client as design develops. This is part of the design process as the client begins to understand the impact of earlier decisions. Some change should be tolerated, but major changes must be controlled, and additional fees sought before embarking on the extra work. If the client is not aware of the financial implications, they will change their mind without a second thought. |
C9: | Establish which outside bodies must be consulted, and their approval obtained prior to commencing. These may be statutory bodies, environmental groups, planning authorities etc. Time to obtain such approvals must be allocated and milestones recognised. You may require input from the consultant team at regular intervals depending on the product. Identify and program this information as a strategic part of the design process. |
| |
avoided. Many people suggest freezing user requirements at an early stage. But that can lead to ineffective solutions, as the process of designing the asset and its product can help to clarify user requirements. What is needed is the application of effective configuration management so the design moves steadily forward, until a viable design is produced which meets user's needs.
New product development (NPD) can lead to many types of project, including:
Research and development
Product design
Facility design and construction
Product launch
Encouraging Innovation
NPD plays a key role in organizational competitiveness, yet is it one of the most difficult aspects to manage. Organizations which choose in-house development must create a climate which favours innovation.7 Top management have a key role in this process, to encourage the establishment of a creative environment, which has three key components.
Climate for Innovation. The innovative climate of an organization and its development policies are inseparable. Product development demands a flexible structure which encourages creativity and entrepreneurship and provides necessary conditions which favour development. However, there can be many pressures within an organization which act to hinder enterprise, and encourage bureaucratic policies and procedures which constrain change.
Innovative Organization. In order to harness innovation, organizations must be versatile and adaptable in their approach to their circumstances. In essence, product development is at its best in organizations which encourage imagination and are organic in nature, rather than those with bureaucratic structures based on routine management processes.
Individual Innovation. Whether bureaucratic or organic organizations consist of people whose personalities and performance affect the success of projects and overall performance. Thus, organizations need to adopt structures which harness individual innovation. This will be reflected in recruitment and selection procedures, opportunities for development, removal of bureaucratic restraint, and rewards to innovators. It is not possible to prescribe the definitive organizational structure to achieve this; much depends on the company's response to its environment.
Planning New Product Development
The nature of product development creates several planning problems, as projects range from modest expenditure to major investments, combined with indeterminate time constraints incompatible with routine reporting cycles. The diverse activities involved in new product programs should move through a logical sequence of events. Though considered contrary to flexibility and creativity, development plans are necessary as they help determine critical components of the project. The sequence, project life cycle, suggested by Kotler5 is often used to illustrate the new product planning process (Fig. 11.4).
Plans should be used to enhance rather than hinder the development process. Management should not be limited by this logical progression. The sequence outlined
FIGURE 11.4 New product planning process (project life cycle).
FIGURE 11.5 Revised sequence for ideas generated by users.
FIGURE 11.6 Revised sequence for products not requiring radical change.
is a guideline to help development, not constrain it. Idea generation, for example, does not always automatically occur as part of the formal planning sequence. Ideas may be initiated by users or employees during normal work (Fig. 11.5). Similarly, product development does not always require radical change. Projects may be initiated to modify existing product lines (Fig. 11.6), or may also have several stages running simultaneously (Fig. 11.7).
FIGURE 11.7 Sequence with several simultaneous changes.
FIGURE 11.8 Revised sequence incorporating strategic focus.
The planning process so far has not established links with corporate strategy. Although not part of the routine of the company, project plans should be fully integrated into the strategic plans (Sec. 2.5). NPD should be complimentary to existing products and meet the needs of the product portfolio against market demands. New products give an important strategic capability for achieving corporate and business objectives. Strategic issues should direct and influence the new product project in three ways: strategic focus, technical criteria, and market acceptance. Figure 11.8 proposes a revised product development planning process which combines strategic focus with the need to combine phases of new product development.
Organizing New Product Development
In a climate which welcomes creativity, the marketing function has two distinct roles:
1. Routine, operational marketing tasks: Demanding a structure based on routine activities, planning, and coordination of the marketing mix for products which form part of the existing product line.
2. Novel projects: Requiring less defined structure. NPD projects operate in uncertain conditions, and plans require freedom from routine organization.
In order to implement in-house product development, the first problem is to find the right organizational format. By nature, innovation is individualistic, requiring each company to develop their own working arrangements. There are several ways in which a business can organize itself for product development.
New Product Committees. These are committees, meeting on a continual or ad-hoc basis, responsible for coordinating product development. Members are senior functional managers and executives from research, marketing, finance, production, engineering, and so on. Their responsibilities include reviewing and screening proposals, determining policy, planning, and coordination. Often the committee is considered to be the coordinating function which ensures the product maintains its momentum and controls the activities of the multifunctional team developing the product.
Product Managers. Product managers may be given responsibility for developing new products alongside their normal duties of managing existing product lines. There are several reasons for this. As well as monetary benefits, product managers are sympathetic to the customer requirements and considered to be in the best position to ensure synergy with the existing product portfolio. The disadvantages are additional management time required may not be forthcoming, nor can the product managers give this unique activity the specialized attention, resources, and expertise required while maintaining responsibility for routine activities.
New Product Managers. They are given overall responsibility for product development from planning to implementation. Often the new product manager works alongside existing product managers but without their operational responsibility, and can thus turn their attention to the creative role and generate practical new product ideas. Although the establishment of a new product manager formalizes the product development role, there are strong links with existing product lines, leading to minor changes, rather than independent, novel, or radical innovations.
New Product Departments. These are common in large organizations, working alongside new product managers in generating ideas, and evaluating their feasibility. In contrast to other methods, new product departments place the responsibility with a senior manager. The department provides the umbrella for coordination of various functions for continuous project management. It does not have responsibility for operational duties, so may dedicate its efforts to producing quality new products. Sometimes a new product department may be situated within a larger department, such as planning, marketing, research and development, projects, or engineering.
Venture Teams. These are composed of functional specialists working to a closely defined brief, and generally recruited on an ad hoc basis for a short time. While located in the team, the individuals are removed from day to day activities. The team ideally reports to a nonoperating executive.
Task Forces. These groups are organized on an ad hoc basis. Members are seconded from operational duties for the duration of a project, or divide their time between routine activities and project work. The aim of task force management is to ensure continued support from the functions throughout a project. As a project reaches the latter stages, task forces may recruit more members with specialist skills.
Project-Based Product Development. Product development involves individuals with specialist skills, from various functions and managerial levels. The formation of project teams can be effective in solving problems and creating benefits which cannot be achieved in routine ways. However, one structure may not be appropriate at all stages of the project. Just as the activity needs to be fluid and flexible, the organization must also adapt to accommodate the different expertise needed throughout the project.
Controlling New Product Development
Control is an important element of NPD. The application of marketing control systems to an NPD process reduces the risk. Control processes should be integrated into all aspects of the plan and linked to critical components mentioned earlier. A continuous monitoring program provides project teams with valuable information which may determine the successful outcome of projects. The key of any system is the extent to which it allows the manager
FIGURE 11.9 Schema for a hierarchy of plans for new product development.
to influence the success of the outcome of the venture. Several planning and control techniques may be used to monitor new product projects. Figure 11.9 illustrates how these methods may be combined to monitor progress based on project objectives.
Figures 11.1, 11.2, and 11.4 show the product development process taking place sequentially. Traditionally, product development took place as a relay race: research, followed by development, followed by product engineering and prototyping, followed by production process engineering. Product development processes became artificially extended, not only as it was insisted that one step was finished before the next started, but inevitably there was a delay between one step and the next. Concurrent engineering attempts to overcome the built-in delays by running the product development process with the steps in parallel, as suggested by Figs. 11.5 to 11.7. The concept was first adopted in the development of fast-moving consumer goods as early as the late 1970s, but subsequently became widely adopted across a range of industries. Concurrent engineering is a systematic approach to the integrated concurrent design of products and their related processes, including manufacture and logistics support. This approach is now used in areas other than manufacturing, including construction and organizational change projects. The objectives of concurrent engineering are to achieve:
Decreased product development times and hence earlier time to market
Improved profitability and competitiveness
Greater control of design and development
Reduction in product costs
Improved product quality
Requirements of Concurrent Engineering
Several changes are required within the organization and in its approach to projects, in order to allow this to happen.
A Change in the Organizational Culture. A shift is needed to the flatter, more flexible approaches of project-based management. There needs to be decentralisation of authority, with managers empowered to take decisions without referring them up the line, which builds in delay (Example 11.2). However, this environment creates an almost greater requirement for senior management support, to show their faith and support for the product development process.
Cross-Functional Team Working. The use of cross-functional teams is inherent to concurrent engineering. It is the only way to achieve the necessary parallel development. This requires people to communicate freely across the functional hierarchy, demonstrating the need for the empowerment and support of managers mentioned above (Example 11.2). It also requires teams to work closely with suppliers since their development must take place in parallel. This may require partnering or integrated supply chain management. It also requires advanced contracting methods to allow contracts to be agreed with suppliers long before the closure of design.
Use of Technology. Concurrent engineering only really becomes possible with the use of modern information systems. This includes the use of computer-aided design, engineering, and manufacture systems, (CAD, CAE, and CAM), with access via the intranet, to aid design integration through shared product and process models and databases. It also requires the use of good project management to coordinate the work of the people involved. Configuration management becomes a significant element of concurrent engineering and so the Project Management Information System (PMIS) must be able to perform the status accounting involved.
Techniques. Concurrent engineering requires the extensive use of iterative working techniques to develop all the aspects of the product, process, and logistics design simultaneously.
Example 11.2 Communicating across the hierarchy
Some years ago I did some work with the National Air Traffic Service, responsible for monitoring the U.K.'s air space. One person I interviewed had recently joined from the private sector to help implement a major project. He said he found it difficult doing his project work, because if he needed to communicate with another person working on the project but from another department he had to write a memo. The memo would go to his boss, who would critique it and send it back for revision. It would then go to his boss's boss, who would also critique it, and so on until it reached the lowest common boss, and then it would go to the person he was trying to communicate with. It could take two weeks or more for the memo to get to the person he was trying to communicate with. He said it was impossible because on a project you need to make instant decisions, advancing simultaneously across a number of disciplines from different departments.
The next person I interviewed was an air force officer on secondment. I was reeling from what the previous person had said, and asked the air force officer about it. He said, yes it happens, but what he did was send a draft memo to the person he was trying to communicate with while the official memo went through the cycle. As a military person, used to the need for fast communication (Fig. 1.10), he had found a way around it.
You can understand the concern of middle and senior managers. If a plane crashes because of a decision made by somebody in their department, they want their stamp on the decision trail. But it makes project work impossible. Managers need to be empowered. It is about setting flexible parameters within which they can work, but setting limits where limits matter.
Risks and Pitfalls of Concurrent Engineering
Attitudes of Middle Management. There may be resistance from middle managers (see Example 11.2). Not only does the cross-functional working threaten their influence, it increases their costs initially. Although the increased costs will be repaid through earlier completion times, managers can see an early fall off in the profitability of their departments, and hence a reduction in their bonus in the early years. When told that the higher costs associated with faster development times will be repaid through increased sales over a three-year period, managers may say that they are only in post for two years, and hence do not get the enhanced payback within their period of tenure.
Authorisation of the Concurrent Engineering Project. The first problems to be overcome are those of obtaining sanction for the project and for executing it on a concurrent engineering basis. If this has been done before it should not be a problem, otherwise it may be a long hard battle with all of the organizations and departments involved. The project definition stage is of paramount importance in this respect as it has to satisfy the following major criteria prior to project authorisation and major commitment:
1. The product must be within the organization's aims and objectives.
2. The market need for the product must be established beyond doubt.
3. The supply of raw materials must be shown to be secure.
4. The design of the product must be carried out to a sufficient level to establish its feasibility. (If necessary including models and/or prototypes.)
5. The design of product manufacturing system and its associated support systems must be evaluated, and must be within the organization's intended capability.
6. Economic and financial evaluations must show the product to be viable bearing in mind the predicted life cycle, development, and production costs.
It is usual during project definition to survey the industry, benchmarking to obtain typical implementation costs for similar products (Chap. 17). It may also be possible to use the organization's standard investment appraisal techniques,6 but these do not always account for combined development and implementation stages. The risk associated with authorisation of a concurrent engineering project is significant as it is an all-or-nothing approach that commits the organization to prosecute the project to completion. (The only factors to prevent its continuation after authorisation would be due to external items such as a dramatic market shift.) In authorising a concurrent engineering project, senior management must be seen to give both the project and the approach their full support. They are not only authorising a technical development, but are authorising radical change and way of life in the organization.
Organizational and Cultural Change. The adoption of a concurrent engineering policy will inevitably involve significant changes to an organization and its culture. Some of the more important of these may be:
Departmental organization shift to project orientation
Conventional project-oriented organization shift to concurrent project organization
Move out of deep hierarchical structure into shallow, multidiscipline teams
New organizational reporting structures
Change to business practises and procedures
Establishing long-term customer/supplier relationships and elimination of counterproductive competitive tendering policies
Reorientation of accounting policies away from departments and towards projects
The importance of these changes will be determined by many factors including:
The degree of support from senior management
The existing organization's size and culture
Resistance from established functions
Degree of product novelty and complexity
Difficulties in implementation
Managing Interfaces. There will be many interfaces to be managed including those between:
Management and design
Commercial considerations and design
Suppliers and design
The various design functions within the concurrent engineering design team
New product production and support facilities and those of existing products.
Careful selection of the concurrent engineering team, its working procedures, and the control facilities employed to ensure that these are managed effectively.
Technical Management. The most important function to control is that of design as this largely determines how a product is to be made or implemented and its associated costs. The designer is often only limited by a relatively few critical constraints but his or her work may have great impact on the work of others and on downstream costs. The following aspects of the project are identified at an early date and monitored closely:
1. Differentiation: where there are linkages between highly differentiated departments.
2. Cross-functional requirements: where there is a need to take account of requirements of the other function, particularly those downstream in the development process.
3. Uncertainty: where there is high uncertainty in the use, interpretation, or content of data.
4. Intensity and frequency of two-way flow: where there are major feedback requirements between departments or functions.
5. Complexity: where there is a need to liaise between groups because of the complexity of the product or task.
Standardisation policies help ensure conformity and the extensive use of common electronic data management tools helps to keep all parties working to the same model and standards. The early development of prototypes and prototype testing is a powerful tool used extensively in concurrent engineering. Its major value is that of identifying and forcing problems out into the open at an early stage. These can then be solved before they become too serious.
Cost Control and Release of Finance. The implementation of concurrent engineering requires a significant departure from conventional financial release and cost control methods as it involves
Initial release of greater fund on more preliminary information in the early stages.
Negotiation of less well-defined contracts with suppliers or contractors who are to assist in the design process.
Commitment of greater funding for production facilities at an early stage when parameters are not well defined.
The chief departure from conventional methods is the acceptance of significant financial risk at an early stage and the greater requirement for an effective and continuous cost review procedure that gives early warning of possible cost risk areas. (Bear in mind that the rolling-wave approach to both planning and technical design will have major impact on the increasing confidence in cost estimates).
Risk Controls. More stringent risk management procedures are required with concurrent engineering than with conventional developments. In particular, they have to operate across the whole range of project activities including sales, marketing, personnel, production, and support. They need to impose a consistent risk approach on a continuous basis, covering all items that would otherwise be analysed at stage reviews. As with conventional developments, they fall into the usual categories including technical, commercial, financial, and time. Most of the concurrent engineering techniques and procedures operate with the reduction of risk as a prime motive.
11.6 INFORMATION SYSTEMS PROJECTS
As software has become more complex, managers have a greater need to understand its production, and several models of the software life cycle have been developed to aid this process. Many of the models are applicable to other areas of technology, and to R&D projects. The function of a life-cycle model is to determine the order in which software development should be undertaken, and to establish transition criteria to progress from one stage to the next. Transition criteria include completion criteria for the current stage, and entry criteria for the next. More sophisticated models of software development life cycles have evolved because traditional models discouraged effective approaches to software development such as prototyping and software reuse. This section traces the evolution of the different models, and explains their strengths and weaknesses.
The Code-and-Fix model
The earliest model for software development had two simple stages:
Stage 1: Write some code.
Stage 2: Fix the problems in the code.
Code was written before requirements were fully defined, design done, and test and maintenance procedures described. The strength of this approach was its simplicity, but that is also the source of its weaknesses. There are three main difficulties:
1. Maintainability: After a number of fixes, the code becomes so poorly structured that subsequent fixes are very expensive. This reinforces the need for design prior to coding.
2. User requirements: Often the software is a poor match to users needs so it is either rejected or requires extensive redevelopment.
3. Cost: Code is expensive to fix because of poor preparation for testing. This highlights the need for these stages, as well as planning and preparation for them in early stages.
FIGURE 11.10 Stage-wise model of software development.
The Stage-Wise and Waterfall Models
Experience on large software systems as early as the mid-1950s led to the recognition of these problems, which resulted in the development of a stage-wise model. This suggests software should be developed in successive stages (Fig. 11.10). The waterfall model (Figs. 11.11 and 11.12) is a refinement of the stage-wise model from the late 1960s which is still popular. The major enhancement was that it recognized feedback loops between stages, but with a requirement to confine loops back to the previous stage only, to minimise the expensive rework resulting from feedback over several stages. I use the second waterfall model (Fig. 11.12) to illustrate principles common to many of the life cycles, as it can be easily related to other models, although the specific stages and names vary between models.
The second waterfall model is characterized by its V-shape. Down the left-hand side are stages which derive elements of the system, while up the right-hand side is the delivery of the elements to form the system, Table 11.6. Each stage is defined by its outputs, the deliverable, rather than its constituent activities. A tangible output is the only criterion of progress, the only thing which can be assessed objectively. In this way the 95 percent complete syndrome is avoided. The product of each stage represents points on the development path where there is a clear change, where one viewpoint of the design or emerging system is established, and is used as the basis for the next. As such, these intermediate products are natural milestones of the development progression and offer objective visibility of that progression.
To provide management control, the ideas of baseline and configuration management are adopted. The completion of a stage is determined by the acceptance of the quality of the intermediate products, or deliverables, of that stage. These deliverables form the baseline for the work in the next stage. Thus the deliverables of the next stage are verified against the previous baseline as part of configuration management and quality assessment, before they become the new baseline. Each baseline is documented, and the quality assessment includes
FIGURE 11.11 The water-fall model (1).
reviews of intermediate products by development personnel, other project and company experts, and usually customer and users. We met baselining in Chaps. 8 and 9. However, there the focus was on baselining time and cost, whereas here it is on quality and scope. For these, you cannot baseline the whole project, only one stage at a time, as the definition of scope and quality evolve through the project. This evolution is controlled by configuration management (Sec. 7.3). It is the documentation and reviews which provide the tangible and objective milestones throughout the entire development process. The waterfall model shows how confidence in the project's progress is built on the successive baselines.
This simplistic description of the life cycle could imply that control of software development can only be achieved by rigorous control of the staging, so that no stage is considered
FIGURE 11.12 The water-fall model (2).
complete until all prescribed documents have been completed to specified standards, and no stage can be started until all its input documents are complete, giving nonoverlapping stages. Although the intended rigor of such an approach is commendable, it is unrealistic on a large development project. It is not intended that the life cycle should be interpreted in such as simplistic way.
TABLE 11.6 Stages of the Software Development Life Cycle
| |
Stage | Description |
| |
Feasibility study | Production of verified/validated system architecture based on a design study, including allocation of tasks to staff and machines, milestone plan, responsibility chart, schedules of major activities, and outline quality plan |
Requirements specification | Production of complete/validated specification of requirements (functional/nonfunctional) the system must satisfy. Produced in close liaison with the end user. Means of system acceptance also agreed with end user |
Systems design | Production of complete/verified specification of overall architecture, control structure, and data structure for the system. Production of draft user manuals, and training and test plans for integration |
Module design | Production of detailed designs for each module, together with module test plans. This may actually consist of more than one level of design |
Code | Module designs are converted into code units in the target language |
Unit test | Code units are tested by the programmer. Errors are corrected immediately by the programmer. Once complete, code units are frozen and pass to integration |
Module integration (structural testing) | Component units of a module are integrated together, and tested as specified in module test plan. Errors detected are formally documented, and the affected area returns to a stage where the error was introduced |
Systems test (functional testing) | Modules are integrated together to form the system, and tested against the system test plan. Errors detected are handled as for module testing |
Acceptance test | Client formally witness the exercising of the system against agreed criteria for acceptance |
Maintenance | Service life is often grossly underestimated. The cost of development can be small compared to maintenance, but the latter is given little consideration. |
| |
The strengths of the waterfall model are that it overcomes the problems in the code-and-fix model. However, its great weakness is its emphasis on fully elaborated documentation as completion criteria for early stages. This is effective only for some specialist classes of software, such as compilers and operating systems. It does not work well for the majority of software, for example, user applications and especially those involving interactive interfaces. Document-driven standards have pushed many projects to write elaborate specifications of poorly understood user interfaces and decision support functions, which have resulted in the design and development of large amounts of unusable code.
The Spiral Model
The spiral model (Fig. 11.13), first developed by Barry Boehm,8 can accommodate all the previous models as special cases. The radial dimension represents the cumulative cost of undertaking the work to date. The angular dimension represents the progress of each cycle of the spiral. The model reflects the concept that each cycle involves a progression through a repeated sequence of steps for each portion of the product, and for each elaboration from overall concept document to coding of each individual program. Each loop of the spiral passes through four quadrants:
1. Determine objectives, alternatives, and constraints.
2. Evaluate alternatives and identify and resolve risks.
FIGURE 11.13 The spiral model.
3. Develop and verify the next level of product.
4. Plan the next stage.
Determine Objectives, Alternatives, and Constraints. After planning and launching each cycle begins with identification of:
Objectives of this portion of the product being set, including performance, functionality, ability to accommodate change, and so on
Alternative means of delivering this portion of the product, including alternative designs, reuse, or buying in
The constraints imposed on final deliverable by the various alternatives, including cost, schedule, interfaces, and so on
Evaluate, Identify, and Resolve Risks. The next step is to evaluate alternatives against the objectives and constraints. Frequently this process identifies areas of uncertainty which are significant sources of risk. If so, this stage should involve the formulation of a cost-effective strategy for resolving the sources of risk.
Develop and Verify the Next Level of Product. Once the risks are evaluated, the next stage is determined by the relative importance of remaining risks. This risk-driven basis of the spiral model allows it to accommodate any appropriate mixture of different approaches to software development including specification-orientated, prototype-orientated, simulation-orientated, transformation-orientated, and the like. The appropriate mixed strategy is chosen by considering the relative magnitude of the program risks, and the relative effectiveness of the various approaches to resolving risk.
Plan the Next Stage. This completes the cycle. An important feature of the spiral model, as with others, is that each cycle is completed by a review involving the primary parties concerned with the product.
Management and the Spiral Model
There are four key points.
Initiating and Terminating the Spiral. The spiral is initiated by the hypothesis that a particular operational objective can be improved by a software solution. The spiral evolves as a series of tests of this hypothesis. If at any time the hypothesis fails, the spiral is terminated. Otherwise it terminates with the installation of new or modified software.
Features of the Spiral Model. The model has three essential features:
1. It fosters the development of specifications which need not be uniform, exhaustive, or formal. They defer detailed elaboration of low-risk software elements, and avoid unnecessary breakages in their design until the high-risk elements are stabilised.
2. It incorporates prototyping as a risk-reduction option at any stage of development. Prototyping and the reuse of risk analysis were previously used in going from detailed design to code.
3. It accommodates reworking or a return to earlier stages as more attractive alternatives are identified, or as new risk issues need resolution.
Evaluation. The main advantage of the spiral model is its range of options accommodates the good features of existing software, while its risk-driven approach avoids many difficulties. Other advantages include
It focuses early attention on options reusing existing software.
It accommodates evolution, growth, and changes of the product.
It provides a mechanism for incorporating software quality into product development.
It eliminates errors and unattractive alternatives early.
It identifies the required amount of each resource.
It uses the same approach for software development, enhancement, or maintenance.
It provides a viable framework for integrated hardware and software system development.
However, there are three areas which must be recognized:
1. Matching to contract software: The model works well on internal development projects, but needs further work for contact software. Its adaptability makes it inappropriate for fixed-price contracts.
2. Relying on risk assessment expertise: The spiral model places a great deal of reliance on the ability of software developers to identify and manage sources of project risk.
3. Need for the further elaboration of the stages of the model: The steps of the model need further elaboration to ensure all software developers are operating in a consistent manner. This includes detailed specification of deliverables and procedures, guidelines, and checklists to identify the most likely sources of project risk, and techniques for the most effective resolution of risk.
Risk Management. Efforts to apply and refine the model have focused on risk management (Chap. 10). A top 10 list of software risk items (Table 11.7) is a result. Table 3.6 also gave a list of 10 success factors developed by Jim Johnson of the Standish Group.9 The reverse of these can be suggested as risks.
Agile Methods
One of the success factors that Jim Johnson suggests in the adoption of agile, iterative processes.10,11 These are the basis of Rapid Applications Development (RAD) or Extreme Programming. These two techniques basically follow the spiral model, but with very short cycle times. Some people say that RAD doesn't follow a life cycle, and therefore shows that the life cycle is not an inherent feature of projects. It does, it is just that it goes repeatedly around the life cycle in very short bursts of activity. So as we have seen in this chapter, the life cycle can be a single sequential process, a parallel process as in concurrent engineering, or an iterative process as in the spiral model, rapid applications development, or extreme programming.
The Problems of Real Life
Unfortunately, software development is not quite as simplistic as these models might imply:
Exploratory work on subsequent stages, including costing, can be required before the current stage is complete, for example, design investigation is almost invariably required before it can be stated that the user requirement can be achieved within a realistic budget.
TABLE 11.7 A Prioritised Top Ten List of Software Risk Items
| |
Risk item | Risk management technique |
| |
Personnel shortfalls | Staff with top talent, team/morale building, cross training prescheduling key people |
Unrealistic schedules and budgets | Detailed cost and duration estimates, design to cost, incremental development, reuse of software, requirements scrubbing |
Developing wrong functionality | Organization/mission analysis, ops concept formulation, user surveys, prototyping. early user manuals |
Developing wrong user interface | Task analysis, prototyping, scenarios, user profiles (functionality, style, workload) |
Gold plating | Requirements scrubbing, prototyping, cost-benefit analysis, design to cost, value engineering |
Continuing changes to requirements | High change threshold, information hiding, incremental development (defer changes to later increment) |
Shortfalls in procured components | Benchmarking, inspection, expediting, reference checking, quality auditing, compatibility analysis |
Shortfalls in subcontracted tasks | Reference checking, pre-award audits, fixed price contracts, competitive design/prototyping, team building |
Shortfalls in real-time performance | Simulation, benchmarking, modelling, prototyping, instrumentation, tuning |
Straining the capabilities of computer science | Technical analysis, cost-benefit analysis, prototyping, reference checking |
| |
Problems encountered in later stages may require reworking of earlier stages—failure to recognise this leads to earlier documentation becoming inaccurate and misleading.
The users' requirement may not remain stable throughout a protracted development process—it is then necessary to consider changed requirements and consequential changes.
It is important that the life cycle is not rigidly imposed. In reality, there are no clearly defined break-points between the stages. Equally, all the stages are composed of several substages or packages of work. Once this is recognized, it leads not to the conclusion that the life cycle model must be discarded, but it represents a valuable model of what is involved in the work of software development. The biggest single problem in the software cycle is communication across the boundary from one stage to the next. At each stage there can be a degradation of the definition of the users' requirements. Quality assurance (Sec. 7.2) and configuration management (Sec. 7.3) play a crucial role in managing this flow of information.
Resourcing the Life Cycle
Many of the names of stages in the life cycle are similar to resource types working in software development. This results in each type becoming primarily associated with a stage: systems analysts with design, programmers with coding. You will hear IT people referring to the work of each resource types as an "activity," and then they confuse the "activity" of the resource, with the work of the stage. Resource types are then not assigned to the project until the work of the stage with which they are associated is about to begin. The result is long lead items are ignored by earlier resource types, resources have no time to prepare before starting, and resources cannot complete their input within the time allotted. In reality, most resource types should work throughout the project. Where the work of one resource type overlaps with a stage that defines a work package. Early work packages are in support of the design process, and in preparation for the stage in which the resource is primarily involved. Later work packages are in support of implementation.
1. Projects can be classified in many ways. Different types of projects require a different approach or emphasis to their management.
2. In addition to traditional projects to deliver and commission a facility, projects can conduct:
Marketing surveys and product development
Research and development
Maintenance and decommissioning
3. New product development can lead to many projects:
Research and development
Product design and prototyping
Facility design and delivery
Product launch
4. New product development can be managed through:
New product committees
Product managers
New product managers
New product departments
Venture teams
Task forces
5. The stages of the product development life cycle include
Idea generation and screening
Concept development and testing
Marketing strategy
Business analysis
Product development
Market testing
Commercialization
6. Concurrent engineering is used to overlap stages in the product development cycle, to speed up the delivery of new products.
7. Concurrent engineering requires the adoption of new project management practices, including:
A change in organizational culture
Cross-functional team working
Use of new technology, information systems, and other new techniques
8. There are risks and pitfalls associated with concurrent engineering, including:
Attitudes of middle management
Authorization of the project
Organizational and cultural change
Managing interfaces
Technical management
Cost and risk controls and release of finance
9. There are five types of model of the life cycle for software development projects:
Code-and-fix models
Stage-wise models
Waterfall models
Spiral models
Agile methods including Rapid Applications Development and Extreme Programming
10. Stages in all the models are identified not by the work done, but by the deliverables, or intermediate products, in which they result. The control process focuses on the quality of these deliverables.
11. Spiral models, which can incorporate any one of the other four as a special case, view the project as moving repeatedly through four quadrants:
Plan the forthcoming stage.
Determine objectives, alternatives, constraints.
Evaluate alternatives and identify and resolve risks.
Develop and verify the next level product.
1. Fayol, H., General and Industrial Management, London:Pitman, 1949.
2. Project Management Institute, A Guide to the Project Management Body of Knowledge, 3d ed., Newtown Square, P.A.: PMI, 2004.
3. Wearne, S.H., Principles of Engineering Organization, London:Edward Arnold, 1973.
4. Kerzner, H., Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 9th ed., Hoboken, N.J.: Wiley, 2006.
5. Kotler, P. and Keller, K.L., Marketing Management, 12th ed., New York: Prentice Hall, 2005.
6. Turner, J.R and Wright, D., The Commercial Management of Projects, Aldershot, U.K.: Gower, 2009.
7. Keegan, A.E. and Turner, J.R., "The management of innovation in project based firms," Long Range Planning, 35, 367–388, 2002.
8. Boehm, B.W., "A spiral model of software development and enhancement," Computer, May, 61–72: The Institute of Electrical and Electronic Engineers, 1988.
9. Johnson, J., My Life Is Failure: 100 Things You Should Know to Be a Successful Project Leader, Boston:Standish Group International, 2006.
10. Martin, R.C., Agile Software Development: Principles, Patterns, and Practices, New York: Prentice Hall, 2002.
11. Beck, K. and Andres, C., Extreme Programming Explained: Embrace Change, 2d ed. New York: Addison Wesley, 2004.