Innovation product management Question
kc121
RobDekkers_2018_Chapter6ProjectManage_InnovationManagementA.pdf
chApter 6
project management (for innoVation)
The previous chapters, particularly Chapters 4 and 5, have captured the sources of innovation and collaboration with actors of the innovation pro- cess in addition to some of the methods and processes that can be used. However, these chapters have said little about how innovations can be achieved in terms of management and control, which is denoted as the development of new products, services, and processes. For the controlled development of products, services, and processes, project management methods and techniques are used. Project management is often described as the discipline of initiating, planning, executing, and controlling activ- ities that aim at achieving specific goals constrained by specific perfor- mance criteria. Thus, an innovation project is a temporary undertaking designed to generate a unique product, service, or process with a defined beginning and end (usually time-constrained, and often constrained by funding or deliverables), typically to bring about beneficial change or added value. The temporary nature of projects contrasts with recurrent operational processes that are repetitive, permanent, or semi-permanent functional activities to produce products or services. In practice, the man- agement of these two systems is often quite different, and as such, requires distinct technical and managerial skills. The primary challenge of project management is to achieve all of the project goals within given constraints that are defined at the start of a specific project for innovation.
This chapter starts by comparing projects as a modus operandi with two other methods of working in Section 6.1. The contrasting will lead to a better understanding of what project management stands for. This is followed in Section 6.2 by how projects for new product and service development take place in a staged way. Section 6.3 describes how a work breakdown structure can be derived from the deliverables of the project. This work breakdown structure serves as base for the planning
C o p y r i g h t 2 0 1 8 . M o m e n t u m P r e s s .
A l l r i g h t s r e s e r v e d . M a y n o t b e r e p r o d u c e d i n a n y f o r m w i t h o u t p e r m i s s i o n f r o m t h e p u b l i s h e r , e x c e p t f a i r u s e s p e r m i t t e d u n d e r U . S . o r a p p l i c a b l e c o p y r i g h t l a w .
EBSCO Publishing : eBook Collection (EBSCOhost) - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY AN: 1881425 ; Rob Dekkers.; Innovation Management and New Product Development for Engineers, Volume I : Basic Concepts Account: s8991307.main.ehost
178 • innovAtion MAnAgeMent And npd for engineers
and budgeting of projects in Section 6.4. Management of uncertainties, inherent to projects, is the topic of Section 6.5. The organization of proj- ect teams appears in Section 6.6, and in this section, these teams are also linked to organizational structures. This is followed by information and communication plans in Section 6.7 and project leadership in Section 6.8.
6.1 Modes of operAtion
Project management is often linked to introducing new products and services, new processes, and change within organizations. However, project management is one of the three archetypes for methods of working (Wijnen et al. 1996, p. 21) to obtain these outcomes and deliverables; this comparison between the three will take place in the first subsection. In addition to comparing project management with two other approaches, the second subsection will discuss the objectives of projects and the related scope. A final subsection discusses the fuzzy front end, which is a specific feature of new product and service development.
6.1.1 comPaRing moDi oPeRanDi
To better understand project management as a modus operandi, it could be compared with another archetype of obtaining results: standardized oper- ations or recurrent processes (you could also just called it operations). The characteristic of standardized operations is that, as soon as a request is placed for a product, service, process, or any other so-called change of state of systems, a predefined set of activities takes place, and these result in the required outcome (Figure 6.1); see Dekkers (2017, pp. 117–24) for an extended description of changes of states of systems and related pro- cesses. Such standardized processes are also called recurrent processes;
Figure 6.1. Standardized operations as modus operandi.
Required change of state
Deliverables
Resources
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
project MAnAgeMent (for innovAtion) • 179
typically, these processes are found in logistics, manufacturing, and deliv- ery of services to customers. This indicates that this modus operandi can only yield defined outcomes and deliverables created in a prescribed way; the advantage of such a way of working is that the quality of the outcome of the process is predictable. In addition to the predictability of the out- come, the standardized processes also make the utilization of the required resources predictable; this contributes to a high degree of efficiency during the execution of these processes. Thus, if a request is made to produce a different product or service, then first, a process needs to be designed and tested before its delivery of products and services can take place. That means that the modus operandi of recurrent processes makes the outcome predictable, but that the outcome and deliverables are inflexible.
The second way of obtaining deliverables is an ad-hoc approach. In this mode, the request for a new process, product, or service is solved in a disorganized way: all kinds of resources are working on the problem to be resolved, and there is an absence of coordination; see Figure 6.2. Those that are involved with the problem undertake actions based on their own per- ception of the problem and the state-of-the-art, and sometimes that means taking steps back, rather than necessarily moving forward. For this rea- son, the outcome of the process is unpredictable, but it might also result in novel solutions. Consequently, the allocation of resources is not controlled because the oversight of what is taking place is lacking. However, the search for novel solutions might benefit from this ad-hoc approach to new products and services, new processes, and to changes in organizational structures.
Different from recurrent processes and ad-hoc processes, project management aims at delivering novel deliverables in a staged approach. This staged approach is necessary because, in the beginning of the project, there is uncertainty about how the solution to the problem is going to look like or how the deliverables can be used. This means that, after a phase in a project, there is a review whether the deliverables or part of them are still
Figure 6.2. Ad-hoc as modus operandi.
Resources
?
Required change of state
Deliverables
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
180 • innovAtion MAnAgeMent And npd for engineers
attainable, to what extent the scope of the project in terms of deliverables has to be changed, and whether the available resources are capable of making the required contributions; see Figure 6.3. That also implies that resource allocation may change during the project to reflect changes in deliverables and activities.
Thus, the three approaches differ substantially, which results they achieve and how, see Table 6.1. First, the deliverables are different. In the case of ad-hoc processes, the result might be novel and creative solutions, but at the same time, it may be unpredictable how and when these will be achieved. In recurrent processes, the deliverable is set and unchange- able within the capabilities of the resources. For projects, the deliverable is based on elicited requirements, but needs to be reviewed during suc- cessive stages; during each stage, the information about the feasibility of the solution becomes available, which allows plans to be evaluated. Thus, characteristics for projects are the staged activities and regular reviews of progression. These reviews could result in changes of scope of the proj- ect and its deliverables. Both the modi operandi of ad-hoc and recurrent processes lack these reviews. Furthermore, resource allocation differs across the three different approaches. In the case of an ad-hoc approach, the allocation of resources is dependent on instant decisions by individ- ual actors and activities as they appear on-the-go. Contrastingly, recurrent processes in operations are aiming at achieving efficiency, given a range of products and services to be produced. In projects, the onus of work allocation is directed at effectiveness; within the given constraints of time and budget, the activities in projects should yield predefined output in order for next activities to take place. However, a degree of uncertainty remains whether the outcomes of activities are fully achievable, given the uncertainty about the feasibility of the deliverables. These three different ways of dealing with deliverables, processes, and resource allocation also influence the performance.
Figure 6.3. Projects as modus operandi.
Required change of state
Deliverable(s)
Resources Review
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
project MAnAgeMent (for innovAtion) • 181
A d-
ho c
Pr oj
ec t
R ec
ur re
nt D
el iv
er ab
le s
N ov
el a
nd c
re at
iv e
U np
re di
ct ab
le N
ov el
, b ut
p re
de fin
ed B
as ed
o n
sp ec
ifi ca
tio ns
St an
da rd
iz ed
Q ua
lit y:
p re
di ct
ab le
Pr oc
es s a
nd
ac tiv
iti es
A ct
iv iti
es b
as ed
o n
in di
vi du
al
in iti
at iv
es V
is io
na ry
a t t
im es
Sh or
t-t er
m c
ha lle
ng es
a nd
pr
ob le
m s d
om in
at e
St ag
ed p
ro ce
ss R
ev ie
w s f
or a
sc er
ta in
in g
w he
th er
o bj
ec tiv
es fe
as ib
le N
ot fu
lly p
re di
ct ab
le (e
le m
en t
of u
nc er
ta in
ty )
St an
da rd
iz ed
p ro
ce ss
es In
te gr
at io
n de
fin ed
o n
be fo
re ha
nd
R es
ou rc
e al
lo ca
tio n
B as
ed o
n ov
er co
m in
g sh
or t-
te rm
c ha
lle ng
es a
nd p
ro bl
em s
In effi
ci en
t b ec
au se
o f
co nt
in uo
us c
ha ng
es in
fo cu
s
Fo cu
s o f a
llo ca
tio n
on
eff ec
tiv en
es s
N ot
fu lly
p re
di ct
ab le
, t ho
ug h
la rg
el y
pl an
ne d
Fo cu
s o n
effi ci
en cy
Pe rf
or m
an ce
D iffi
cu lt
to a
llo ca
te b
ud ge
t be
ca us
e of
e rr
at ic
a nd
ch
an gi
ng d
ec is
io n
m ak
in g
Pl an
b as
ed o
n bu
dg et
a nd
de
ad lin
e D
eg re
e of
u nc
er ta
in ty
a nd
ris
ks re
m ai
ns
D el
iv er
y tim
e an
d co
st in
g pr
ed ic
ta bl
e (N
o de
vi at
io ns
p os
si bl
e, in
pr
in ci
pl e)
Ta bl
e 6.
1. O
ve rv
ie w
o f t
hr ee
a rc
he ty
pe s o
f m od
i o pe
ra nd
i
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
182 • innovAtion MAnAgeMent And npd for engineers
6.1.2 oBJecTiveS anD ScoPe of PRoJecTS
Project management suggests that deliverables should be well defined. These deliverables are always used by another actor and sometimes the same actors; the latter occurs when, for example, the product development is done by the same departments that are going to produce it. For this purpose, it is necessary to elicit the requirements for the deliverables from the users or customers. Because projects are based on a degree of uncer- tainty, about markets, technology, or other factors, the requirements can only be clarified during successive stages. This implies that, for projects with a high degree of uncertainty, there will be a prolonged time during which the deliverables cannot be fully defined; in the case of innovation, these projects can be classified as both radical and architectural innova- tion (see Figure 1.2). In the case of incremental and modular innovation, initial specifications of new products, services, and processes are easier to draft and contain fewer uncertainties. Thus, the degree of uncertainty about the deliverables also depends on the novelty of the product and ser- vice (normally expressed in terms of radical, architectural, modular, and incremental innovation).
The specification of the deliverables also implies that these are trans- ferred to receiving actors at the end of the project. These actors could be customers, internal production departments, external suppliers, logistics, and sales, for example. This transfer from new product development to production is called ramp-up, from new product and service development to sales new product or new service introduction, and from design and engineering to customers commissioning. During this transfer, all kinds of unexpected problems might occur due to alignment of the delivera- bles with operational processes of the receiving party. Vandevelde and Van Dierdonck (2003, p. 1343) find that both a formalized approach for this transition and empathy from design to engineering facilitate smoother production start-up and improve the performance of new product develop- ment projects, albeit that their study is limited to the automotive industry. Similarly, Schuh et al. (2005, p. 407) claim that the use of permanent or project-specific launch teams in the automotive industry (often a launch manager position) seems to improve ramp-up time, costs, and quality. Furthermore, in the past, Leonard–Barton (1988) has pointed out that adaptation cycles that assess aberrations during manufacturing on their implications for product and process design and strategy might be a necessity for integrating product design and engineering and manufac- turing; please note that this corresponds to the echelons of feedback in Figure 2.5. In addition, Tyre and Orlikowski (1993) have pointed out that periods of freezing and unfreezing might be an effective mechanism for
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
project MAnAgeMent (for innovAtion) • 183
the implementation of changes. This implies that secondary engineering processes are necessary, see Figure 2.5; at the start of a project, it is nec- essary to define whether these are part of the scope of the project or are identified as additional work in the contract with preset arrangements on how to deal with these changes.
The transition of the deliverables to a receiving party also implies that projects can be described in terms of having a narrow scope or broad scope; see Figure 6.4. A project with a narrow scope only focuses on deliv- erables, no matter how they are used by the receiving party or actors. This also means that in the case of a narrow scope that the project ends as soon as the deliverables have been commissioned. A broader scope for a proj- ect involves activities for the start-up and transfer of deliverables, docu- mentation, training, and knowledge to those that are going to work with the deliverables. Within an organization, even if outsourced, this concerns the production or operations department, logistics and distribution depart- ments, and sales departments. The inclusion of these internal stakeholders in the project increases the deliverables of the project, thus making the project more complex, but will be beneficial for the use of the deliver- ables in recurrent processes. Besides, for the external stakeholders, the deliverables could also be extended to documentation and training for use (utilization), maintenance and overhaul, disposal, and recycling; see the reference model in Figure 2.5. This means that somehow the perspective of the customers should be involved; see Section 4.2. It implies that proj- ects with a broad scope have more and diverse activities than those with a narrow scope; however, such a broad scope may be beneficial for use later.
In terms of deliverables, scope creep (aka requirement creep and fea- ture creep) refers to how a project’s requirements tend to increase during a project. For example, what once started out as a single deliverable could
Figure 6.4. Scope of projects.
Problem situation Deliverables
Ad-Hoc Operations
Project with broad scope
Project with narrow scope
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
184 • innovAtion MAnAgeMent And npd for engineers
have become three. Or, midway through a project, the views of custom- ers change, prompting a reassessment of the project requirements. Scope creep is typically caused by key project stakeholders changing require- ments or sometimes by differing perspectives resulting from internal miscommunication and disagreements about the objectives and merits of projects. While it might result in delays, hurdles to overcome, or going over budget, scope creep is not necessarily to be avoided. A project is sub- ject to progressive insight, and this may change the views of stakeholders, particularly the customer or (end) user. Because of these changing views, more insight into details of deliverables and more clarity about the impact of deliverables on use, maintenance, and so on, delivering a project that answers their expectations often means altering the scope. Thus, scope creep is a reality that every project plan should cater to.
6.1.3 fuzzy fRonT enD of DeveloPmenT anD innovaTion
In new product and service development, the initial phases of the project are called the fuzzy front end; these initial phases are also sometimes described as the front end, phase 0, stage 0, or pre-project activities. This fuzzy front end is the starting point in which opportunities are iden- tified and concepts are developed prior to entering the formal product or service development process. Innovation on the front end is where exciting breakthroughs are created through a process that allows for creativity and value creation in a systematic manner different from the formal development process. In this front end, idea genesis, opportunity validation, and concept development are dynamic and consist of adap- tive interactions between involved participants with a variety of views and varied skills. These actors create, evaluate, analyze, and iterate many alternatives and external technologies into potential breakthrough opportunities. The final result of the front end is a product concept, including potential external technology partners, conceptual business model, preliminary product specifications, the formation of stakeholders support, a startup action plan, and go/no go milestones for inclusion in to the formal development process.
As can be seen from Figure 6.4, the front end of a project is a more chaotic process (ad-hoc) than the execution of the project itself. This fuzzy front end is not a standard linear process as in formal development that is directed toward turning a concept into reality. The concept validation, also called proof-of-concept, marks the conclusion of the fuzzy front end; after this stage, the formal product, service, or process development process
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
project MAnAgeMent (for innovAtion) • 185
starts. Despite it being viewed as critical, many firms also seem to have great difficulties managing the fuzzy front end. The fuzzy front end brings together ill-structured information from different sources, knowledge about technologies, capabilities of resources and markets, and views from departments and stakeholders under considerable uncertainty and equiv- ocality of the outcomes. In addition, this phase is also often ill-defined and characterized by ad-hoc decision making in many firms. The non- sequential activities are due to the nature of discovery and inspiration that come from new input being injected into the analysis process that in turn triggers re-evaluation of prior points of departure and assumptions. The analysis must run its course as all points of assumptions are validated, and if necessary, modified until the relevant participants are jointly satisfied that they have an optimum result that is ready to move forward conceptu- ally or the concept is rejected and no further action is taken.
Although incurring lesser expenses than later phases of product and service development, the fuzzy front end is vital; it is the point where decisions to invest resources for new product and service development are fundamentally made. There are five generic activities taking place during the fuzzy front end:
• Preliminary analysis, which includes aggregated market develop- ments, technological developments, and assessments of industrial sectors. This preliminary analysis is not just market research, as the latter is more focused on investigating market size and (specific) market segments.
• Demand refinement, which covers customer discovery, voice of the customer, and other related research. These activities are aiming at eliciting initial requirements.
• Technology development, which encompasses includes locating emerging and pacing technologies (see Subsection 5.1.3), whether externally or internally being developed, and testing feasible product and service concepts. This step can be achieved via early customer feedback, individually or through focus groups (see Table 4.1 for more detail on involving customers).
• Proof-of-concept, which includes building prototypes and perform- ing continued research in related domains, designed to demonstrate a key aspect of a novel technology.
• Portfolio analysis, which involves examination of each potential innovation against criteria. The purpose of this analysis is to priori- tize potential innovations (see also Section 3.5) and raise questions designed to increase understanding of potential product and service concepts.
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
186 • innovAtion MAnAgeMent And npd for engineers
The activities are often not done in any order, which depends on iteration caused by discovery through these steps and evaluation of opportunities for new product and service development.
6.2 stAge-gAte ModeLs
Typically, projects consist of phases and gates; sometimes, gates go by the name of milestones. The review that takes place at a so-called gate serves two purposes. The first purpose is to ascertain what has been accomplished in the past period since a previous review (or start of the project). Princi- pally, the activities preceding the gate should have reduced the uncertainty about the product or service concept, the feasibility of the technology, and the conditions for market acceptance. The second purpose of the review is to review the feasibility of the scope of the project. For projects with a narrow scope, this part of the review is limited to the deliverables. For projects with a broader scope, it includes how the deliverables can be used by the receiving organization and how the transfer will take place. The progressive insight during review in the stages should lead to changes in the activities during the next stage; these stages or phases are bundles of activities that should lead to further reduction of uncertainty, in addition to progression in developing the product or service.
For new product, service, and process development, some stage-gate models have been developed. A model, based on project management and similar to Cooper’s (1994, p. 5) description for new product development, is found in Figure 6.5. The project starts with a feasibility study resulting in a concept that is developed during the next phase. When the development is complete, a pilot or test phase takes place followed by a product or ser- vice launch or commissioning. Finally, the deliverable of the product is taken to manufacturing or deployed. Each of these stages are separated by gates in which the reviews take place. These reviews could result in continuation,
Figure 6.5. Stage-gate model for new product, service, or process development.
Feasibility study
Development phase
Pilot/Test phase
Launch/ commissioning
phase Manufacturing/
deployment phase
Gate
Gate
Gate
Gate
Gate
Fuzzy front end
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
project MAnAgeMent (for innovAtion) • 187
change of scope or termination of the project; the early gates are directed at the business case, whereas later gates are more directed at the usability of the deliverables. The German guidelines for new product development (VDI 2211, 1993) follow similar phases, though more directed at engineering pro- cesses; see Figure 6.6. It also includes the feedback from next stages and feed- forward from previous stages to depict the iterative nature of development, design, and engineering (see Dekkers [2017, pp. 152–61] for a more detailed description of feedforward and feedback). The life-cycle model of ten Haaf et al. (2002, pp. 166–312) has seven phases, as depicted in Figure 6.7, cover- ing the scanning of market needs and demands to the disposal or renovation of products; it extends the feedback to the use and disposal of the product
Figure 6.6. Stage-gate model for new product, service, or process development (adapted from VDI 2221).
Product planning/ Project scope
Elicitation of requirements and constraints
Specifications
Determining functions and architecture
Searching principle solutions and integration
Product/Service architecture
Conceptual design
Design of modules and interfaces
Detailing of critical modules and components
Pre-design
Detailing of pre-design, components and parts
Detailing for production planning and use
Pre-design
Documentation
Detailed design
Operations/Deployment
Pr oj
ec t p
la n
(F uz
zy fr
on t e
nd )
C on
ce pt
ua liz
at io
n
D es
ig n
an d
en gi
ne er
in g
D et
ai le
d en
gi ne
er in
g
It er
at iv
e cy
cl es
fo r
fe as
ib ili
ty o
f d es
ig n
an d
pe rf
or m
an ce
tr ad
e- of
fs
Figure 6.7. Life-cycle model for new product, service, or process development.
Eliciting customers’ and stakeholders’ requirements
Developing product
requirements plan
Developing conceptual
design
Developing product design
Manufacturing Commissioning, Deployment, Management/
Adm.
Terminating deployment, Renovating
or Discarding
GFEDCBA
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
188 • innovAtion MAnAgeMent And npd for engineers
or service. The innovation process within this life-cycle concept consists of phases A through E. The organization has several drivers to perform research and a scan of the environment to find out what the market needs, now and in the future. Input can come from stakeholders (customers, producers and sup- pliers, governments), organizational processes, and characteristics from the system. During the next phase, these market needs and requirements are trans- lated into functional requirements for the system to be developed. The func- tional criteria result in the generation of alternative system concepts followed by an evaluation to find the most suitable concept. Typically, phases A to C are not a linear process, but consist of iterative activities. During the final phase of development, the construction of the product takes place during phase D. The subsequent phases F to G provide information about design requirements with respect to usage, maintenance, and disposal. These three models, few of the available ones, exemplify the stages and gates commonly found in models for new product, service, and process development.
The stages do not have to be positioned subsequent to each other; in what is known as concurrent engineering (aka simultaneous engineering), the different stages for new product, service, and process development overlap (see Subsection 2.4.6 and Figure 2.14). This requires that a team- work approach is used, with all functions involved in the project working at the same time. Thus, concurrent engineering is a method of designing and developing products, in which the different stages run simultaneously, rather than consecutively. Employing this approach to development has advantages in comparison with the traditional sequential method:
• The new product or service is brought to the market much more quickly. This increases the chances that a firm can charge a pre- mium price that will give a better profit margin; this will help recouping costs for development faster.
• There is less likelihood that the product or service will have to be modified later due to unforeseen problems. All functions downstream in the project have the possibility to integrate their knowledge in the development process; this is supposed to reduce problems for fitting the products and services in the recurrent oper- ations, logistics, and sales processes.
• The involvement across business functions improves staff commit- ment to the project.
This approach can, therefore, contribute to competitive advantage (first- mover advantage) for the firm if it can get a reliable new product or service into the market and build brand loyalty before its competitors can.
Another method linked to the staging of processes for new product, service, and process development is the controlled convergence method, aka set-based concurrent engineering. Whereas the models in Figures 6.5 to 6.7
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
project MAnAgeMent (for innovAtion) • 189
take one specific design as point of departure, Pugh’s controlled conver- gence method (see Subsection 2.4.4) is based on the subsequent narrowing down of alternatives to a selected design; see Figure 2.13 for its symbolic overview. Different from the stage-gate models in the beginning of this sub- section, at the end of each stage progress of concepts and design are set off against criteria and requirements; with progressive insight, these criteria become more detailed, too. The advantage of this method is that it avoids an early selection of a specific design or concept, which could lead to a lock-in; the focus on only one concept early on leaves no alternative when the feasi- bility is less than expected, and it could cause problems downstream in new product and service development. The disadvantage of the controlled con- vergence method is that, during early stages of product design and engineer- ing, more parallel projects run in parallel, drawing on resources. For part, this can be circumvented by concentrating on essential specific challenges for each concept, rather than trying to do everything for all concepts.
6.3 WorK breAKdoWn structure
In addition to phasing the development of processes, products, and ser- vices, often at the start of a project, a so-called work breakdown structure is created. A work breakdown structure (mostly known by its acronym WBS), in project management and systems engineering, is normally a deliverable-oriented decomposition of a project into smaller components; the term decomposition follows the term from systems theories (Dekkers 2017, p. 50). The Project Management Institute (2000, pp. 57–61) describes the work breakdown structure as a hierarchical decomposition of the total scope of work to be carried to accomplish the project objectives and create the required deliverables. An element of the work breakdown structure element may be a product, data, service, or any combination thereof. For each element of the work breakdown structure a description of the task to be performed is generated. The work breakdown structure can also serve as the necessary framework for detailed cost estimating and control along with providing guidance for schedule development and control. To this pur- pose, a work breakdown structure permits summing of subordinate costs for tasks, materials, and so on, into their successively higher level parent tasks, materials, and so on. In addition to its function in cost accounting, the work breakdown structure also supports mapping requirements from one level of system specification to another, for example, a requirements cross-reference matrix that interrelates functional requirements to high- or low-level design documents. Thus, the work breakdown structure reflects the total scope of a project by decomposing it into smaller components, so that the activities within the project can be controlled and managed.
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
190 • innovAtion MAnAgeMent And npd for engineers
Because the work breakdown structure plays a central role in the devel- opment of control and managerial structures for a project, a well- designed structure makes it easy to assign each project activity to one and only one terminal element. The development of the work breakdown structure nor- mally occurs at the start of a project and precedes detailed project and task planning. There are several ways for constructing this structure:
• Based on the deliverables. This structure focuses on a decompo- sition of deliverables into smaller work packages that constitute a lower level of detail. This is the most common method. See Figure 6.8a for a work breakdown structure for a bicycle.
Figure 6.8b. Work breakdown structure for information system based on decomposition of phases.
Shifting syst. 1.5
Frame set 1.1
Wheels 1.3
Braking syst. 1.4
Crank set 1.2
Frame 1.1.1
Handle bar 1.1.2
Front wheel 1.3.1
Rear wheel 1.3.2
Bicycle 1
Preliminary concept 1.6.1
Design structure
1.6.2
Integration 1.6
Widget management system 1
Close-out 1.5
Initiation 1.1
Execution 1.3
Control 1.4
Planning 1.2
Evaluation & conclusions
1.1.1
Project charter 1.1.2
Preliminary scope stat.
1.2.1
Determine project team
1.2.2
Kick-off meeting
1.3.1
User requirements
1.3.2
Project management
1.4.1
Project meetings
1.4.2
Audit procurement
1.5.1
Lessons learned
1.5.2
(a)
(b)
Figure 6.8a. Work breakdown structure for a bicycle based on decomposition of deliverables.
Shifting syst. 1.5
Frame set 1.1
Wheels 1.3
Braking syst. 1.4
Crank set 1.2
Frame 1.1.1
Handle bar 1.1.2
Front wheel 1.3.1
Rear wheel 1.3.2
Bicycle 1
Preliminary concept 1.6.1
Design structure
1.6.2
Integration 1.6
Widget management system 1
Close-out 1.5
Initiation 1.1
Execution 1.3
Control 1.4
Planning 1.2
Evaluation & conclusions
1.1.1
Project charter 1.1.2
Preliminary scope stat.
1.2.1
Determine project team
1.2.2
Kick-off meeting
1.3.1
User requirements
1.3.2
Project management
1.4.1
Project meetings
1.4.2
Audit procurement
1.5.1
Lessons learned
1.5.2
(a)
(b)
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
project MAnAgeMent (for innovAtion) • 191
• Based on the processes for new product and service development. This type of structure follows mainly the phases of development, design, and engineering as discussed in the previous section of this chapter. See Figure 6.8b for the work breakdown structure aiming development of an information system.
• Based on functions in an organization. Such a structure of the work breakdown structure can be used when the disciplines for a product or service are relatively independent and the processes for design and engineering have been standardized.
These work breakdown structures are consisting of several levels, each providing more detail than the next higher one; normally, these work breakdown structures are numbered so that these levels are easily distinguished.
Despite the work breakdown structure being a key element of project management, it does not solve all issues for controlling and managing projects; the main reasons for this are:
• It is not an exhaustive list of work and activities in a project. It is instead only a comprehensive classification of the scope of a project.
• It is neither a project plan nor a schedule nor a chronological listing. It only specifies what will be done, not how or when.
• It is not an organizational hierarchy, although it may be used when assigning responsibilities.
Thus, the construction of an appropriate work breakdown structure plays a central role in the planning of a project, but is only one of the steps for its control and management.
6.4 pLAnning And scheduLing of projects
The need for control of any project, including those for new process, product, and service development, arises from ensuring the scope of the project, assuring the quality of the deliverables so that they can be used, and meeting the constraints in time (deadline) and costing (budget). The deadline of a project and the constraint by a budget are related to the scope of a project. This means that the scope and deliverables deter- mine which activities and related resources are necessary to accomplish the project; these activities and the availability of resources determine the planning of activities, the use of resources, and the budget for the project. Thus, when constraints restrict the execution of a project, the
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
192 • innovAtion MAnAgeMent And npd for engineers
only way is to reduce the scope of a project. Conversely, when the scope is defined, the resources must be available to achieve the deliv- erables, which may imply that the constraints need to be relaxed. These so-called trade-offs are depicted in Figure 6.9; in reality, these trade- offs are difficult to make. Sometimes, it may be an option to stage the deliverables, meaning not all deliverables are available at the same time. Although this means relaxing the constraint of time, it allows the receiving party of the deliverables already to generate revenues before other deliverables are realized. Furthermore, to meet the constraints, often, it is suggested that the quality of the deliverables may be traded off against time and cost; however, this will reduce the viability of a project. Take for example the development of a car. If the quality is less than required, this would reduce the competitiveness of the car, increase the cost of production, and increase the cost of warranties. In this sense, often the quality of the deliverables should be assured to avoid problems downstream, which make the project less feasible. In a similar vein, the use of resources with reduced capabilities may also result in similar problems. Thus, the realistic trade-offs for projects concern the scope against the constraints of deadline and budget, in which resources with their capabilities play a central role to achieve the purpose of the deliverables.
6.4.1 eSTimaTing
To make a realistic planning for a project and compile a budget, the esti- mation of how many resources are needed is key. This estimating of how much time is needed can be based on the components of the work break- down structure. There are several methods for estimating:
Figure 6.9. Trade-off for projects, between scope, time, and cost.
Scope
CostTime
Resources
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
project MAnAgeMent (for innovAtion) • 193
• Standard times. These times are based on time and motion stud- ies, which set out how long each task will take in detail. Although originally based on production techniques (notably by Frederick Taylor for scientific management and Frank and Lillian Gilbreth for motion studies), this approach to determining standard times applies to process, product, and service development, too. For example, the time it takes for an engineer to fill out forms or to write specific documentation, such as for maintenance.
• Parameterization. In this technique, the deliverables are described in parameters; these parameters serve as the base for estimating the workload. For instance, the number of code lines that have to be written determines the budget for programming of code.
• Use of historical data. In the case of this technique, the data used for a new project is derived from data of previous projects. This implies that an accurate record is kept not only about the budgets, but also the actual expenditures and hours that were needed to com- plete preceding projects. Note the parallel with case-based reason- ing for its potential drawbacks (see Subsection 2.4.3).
• Three-point estimation. This method uses three estimations for a weighted average. The first estimate is an optimistic one, the sec- ond one a realistic one, and the third one a pessimistic one; these three are weighted for an average, with usually the realistic one receiving a weight of four.
• Expert judgment. In this case, the estimation of hours and workload is put forward by experts. It depends heavily on their experience and the description of the activities put in front of them; the lesser the accuracy of these descriptions, the more erratic the judgment by experts might be.
• Guessing. Not least, guessing is used also. Certainly, when the activities have a high degree of novelty, this may be the only resort for estimating the hours and the duration of activities in projects.
These methods for estimation were presented in order of decreasing accuracy and reliability. Within a project, these may be used in combi- nation. This could be for the purpose of so-called tri-angulation; by using different methods for estimating the efforts for activities, the reliability can be increased. Or, it could be that, for some activities, accurate data is available, whereas for others, the degree of novelty limits the use of available data and experience. In any case, estimates are necessary to find out how much of each resource is needed to for a project and what the approximate duration of activities will be.
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
194 • innovAtion MAnAgeMent And npd for engineers
6.4.2 PRoJecT Planning
Based on the estimates of hours for resources and duration of activities, the project can be scheduled. Traditional project planning and execution has been marked by the definition of objectives and milestones based on activities to achieve them. Thus, these goals are met through a progression of networked activities, some of which must be performed sequentially, others of which may be conducted in parallel. Planning techniques, such as the program evaluation and review technique (PERT), graphical evalu- ation and review technique (GERT), and critical path method (CPM), are used to support this sequencing of tasks and activities in a project; note that these methods are mostly known by their abbreviations. The first two are instances of so-called activity-in-node diagrams, and the third one an activity-on-arrow diagram. There are different versions of these planning techniques, but their purpose and use is similar.
The critical path method, an activity-on-arrow planning method, is taken as an example. To use this method, in fact, any method, first, a dependency table needs to be created, see Table 6.2. This table lists which activities are preceded by other activities and which activities follow a specific activity. For example, activity D is preceded by Start and suc- ceeded by activities E and J; the duration of activity D is five units. Next, a diagram can be drawn, see Figure 6.10. Because this method is a so-called activity-on-arrow, the label of the activities is found above the arrow and between parentheses the duration (alternatively, the duration can be put below the arrow). A node represents a milestone in which at least one activity precedes it and one succeeds it; except the node for the start and the finish of the project, of course. As a next step, first, the earliest start
Activity Preceded by Succeeded by Duration A Start B 7 B A C 5 C B H 3 D Start E, J 5 E D G 8 G E H 6 H C, G Finish 3 J D K 4 K J Finish 3
Table 6.2. Precedence table for planning
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
project MAnAgeMent (for innovAtion) • 195
dates are calculated for each activity. For instance, activity C can start earliest at 12 units of time. In nodes where several paths of activities come together, the longest path is taken as the start for the activity after the node. After calculating all earliest start dates and the finish of the project by calculating forward, the latest start date is calculated. This is done in the reverse way, starting with the activities at the Finish first; this is also backward pass calculating. Taking activity C again, the latest start date is 16 units. The difference between the earliest and latest start date is called slack or float; for activity C, the slack is four units. All these calculations are made to find the critical path; the critical path is defined as the activ- ities that have no slack. In other words, the critical path defines those activities that, if they are delayed, will also cause delays for the deadline of the deliverables. Therefore, the critical path method and other planning techniques aim at identifying those activities that have no slack and may cause delays for the project.
This means that the focus of monitoring the schedule of a project aims at keeping an eye on these critical activities in the first place; however, limiting the monitoring to the critical path is not sufficient to adhere to schedules and deadlines. First, it should be noted that, whereas the critical path reflects the activities that might cause delay for the completion of the project, neglecting the other activities may also results in not making the deadline. If the activities that are not on the critical path are not monitored, eventually, they may become part of the critical path. Second, these meth- ods for network planning do not account for the availability and capacity of the resources. Therefore, network planning needs to be complemented with resource allocation to verify the availability of resources and their utilization; if this utilization exceeds 100 percent, then the project needs to be rescheduled to fit with the capacity of the resources; this could mean delaying activities to level the resource utilization. Third, a project needs a detailed structure for managing activities. This means that, when activ- ities are delayed or when resource utilization exceeds the availability,
Figure 6.10. Simplified example of critical path method.
S 0 0
I 7 11
A (7)
II 5 5 V 9
14
IV 13 13
III 12 16
VI 19 19
F 22 22
B (5) C (3)
D (5)
E (8)
G (6)
J (4)
K (8)
H (3)
VI 19 19Node Earliest start date
Latest start date
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
196 • innovAtion MAnAgeMent And npd for engineers
interventions should be at hand and be considered. These interventions could range from rescheduling to allocating additional resources to rede- signing activities. Thus, monitoring and controlling the schedule relies on balancing the monitoring of activities on the critical path and the other activities, feasible resource allocation, and appropriate control and inter- vention in activities.
Figure 6.11 presents such an approach to monitoring and intervening (taken from the steady-state model in Dekkers [2017, p. 188]); this model details the activities that are necessary to ensure that an activity is on track. The core of this model is the transformation process (the activity in a proj- ect). For this process, coding and encoding is necessary; this means that information for an activity should be presented in such a way that it can be used by the resources undertaking this activity. Examples are providing an adequate, coherent description what is needed, such as a specification, and clear statements about what the output is, drawings, and user documen- tation, and so on. When the activity does not yield the expected quality of the output, the deficiencies need to be addressed or it needs to be done again (e.g., a test). The feedforward control mechanism on the left ensures that, in case of deviations in the input, the resources are adjusted or the process is changed to fit with the input. The feedback mechanism monitors progress and intervenes when completion dates are not going to be made (overtime, additional resources, etc.). There is also feedback as evaluation for the total project planning. If for some reason the original planning is not realistic anymore, a new project schedule needs to be issued (the ini- tiating process). In the case that the project will not be on track anymore, the stakeholders need to be informed (capability of process). It may also be that the information from the stakeholders is received that the deadline for the project has changed; for example, the deadline is pulled forward, which will result in a new overall project planning and the use of addi- tional resources. Thus, the monitoring of a project depends not only on controlling the critical activities, but also on not neglecting the non-crit- ical activities, and having a structure for monitoring and intervention in place, as demonstrated by the steady-state model.
6.4.3 BuDgeTing
Using the estimates for resource allocation and planning, a budget for a project can be prepared. Such budgets are also related to the scope of a project (see Subsection 6.1.2). In the case of a narrow scope, the inter- actions with the receiving party of the deliverables—in most cases to be seen as a customer, whether external or internal—are restricted to the
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
project MAnAgeMent (for innovAtion) • 197
Fi gu
re 6
.1 1.
G en
er ic
m od
el fo
r t he
m on
ito rin
g of
p la
nn in
g an
d bu
dg et
in g
of p
ro je
ct s.
In pu
t (fl
ow in
g el
em en
ts )
O ut
pu t
In pu
t b ou
nd ar
y zo
ne
O ut
pu t
bo un
da ry
zo ne
R eg
ul at
or y
bo un
da ry
z on
e
(E xt
er na
l) St
an da
rd s
En co
di ng
Ev al
ua tin
g A
be rr
at io
ns
(I nt
er na
l) st
an da
rd s
Measurement
In fo
rm at
io n
fr om
en vi
ro nm
en t
C ap
ab ili
ty of
p ro
ce ss
R eg
ul at
in g
C om
pa ri
ng C
om pa
ri ng
M ea
su ri
ng M
ea su
ri ng
In te
rv en
in g In ve
rs io
n of
pr oc
es s
C om
pl et
in g
de fic
ie nc
ie s
D ec
od in
g Pr
oc es
s
(I nt
er na
l) st
an da
rd s
In iti
at in
g Le
ge nd
Fl ow
o f i
nf or
m at
io n
Fl ow
in g
el em
en ts
fo
r pr
im ar
y pr
oc es
s
Q ua
lit y
fil te
r
Bu ffe
r (in
ve nt
or y)
O ve
rf lo
w (v
al ve
)
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
198 • innovAtion MAnAgeMent And npd for engineers
specifications of the process, product, or service that is developed and the progression against planning; the latter could be time and cost. It may involve the development of manuals and training for operators in recurrent processes. In the case of a broader scope, stakeholder management is part of the project and also management of interfaces with functions or other projects. For instance, the conversion of a production machine in a paper mill to deliver smaller batches of specialized paper requires interaction with the logistics department for the supply of materials and distribution of orders to customers. An example of the interaction with other projects is the case of a clean room facility in a new plant for pharmaceuticals; cleanroom facilities are often supplied by specialized suppliers, but have to be integrated in the design and construction of the plant. Thus, insight is needed beyond the deliverables about the expectations of a project for the development of processes, products, and services to adequately plan all necessary activities.
In addition to identifying all necessary activities, because there is some degree of uncertainty and possibly there are iterations, the basic activities need to be complemented with milestones and foreseen deci- sions. This is necessary because these milestones have implications for activities and resource allocations. Take for example, a company using the controlled convergence method (see Subsection 2.4.4) for a product devel- opment project; this company is developing two alternative concepts. In the spirit of this method, only when the design of both concepts has been completed, a decision will be taken how to go ahead. However, whether the company decides for one concept or the other, the implications for activities, resource allocation, and budgeting are known beforehand. For this reason, the budget (and also the planning preferably) should account for the differences between the most expensive option and least expen- sive option. Once an option is chosen with lesser impact on planning and budget, the budget allocation for the project can be reduced to reflect the decision taken. This means that budgets and planning are dynamic during the execution of a project, and these decisions can be foreseen and planned.
Furthermore, risks and contingencies need to be incorporated into a budget. First, each estimation for resource allocation to specific activi- ties has a degree of uncertainty. This also covers the impact of interfaces, though such also depends on the contractual arrangements. Second, each project has risks (see Section 6.5); not all risks can be foreseen, but a budget needs to allow some degree of flexibility to cater for these. Third, each project encounters unforeseen circumstances. These three aspects of risks and contingencies—variability due to estimation, countermeasures for risks, and unforeseen circumstances—lead to posts in a budget that may have to be used or may not; such depends on the monitoring.
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
project MAnAgeMent (for innovAtion) • 199
Based on the resource allocation, the impact of milestones and foreseen decisions, and identification of the risks (see Section 6.5) and contingencies, the budget for a project can be prepared. How from these components a budget for a project is built is shown in Table 6.3 for an example; this example is for the extension of a house by building a conser- vatory. In this case, the budget is drafted by the home owners in advance of allocating the contract to a builder, though they have asked two build- ers to submit a proposal and cost estimate. As can be seen, two types of contingencies have been included in the budget. The first is that, depend- ing on the ground conditions, a foundation wall may be needed; during the early stages of the project, these conditions can be investigated, and depending on the outcome, this wall may be necessary. The second contin- gency is a generic one, catering for all costs being estimates. This example shows that contingencies may constitute a substantial portion of a budget; therefore, these milestones and foreseen decisions, the identification of the risks, and the inclusion contingencies should be identified as soon as possible in the budget of a project.
Akin the points for monitoring planning, the managing and monitor- ing of budgets is particularly focused on those items in the budget that have considerable impact caused by progressive insight and iterative steps inherent to projects. The monitoring can be based on the same processes as for planning, see Figure 6.11. However, interventions in the budget
Post Expenditures Labor (hrs.)
Materials (£)
Costs (£)
Concrete footing and dwarf wall 75 2,000 3,000 Edwardian luxury conservatory (5 × 2 meters)
150 4,000 10,000
One radiator supplied and fitted 6 250 490 10 m2 of Roman roof blinds 12 1,500 1,980 12 m of Venetian window blinds 16 1,200 2,040 Suite of cane furniture 1,000 Plants and pots 450 Contingencies Foundation wall (ground conditions) 80 1,000 4,200 Generic contingency 2,000 Total 339 10,450 25,160
Table 6.3. Budget for Edwardian conservatory (extension of house)
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
200 • innovAtion MAnAgeMent And npd for engineers
may also have an impact on the planning and scheduling. For example, if the owners in the example decide to use second-hand bricks for the dwarf wall, these might have to be delivered by a supplier further afield, thus affecting the planning (and possibly the hours for masonry). Similar to scheduling, there is the need for balancing critical expenditures (those expenditures that can easily impact the budget), feasible allocation and utilization of resources, and the impact of intervention in activities when they need to be adjusted to attain the deliverables.
6.4.4 STePS foR Planning anD ScheDuling conSTRainTS
So far, the development of a project plan has not looked at constraints in time and costs, which is inherent to projects. Thus, it is often the case that the ideal planning and budgeting are subject to modifications for meet- ing these constraints for deadlines and budgets. Figure 6.9 shows these trade-offs to be made during the preparation of a project plan. However, such decisions only become possible when there is insight derived from a first, coarse estimation, or there is experience and learning from pre- vious projects; the latter could be based on case-based reasoning (see Subsection 2.4.3). Common options for meeting constraints are (i) relax- ing the budget if the deadline is more important, (ii) extending the dead- line, (iii) reducing the scope, which implies somehow that the deliverables are changed, and (iv) phasing the deliverables so that the implications of the budget are spread over a longer time span. The latter is illustrated in Box 6.1 for the Edinburgh Tram project. However, such phasing of deliv- erables also may lead to the initial stages being less feasible on their own. Looking at the Edinburgh Tram project, the delivery of just one phase did result in less passengers using the tram, even though numbers for this specific traject were slightly higher than expected. This means that any of these four decisions to meet constraints results in a trade-off between scope, time, and cost always, which consequently leads to less optimal solutions being delivered by the project.
A particular place technique for meeting deadlines is the so-called crashing of a project. This approach is put into action when the deadline is so tight that only through using the shortest timeline the project can be realized. In this case, the activities are re-organized so that, principally, all activities are on a critical path. Looking at Figure 6.10, this means that not only the paths D, G, E, G, and H are critical, but also these activities need to redesigned and re-allocated to reduce their lead time. This rethinking
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
project MAnAgeMent (for innovAtion) • 201
of activities causes more activities in the project to be on a critical path. In this case, the lead-time of D is reduced by 1 unit, E by 2 units, and G by 1 unit; consequently, not only the overall lead-time of the project is shorter, but also activities A, B, and C are now on the critical path. However, this approach has implications for budget, is sensitive to per- turbations, and may lead to poor quality. Looking at the reworked exam- ple in Figure 6.12, the shortening of the activities can only be possible when the activities A, B, and C use different resources than the activities D, E, G, and H. Furthermore, it should be possible to allocate additional resources to activities D, E, G, and H; this could be achieved through overtime or hiring additional resources. Assuming that the original allo- cation was optimal from a cost perspective, the options for shortening the
Figure 6.12. Crashing of project using example of Figure 6.10.
S 0 0
I 7 7
A (7)
II 4 4
V 8 10
IV 10 10
III 12 12
VI 15 15
F 18 18
B (5) C (3)
D (4)
E (6)
G (5)
J (4)
K (8)
H (3)
The project for the Edinburg Tram is an example of the trade-offs to be made when preparing a plan for a project. Initially, the project costs spiraled out of hand as widely reported in the media. To counter these effects, Phase 1a was only implemented. Currently (at the time of this writing), the Council of Edinburgh is considering to extend the tramline with Phase 1b.
Box 6.1. Edinburgh Tram
Source: https://upload.wikimedia.org/wikipedia/commons/thumb/2/21/ Edinburgh_tramway_map.svg/800px-Edinburgh_tramway_map.svg.png. [Downloaded: April 23, 2017]
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
202 • innovAtion MAnAgeMent And npd for engineers
activities will lead to an increase in the budget. Moreover, there are now two critical paths. Any disturbance on any of these pathways will lead to a delay of the project. This also means that a project manager has to monitor two paths more intensely for repercussions when delays happen; therefore, implicitly, the crashing of a project also increases the workload of a project manager. Because of the increased workload and the pressure to be in-time, the chances of poor quality for the deliverable of one activity that is the input for another activity increase, too. Again, this increases the chances of deviations from the planned work and requires additional monitoring by the project manager. In addition to these points of attention for monitoring, note that crashing a project requires a totally different style of managing a project. Although possible trade-offs should highlight areas of concern, crashing projects can be both beneficial in terms of realizing the earliest possible date for completing a project, it may also have det- rimental effects because of the pressure to complete, rather than passing on deliverables that are appropriate for the next activity (or activities) in addition to the impact on budget and monitoring.
The constraints in budgets are generally more difficult to resolve than those of planning. For instance, resources have often unique capa- bilities, and therefore, comparisons rely on tacit knowledge. A case in point was the sourcing of suppliers for the Boeing 787 Dreamliner (see Dekkers et al. 2013, pp. 325–6). Though sparsely mentioned in news about this airplane, its delivery was delayed by the selection of suppli- ers mainly through a web application; this resulted in suppliers being awarded contracts that they were not capable of delivering, though being far less expensive than competing suppliers. The integral cost of the delay exceeded by far the cost savings in addition to damaging the reputation of Boeing. This example shows that simply having a technical approach to projects not really works. In addition to that, the cheapest may not be the best solution, because the life-cycle costing should be accounted for (see Subsections 3.1.3 and 3.1.4). An example of this is the well-known sub- way system of Singapore. In the 2010s, rolling stock and the infrastructure started to breakdown. These failures could be traced back to decisions related to the initial investment. Constraints in the budget at the time led to the buying of less-optimal equipment, which caused disruptions later for train services. Ultimately, such cost for maintenance and cost caused by disruptions during operations may exceed those of the initial expendi- tures; however, sometimes, the constraints in available budgets leave little choice. This also leads to the conclusion that resolving budgetary issues in projects need not only to consider the here-and-now, but also to include a vision of the future; if budgets do not permit to be extended, then it is
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
project MAnAgeMent (for innovAtion) • 203
better to make the impact of future risks visible so that stakeholders can review how they contribute to the project.
6.5 MAnAgeMent of uncertAinties And risKs in projects
In addition to managing the measures caused by the temporal and budget- ary constraints, uncertainties, which are inherent to projects, need to be assessed, too. Going back to what defines a project in Subsection 6.1.2, it is the unique element(s) that make every project different from a previous one; otherwise, a request for an artifact can be managed merely as a recur- rent process. These unique elements of a project could be decision points along the way or uncertainties that need to be resolved. In the case of inno- vation, the emphasis is on managing uncertainties. These uncertainties are most likely technological in nature or market-related. An example of the first is the integration of web services into artifacts (Internet of Things), and an example of the latter was the uncertainty whether the market was ready for smartphones (this was the opposite for the Apple iPhone: the underestimation of its initial demand could be observed through the well-reported shortages for phones and their components). Furthermore, the incorporation of these uncertainties in a project plan leads to decision points and pre-set responses. However, this also depends on whether a project has a narrow scope or a broad scope; in the case of a broader scope, this also extends to the stakeholders and interfaces of the project. These uncertainties should be monitored, and their effect on the project execu- tion assessed as insight progresses.
Moreover, it also possible to conduct a risk analysis at the level of a project; the ultimate goal of risk analysis to devise countermeasures. The two basic techniques for risk analysis are fault tree analysis (see Subsec- tion 2.3.4) and failure mode and effect analysis (see Subsection 2.3.5.); in the context of project management, these techniques are not only applied to the deliverables, but also the processes of the project. Often, the con- straints can be taken as a starting point. An example of fault tree anal- ysis applied to project management is the analysis of the availability of resources on meeting the deadline for a project; if the analysis is under- taken by using a project schedule and the chances that specific resources are not available is incorporated in the analysis, then resources that are potential bottlenecks can be identified. Applying the failure mode and effect analysis to the same purpose would mean using the availability of a specific source as starting point for the analysis; this could lead to the over- sight that other resources, which might cause delays, are overlooked. After
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
204 • innovAtion MAnAgeMent And npd for engineers
analyzing the risks, countermeasures should be introduced and monitoring put into place. Note that countermeasures most likely never mitigate a risk fully. Thus, risk management is not only about identifying risks, but also about risk mitigation and swift response once risks manifest themselves.
6.6 orgAnizAtion of project teAMs
With all activities, the project planning, budget, and risks mitigation deter- mined, the organizational structure of the project can be set up. When structuring projects, keep in mind that they are often embedded in existing organizational structures and working methods in organizations; however, there are pros and cons how this is organized. This means that the forma- tion of a project should be looked at from an internal perspective (project team) and external perspective (embedding of project in existing organi- zational structures).
6.6.1 STRucTuRing PRoJecT TeamS
For the structure of the project organization, advantage should be taken of the existing processes and routines in organization. This thinking goes back to Subsection 6.1.1 about the different modi operandi; although project management is effective, recurrent processes are more efficient (based on feedback that leads to optimization of processes and resources). This means that the structure of a project team can build on the strengths and capabilities of an organization. However, a project has unique features that should be facilitated by multidisciplinary working groups (or teams); these working groups vary for each project. An example is the develop- ment of a pregnancy test; see Figure 6.13. In this case, the project team consisted of the representatives of eight departments. However, two topics posed a challenge for the project, for which the regular processes for new product development were insufficient. The first one was the specifica- tions for the paper on which the urine sample would be tested; this strip would contain the reagents for detecting the pregnancy hormone (human chorionic gonadotropin) in urine. Early on in the project, it appeared that sample material was no longer available and also the specifications for the material were unknown. The second issue was assuring the quality of the reagents for detecting human chorionic gonadotropin. This reagent appeared to be of varying quality, but was critical to the performance of the diagnostic test. For both challenges, working groups were formed con- sisting of experts from relevant departments; care was taken that different
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
project MAnAgeMent (for innovAtion) • 205
representatives from each department were part of these multidisciplinary teams to stimulate independent action plans. This means that a project normally consists of representatives of departments in an organization supplemented by working groups that focus on challenges or unique features for the project execution.
6.6.2 emBeDDing PRoJecT TeamS in oRganizaTional STRucTuReS
How the project team is embedded in an organizational structure can take four forms; the first form of project organization is called departmental project management (see Figure 6.14). In this case, each department has its own project manager. This only works when each department has sep- arate projects or each project’s activities are similar to other project. The latter is the case when a project follows a standardized process. This orga- nizational structure of a project means that each department determines the what, how, and when of a project, without necessarily considering implications for other departments or the completion of the project. The company that served as example for Figure 6.13 followed this structure. This complicated new product development, because individual project leaders in departments thought they were empowered to make decisions, even with implications for other departments. A project charter at the
Figure 6.13. Project team structure for development of hCG diagnostic consumer device.
Process engineering and testing
Quality assurance
Design and engineering
Production
Laboratory hCG diagnostics
Marketing
Packaging and labeling
Purchasing
Project administration
Working group paper • Junior project manager • Lab. hCG diagnostics • Quality assurance
Working group QA antibody • Junior project manager • Experiments • Lab. hCG diagnostics • Quality assurance
Project hCG diagnostic consumer device
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
206 • innovAtion MAnAgeMent And npd for engineers
beginning of the project countered this uncoordinated decision making; this charter described how decisions were taken and how they had to be approved by project management before being implemented.
The second form for a project organization is the so-called line-staff structure; see Figure 6.15. In this case, the project manager is centrally located, but has no direct authority with regard to activities within depart- ments. This means that the project manager coordinates the project exe- cution with the heads of departments, but that the factual decisions about the what, how, and when are taking by these heads. This also requires from the project manager a certain degree of tact to align the activities in each department with the overall project plan and schedule. Again, a project charter that is agreed before a project starts can overcome such disadvantages.
The third form for a project organization is the matrix organization; see Figure 6.16. Typically, project managers are responsible for the what and when, whereas line managers have the responsibility of how activities are conducted. In some organizations, the line managers are responsible for the when. In either of these two variants, the project manager has more
Figure 6.14. Departmental project management
Department A
Department B
Department C
Project management
Manager
Project management
Project management
Figure 6.15. Line-staff structure for projects.
Department A
Department B
Department C
Project management
Manager
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
project MAnAgeMent (for innovAtion) • 207
influence on the execution of the project. However, in practice, it is more difficult to delineate the what from the how and when.
The fourth form is the pure project organization, in which projects are the core of the organizational structure; see Figure 6.17. Members of staff are allocated to specific projects. In this structure, it is often difficult for experts to identify themselves; other experts in the same domain are working in different projects, and there may be limited contact. Some companies have circumvented this by creating special interest groups or communities of practice; these groups serve as platform for experts to exchange ideas and support each other (perhaps one could also call this virtual departments). It could also be that the internal organization of a firm does not have the capabilities to deal with the project. This is the case for the Capital Programme for Amsterdam Airport Schiphol; this includes the building of a new pier and terminal to be completed by 2023. Although management and organization of Schiphol have been dealing with refurbishment and extensions, the last terminal was built 20 years before. This means that people with skills to manage such a transition have left Schiphol or retired. In combination with the scale and
Figure 6.16. Matrix structure for projects.
Department A
Department B
Department C
Project I
Manager
Project II
Project III
Pr oj
ec t
m an
ag em
en t
Figure 6.17. Pure project organization.
Project A
Project B
Project C
Manager
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
208 • innovAtion MAnAgeMent And npd for engineers
complexity of this extension, this has led to the conclusion that the only viable option is to execute the program by setting up an external entity; it is expected that this will lead to a smoother execution of the project. This means that the pure project organization can be an effective means for managing a large and complex project, though experts may need addi- tional attention.
Within project management, multidisciplinary teams have become the norm. These teams can consist of representatives from the engineering disciplines involved, marketing department, manufacturing department, logistics department, and so on. The advantages of these teams are that all relevant functions are brought together, and hence that information is shared, particularly for decision making; these multidisciplinary teams are often associated with concurrent engineering (see Subsection 2.4.6). These multidisciplinary teams are especially helpful for the unique points of a project and can complement standardized working processes.
6.7 inforMAtion And coMMunicAtion pLAns
For project teams and multidisciplinary teams, but also for departments and stakeholders that are involved in the project, sharing of information is crucial to progress. The first instance of information sharing in a proj- ect relates to technical information. This sharing of technical and product information is mostly done by using a knowledge repository in IT sys- tems. Keeping this up to date is often associated with systems engineering (Subsection 3.1.4) and can be linked to the work breakdown structure (see Section 6.3). In addition to technical information, also information about the progress of a project is shared within the project teams and multi- disciplinary teams, but also commonly with departments involved in the project. This facilitates keeping information about the scope of the project, the allocation of resources, and the actual planning and budgeting with the purpose of informing decisions in the project team and departments. Third, also with stakeholders information needs to be communicated. This differs depending on the scope of a project (Subsection 6.1.2). Projects with nar- row scope tend to focus on the customer and technical specifications. Proj- ects with a broader scope involve more relevant actors. A fourth reason for an information and communication plan can be the creation of legacy and regulatory requirements. The legacy can enable learning from proj- ects. The regulatory requirements are often specific to certain industries, such as aerospace and pharmaceuticals. Thus, information sharing and documentation concern both technical information and information about the status of the project so that the project team members can contribute
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
project MAnAgeMent (for innovAtion) • 209
to the project more effectively and efficiently, stakeholders can be better involved, learning across projects can take place, and legacy is assured.
For communicating with team members, departments, and stakehold- ers (including customers), a method that is called the RACI matrix is often used; RACI is an acronym that means responsible, accountable, consulted, and informed. It uses a matrix to align the level of responsibility with the activities to be accomplished and the roles participants play in a project or as stakeholder. The left column of the matrix lists the project deliverables that must be completed for the project to be successful; see Figure 6.18. The top row lists the functional roles that the team members have in a project. For each activity, only one of the roles, or team members, can be held accountable (A) for the completion of a deliverable and particular decisions made on the project. Multiple team members can be responsi- ble (R) to perform the work and make decisions necessary to complete a deliverable, be consulted (C) for inputs while the work is being done, and decisions are being contemplated, or be informed (I) when a deliverable is completed and a decision is made. To build the RACI matrix, it requires the team to collaborate on the overall deliverables of the project plan.
Also, for managing the stakeholders and interfaces within an organi- zation, a similar method can be used; see Figure 6.19 for the stakeholder matrix. However, this matrix aims at identifying and managing how the project contributes to the activities of a particular stakeholder; this means that the use or implementation of a deliverable has some effect and con- tributes to achieving objectives. An example is the commissioning of
Figure 6.18. RACI matrix for a project (only part of this matrix).
Functional requirements
Project manager
Functional analyst
Database specialist
Programmer
Design of system Server specifications Programming interface
R
R R
A A A A
C C
C
I
I
Figure 6.19. Stakeholder matrix for a project.
Stakeholder A
Deliverable Objective Priority When
Stakeholder B 3
•••• •••• •••• ••••
Key (1) 2
Support/Mitigation
Stakeholder C
Stakeholder i ••••
••••••••••• •••••••••
•••••••••• •••••••
•••••••••••
Key (1)
3
MM/YY MM/YY MM/YY MM/YY
MM/YY
•••••••••
••••••••• ••••••••• •••••••
•••••••••
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
210 • innovAtion MAnAgeMent And npd for engineers
manufacturing equipment. This may lead more efficient operations, which can be measured. Then, the objective of increasing efficiency will become a key priority for the manufacturing manager as stakeholder of the project, but also for the project itself. This applies particularly to projects with a broader scope. These objectives may need further support or might pose risks in which case mitigation is needed.
6.8 MAnAging projects
For new product, service, and process development projects to be successful, adequate or, some say, strong leadership is necessary. This section goes only briefly into more detail about what adequate leadership for project is and how project teams should be managed.
6.8.1 PRoJecT leaDeRShiP
From the descriptions of a project so far, it has become obvious that proj- ects require working together with team members, heads of departments, management of firms, suppliers, stakeholders, and so on; in this respect, a distinction can be made between project management and project lead- ership. Project management can often be associated with an emphasis on processes and methodologies. These managers wield authority (depend- ing on how a project is embedded in an organization; see Section 6.6.2), assign responsibility for activities to team members, and focus on (set) deliverables. Project leadership adds to project management working with team members and interacting with stakeholders. This puts the emphasis on motivating team members, shaping the project in communication with team members and stakeholders, and ensuring that the deliverables are defined in such a way that they are of benefit to all involved. To this purpose of defining the leadership style, many methods and tools are available. One is the project leadership matrix (Madsen 2016), which breaks down lead- ership into four quadrants: reactive people-leadership, reactive task man- agement, proactive people-leadership, and proactive task management. In this matrix, reactive people-leadership and proactive people-leadership are representing leaders who inspire, engage their teams, and provide a great deal of autonomy. Leadership through task management is a more authoritative, directive method and fits better with projects with a narrow scope (see Subsection 6.1.2). Proactive project leaders focus on the contri- bution and benefits of the project for stakeholders (projects with a broader scope, see Subsection 6.1.2). Project leadership that is more reactive deals with the immediate issues as they emerge during project execution. This
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
project MAnAgeMent (for innovAtion) • 211
characterization shows that possibly different leadership styles lead to different outcomes of projects, too.
6.8.2 managemenT of PRoJecT TeamS
No matter the project leadership style, team management is seen as crucial to projects. Acquiring the project team is often complicated by the fact that the project management team will not usually have direct control over whom they would like to have involved in the project. They may need to negotiate with department managers and others who are in a position to provide the right number of personnel with the appropriate level of knowledge skills and experience. This situation is very common in projects that cut across departmental boundaries. Failure to secure the necessary human resources can affect project schedules, budgets, customer satisfaction, and quality, as well as increasing the risk that the project will simply fail to deliver on time and within budget. The impact of any unavailability of required human resources needs to be considered in the planning stages of the project.
Once the project team membership is set, team roles become important; there are different approaches to this with different purposes. A well-known one is roles based on lateral thinking (de Bono 1967); his method for creativity is based on using six hats, each representing a perspective on the problem and solutions, which are often associated with participants:
• White hat: neutral information. This perspective focuses on collect- ing facts and information needed.
• Red hat: emotions and hunches. This hat entails the perspective of uncovering emotions and feelings and sharing fears, likes, dislikes, loves, and hates.
• Black hat: judging and evaluating. This angle focuses on being the devil’s advocate or why something may not work. It spots the difficulties, challenges, and failures.
• Yellow hat: optimism and positive views. This viewpoint explores the positives and probes for value and benefit.
• Green hat: ideas and creativity. This role provides possibilities, alternatives, and new ideas as an opportunity to express new concepts and new perceptions.
• Blue hat: big picture and control. This position manages the think- ing process, the generation of ideas, and their evaluation.
Another famous method for team roles has been devised by Belbin (1981); it distinguishes nine roles that contribute to a project team in a different manner:
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
212 • innovAtion MAnAgeMent And npd for engineers
• Resource investigator. These team members use their inquisitive nature to find ideas to bring back to the team.
• Teamworker. These participants help the team to gel, using their versatility to identify the work required and complete it on behalf of the team.
• Co-ordinator. These are needed to focus on the project’s objec- tives and deliverables, draw out team members and delegate work appropriately.
• Plants. These members of a team tend to be highly creative and good at solving problems in unconventional ways.
• Evaluator. These persons contribute by providing a logical perspec- tive, making impartial judgments where required, and weigh up the team’s options in a dispassionate way.
• Specialist. These team members bring in-depth knowledge of a key area to the team.
• Shaper. These participants ensure that the team keeps moving and does not lose focus or momentum.
• Implementer. These are needed to plan a workable strategy and carry it out as efficiently as possible.
• Completer. These members of a team are most effective at the end of tasks to polish and scrutinize the work for errors, subjecting it to the highest standards of quality control.
Some team members may fit with multiple roles in this approach. A third method is known as profile dynamics. It is based on the level of existence theory of Graves (1970). He recognized there were seven distinct value systems that determine the way people think and behave; each of these types has been assigned a color. These three methods seek to balance a team by having all archetypes present so that decision making covers all grounds and does not become unbalanced; this means also that, when one or more of the archetypes are not represented, teams can become focused on specific issues and neglect others. This notion of finding balance is characteristic for team management.
6.9 Key points
• A project is an effective way of fulfilling a need, though it is less efficient than recurrent processes, which are often optimized, and for this reason, more efficient. The unique features of a project are exceeding the capability of organization; thus, this staged approach with reviews aims at fulfilling the need for unique deliverables. The project approach is aiming at avoiding the trap of the ad-hoc
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
project MAnAgeMent (for innovAtion) • 213
approach, which often leads to uncontrollable use of resources while not ensuring that deliverables will become available in time.
• Characteristic for a project is a stage-wise approach to solve a problem or fulfill a need. This stage-wise approach incorporates milestones as points for decision making on predefined outcomes of activities. These milestones lead to looking at what progress has been made and looking forward to the next stages and activities.
• Figure 6.20 shows an overview of how a project can be structured starting with the project definition (new product, service, and process development) to the organization of a team and its related information and communication plan; the overview follows the con- cepts presented in this chapter. The figure does not include iterative cycles that exist; for example, that risk assessment and mitigation may lead to a new schedule for the project has not been depicted.
• Essential for many aspects of projects is whether it concerns a project just focusing on the deliverable(s) (project with narrow scope) or it pertains to a project that includes how deliverable(s) will be used by stakeholders (project with a broader scope); the latter may also include interfaces with other projects.
• The capabilities of team members, suppliers, and others involved in the project have a strong bearing on its outcomes, timeline, budget, and risks.
• Scheduling and budgeting will point to critical activities that should be monitored more intensely than other activities. If constraints in deadline and budget cannot be met, trade-offs should be made with the scope of the project; in practice, this means redefining the deliv- erable(s) or less deliverables. Alternatively, deliverable(s) can be staged to relax these constraints.
• Risk assessment and mitigation can be performed on the project definition, deliverables, activities, scheduling, and budget of the project. For projects with a broader scope, this can extend to the interaction with stakeholders and their benefits from the project.
• The design of monitoring and control can be informed by the steady-state model and breakthrough model for interventions; the latter can be found in Subsection 10.1.1. The steady-state model applies better to activities within the project, and the breakthrough model with its innovation impact points to scope and changes in the project (including the interaction with stakeholders).
• Information and communication plans are a prerequisite for ade- quate project management and should be set up at the beginning of a project. Adequate processes and procedures for information management underpin these plans.
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
214 • innovAtion MAnAgeMent And npd for engineers
Pr oj
ec t
de fin
iti on
D el
iv er
ab le
s
Fu zz
y fr
on t e
nd O
pe ra
tio ns
Pr oj
ec t w
ith b
ro ad
sc op
e
Pr oj
ec t w
ith n
ar ro
w sc
op e
D el
iv er
ab le
s W
BS 1
W BS 1. 2
W BS 1. 3
W BS 1. 1
W BS
1. 1.
1
W BS
1. 1.
2
W BS
1. 2.
1
W BS
1. 2.
2
W BS
1. 3.
1
W BS
1. 3.
2
S . .
I . .
II . .
V 9 .
IV . .
II I
. . V
I . .
F . .
Pl an
ni ng
In pu
t (fl
ow in
g el
em en
t)
O ut
pu t
R es
ou rc
es
Pr im
ar y
pr oc
es s
Se co
nd ar
y pr
oc es
s
R es
ou rc
e al
lo ca
tio n
• C ap
ab ili
tie s o
f r es
ou rc
es
(in te
rn al
a nd
e xt
er na
l) • I
nc l.
m ak
e- or
-b uy
• S ec
on da
ry p
ro ce
ss es
Bu dg
et in
g
Im pl
ic at
io ns
fo r
re so
ur ce
s
Po st
H ou
rs M
at er
ia ls
C os
t
To ta
l
A aa
...
Z zz
... C
on tin
ge nc
ie s
•• •
•• •
•• •
•• •
•• •
•• •
•• •
•• •
•• •
•• •
•• •
•• ••
R is
k as
se ss
m en
t a nd
m
iti ga
tio n
• F au
lt tr
ee a
na ly
si s
• F M
E A
• S ce
na ri
o an
al ys
is • C
ou nt
er m
ea su
re s
Pr oj
ec t O
rg an
iz at
io n
Pr oj
ec t t
ea m
D ep
ar tm
en t
A D
ep ar
tm en
t B
D ep
ar tm
en t
C
Pr oj
ec t
m an
ag em
en t
M an
ag er
Pr oj
ec t
ad m
in ist
ra tio
n
Pr oj
ec t
m an
ag em
en t
W or
ki ng
gr ou
ps
D ep
ar tm
en t
B D
ep ar
tm en
t B
D ep
ar tm
en t
B
E m
be dd
in g
in o
rg an
iz at
io n
In pu
t (fl
ow in
g el
em en
ts )
O ut
pu t
In pu
t b ou
nd ar
y zo
ne
O ut
pu t
bo un
da ry
zo ne
R eg
ul at
or y
bo un
da ry
z on
e
(E xt
er na
l) St
an da
rd s
E nc
od in
g
E va
lu at
in g
A be
rr at
io ns
(I nt
er na
l) St
an da
rd s
Measurement
In fo
rm at
io n
fr om
en vi
ro nm
en t
C ap
ab ili
ty of
p ro
ce ss
R eg
ul at
in g
C om
pa ri
ng C
om pa
ri ng
M ea
su ri
ng M
ea su
ri ng
In te
rv en
in g In
ve rs
io n
of pr
oc es
s
C om
pl et
in g
de fic
ie nc
ie s
D ec
od in
g Pr
oc es
s
(I nt
er na
l) St
an da
rd s
In tia
tin g
A ct
iv ity
1
Pr oj
ec t
m an
ag er
Te am
m em
be r
A Te
am m
em be
r B
Te am
m em
be r
C
A ct
iv ity
2
A ct
iv ity
3
R
R
A A A
C C I
St an
da rdINTERVENTION
Pr oj
ec t s
co pe
Pr oj
ec t d
ef in
iti on
an d
pl an
ni ng
Pr oj
ec t
ex ec
ut io
n
R ec
ur re
nt p
ro ce
ss es
INTERVENTION
Control of breakthrough and baster plan
En vi
ro nm
en t
En vi
ro nm
en t
M
C ap
ab ili
ty as
se ss
m en
t
Pr oj
ec t
pl an
Evaluaton of performance
II P-
1
II P-
2
II P-
3
II P-
4
M on
ito ri
ng a
nd C
on tr
ol
In fo
rm at
io n
an d
C om
m un
ic at
io n
Pl an
St ak
eh ol
de r
A
D el
iv er
ab le
O bj
ec tiv
e Pr
io ri
ty W
he n
St ak
eh ol
de r
B 3
•• ••
•• ••
•• ••
•• ••
K ey
(1 )
2
Su pp
or t/M
iti ga
tio n
St ak
eh ol
de r
C
St ak
eh ol
de r
i ••
••
•• ••
•• ••
•• •
•• ••
•• ••
•
•• ••
•• ••
•• ••
•• ••
•
•• ••
•• ••
•• •
K ey
(1 )
3
M M
/Y Y
M M
/Y Y
M M
/Y Y
M M
/Y Y
M M
/Y Y
•• ••
•• ••
•
•• ••
•• ••
• ••
•• ••
•• •
•• ••
•• •
•• ••
•• ••
•
In te
rn al
C om
m un
ic at
io n
C om
m un
ic at
io n
w ith
S ta
ke ho
ld er
s
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
project MAnAgeMent (for innovAtion) • 215
Fi gu
re 6
.2 0.
O ve
rv ie
w o
f p ro
je ct
m an
ag em
en t (
w ith
ou t i
te ra
tiv e
cy cl
es ).
Pr oj
ec t
de fin
iti on
D el
iv er
ab le
s
Fu zz
y fr
on t e
nd O
pe ra
tio ns
Pr oj
ec t w
ith b
ro ad
sc op
e
Pr oj
ec t w
ith n
ar ro
w sc
op e
D el
iv er
ab le
s W
BS 1
W BS 1. 2
W BS 1. 3
W BS 1. 1
W BS
1. 1.
1
W BS
1. 1.
2
W BS
1. 2.
1
W BS
1. 2.
2
W BS
1. 3.
1
W BS
1. 3.
2
S . .
I . .
II . .
V 9 .
IV . .
II I
. . V
I . .
F . .
Pl an
ni ng
In pu
t (fl
ow in
g el
em en
t)
O ut
pu t
R es
ou rc
es
Pr im
ar y
pr oc
es s
Se co
nd ar
y pr
oc es
s
R es
ou rc
e al
lo ca
tio n
• C ap
ab ili
tie s o
f r es
ou rc
es
(in te
rn al
a nd
e xt
er na
l) • I
nc l.
m ak
e- or
-b uy
• S ec
on da
ry p
ro ce
ss es
Bu dg
et in
g
Im pl
ic at
io ns
fo r
re so
ur ce
s
Po st
H ou
rs M
at er
ia ls
C os
t
To ta
l
A aa
...
Z zz
... C
on tin
ge nc
ie s
•• •
•• •
•• •
•• •
•• •
•• •
•• •
•• •
•• •
•• •
•• •
•• ••
R is
k as
se ss
m en
t a nd
m
iti ga
tio n
• F au
lt tr
ee a
na ly
si s
• F M
E A
• S ce
na ri
o an
al ys
is • C
ou nt
er m
ea su
re s
Pr oj
ec t O
rg an
iz at
io n
Pr oj
ec t t
ea m
D ep
ar tm
en t
A D
ep ar
tm en
t B
D ep
ar tm
en t
C
Pr oj
ec t
m an
ag em
en t
M an
ag er
Pr oj
ec t
ad m
in ist
ra tio
n
Pr oj
ec t
m an
ag em
en t
W or
ki ng
gr ou
ps
D ep
ar tm
en t
B D
ep ar
tm en
t B
D ep
ar tm
en t
B
E m
be dd
in g
in o
rg an
iz at
io n
In pu
t (fl
ow in
g el
em en
ts )
O ut
pu t
In pu
t b ou
nd ar
y zo
ne
O ut
pu t
bo un
da ry
zo ne
R eg
ul at
or y
bo un
da ry
z on
e
(E xt
er na
l) St
an da
rd s
E nc
od in
g
E va
lu at
in g
A be
rr at
io ns
(I nt
er na
l) St
an da
rd s
Measurement
In fo
rm at
io n
fr om
en vi
ro nm
en t
C ap
ab ili
ty of
p ro
ce ss
R eg
ul at
in g
C om
pa ri
ng C
om pa
ri ng
M ea
su ri
ng M
ea su
ri ng
In te
rv en
in g In
ve rs
io n
of pr
oc es
s
C om
pl et
in g
de fic
ie nc
ie s
D ec
od in
g Pr
oc es
s
(I nt
er na
l) St
an da
rd s
In tia
tin g
A ct
iv ity
1
Pr oj
ec t
m an
ag er
Te am
m em
be r
A Te
am m
em be
r B
Te am
m em
be r
C
A ct
iv ity
2
A ct
iv ity
3
R
R
A A A
C C I
St an
da rdINTERVENTION
Pr oj
ec t s
co pe
Pr oj
ec t d
ef in
iti on
an d
pl an
ni ng
Pr oj
ec t
ex ec
ut io
n
R ec
ur re
nt p
ro ce
ss es
INTERVENTION
Control of breakthrough and baster plan
En vi
ro nm
en t
En vi
ro nm
en t
M
C ap
ab ili
ty as
se ss
m en
t
Pr oj
ec t
pl an
Evaluaton of performance
II P-
1
II P-
2
II P-
3
II P-
4
M on
ito ri
ng a
nd C
on tr
ol
In fo
rm at
io n
an d
C om
m un
ic at
io n
Pl an
St ak
eh ol
de r
A
D el
iv er
ab le
O bj
ec tiv
e Pr
io ri
ty W
he n
St ak
eh ol
de r
B 3
•• ••
•• ••
•• ••
•• ••
K ey
(1 )
2
Su pp
or t/M
iti ga
tio n
St ak
eh ol
de r
C
St ak
eh ol
de r
i ••
••
•• ••
•• ••
•• •
•• ••
•• ••
•
•• ••
•• ••
•• ••
•• ••
•
•• ••
•• ••
•• •
K ey
(1 )
3
M M
/Y Y
M M
/Y Y
M M
/Y Y
M M
/Y Y
M M
/Y Y
•• ••
•• ••
•
•• ••
•• ••
• ••
•• ••
•• •
•• ••
•• •
•• ••
•• ••
•
In te
rn al
C om
m un
ic at
io n
C om
m un
ic at
io n
w ith
S ta
ke ho
ld er
s
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
216 • innovAtion MAnAgeMent And npd for engineers
• For project execution, actual project leadership is determined by how the project leader interacts with team members and stakeholders. The project leadership style may also depend on the type of project.
• Methods for team management focus on a balanced representation of team roles to ensure that decisions and collaboration are focus- ing on all relevant aspects.
6.10 references
Belbin, M. 1981. Management Teams. London: Heinemann. Cooper, R.G. 1994. “Third-Generation New Product Processes.” Journal of
Product Innovation Management 11, no. 1, pp. 3–14. de Bono, E. 1967. New Think: The Use of Lateral Thinking in the Generation of
New Ideas. New York, NY: Basic Books. Dekkers, R. 2017. Applied Systems Theory, 2nd ed. Cham: Springer. Dekkers, R., C.M. Chang, and J. Kreutzfeldt. 2013. “The Interface Between
‘ Product Design and Engineering’ and Manufacturing: A Review of the Literature and Empirical Evidence.” International Journal of Production Economics 144, no. 1, 316–33. doi:10.1016/j.ijpe.2013.02.020
Graves, C.W. 1970. “Levels of Existence: an Open System Theory of Values.” Journal of Humanistic Psychology 10, no. 2, 131–55. doi:10.1177/0022167 87001000205
Leonard-Barton, D. 1988. “Implementation as Mutual Adaptation of Technology and Organization.” Research Policy 17, no. 5, 251–67. doi:10.1016/0048- 7333(88)90006-6
Madsen, S. 2016. The Power of Project Leadership. London: Kogan Page. Project Management Institute. 2000. A Guide to the Project Management Body of
Knowledge. Retrieved from Newton Square, PA. Schuh, G., A. Kampker, and B. Franzkoch. 2005. “Anlaufmanagement, Kosten
senken–Anlaufzeit verkürzen–Qualität Sichern.” wt Werkstattstechnik online 95, no. 5, pp. 405–09.
ten Haaf, W., H. Bikker, and D.J. Adriaanse. 2002. Fundamentals of Business Engineering and Management. Delft: DUP Science.
Tyre, M.J., and W.J. Orlikowski. 1993. “Exploiting Opportunities for Technologi- cal Improvement.” Sloan Management Review 35, no. 1, pp. 13–26.
Vandevelde, A., and R. Van Dierdonck. 2003. “Managing the Design-Manufactur- ing Interface.” International Journal of Operations & Production Manage- ment 23, no. 11, 1326–48. doi:10.1108/01443570310501871
VDI (Verein Deutscher Ingenieure). 1993. Methodik zum Entwickeln und Konstru- ieren technischer Systeme und Produkte (Systematic Approach to the Devel- opment and Design of Technical Systems and Products). Berlin: Beuth Verlag.
Wijnen, G., W. Renes, and P. Storm. 1996. Projectmatig Werken. Utrecht: Het Spectrum/Marka.
EBSCOhost - printed on 10/26/2023 4:08 AM via TRINE UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
