irrelevance of pm discipline

8/15/2019 Irrelevance of PM Discipline

1/20

Peter Morris Page 1 3/23/2004

The irrelevance ofproject management

as a professionaldiscipline

Peter W G Morris


2/20


The irrelevance of project management as a professional discip line.

Peter W.G. Morris

Abstract

Our understanding of the central core of generic project management has notchanged very much (though it has a little) in the last 20 years or so. However,this central core does not reflect adequately what managers have to addressin managing projects successfully. The analysis given in this paper shows thatstrategic, technical and commercial matters also need to be addressed. Thisbroader framework is the real 'body of knowledge' of the discipline ofmanaging projects. Unless and until this broader framework is recognized andpromoted, project management will be seen as, at best, a planning andreporting based, execution oriented activity, and not as one central to, oreffective in, the management of projects. Getting this broader frameworkaccepted by managers in project-based industries is the task now facing

project management professionals.

Introduction

Project management associations have been in existence since the late1960s. In recent decades many have taken on the more formal characteristicsof professional bodies. Overall, however, their impact on project-basedsectors is limited, as indeed is project management as a discipline. There isconfusion as to what the discipline actually refers to and little or no researchinto the discipline as a whole; while many accept it as a managementpractice, few industries or research bodies see it as a cognate discipline thatcovers the definition and development of projects and which is central tobusiness performance. Too often it is seen merely as, at best, projectexecution or, at worst, planning and scheduling.

This paper prosecutes this thesis by briefly reviewing models of what is takento be management as a professional discipline, and then examining itsrelative relevance in four sectors: construction, IT, defense-aerospace, andpharmaceutical drug development projects. The analysis suggests that (a) thediscipline needs to be seen as a comprehensive management body ofknowledge and skills that (b) covers program and project definition as well asexecution – the management of projects; and (c) greater effort needs to bemade to promote this discipline within the major project-based industries in

particular.

Models of project management

What do we mean by project management? There are probably somethinglike at least 90,000 people – the membership of the Project ManagementInstitute (PMI) – who might be expected to say that project management is asdefined in PMI’s “Guide to the Project Management Body of Knowledge®”(Figure 1) [1].


3/20


Figure 1: PMI’s PMBOK®: “ Guide to the project management body ofknowledge”

Though widely accepted, many practitioners, academics and others however

believe it has serious shortcomings. It contains nothing detailed on projectstrategy, nothing on project definition, little on value management, nothing ontechnology management, and little on the linkage with programs andportfolios. All these shortcomings derive from its intellectual perspective ofproject management essentially as an execution discipline: of delivering aproject ‘on time, in budget, to scope’. There are many people for whom that isadequate. Many firms still separate the project execution end of projects fromthe project definition and development, labelling the former as projectmanagement and the latter as something else (e.g. project development).

For others however, from both a practical and theoretical view, it is not. Itmisses the whole area of setting up the project objectives (defining scope,

budget and schedule) as well as the linkages with business performance(through portfolio and program management, project strategy and valuemanagement). For many, this really is the important area in the successfulaccomplishment of projects. And seeing the management of the project as awhole for them brings added benefits of optimisation. Project managementhas to be about delivering business benefit through projects, and thisnecessarily involves managing the project definition as well as downstreamimplementation.

Project

Management

Project Integration

Management• Project Plan Development

•Project Plan Execution

•Overall Change Control

Project CostManagement

•Resource Management

•Cost Estimating

•Cost Budgeting

•Cost Control

Project CommunicationsManagement

•Communications Planning

•Information Distribution

•Performance Reporting

•Administrative Closure

Project Scope Management

•Initiation

•Scope Planning

•Scope Definition

•Scope Verification

•Scope Change Control

Project Quality

Management

•Quality Management

•Quality Assurance

•Quality Control

Project Risk Management

•Risk Identification

•Risk Quantification

•Risk Response Development

•Risk Response Control

Project Time Management

•Activity Definition

•Activity Sequencing

•Activity Duration Estimating

•Schedule Development

•Schedule Control

Project Human ResourceManagement

•OrganiztionalPlanning

•Staff Acquisition

•Team Development

Project ProcurementManagement

•Procurement Planning

•Solicitation Planning

•Solicitation

•Source Selection

•Contract Administration

•Contract Close-out


4/20


Ultimately, perhaps it is more useful to recognize that what reallydistinguishes projects from non-projects is their development cycle (Figure 2):the sequence of going from concept into definition, development/ executionand completion [and sometimes including operation, leading to close out] – orsome variant of these words. All projects go through the same sequence, nomatter how trivial or complex (only the wording will change). Non-projects –

steady state operations – do not follow this development cycle. Really,therefore, what we are talking about is the management of projects [2].

Figure 2: the generic project development cyc le

Managing people, information and things as they progress through thisdevelopment cycle has many common characteristics and benefits from using

several common practices, for example:• aligning the development of the project strategy with the sponsor’s (and

other stakeholders’) business strategy;

• defining the requirements (in a testable manner) – these lead tospecifications and solutions being designed and developed;

• defining and manage the project scope, schedule, resourcerequirements, and budget (ensuring this represents optimal financing);

• installing and progressing project control systems;

• procuring/inducting resources into the project;

• building effective project teams;

• exercising leadership;

•

ensuring effective decision and efficient communications.

Knowledge of how to do this is now familiar through the many thousands ofarticles, papers, books and seminars that have been produced on projectmanagement over the last forty or more years; much of the central core ofproject management, as expressed for example in the PMBOK model, hasbeen with us since the 1960s.

• Most basic network scheduling techniques and practices weredeveloped by the mid 60s – probably the only development since hasbeen in critical chain planning.

• Little if anything at all has changed in the area of budgeting and costcontrol (though there have been developments in estimating).

• The basic principles of scope management, at the PMBOK level, havenot changed a jot since the early work of DOD and NASA in the late1950s.

• Risk management practices certainly existed in the 60s (PERT forexample) and again, the basic project risk management processeshave been available since the 70s – though the application of riskmanagement is challenging and this continues to be an area oftheoretical and strong practical interest.

Concept Definition Development Execution Delivery


5/20


• Similar statements may perhaps be made for much of our knowledgeof what PMBOK® calls ‘Human Resources Management’ andProcurement (though there have been major new developments in both – for example around competences and in partnering and supply chainmanagement)

Many other project management practices were available by the early 60s: for

example, value management, quality management, configurationmanagement, etc. [3].

What has changed however is the socio-economic/ business context in whichprojects are managed; the technical environment; and the commercialconditions. Project management, like all management, is contextual, and it ismanaging projects in their changing, modern contexts that is the realchallenge.

To reflect this we need a broader framework in which to position andunderstand project management, a framework more aligned to themanagement of projects. A framework like that of the Association for Project

Management (reflecting the factors that research has shown affect thelikelihood of project success), covering program (and portfolio) management,strategy, technical, and commercial matters, as well as the more traditionalPMBOK areas of control and organization (Figure 3). (IPMA’s is similar, as isENAA’s [4]).

Figure 3: the APM project management body of knowledge

Promoting this broader view of the discipline is, this paper argues, vital to thecontinued health and validity of the discipline. For so long as it is only seen as

Operation & Maintenance /

Integrated Logistics;

Project Reviews/ Learning

From Experience

3.0 Control:3.1 Work Content & Scope Management:3.2 Time Scheduling/ Phasing:3.3 Resource Management:3.4 Budgeting & Cost Management:3.5 Change Control:3.6 Performance Management:3.7 Information Management:

4.0 Technical4.1 Design, Production & Hand -Over Management:4.2 Requirements Management4.3 Technology Management:4.4 Estimating:4.5 Value Engineering:4.6 Modelling & Testing4.7 Configuration Management:

5.0 Commercial5.1 Business Case5.2 Marketing &Sales:5.3 Financial Management:5.4 Procurement:5.5 Bidding:5.6 Contract Management:5.7 Legal Awareness

6.0 Organisational6.1 Life Cycle Design & Management

6.1.1Opportunity6.1.2 Design & Development6.1.3 Production6.1.4 Hand-over 6.1.5 (Post) Project Evaluation Review [O&M/ILS] :

6.2 Organisation Structure:6.3 Organisational Roles

7.0 People:7.1Communication:7.2 Teamwork:7.3 Leadership:7.4 Decision Making:7.5 Negotiating &

Influencing:7.6 Conflict Management7.7 Project Management

CompetencyDevelopment:

7.8 Personnel Management:

1.0 General:1.1 Project Management 1.3 Portfolio Management:1.2 Programme Management 1.4 Projec t Context:

2.0 Strategic2.1 Project Success Criteria: 2.4 Risk Management:2.2 Strategy/ Project Management Plan: 2.5 Quality Management:

2.3 Value Management 2.6 Safety, Health & Environment2.7 Ethics

Concept/

Marketing

Opportunity

Identification

Feasibility/

Bid

Design &Development

Design,

Modelling

& Procurement

Production

Make, Build

& Test

Hand-over

Test,

Commission,

Start-up

Post-Project

Evaluation


6/20


the PMBOK® type model it will be seen as only partially relevant, as will theproject management professional associations.

For as the following sections of this paper shows, the reality in construction,IT, defense-aerospace and drug development, to take just four of the mostproject-based of industries where one would expect the discipline to be

central and flourishing, is precisely this. Project management is at best seenas a significant if limited practice rather than as a coherent managementdiscipline. For as long as it is seen only as the PMBOK type model, itsintellectual base will be questioned and seen as inadequate. The disciplinewill be viewed if not quite irrelevant certainly as not centrally important.

Project management’s professional societies need to promote the broaderframework in a manner that provides value in each industrial setting.

The construction industry

Construction in the wider sense comprises several different sectors:

classically, building (of which there are several subsectors from housing tocommercial office development), civil engineering, and process engineering(sometimes called ‘engineering construction’). Buildings are structures withroofs on them; civil engineering tends to be more in the ground and relatemore to infrastructure (roads, harbours, dams, etc.; process plants generallyrelate to the processing of fluids, gases or other forms of materials, generallyin the oil, gas, chemical, power and pulp & paper sectors1.

Buildings are generally designed by architects, with the assistance of severaltypes of engineers and other specialists. Civil engineering projects are rarelydesigned by architects but by engineers. Process plants are designed byprocess engineers. Building projects are typically more complex technicallyand organizationally than civil engineering and process projects, having moretrades working in less space.

Building puts higher premium on design originality (hence architects). It alsotypically has fewer experienced owners [clients] than the other sectors, andhence tends to expect the architect to act as the project leader 2. In civilengineering this tends to be the engineer. In process engineering, it is the

1

Rail and water projects were historically within civil engineering; over the last few decadeshowever they have moved more into process engineering, partly as technology has becomemore process oriented - signaling in rail, water treatment systems in water, etc. – and partlyas process engineering contract terms have been adopted as more appropriate. 2 This has been challenged with the emergence of ‘construction management’ and more

recently formal ‘project management’. Construction management (which as a form ofmanagement has a quite specific meaning in the industry) however is essentially an approachto managing the site end of the project [trades contractors] with bare recognition of the realchallenge, and opportunities, of managing design and the ‘front end’, while much of projectmanagement in building is a synonym for scheduling and cost management, and in civilengineering, for supplier management.


7/20


project manager. In neither building nor civil engineering is this designleadership the equivalent of active project management however 3.

Building (particularly) is a largely local industry: though there are exceptions,practices vary between countries. To an extent this is also true for civilengineering. It is less true for process engineering. The following statements

concerning the irrelevance of project management as a formal discipline holdtrue largely for the UK and USA (but are unlikely to be wildly wrong for othercountries).

Take for example the intellectual debate about how to improve constructionperformance. The late 1980s and 1990s saw several initiatives in the UK andUSA in this area yet project management as a discipline was rarelymentioned. The most influential critique of building in the UK in recent years inthe UK (Egan) for example calls for greater integration of project processeswhile studiously avoiding the term [5].

Process engineering studies have taken a more explicitly project management

approach, though even then barely recognizing it as a discipline. A series ofmajor and influential joint industry/ academia based studies for example [6]identify the practices of pre-project planning, scope definition, design andtechnology, change management, risk mitigation, safety, team building,strategic alliancing, and construction start-up as having the greatest impact onproject performance.

While the language here is recognizably ‘project management’ what isinteresting is just how much of it extends beyond the PMBOK model andexplicitly incorporates technology and commercial issues. The same is truewhen we look at the management trends seen as key to the industry’s future[7]:

• global digitised technology, design and procurement, leadership in IT/CAD-CAM, improved materials;

• value-based procurement and contracting, incentives aligned toowners’ requirements, greater distribution of risk throughout the projectteam, more partnering, global outsourcing;

• broader, more intelligent planning, design and construction, greateremphasis on project selection, early emphasis on critical equipment,more ‘whole life’ design [‘design to capacity/ for plant life’], more

3 This is for structural and historic reasons. In building and civil engineering dominantly the

(very old) separation of the designer from the overall management of the project, the process

of bringing in contractors and suppliers, the terms and conditions of those contracts, togetherwith the historic role of the designer in administering that contract. Process engineering on theother hand has the very different characteristics: large, efficient owners having integratedviews of their projects with substantial opportunities for standardization within the engineeringdesign. These are quite different characteristics from say the prestige building market wherethere is a premium on innovative, high quality design. They lead much more readily to anapproach to construction project management that is owner oriented, integrating engineering,procurement and construction. The process engineering industries hence were able todevelop a much more ‘through-project’ integrated approach to engineering projectmanagement, with engineering [design], procurement and construction typically beingperformed by the same management team.


8/20


standardization, greater single data entry, increased prefabrication,more intelligent tools, more benchmarking.

This broader view of the management of projects is further reflected inconstruction’s increased interest in the front-end and project definition. Overthe last decade or so all the construction sectors have seen a shift in

management focus from the site ‘back-end’ forwards, through procurement, tothe ‘front-end’ area of design, planning and financing. In process engineering,this focus tends to be heavily oriented around engineering and finance (Figure4); in building it typically involves people issues more. In process engineering,this emphasis has become so widely accepted that ‘Front End Loading’ (FEL)is now widely seen as a key success indicator. (Benchmarking data showsthat there is a correlation between time spent in FEL and project outcomes[8].)

Figure 4: Standard FEL diagram (source: ACTIVE)

Project strategy is important in construction, particularly in building. In processengineering alignment between business and project strategy is largely interms of product positioning, and financial and technical measures. In buildingthere is more attention to the interaction between design and project delivery,on the one hand, and business return and user satisfaction on the other.Commercial development projects for example will pay great attention tooptimising floor layouts and occupancy [lettable space] ratios (and possiblyeven attractiveness of design!) in order to improve the commercial return.Value management in process engineering for example is generally lesscommon than in building.

Briefing (translating requirements into instructions for the designer) is a morecomplex activity in building than in process engineering. Requirements aregenerally expressed as the client’s requirements: in the more speculative type

• Project Objectives

• Technology Evaluation/ Selection

• Process Simplification (VE1)

• Facility Quality• Waste Minimization

• Contracting Strategy

• Constructability Review (1)

• Process Reliability Modelling

• Minimum Standards & Specifications

• Predictive Maintenance• Design-to-Capacity

• Energy Optimization

• 3D CAD

• VE (2)

• Constructability Reviews (2)

Discovery/

Opportunity/

Feasibility

Concept

Selection

Concept

Definition

FEED Detailed

Design

Construct

& Install

Commission

P O T E N T I A L T O

R E D U C E

C O S T S

Board/ Executive Approval

•Constructability Reviews (3)

• Project Objectives

• Technology Evaluation/ Selection

• Process Simplification (VE1)

• Facility Quality• Waste Minimization

• Contracting Strategy

• Constructability Review (1)

• Process Reliability Modelling

• Minimum Standards & Specifications

• Predictive Maintenance• Design-to-Capacity

• Energy Optimization

• 3D CAD

• VE (2)

• Constructability Reviews (2)

Discovery/

Opportunity/

Feasibility

Concept

Selection

Concept

Definition

FEED Detailed

Design

Construct

& Install

Commission

P O T E N T I A L T O

R E D U C E

C O S T S

Board/ Executive Approval

•Constructability Reviews (3)


9/20


of projects, users’ requirements are rarely specified in detail. The practice ismore common however in projects having a strong facilities managementorientation, such as hospitals, schools, pharma, etc.

The two biggest changes in construction over the last decade or so have beenin the use of private sector financing for public sector works (roads, hospitals,

schools, prisons, etc.) and the move towards partnering and alliancing.

From a project management perspective, the former – concession financing,PFI, BOT, etc. – has forced project participants to focus on the ‘whole life’characteristics of the thing being built. Since the project’s financial return isnow a function of its long-term financial performance, design (includingstrategy and briefing) and construction have to become subservient to long-term operational performance. The short-termism that has so typicallybedeviled building and civil engineering in particular is now increasinglychallenged by the newer long-term perspectives of operational performance.Hence we see a rising interest in construction in practices such as FacilitiesManagement, Costs-in-Use, Whole Life Performance, and Integrated

Logistics Support. Partnering has dramatically changed the way projectmembers cooperate4.

Several conclusions can be drawn from this brief analysis.

• Project management in short does not figure significantly as a centraldiscipline in construction.

o In process engineering project management is more common asa recognized practice but is nevertheless not seen as a coreprofessional discipline.

o In building and civil engineering it has even less of a profile,being seen at best as an extension of site management or costsurveying.

• Actual project based management practices in construction generallyencompass a much wider scope than those covered by the traditionalPMBOK model: the management of strategic, technical andcommercial issues, not least at the front-end, are where there is thebiggest opportunity to generate real project delivery value.

• Neither PMI nor APM certificated membership has any real clout in theindustry (nor indeed do these institutions themselves).

Information technology (IT) projects

Information and Communications Technology (ICT) projects cover both the

specification, supply and installation of ‘off-the-shelf’ equipment (‘kit’) and thedevelopment of bespoke software5. Bespoke software development becomesthe overriding paradigm: it is several orders of magnitude more difficult.

4 CII metrics indicate that “partnering and strategic alliances contributed directly to the

success of projects 80% of the time. On average, schedules were reduced by 15%; costs by12%; and change control, safety, and quality were enhanced” [9]5 For this reason the acronyms IT and ICT are here being used interchangeably


10/20


The track record of the successful accomplishment of IT projects is not good[10]: a significant proportion fail to be completed on time and/ or to deliverbusiness benefit. Failing IT project performance is virtually a continuous newsitem. Yet there is no really effective IT project management paradigm6 andvery few educational or training programs. (Hence there is strong interest inPMI and APM, but equally a lot of frustration, generally because the model is

inadequate.)

IT projects are very rarely developed for their own sake. User involvement inthe project is critical. Recognition of this has been a distinguishing feature ofthe development of IT project management over the last few decades.

Initial attempts to put some structure into the management of IT projectsfocussed on structured design methods, such as SSADM and specialist toolssuch a COCOMO (estimating) [11]. Systems development was seen as aform of engineering (which it is); over the last few decades, the managementof this engineering development has become recognized as a robust,substantive activity in its own right. By the early 80s most competent software

development houses were combining some form of systems analysis anddesign with a formal project management environment.

At the heart of IT’s project management are processes and practices. (Peopleissues, such as team working and leadership, perhaps tend to be emphasizedless, maybe wrongly, due perhaps to the small size of many IT projects, andthe more solitary nature of the work.) Typically these processes and practicesare documented as some form of methodology. While ten to twenty years agothese methodologies were predominantly technical in character; they tendnow to concentrate more on the management activities themselves, andindeed on the business benefit of this management (program management,business benefits management, etc.).

As all projects, IT projects follow a common development cycle. Partlybecause of the special challenges posed by the intangible nature of software,and the importance of getting user involvement in a structured manner, thisprocess tends to be both more consistent and dominant than in construction,which, as we have seen, has a lot more variability. There are various versionsof this: the spiral, the spiral and the waterfall being the two best known [12].(Broader versions have been developed for generic systems developmentprojects, for example by DOD [13]).

The waterfall cycle, for example, follows a sequence such as that shown in

Figure 5. Business strategy leads to the formulation of business requirements,which will generally significantly incorporate explicit user requirements. Thesethen lead to the definition of systems requirements and specifications.Software design and coding then creates the system which is then tested ‘up’the waterfall against the different levels of specification, as shown.

6 The best is probably PRINCE2 (see below) but is far from perfect: it is not integrated with

Program Management and has virtually nothing on human factors and little on resourcemanagement.


11/20


Figure 5: The Waterfall development cycle

Much of the difficulty in delivering IT projects successfully comes from the (a)the challenge in specifying the system requirements in a way that will lead tobusiness benefit, (b) the intangible nature of the product being produced.

The intangible nature of IT projects has led to a variety of managementtechniques and practices.

• Requirements management tools which help capture and organizerequirements so that they can be structured, traced and tested in anorderly manner.

• Prototyping, as a means of developing models of what is to bedeveloped so that either the technical issues can be investigated or theuser can see a mock-up of what he will get.

• Configuration management, the discipline of managing the evolvingdefinition of the product (status, mutual relationships, ownership, etc.)

• Document management, to provide a record of the factors leading tothe design of the system. (Lack of adequate documentation canbecome a major problem for ‘embedded’ systems.)

User/operator training is also typically a major feature of most IT systems: thedelivered system is often of only limited value if the users cannot use it and itsfeatures effectively.

These important areas of systems project management represent a technicalmanagement level above that of systems design, coding and testing. As in

construction where there is a similar set of technical management issues, theycombine with the more generic, traditional approaches to project management(estimating, resource management, scheduling, budgeting, cost control,change control, etc.) to form a more enlarged view of the discipline (‘themanagement of projects’).

Of all the areas of ‘classical’ project management, estimating has probablycaused the greatest difficulty in IT, primarily (again) because of the intangiblenature of the product. ‘Functional Point Analysis’ and other techniques have

Acceptance test

System test

Integration tests

Component tests

User/ Business

Requirements

SystemRequirements

Architectural

Design

Component

Development

Operational

Capability

CompletedSystem

Assemblies

Components

I n s t a l l a t i o n &

v a l i d a t i o n

I n t e g r a t i o n &

v e r i f i c a t i o n

Business

StrategyMaintainability

Acceptance test

System test

Integration tests

Component tests

User/ Business

Requirements

SystemRequirements

Architectural

Design

Component

Development

Operational

Capability

CompletedSystem

Assemblies

Components


v a l i d a t i o n




v a l i d a t i o n



Business

StrategyMaintainability


12/20


been used as aids in the organization of data but with varying and at timesquite poor results. The trend today is increasingly to take both a top-down anda bottom-up approach so that the big picture marries with the detailed.

Over the last decade the technical project management model has beenenlarged further by a growing awareness of need to incorporate consideration

of business issues into the systems project management model. PRINCE2,the highly influential methodology promoted by the government sector in theUK [14], for example, emphasizes:

• the role of the project sponsor and the project board as means ofanchoring the evolving project definition to the sponsoringorganizations’ business needs;

• the development of the project by phases, with gate reviews at the endof each phase, with approval to proceed being required at each gate.

Program management has emerged as an increasingly important concept inrecent years. Programs are projects that share common business objectives,and that often share resources. A program might be a product for example

that has various versions of the base model associated with it. Importantly,the program idea encourages the systematic management of upgrades.(There may be a revised definition of the product, incorporating some newtechnical or market feature say, that is planned for a later release [15].) Thisbrings emphasis on business benefit and the chance to manage product[project/program] change creatively but in a controlled manner.

The management of business benefit is one of the most interesting anddifficult areas in IT projects today7. Historically, projects have been assessedin primarily numerical terms – NPV etc; even cost-benefit analysis wasmeasured largely numerically. Over the last decade however there has been

increasing recognition of the need to deploy broader measures. Benefitsmeasures hence now build off a range of diversified models such as theBalanced Scorecard, quality models, shareholder value added, etc. [16].Benefits management includes the notion of benefits harvesting as well asidentifying appropriate measures and the activities of measuring andreviewing. ‘Harvesting’ ensures that benefits are actually being taken into thebusiness: for example, it is not just measuring and reviewing the collection ofdata off a new credit card system but the use of this data for business benefitthat is important.

Benefits, and requirements, flow from strategy and the link between projectstrategy and business strategy is critically important. IT projects are a direct

extension of business strategy. Too often this linkage is weak, resulting in ITprojects developing a life of their own and becoming ‘out of synch’ with thebusiness strategy. It is therefore important that the program/project boardkeep project strategy strongly aligned with the business strategy; that gatereviews constantly refer, inter alia, to the strategy; and that staff remuneration

7 Benefits could really be the third apex in the iron triangle: cost, schedule, and benefit (rather

than scope or quality). Achieving benefit is logically the most important of the three, someasuring and recording completion over budget or schedule may not be the most significantmeasure of project success.


13/20


schemes not get in the way of cancelling (or modifying) projects where this isrequired (a frequent problem)8.

Curiously, one area IT project management does not yet seem to haveapplied in any significant way is value management. Given the poorperformance of many IT projects, and the close relationship with business

strategy (and indeed technical design), there would seem to be a prima faciecase of compelling logic for adopting a process that systematically reviews thecontribution of project strategy, and technical design, to business benefit.

The following stands out from this analysis of ICT project management.

• The professional project management societies have a relatively highvisibility in ICT, largely because there are few other natural providers ofproject management knowledge.

• However the reality of the management task is far broader than thataddressed via PMBOK®:

o the management of technical issues is crucial;o but the real purpose of ICT projects is to deliver business/

organizational benefit: the whole interaction with strategy andvalue is central to this.

• There seem to be no public methodologies available that adequatelyintegrate the broad program (business benefit) aspects of IT (quabusiness or change) projects and the specific, detailed projectexecution management needs of projects.

Defense-aerospace

Aerospace projects are very similar to ICT projects and much if not all of theforegoing applies. However, over and above this they generally:

•

are often many orders of magnitude bigger and more complex,• involve more technical innovation,

• have procurement/ contact administration/ supply chain issues as amajor element of project delivery.

Civil aerospace projects have a much better track record generally thandefense projects: civil projects are generally much more within the control ofthe manufacturer; defense projects are produced for governments. Defenseprojects are more prone to problems of monopsonic purchasing behaviour:the tendency to change requirements, with the resulting difficulties that ensue(aggravated by the size and complexity of most projects) both to the baselineproject targets and, in contracts where the risk is transferred to the supplier, to

the supplier.

Again, in recent years there have been considerable efforts to move towardsmore partnering based approaches and to better risk allocation, withconsiderably more emphasis on front-end definition. In the UK for example awhole new approach to better risk allocation and partnership-based

8 Morris and Jamieson review four case studies exploring the move from business strategy to

project strategy drawn from construction, IT, drug development, and aerospace [17].


14/20


procurement (SMART) has been rolled-out over the last five years. The UShas put similar emphasis though without such a formal program: EarnedValue has reappeared as a DOD initiative but this time the emphasis more onobtaining value (value management etc.) than the integrated performancemeasurement of thirty or forty years ago.

The greater technical complexity of aerospace projects means that technical/commercial issues have greater prominence in aerospace project/ programmanagement – the two terms are used much more fluidly in the sector. As aresult project management is tied into several companion systemsmanagement disciplines, most notably systems engineering, configurationmanagement, CALS, and integrated logistics management9. Project/ programmanagement is thus profoundly integrated with the activity of technicallydefining the project; this occurs relative to the extended life of the product;and of course happens within a commercial and organizational context.

Project management/ systems management/ program management isundoubtedly a major discipline area in defense-aerospace. Intellectually, the

discipline is taken more seriously: DOD’s Defense Systems ManagementCollege (DSMC) for example has several teaching and research programs inthe area, as do other arms of DOD and other national defense bodies.

Overall the world of [defense-]aerospace projects is suffused by the strongimpact of technical, procurement, and organizational/people issues, bothindividually and in combination. The professional project managementsocieties are important to project management practice in this sector, but notexactly central (despite the earnest efforts of the MOD in the UK), probably forthree reasons.

• They are important because project management came, intellectually,from defense-aerospace and there is a natural disposition towards it.

• The more simple PMBOK type model of project management,however, is not as relevant as that documented by the majoraerospace enterprises, not least DOD and MOD etc.

• The professions are too small relative to the large and substantialinstitutions that dominate the industry, and cater to a broadercommunity.

Drug development projects

The pharmaceutical industry is one of the most recent of converts to projectmanagement. Ten years ago few pharma companies had anything like a

formal project management discipline in drug development; now most are wellon the way to implementing a project management capability. Many pharmacompanies have naturally reached out to the professional projectmanagement institutions for guidance; most have found that the basic

9 Systems engineering refers to the architecting of the design problem and solution

realization; configuration management to the management of the information model of theevolving product – vital for future whole life management; CALS variously means continuousacquisition and life-cycle support or computer-aided logistics support; ILS focuses on the costand supportability of equipment over the whole life-cycle of the product.


15/20


PMBOK type model does not work, partly because the language(environment) is so different; partly because of the split – mirroring that in ICT – between execution oriented project management and business drivenprogram and portfolio management is not adequately addressed by thePMBOK model.

Drug development projects are characterized by their length and their highrate of attrition10. They differ importantly from other science or engineeringbased projects in that the ‘product’ is not so much being designed or built asthe therapeutic and commercial attributes of a discovered chemical entity arebeing assessed. Hence there is not the management/ technical shapinginteraction that we have seen in the other sectors: instead the emphasis inmore on designing clinical trials and on managing support activities (materialsproduction, packaging, marketing, etc.), and balancing these against the riskof clinical failure. Many also pose significant organizational challenges: drugdevelopment generally involves several hundred scientists and thousands ofpatients, often working in teams spread between Europe, the USA and Japan.This creates special challenges of working in large matrix-based organizations

and virtual teams, staffed predominantly by scientists.

Process is overriding in drug development. The regulatory bodies require thatpotential drug candidates follow an established staged development process(Figure 6).

Figure 6: The standard drug development process

10 Out of the thousands of compounds that may be initially synthesized and screened during

discovery, only a very few typically enter into pre-clinical development; of these less than 5%might actually receive regulatory approval (and the majority of these do not then prove to beprofitable!). Doing this may take from 12 to 20 years and cost several hundred million dollars.

12

10

8

6

4

2

0

Pre-clin Phase I Phase II Phase III Registration Market

Animal toxicity, chemical

stability, superior compound

Human pharmacokinetics,toleration, formulation

Efficacy, safety

differentiation, dose

Long-term safetyNonapproval

CAN

12

10

8

6

4

2

0

Pre-clin Phase I Phase II Phase III Registration Market

Animal toxicity, chemical

stability, superior compound

Human pharmacokinetics,toleration, formulation

Efficacy, safety

differentiation, dose

Long-term safetyNonapproval

CAN


16/20


Around this, a set of management activities is positioned relating to theproject’s strategic and detailed planning and scheduling, cost management,resourcing, risk management, team/ organization development, etc. Theconsistency of the process brings considerable benefits in planning andperformance reviews. One goes through the same process rigorously timeafter time: planning templates can thus be used to schedule development

activities; metrics record how productively the candidates are being movedthrough the pipeline. Benchmarking becomes very important.

Project management was seen initially by many companies as a tactical‘execution’ activity: preparing detailed schedules, arranging meetings,following up progress. Gradually however it has been assuming a morestrategic role. At one level this has involved taking greater responsibility forcost and resource performance, and for increasing development productivity. At another, it involves the strategy-setting and leadership roles of the ‘projectdirector’ role, extending indeed into portfolio management. (Manypharmaceutical companies essentially employ two levels of projectmanagement: project managers and project directors. The former is more

concerned with controlling the project tactically, the latter with developmentstrategy. The analogy has been drawn between the roles of the director andthe producer in filmmaking.) The important point is that both levels arerequired to manage projects effectively. They are both key actors in ‘themanagement of projects’11.

Managing pharmaceutical projects effectively also involves managing theportfolio: because of attrition and because there are often more potentialcandidates than resources available to develop them. Priorities have to bemade on an on-going basis on the relative resourcing of the competingprojects in the pipeline. And as candidates attrite, new resource availabilityoptions become available which need coordinating. Decision making andresourcing within the matrix thus become major issues in drug development‘management of projects’ requiring attention at all management levels:therapeutic portfolio and programs, strategic project director, and tacticalproject manager 12.

Culture and communications are increasingly receiving attention as greaterrecognition is given to the organizational dimensions of project productivity.Effective team working is essential, and is obviously harder in a global, virtualenvironment (a completely different scenario from both construction and IT).Working in the matrix, and particularly emphasizing the strength of the projectviewpoint within an often strongly functional (line) dominated culture, is a key

11 The situation bears comparison with automotives. Many [most] auto manufacturers employ

a Project Leader as lead integrator of the technical and commercial product developmentwork, but if they recognize project management at all see it as a form of execution scheduling – à la pharma a few years ago. There is not yet an integrated model of ‘the management ofprojects’ in autos, covering both program and project management, as there is now indefense-aerospace and as is emerging in pharma.12

Programs generally seem to have slightly less significance in drug development than eitherprojects or portfolios. The equivalent to a program is probably ‘the brand’ – the chemical entityand its indications.


17/20


challenge. Start-up meetings are important opportunities to build teambehaviours and to introduce project management practices.

Comparing project management practices in cons truct ion, IT, defense-aerospace, and drug development and the implications for projectmanagement societies

There are several insights that emerge from this cross-sectoral analysis.Firstly, while there are clearly common practices, the environments in whichthey are deployed are significantly different. This leads to a difference in theway project management topics are handled. Table 1, below, shows therelative significance of topics relating to the management of projects.

Table 1: Comparison o f ‘management of projects’ practices in construction, IT,defense-aerospace, and drug development

• Defense-aerospace has scores across more topics than any othersector – a further reason why project management is more central tothis sector than to the others.

• Virtually all the classical ‘control’ project management topics arestrongly applied.

•

All the ‘organization’ topics are strong in construction but often less soin IT and drug development (with smaller technical teams in IT and lesson negotiating and conflict in drug development).

• Most of the ‘technical’ issues are strong (and particularly so in defense-aerospace), with ‘requirements’ being less in construction and drugdevelopment (going in construction, perhaps not necessarily correctly,straight to briefing and specifications and being less dominant in drugdevelopment). Configuration management is hardly known in

STRATEGIC Const'n IT Def-aero Drug dev COMMERCIAL Const'n IT Def-aero Drug dev

Portfolio Management w s/m w s Finance s m/w m/w w

Program Management w/m s s w/m Marketing w w s/m s

Project Strategy w/m s s s/m Legal s m s s

Benefits Management m/s s w m/s Procurement s m/w s m/w

Value Management s/m w s/m m (Supply Chain Management) s w s m

Risk Management s s s s Bidding (Tendering) s m s w

Quality Management s s s m Contract Administration s m s w

Health, Safety & Environment s w s m/s

TECHNOLOGY ORGANIZATION

Requirements Management w s s m/w Organization Structure s s s s

Briefing s w w w (Project Development Cycle) s s s s

Technology Management m s s s Teamwork s m s s/m

Design Management s s s N/A Leadership s s s s

Configuration Management w s s w Negotiating & Influencing s m s m

Information Management s s s s Conflict Management s m s m

(Document Management) s s s s Communications s s s s

Production Management s w s s (Stakeholder Management) s s s s

(Supply Chain Management) s w s m Career Development m m s m

(Construction Management) s N/A N/'A N/A (Competences) w w s w

(Integrated Logistics Manag't) w m/w s m Ethics m m s s

Testing m s s s

(Commissioning) s s s (s)

CONTROL

Scope Management s s s s KEY

(Change Management) s s s s Generalizations are dangerous

Estimating s s s s but the indications are:

Resource Management s s s s strong s

Scheduling s s s s medium m

(Concurrent Engineering) m w s w weak w

Budgeting s s s s not applicable N/A

Cost Control s s s s

Integrated performance meas'mt m m s w/m


18/20


construction, and is covered by regulatory affairs and documentmanagement in drug development.

• There are important differences at the ‘strategic’ level. Drugdevelopment is strongest in active portfolio management; IT in programmanagement and benefits management. Defense-aerospace is strongon program and project management. Construction is generally weaker

in all the business oriented strategy functions, for the reasonsexplained above. Drug development emphasizes project quality lessthan the other two sectors (though product quality receives hugeattention).

• Procurement related matters are much more dominant in constructionand defense-aerospace than in the other two sectors. The link withmarketing is stronger in drug development and aerospace than inconstruction and IT.

Clearly there is much more that could be said around such a comparison(including many caveats about the limitations of such generalizations). Twoimportant points stand out however: (1) the centrality of the ‘control’ topics

(which is the rationale behind PMI’s PMBOK®), and yet (2) the importancenevertheless in each of the other sectors of parts of the other functions.Technical issues are important in all; strategic issues are particularlyimportant in IT and drug development and, with program management, indefense-aerospace; procurement (and finance) are stronger in constructionand defense-aerospace. Project management in the PMBOK sense is notsufficient for the effective management of projects: these broader topics haveto be included. (Something in fact that PMI would agree with.)

This paper began by suggesting that project management was too often seenas execution oriented discipline whose theoretical basis is best represented

by the PMBOK® type model. The analysis shows that the reality of managingprojects in the most obviously project-oriented industries covers projectdefinition as much as delivery, and that strategic, technical and commercialissues are as important as control and organizational ones. Until projectmanagement is clearly seen by these industries (and by the projectmanagement societies) as including these – as including project definition aswell as implementation and execution – the discipline, and its professionalsocieties, will not be seen as relevant or important.

To the members of IPMA this may all seem rather obvious. For afterall, theIPMA Body of Knowledge – the ‘sunflower’ (Figure 7) – is largely a‘management of projects’ one. This is true, but still the issue still remains that,

as this paper has shown, the discipline is not seen as central, robust orrelevant in construction; is not as effective as it should be in IT; does notengage adequately in defense-aerospace; and is under-perceived in drugdevelopment. Ultimately this has to be because practitioners, policy makers,educators and others have yet to grasp this bigger ‘management of projects’framework, accept this as what project management really is, and then applythis to their businesses.


19/20


This, ultimately, is the challenge now facing the professional projectmanagement community.

Figure 7: The IPMA Body of Knowledge Framework

Conclusions

While the historical model of project management is centred around controland organization, increasingly it is being seen as relating also to strategic,technical and commercial issues. Too often project management is

considered to be an execution, implementation only discipline: it needs to beseen as also covering project definition, and program management.

Until this broader, more holistic view of project management is accepted thediscipline will not be seen as important and central to business performance.Getting this perception right should be the task of all professionals working inproject management today.


20/20

References

1. Project Management Institute (2000) A Guide to the Project ManagementBody of Knowledge (PMBoK® Guide) http://www.pmi.org

2. Morris, P.W.G. (1997) The Management of Projects Thomas Telford,

London, 19973. op.cit 2, Chapter 54. Association for Project Management (2000) Body of Knowledge 4th ed

http://www.apm.org.uk ; Caupin, G., Knöpfel, H., Morris, P., Motzel, E.,Pannenbäcker, O. (1998) ICB IPMA Competence Baseline, InternationalProject Management Association, Zurich http://www.ipma.ch; Engineering Advancement Association of Japan (2001), P2M: Project and ProgramManagement for Enterprise Innovation, http://www.enaa.or.op.jp; Morris,P.W.G. (2001) “Updating The Project Management Bodies Of Knowledge”Project Management Journal Vol. 32(3): 21-30, September, 200; Morris,P.W.G., Patel, M.B., and Wearne, S. H. “Research into revising the APMProject Management Body of Knowledge” International Journal of Project

Management Vol. 18(3), June 2000: 155-164.5. Rethinking construction: the report of the construction task force

Department of Trade and Industry, London, 19986. http://www.construction-institute.org/; http://www: eci.online.org 7. Construction Industry Institute (1999): Vision 2000 8. http://www.cii-benchmarking.org 9. Jorberg, R.F. (1998) An Assessment of the impact of CII, Construction

Industry Institute http://www.construction-institute.org/.10. KPMG Information Technology (2000) Unsuccessful Information

Technology projects: what went wrong; Gartner Group (2000) ResearchNote, 17 May; http://www.it-cortex.com/Stat_Failure_Rate.htm

11. Boehm, B. W. (1981) Software Engineering Economics Prentice-Hall,Englewood Cliffs; Yourdon, E. and Constantine, L.L. (1978) StructuredDesign Prentice-Hall, Englewood Cliffs

12. Boehm, B. W, (1988) “A spiral model of software development andenhancement” IEEE Computer Vol. 21 (5): 61-72; Forsberg, K., Mooz, H.,and Cotterman, H. (1996) Visualizing Project Management, Wiley, NewYork.

13. DOD Directive 5000.2-R (1996) Mandatory Procedures for Major Defense Acquisition Programs and Major Automated Information Systems Department of Defense, Washington D.C.

14. Office of Government Commerce (2002): Managing Successful Projectswith PRINCE2, The Stationery Office, London

15. Pellegrini, S. (1997) “Programme management: organizing project-basedchange” International Journal of Project Management, Vol. 15(3): 141-150;Wheelwright, S. C. and Clark, K. B. (1992) op.cit. [1]

16. Ward, J., and Peppard, J. (1999) Strategic Planning for InformationSystems John Wiley & Sons, London

17. Morris, P.W.G. and Jamieson, H. A. (2003) Moving from business strategyto project strategy Project Management Institute, Drexel Heath, Penn.

irrelevance of pm discipline

Documents