Project Management in Practice
Short Description
Details on how to manage the project by practice......
Description
e
pl
m
Sa ly
on
NEIL PEARSON E W LARSON C F GRAY
on
ly
IN PRACTICE
Sa m
pl
e
A Complete Course for BSB41513 and BSB51413
Pearson_Prelims.indd 1
3/29/2013 5:05:06 PM
Copyright © 2013 McGraw-Hill Education (Australia) Pty Ltd Additional owners of copyright are acknowledged on the acknowledgments page. Every effort has been made to trace and acknowledge copyrighted material. The authors and publishers tender their apologies should any infringement have occurred.
on
ly
Reproduction and communication for educational purposes The Australian Copyright Act 1968 (the Act) allows a maximum of one chapter or 10% of the pages of this work, whichever is the greater, to be reproduced and/or communicated by any educational institution for its educational purposes provided that the institution (or the body that administers it) has sent a Statutory Educational notice to Copyright Agency Limited (CAL) and been granted a licence. For details of statutory educational and other copyright licences contact: Copyright Agency Limited, Level 15, 233 Castlereagh Street, Sydney NSW 2000. Telephone: (02) 9394 7600. Website: www.copyright.com.au
e
Reproduction and communication for other purposes Apart from any fair dealing for the purposes of study, research, criticism or review, as permitted under the Act, no part of this publication may be reproduced, distributed or transmitted in any form or by any means, or stored in a database or retrieval system, without the written permission of McGraw-Hill Education (Australia) Pty Ltd including, but not limited to, any network or other electronic storage.
pl
Enquiries should be made to the publisher via www.mcgraw-hill.com.au or marked for the attention of the permissions editor at the address below. National Library of Australia Cataloguing-in-Publication Data
Pearson, Neil. roject management in practice: for the certificate IV and Diploma of Project Management in the BSB07 training package / Project Neil Pearson, Erik W. Larson, Clifford F. Gray. ISBN: 9781743077238 (pbk.) Notes: Includes index. roject management—Study and teaching—Handbooks, manuals, etc. Subjects: Project Other Authors/Contributors: arson, Erik W. Gray, Clifford F. Larson, Dewey Number: 658.404
Sa m
Author: Title:
Published in Australia by McGraw-Hill Education (Australia) Pty Ltd Level 2, 82 Waterloo Road, North Ryde, NSW 2113 Publisher: Norma Angeloni-Tomaras Development editor: Alex Payne Senior production editor: Claire Linsdell Permissions editor: Haidi Bernhardt Copy editor: Julie Wicks Proofreader: Angela Damis Indexer: Mary Coe Design coordinator: Dominic Giustarini Cover design: Christa Moffitt Internal design: Georgette Hall Typeset in Minion Pro Regular 9.5/12 pt by SR Nova Printed in China on 70 gsm matt art by CTPS
Pearson_Prelims.indd 2
3/29/2013 5:05:06 PM
iii
Brief Contents Part 1 Setting the Scene 1
Modern Project Management
2
2
Popular Frameworks and Methodologies
17
Organisational Strategy and Project Selection
4
Project Organisational Structures and Cultures
Defining the Scope of a Project
6
Estimating Time, Costs and Resources
7
Project Time Management
8
Project Cost Management
9
Progress ess and Performance Measurements
pl
5
e
Part 3 Defining and Managing Projects
on
3
ly
Part 2 Positioning Projects 46 79
102 130 153 212 227
Project Quality Management
Project Human Resource esource Management
286
12
Project Stakeholder Management
333
13
Project Information and Communications Management
345
14
Project Risk Management
364
15
Project Procurement Management
397
Sa m
10 11
267
Part 4 Project oject Wrap-up 16
Project Closure
428
Bonus Online Content The following additional material is available online at www.mcgraw-hill.co.uk/textbooks/pearson: • Project management career paths (Chapter 17) • Case studies, Appendices, and solutions to selected chapters
Pearson_Prelims.indd 3
3/29/2013 5:05:06 PM
iv
Contents x
PRINCE2® around the world
Acknowledgments
xii
About the Local Author Text at a Glance Text Overview
xiii
xiv xix
22
An introduction to Agile Project Management
25
Traditional versus Agile methods
25
Agile Project Management
26
Agile PM in action: Scrum
29
2
What is a project?
5
The project life cycle
7
The project manager
9
Compression of the product life cycle
35
Integrative project management
36
10
Governance and gates
37
10
PRINCE2 and PMBoK compared
10
10
Corporate downsizing
10
Sa m
11
Organisational change management
11
Small projects represent big problems
11
Project management today: a holistic approach
12
The technical and sociocultural dimensions of implementing projects
Summary
Pearson_Prelims.indd 4
®
Summary
40
41
Online Case: Introducing Scrum at P2P PART 2 Positioning Projects Chapter 3 Organisational Strategy and Project Selection
46
13
Why project managers need to understand strategy
47
13
The strategic management process: an overview
48
Alignment of projects with organisational strategy 12 Management of projects through portfolio management
33
35
Triple bottom line (planet, people, profit) Increased customer focus
32
Limitations and concerns Applying the life cycle approach
pl
Complexity
Applying Agile PM to large projects
A further introduction to PMBoK
e
The importance of project management
on
PART 1 Setting the Scene Chapter 1 Modern Project Management
21
An overview of ISO 21500:2012: guidance on project management
ly
Preface
15
Chapter 2 Popular Frameworks and Methodologies
17
An introduction to PRINCE2®
18
1. Define and review the organisational mission, vision and values
49
2. Set the organisation’s strategic objectives
52
3. Analyse the strategic objectives and identify the ‘ideal’ investment mix 52 4. Implement strategies through portfolios, programs and projects
1. The principles
18
2. The themes
19
3. The processes
20
The need for an effective portfolio management system
53
4. Tailoring
20
Problem 1: The implementation gap
54
53
3/29/2013 5:05:07 PM
Contents
Problem 2: Organisational politics
54
Problem 3: Resource conflicts and multitasking
55
92
56
Implications of organisational culture for organising projects
94
Classification of projects
56
Summary
96
Selection criteria
57
Multi-criteria selection models
59
Online Case: ORION Systems (PART B) Rosas’s Plan
64
Case: Moss and McAdams Accounting Firm
Applying a selection model Sources and solicitation of project proposals
65
Ranking proposals and selection of projects
66
Responsibility for prioritising
67
Managing the portfolio management system
67
PART 3 Defining and Managing Pr Projects Chapter 5 Defining the Scope of a Project
102
Step 1: Defining the project scope
105
ly
A portfolio management system
67
The priority team or portfolio management office responsibilities
67
Typical project scope contents
105
Balancing the portfolio for risks and dependencies
68
Establishing project priorities: the triple constraints
109
Project Portfolio Management (PPM)
69
Step 2: Creating the Work Breakdown Structure (WBS)
110
69
How WBS helps the project manager
71
Sa m
Online Case: Hector Gaming Company
Additional exercises and solutions to selected exercises Chapter 4 Project oject Organisational Structures and Cultures
79
Project management structures
80
Organising projects within the functional organisation
81
Organising projects as dedicated teams
82
Organising projects within a matrix arrangement Different matrix forms
111
WBS development
112
Practice techniques used to develop the WBS
115
pl
Summary
70
e
Prominent Project Portfolio Management (PPM) systems
on
Senior management input
Features of Project Portfolio Management (PPM) systems
Step 3: Integrating the WBS with the organisation
117
Step 4: Estimating: moving towards a draft budget and schedule
119
The scope management plan
121
Change/variation control management
121
Project scope integration
125
Summary
125
Chapter 6 Estimating Time, Costs and Resources 130 Factors influencing the quality of estimates
131
85
Planning horizon
132
85
Project duration
132
People
133
88
Project structure and organisation
133
Organisational considerations
88
Padding estimates
133
Project considerations
89
Organisational culture
133
90
Other factors
133
What is the right project management structure?
Organisational culture What is organisational culture?
Pearson_Prelims.indd 5
Identifying cultural characteristics
90
v
What is being estimated?
134
3/29/2013 5:05:07 PM
Contents
Resources
134
Durations
134
Costs
135
167
170
Laddering
170 170
Estimating guidelines for time, cost and resources
136
Use of leads and lags
Top-down versus bottom-up estimating
137
Network relationship types
171
A hybrid approach: phase estimating
139
Reducing project duration
175
Methods for estimating project costs, time and resources
140
Options for accelerating project completion 176
Rationale for reducing project duration
175
140
Options when resources are not constrained
176
Expert judgment
140
Options when resources are constrained
177
Alternative analysis
140
What if cost, not time, is the issue?
179
Parametric estimating
141
The resource scheduling problem
Analogous method
141
3-point estimate
142
Vendor bid analysis
142
Estimating tools and systems
143
e 145
Range estimating
Level of detail in estimating
Sa m
Refining estimates
pl
Template methods
Summary
145
146 147 14 7
149
Online Appendix 6.1: Learning Curves for Estimating
180
Types of resource constraints
182
Classification of a scheduling problem
183
Resource allocation methods
143 144
Learning curves
ly
Consensus methods
Function point methods for software and system projects
Pearson_Prelims.indd 6
Practical considerations
Extended network techniques to come closer to reality
on
vi
183
Assumptions
183
Time-constrained projects: smoothing resource demand
183
Resource-constrained projects
185
The impacts of resource-constrained scheduling
189
Splitting activities
189
Benefits of scheduling resources
190
Assigning project work
190
Multi-project resource schedules
191
Using the resource schedule to develop a project cost baseline
192
Project time management integration
192 193
Chapter 7 Project Project Time Management
153
Summary
Developing the project schedule
154
From work package to network
154
Online Appendix 7.1: Activity-on-arrow method
Constructing a project network
155
Appendix 7.2: The Critical-Chain Approach
Terminology
155
Case: Power Train Ltd
Two approaches
157
Basic rules to follow in developing project networks
Case: Advantage Energy Technology (AET) data centre migration
157
Activity-on-Node (AON) fundamentals
157
Additional exercises and solutions to selected exercises
The process of building the activity-on-node network
159
Using the forward and backward pass information
167
Level of detail for activities
167
Chapter 8 Project Cost Management
212
A project perspective of cost management
213
Large capital items
213
3/29/2013 5:05:07 PM
Contents
Long lead-time items
214
Performance indexes
Cost management plan
215
Project per cent complete indexes
244
216
Technical performance measurement
245
216
Software for project cost/schedule systems
245
Simple time-phased project budget structure, by WBS
218
220
What can go wrong with cost management?
223
Project cost integration management
224
Summary
225
Chapter 9 Progress and Performance Measurements
227
Structure of a project monitoring system
228 228
Collecting data and analysis
228
Reports and reporting
228
Communications Management Plan
229
Types of reports
246
Other control issues
250
Scope creep
250
Baseline changes
250
The costs and problems of data acquisition
251
Further project performance considerations 252 Summary
229
254
Online Appendix 9.1 The application of additional earned value rules Appendix 9.2 Obtaining Project Performance Information from MS Project Additional exercises and solutions to selected exercises Project Quality Chapter 10 Pr Management
267
pl
What data is collected?
246
Forecasting final project cost
ly
217
More complex time-phased project budgets
Quality and project management
268
230
Cost of Quality
268
Step 1: Setting a baseline plan
230
Step 2: Measuring progress and performance
231
Planning for Quality Assurance and Quality Control
270
Step 3: Comparing plan against actual
231
Carrying out Quality Control
278
Step 4: Taking action
231
The Pareto chart (also known as the 80/20 rule)
231
The cause–effect diagram (fishbone or Ishikawa diagrams)
279 280
Sa m
Controlling project costs, resources and schedules
Monitoring time performance
278
Tracking Gantt chart
231
Control chart
232
Run charts Check sheets
281
234
Checklists
281
Per cent complete rule
235
Benchmarking
281
What costs are included in baselines?
236
The basis of EVM
236
Development of an earned value cost/ schedule system
Developing a status report: a hypothetical example
Processes/flow charting
282
Project quality management integration
284
Summary
284
286
238
Assumptions
238
Baseline development
238
Chapter 11 Project Human Resource Management
238
Qualities of an effective project manager
287
244
Managing versus leading a project
290
Development of the EVM status report
EVM indexes to monitor progress
Pearson_Prelims.indd 7
Additional earned value rules
Simple time-phased project budget structure, by category
on
Why a time-phased budget baseline is needed
244
e
Simple time-phased budgeting
vii
3/29/2013 5:05:07 PM
viii
Contents
Building and leveraging your networks
291
Chapter 12 Project Stakeholder Management
333
Identifying and managing project stakeholders
334
Mapping dependencies
291
Management by wandering around (MBWA)
292
Managing upward relations
293
Leading by example
294
The stakeholder matrix
336
296
Influence as exchange
338
Analysis of stakeholders
340
Ethics and project management
Building trust: the key to exercising influence 296 The Human Resource Management Plan
300
Managing project teams
301
Tuckman’s five-stage team development model
302
Situational factors affecting team development
304
Building high-performance project teams
305
Recruiting project members
306
Capturing resourcing information
307
Generational theory and project teams
310
Conducting project meetings
311
The first project team meeting
311
Creating a shared vision
Managing project reward systems
Sa m
Orchestrating the decision-making process
Managing conflict within the project
345
Communication and project management
346
Communication challenges
Pitching your project: the big picture
346 347
Communication models
348
Sender–receiver model
348
The SMCR model (Berlo’s model)
349
313
350
314
Planning, developing and tracking communications
352
315 316 317
319
Encouraging functional conflict
321
Managing dysfunctional conflict
321
Rejuvenating the project team
322
Ensuring clarity of roles and responsibilities
323
Managing virtual project teams
325
Project team pitfalls
327
Developing communications
355
Project reporting
357
Project management information systems (PMIS)
358
Configuration Management (CI)
359
Project knowledge management
360
Stakeholder and communication integration management
361
Summary
362
Chapter 14 Project Risk Management
364
Groupthink
327
Bureaucratic bypass syndrome
328
Team spirit becomes team infatuation
329
Risk management process
365
Going native
329
Step 1: Establishing the risk context
368
329
Step 2: Risk identification
368
330
Step 3: Risk analysis
372
Human resource integration management Summary
A further complexity in risk analysis
374
Time: an additional factor in risk analysis
376
Probability analysis
376
Case: Cerberus Corporation
Step 4: Risk evaluation
378
Case: Kerzner Office Equipment
Step 5: Risk treatment
378
Online Appendix 11.1 Organisational Change Management
Pearson_Prelims.indd 8
Chapter 13 Pr Project oject Information and Communications Management
The Communications Management Plan
pl
Establishing a team
342
343
e
Managing subsequent project meetings
Stakeholder complexities
Summary
ly
298
on
The leadership style continuum
3/29/2013 5:05:07 PM
Contents
Threat risk response options
378
Fixed price contracts
413
Opportunity risk explored
382
Cost reimbursable contracts
414
382
Time and material contracts (T&M)
414
385
Six essential elements of a contract
414
387
Additional contract considerations
416
Step 6: Contingency planning Common methods for handling risk
Contingency funds and risk
417
388
Management reserves
388
1. Separate the people from the problem
418
Time buffers
388
2. Focus on interests, not positions
418
Risk monitoring and review
389
3. Invent options for mutual gain
419
Communication and consultation
390
4. When possible, use objective criteria
419
Risk Management Plan
390
Dealing with unreasonable people
420
Risk integration management
391
A note on managing customer relations
420
392
Project procurement integration management
423
Summary
424
on
Online Appendix 14.1 PERT and PERT simulation
Online Appendix 15.1 Request for Tender (RFT)
Appendix 14.2 RiskAMP – Monte Carlo Simulation
Chapter 16 Pr Project oject Closure
pl
Identifying procurement requirements
397 397
e
PART 4 Pr Project oject Wrap-up
Chapter 15 Project Procurement Management Procurement and project management
ly
Budget reserves
Summary
398
Types of project closure
428 429
399
Normal
430
400
Premature
430
400
Phase or stage
430
Tenders and the tender process
401
Perpetual
430
Outsourcing project work
402
Failed project
431
406
Changed priority
431
Sa m
Procurement Management Plan
Suppliers and supplier selection
Best practices in outsourcing project work
Well-defined requirements and procedures
407
Wrap-up closure activities
431
Extensive training and team-building activities
407
Creating the final report
434
Other important closure activities
435
Well-established conflict management processes in place
409
Frequent review and status updates
410
Co-location when needed
410
Performance evaluation
437
Post Implementation Review (PIR)
437
Team evaluation
438
Fair and incentive-laden contracts
411
Long-term outsourcing relationships
412
Individual team member and project manager performance reviews
441
412
Contractor and supplier evaluation
443
Contracting and contract types
Pearson_Prelims.indd 9
The art of negotiating
ix
Retrospectives (lessons learned)
444
Build, Own, Operate, Transfer (BOOT)
412
Build, Own, Operate (BOO)
413
Why retrospectives?
444
Build, Operate, Transfer (BOT)
413
Initiating the retrospective review
445
Partnerships
413
Use of an independent facilitator
445
3/29/2013 5:05:07 PM
x
Contents
Managing a retrospective
446
Overseeing a post-project retrospective
447
Project celebration
Concluding retrospective notes
450
450
Utilisation of retrospectives
449
Summary
450
Archiving retrospectives
449
ONLINE AT www.mcgraw-hill.co.uk/textbooks/pearson:
Sa m
pl
e
on
ly
Chapter 17 Project management career paths
Pearson_Prelims.indd 10
3/29/2013 5:05:07 PM
xi
Preface
Sa m
AUDIENCE
pl
e
on
ly
Since you are reading this text, you have made a decision that learning more about project management will have a positive impact for you. You are absolutely right! Project management has become an organizationwide core competency; nearly every manager, regardless of discipline is involved in managing projects. This text is designed to provide project managers and prospective project managers with the knowledge and skills that are transferable across industries and countries. Our motivation for writing this text was to provide students and practitioners alike with a holistic, integrative view of project management. A holistic view focuses on how projects contribute to the strategic goals of the organization. The linkages for integration include the process of selecting projects that best support the strategy of a particular organisation and that in turn can be supported by the technical and managerial processes made available by the organization to bring projects to completion. The goals for prospective project managers are to understand the role of a project in their organizations and to master the project management tools, techniques, and interpersonal skills necessary to orchestrate projects from start to finish. The role of projects in organisations is receiving increasing attention. Projects are the major tool for implementing and achieving the strategic goals of the organisation. In the face of intense, worldwide competition, many organisations have reorganised around a philosophy of innovation, renewal, and organisational learning to survive. This philosophy suggests an organisation that is flexible and project driven. Project management has developed to the point where it is a professional discipline having its own body of knowledge and skills. Today it is nearly impossible to imagine anyone at any level in the organisation who would not benefit from some degree of expertise in the process of managing projects.
This text is written for a wide audience. Although this text is aligned to the Australian VET sector training package for the Certificate IV and Diploma in project management and the Project Management Body of Knowledge (Fourth and Fifth editions), it covers concepts and skills that are used by managers to propose, plan, secure resources, budget, and lead project teams to successful completion. The text should prove useful to students and prospective project managers in helping them understand why organizations have developed a formal project management process to gain a competitive advantage. Readers will find the concepts and techniques discussed in enough detail to be immediately useful in any project situation. Practising project managers will find the text to be a valuable guide and reference when dealing with typical problems that arise in the course of a project. Managers will also find the text useful in understanding the role of projects in the missions of their organizations. Facilitators of VET Training may use this text as a replacement to course notes, as the text is aligned to and covers all subject material at the Certificate IV and Diploma levels. Members of the Project Management Institute will find the text is well structured to meet the needs of those wishing to prepare for PMP (Project Management Professional) or CAPM (Certified Associate in Project Management) certification exams. The text has in-depth coverage of the most critical topics found in PMI’s Project Management Body of Knowledge (PMBoK). People at all levels in the organisation assigned to work on projects will find the text useful not only in providing them with a rationale for the use of project management tools and techniques but also because of the insights they will gain on how to enhance their contributions to project success. Our emphasis is not only on how the management process works but, more importantly, on why it works. The concepts, principles and techniques are universally applicable. That is, the text does not specialise by industry type or sector. Instead, the text is written for the individual who will be required
Pearson_Prelims.indd 11
3/29/2013 5:05:07 PM
xii
Preface
to manage a variety of projects in a variety of different organisational settings. In the case of some small projects, a few of the steps of the techniques can be omitted, but the conceptual framework applies to all organisations in which projects are important to survival. The approach can be used in pure project organisations such as construction, research and engineering consultancy. At the same time, this approach will benefit organisations that carry out many small projects while the daily effort of delivering products or services continues.
CONTENT In this Australian edition of the book, we have responded to valuable feedback received from both students and teachers. As a result of this feedback, the following changes have been made to this edition:
• • • • •
ly
on
•
e
•
Restructuring estructuring of text to provide coverage of all ten areas of the fifth edition of the Project Management Body of Knowledge (2013). Further recognition ecognition and explanation of other project management methodologies such as Agile, PRINCE2 and ISO21500:2012. Localisation of the text ext to the Australian marketplace, including mapping to the VET competency framework for the Certificate IV and Diploma of Project Management. Development elopment of a number of additional online resources to provide students and facilitators (teachers) with a rich set of content. Complete e update of content to bring it in line with current project management thinking. Coverage verage of key project management documents (artefacts) typical of most projects managed under a life cycle approach. Access ccess to a number of online project management templates to visually display the structure and content of such project management documents. Greater eater consideration of the integrative nature of project management.
pl
•
Sa m
Overall the text addresses the major questions and issues the authors have encountered over their 60 combined years of teaching project management and consulting with practising project managers in domestic and foreign environments. The following questions represent the issues and problems practising project managers find consuming most of their effort: • • • •
• • • •
What is the strategic strategic role of projects in contemporary organisations? How Ho w are projects prioritised? improve chances of project success? What organisational and managerial styles will impro How w do project managers orchestrate the complex network of relationships involving vendors, subcontractors, project team members, senior management, functional managers, and customers that affect project success? What factors contribute to the development of a high-performance project team? What project management system can be set up to gain some measure of control? How do managers prepare for a new international project in a foreign culture? How does one pursue a career in project management?
Project managers must deal with all these concerns to be effective. All of these issues and problems represent linkages to an integrative project management view. The chapter content of the text has been placed within an overall framework that integrates these topics in a holistic manner. Cases and snapshots are included from the experiences of practising managers. The future for project managers appears to be promising.
Pearson_Prelims.indd 12
3/29/2013 5:05:08 PM
xiii
About the Authors NEIL PEARSON
e
on
ly
NEIL PEARSON (Ph.D.) is a freelance corporate educator and management consultant, trading as iStrategize Pty Ltd. Neil teaches at various universities, corporate businesses and professional training institutes, and is highly versed in a number of subjects including portfolio, program and project management, strategy, Quality, and information and knowledge management. Neil holds a Ph.D. in a business and ICT-related discipline, having studied project management in both his bachelor and masters degrees. He additionally has a Diploma and an Advanced Diploma in Project Management, obtained through the Australian vocational education system and has facilitated many hundreds of training sessions at the vocational level (Certificate IV, Diploma and Advanced Diploma) in Australia. Neil is a Fellow of the Australian Institute of Management (FAIM) and currently chairs the AIM (Qld & NT) Graduate School Faculty Committee, is a Blue Ocean Strategy affiliate and a Member of the Australian Institute of Project Management (AIPM). He is currently registered as a Certified Practicing Project Director (CPPD) through AIPM. Throughout his long and distinguished career in program and project management Neil has inspired and led many professional teams, working across three continents: the UK, North America and Australia. His experience includes a variety of organisations including large corporates, small to medium enterprises, educational establishments and government-related entities.
pl
ORIGINATING AUTHOR: ERIK W. LARSON
Sa m
ERIK W. LARSON is professor of project management at the College of Business, Oregon State University. He teaches executive, graduate, and undergraduate courses on project management, organizational behaviour, and leadership. His research and consulting activities focus on project management. He has published numerous articles on matrix management, product development, and project partnering. He has been honored with teaching awards from both the Oregon State University MBA program and the University of Oregon Executive MBA program. He has been a member of the Portland, Oregon, chapter of the Project Management Institute since 1984. He is a certified project management professional (PMP) and Scrum Master.
ORIGINATING AUTHOR: CLIFFORD F. GRAY CLIFFORD F. GRAY is professor emeritus of management at the College of Business, Oregon State University USA. His research and consulting interests have been divided between operations management and project management. He has published numerous articles and has conducted research in the International Project Management Association. Cliff has been a member of the Project Management Institute since 1976 and was the president of Project Management International, Inc. 1977–2005. He received his B.A. in economics and management from Millikin University, M.B.A. from Indiana University, and doctorate in operations management from the College of Business, University of Oregon. He is a certified Scrum Master.
Acknowledgments No activity is carried out in isolation; to Karen for her exemplary commitment to our family; and our children for their continued inspiration to achieve. Thanks must go to David Freeman and Peter Bail for their review of this text and their invaluable comments and suggestions. Neil Pearson
Pearson_Prelims.indd 13
3/29/2013 5:05:08 PM
xiv
Text at a Glance
ly
This text is designed to provide a holistic integrative view of project management for students and practitioners. We want students to get the most from this book, and we realise that students have different learning styles and study needs. We therefore present a number of study features to appeal to a wide range of students which are designed to test their knowledge of theory and practical skills. The text also includes a variety of real-life case studies and examples to help illustrate the key topics in each chapter.
Each chapter begins with a number of learning elements that map out the important topics and learning goals to help guide students through the chapter.
pl
e
on
▼ Learning elements
Research highlights These are summaries of relevant research projects and surveys relating to key topics in the text. They provide a fascinating background to the rationale behind the management and team work strategies described in this book and give an insight into the way these strategies are developed and verified.
Sa m
▼
▼ Snapshots from practice A series of short case studies illustrating real-life project management problems and creative solutions. The snapshots provide a fascinating insight into recent projects throughout Australia and internationally and give practical and entertaining examples of the key topics of the text in action.
Cases Selected chapters contain in-depth case studies which are designed to immerse the student in detailed, simulated projects and get them thinking about challenges and potential solutions for each unique case. Each comes with a series of exercises and tasks for the student to complete which mimic the considerations and decisions a project manager would have to make. ▼
Pearson_Prelims.indd 14
3/29/2013 5:05:13 PM
Text at a Glance
xv
on
▼
Within each chapter key terms are highlighted the first time they appear. Key terms are defined in the text. For added reference, there is a comprehensive list of key terms at the end of each chapter.
Exercises A list of exercise questions is also found in each chapter. These test students on more specific skills and knowledge that have been covered throughout the chapter. Answers to selected exercises are provided online.
▼
Chapter summary Each chapter contains a summary of the key points and topics in an easily digestible format, perfect for revision or to remind the student of the important topics in each chapter.
ly
END OF CHAPTER
e
▼ Key terms
Weblinks Websites mentioned throughout the text are listed at the end of each chapter as an easy reference guide for students. These sites can be explored to undertake additional research and to deepen understanding.
Sa m
pl
▼
These are found at the end of each chapter and are designed to get students to reflect on the important topics in each chapter and to ensure students have understood them. ▼ Review questions
IN ADDITION Selected chapters have additional appendices which can be viewed on the Online Learning Centre. These offer a deeper analysis of key topics from each chapter and also hold a range of exercise questions to test students’ understanding of the topic.
▼ Appendices to chapters
Appendix 1: Solutions to exercises Provides solutions to selected technical exercises from the text. ▼
▼ Appendix 2: Computer project exercises
Computer exercises are provided on the Online Learning Centre. These are based on simplified case studies which provide students with data from real projects that has been reduced to prevent detail overload.
Pearson_Prelims.indd 15
3/29/2013 5:05:19 PM
Q Students... Want to get better grades? (Who doesn’t?) Ready to interact with engaging online assignments that help you apply what you’ve learned? (You need to know how to use this stuff in the real world…)
With McGraw-Hill Connect
on
A
ly
Need new ways to study before the big test? (A little peace of mind is a good thing…)
STUDENTS GET:
• Interactive, engaging content
e
• Oppor Opportunities tunities to apply concepts learned in the course
Sa m
pl
• Immediate feedback on performance (No more wishing you could call your lecturer at 1 am)
• Quick access to quizzes, interactive practice materials and much more (All the resources you need to be successful are right at your fingertips)
Q Want to access Connect?
A
Connect is available if your lecturer has elected to use Connect for your course. Ask your lecturer about access.
Q
Want an eBook of this text?
A
This title is available as an eBook and is conveniently accessible via your computer, laptop or tablet device. Interact with your eBook with the search, highlighting and inserting note functions. For more information visit www.mcgraw-hill.com.au/vet
Pearson_Prelims.indd 16
3/29/2013 5:05:20 PM
Connect
Succeed
Lecturers... Would you like your students to show up for class better prepared? (Let’s face it, learning is much more fun if everyone is engaged and prepared…)
Want an instant view of student or class performance relative to learning objectives? (No more wondering if students understand…)
Want ready-made interactive assignments, student progress reporting and auto-assignment grading? (Spend less time marking…)
Need to collect data and generate reports required for administration or accreditation? (Say goodbye to manually tracking student learning outcomes…)
With McGraw-Hill Connect
on
A
ly
Q
Learn
LECTURERS GET:
e
management therefore • Simple assignment management, less administration time
Sa m
pl
The ability to identify struggling students at • The the click of a button
•
Auto-graded assignments, quizzes and tests to save time
•
Detailed visual reporting, where student and section results can be viewed and analysed at a glance
•
Sophisticated online testing capabilities
•
A filtering and reporting function that allows easy assigning and reporting on materials that are correlated to accreditation standards and learning outcomes
Q
Think learning should be a bit more interesting?
A
Find out more about Connect and Connect Plus To see how you can access these exceptional digital resources, go to www.mcgraw-hill.com.au/digital/connect
Pearson_Prelims.indd 17
3/29/2013 5:05:21 PM
xviii
Text Overview This text is written to provide the reader with a comprehensive, integrative understanding of the project management process. The text focuses both on the science of project management and the art of managing projects. CHAPTER 1 is a general introductory chapter, proving a wide background to the subject of project management. Why we do it and what it involves. Chapter 1 sets the scene for all chapters in the text and introduces the concept of using a lifecycle approach to project management. CHAPTER 2 introduces a number of project management frameworks and methodologies. Although the bulk of this text is based on the Project Management Institute’s Project Management Body of Knowledge (PMBoK), it is important for project managers to have a high level understanding of key frameworks and methodologies currently present in the marketplace; and an understanding of the key features each offers. Included in this chapter is a discussion on PRINCE2®, Agile and ISO 21500:2012 in addition to a more detailed overview of the PMI’s lifecycle approach and the PMBoK fifth edition.
on
ly
CHAPTER 3 focuses on how organisations go about evaluating and selecting projects. Special attention is devoted to the importance of linking project selection to the mission and strategic objectives of the organisation. Included in this chapter is the preparation and use of the Business Case prior to project selection and during the life of a project. The chapter also considers project prioritisation and; portfolio and program management as a backdrop to the selection of projects. CHAPTER 4 reviews the setting within which most projects exist, that is, the organisation. The different types of project structures are introduced, ranging from functional and matrix to projectised. This is supplemented with a discussion on the influence of the organisational culture on the project environment.
pl
e
CHAPTER 5 deals with defining and gaining approval for the scope of the project and the development of the project’s Work Breakdown Structure (WBS). Included in this chapter is a discussion on the importance of having a change/ variation process in place from the outset of the project.
Sa m
CHAPTER 6 details the challenge of formulating resource, cost and time estimates. The chapter utilises the information from the WBS to arrive at a project cost and duration. This is then further extended in CHAPTER 7 and CHAPTER 8, where a detailed review of Project Time Management and Project Cost Management is carried out. CHAPTER 9 brings together the scope, time and cost chapters from a performance and monitoring perspective. This chapter introduces the topic of project performance reporting with a focus on Earned Value Management (EVM). CHAPTER 10 moves onto the fourth knowledge area of PMBoK, that of project quality management. Here the importance of specifying quality is discussed (a departure from the phrase ‘fitness for purpose’); along with the discrete activities around ensuring Quality Assurance (QA) and Quality Control (QC) is adequately defined and applied in the project environment. CHAPTER 11 takes a look of the sociocultural side of project management, covering aspects such as the role and skills of the project manager. The chapter then focuses on the core project team; it combines the latest information on team dynamics with leadership skills/techniques for developing a high-performance project team. CHAPTER 12 takes a more in-depth look at stakeholders from the identification of stakeholders, to the analysis of the stakeholders, through to some of the complexities in managing stakeholders on a day-to-day basis. CHAPTER 13 is concerned with planning and developing a communications strategy for the project, the increasing role and significance of stakeholder management; in addition to the identification, scheduling and development of communications across the myriad of mediums now available to the project manager. The task of managing project information systems is also considered in this chapter. CHAPTER 14 is all about risk – beginning with the context of risk within which the organisation operates and how this influences the project environment. This is followed by an extensive discussion on the components and tools used in each part of a mature risk management standard – that of AS/NZS ISO 31000:2009 Risk management—Principles and guidelines.
Pearson_Prelims.indd 18
3/29/2013 5:05:21 PM
Text Overview
xix
CHAPTER 15 reviews the procurement aspects of project management. Procurement activities start from the Initiation phase of the project with the identification of long-lead time items and large capital items. The Procurement Management Plan is introduced along with the different types of tenders and a typical contract negotiation process. CHAPTER 16 brings the project life cycle to a close, with a discussion on project closure. Covering aspects of financial, human and project reporting. This chapter also takes a more in-depth look at lessons learned (or retrospectives). Finally CHAPTER 17 (online) provides insights into project management as a career.
Sa m
pl
e
on
ly
Note: The various websites and links used in this text (and more) have been bookmarked in the author’s social bookmarking resource located at: www.pearltrees.com/drneilpearson
Pearson_Prelims.indd 19
3/29/2013 5:05:22 PM
PMBOK and competencies matrix 1.2 1.3 1.4
1.5
1.6 1.7
What is a Project? What is Project Management? Relationships Among Portfolio Management, Program Management, Project Management, and Organisational Project Management Relationship Between Project Management, Operations Management, and Organisational Strategy Business Value Role of the Project Manager
Project Life Cycle Initiating Process Group Planning Process Group Executing Process Group Monitoring and Controlling Process Group 3.7 Closing Process Group 2.4.2 Project Phases Annex A1 The Standard for Project Management of a Project A1.3 Project Management Process Groups A1.4 Initiating Process Group A1.5 Planning Process Group A1.6 Executing Process Group A1.7 Monitoring and Controlling Process Group A1.8 Closing Process Group
2.4 3.3 3.4 3.5 3.6
Chapter 3 Organisational Strategy and Project Selection
1.4
BSBPMG521A Manage project integration (C)
BSBPMG409A Apply project scope-management techniques (C)
BSBPMG511A Manage project scope (C)
BSBPMG520A Manage project governance (E) BSBPMG417A Participate in project life cycle management processes (E)
BSBPMG417A Apply project life cycle management processes
BSBPMG520A Manage project governance (E)
PMBOK v5 CHAPTER 4 PROJECT INTEGRATION MANAGEMENT
Sa m
pl
Chapter 2 Popular Frameworks and Methodologies
Release 1 - BSB51413 Diploma of Project Management
ly
Chapter 1 Modern Project Management
Release 1 - BSB41513 Certificate IV in Project Management Practice
on
A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fifth Edition
e
Book Chapter
Relationships Among Portfolio Management, Program Management, Project Management, and Organisational Project Management Relationship Between Project Management, Operations Management, and Organisational Strategy Business Value
BSBPMG417A Apply project life cycle management processes
BSBPMG520A Manage project governance (E)
Chapter 4 Project Organisational Structures and Cultures
1.4.4 Project Management Office 2. ORGANISATIONAL INFLUENCES AND PROJECT LIFE CYCLE 2.1 Organisational Influences on Project Management 2.2 Project Stakeholders and Governance 2.3 Project Team 9.1.2.1 Organisation Charts and Position Descriptions
BSBPMG417A Apply project life cycle management processes
BSBPMG520A Manage project governance (E)
BSBPMG413A Apply project human resource management approaches (E)
BSBPMG515A Manage project human resources (C)
Chapter 5 Defining the Scope of a Project
4.1 Develop Project Charter 5.1 Plan Scope Management 5.2 Collect Requirements 5.3 Define Scope 5.4 Create WBS 5.5 Validate Scope 4.4.3.1 Change Requests 4.5 Perform Integrated Change Control 5.6 Control Scope
BSBPMG409A Apply project scope-management techniques (C)
BSBPMG511A Manage project scope (C)
1.5
1.6
Pearson_Prelims.indd 20
3/29/2013 5:05:22 PM
Key: (C) = Core (E) = Elective Book Chapter
A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fifth Edition
Release 1 - BSB41513 Certificate IV in Project Management Practice
Release 1 - BSB51413 Diploma of Project Management
Chapter 6 Estimating Time, Costs and Resources
6.4 Estimate Activity Resources 6.5 Estimate Activity Durations 7.2 Estimate Costs
BSBPMG410A Apply project time-management techniques (C)
BSBPMG512A Manage project time (C)
Chapter 7 Project Time Management
CHAPTER 6 – PROJECT TIME MANAGEMENT
BSBPMG410A Apply project time-management techniques (C)
BSBPMG512A Manage project time (C)
Chapter 8 Project Cost Management
CHAPTER 7 – PROJECT COST MANAGEMENT
BSBPMG412A Apply project cost-management techniques (E)
BSBPMG514A Manage project cost (C)
Chapter 9 Progress and Performance Measurements
3.6 Monitoring and Controlling Process Group 6.7 Control Schedule 7.4 Control Costs 8.3.1.4 Work Performance Data 10.3 Control Communications
BSBPMG412A Apply project cost-management techniques (E)
Chapter 10 Project Quality Management
CHAPTER 8 – PROJECT QUALITY MANAGEMENT
Chapter 11 Project Human Resource Management
CHAPTER 9 – PROJECT HUMAN RESOURCE MANAGEMENT
Chapter 12 Project Stakeholder Management
BSBPMG514A Manage project cost (C)
on
ly
BSBPMG412A Apply project cost-management techniques (E)
e
BSBPMG410A Apply project time-management techniques (C)
BSBPMG512A Manage project time (C) BSBPMG514A Manage project cost (C)
BSBPMG513A Manage project quality (C)
BSBPMG413A Apply project human resource management approaches (E)
BSBPMG515A Manage project human resources (C)
CHAPTER 13 – PROJECT STAKEHOLDER MANAGEMENT
BSBPMG418A Apply project stakeholder engagement techniques (E)
BSBPMG519A Manage project stakeholder engagement (E)
Chapter 13 Project Information and Communications Management
CHAPTER 10 – PROJECT COMMUNICATIONS MANAGEMENT 10.2.2.4 Information Management Systems
BSBPMG414A Apply project information management and communications techniques (E)
BSBPMG516A Manage project information and communication (C)
Chapter 14 Project Risk Management
CHAPTER 11 – PROJECT RISK MANAGEMENT
BSBPMG415A Apply project risk-management techniques (E)
BSBPMG517A Manage project risk (C)
Chapter 15 Project Procurement Management
CHAPTER 12 – PROJECT PROCUREMENT MANAGEMENT
BSBPMG416A Apply project procurement procedures (E)
BSBPMG518A Manage project procurement (E)
Chapter 16 Project Closure
2.4.2 Project Phases 3.7 Closing Process Group 4.6 Close Project or Phase 9.4.2.2 Project Performance Appraisals 9.3.2.6 Recognition and Rewards 12.4 Close Procurements
BSBPMG417A Apply project life cycle management processes
BSBPMG521A Manage project integration (C)
Chapter 17 Project Management Career Paths (online)
APPENDIX X3 INTERPERSONAL SKILLS
Pearson_Prelims.indd 21
pl
BSBPMG411A Apply project quality -management techniques (C)
Sa m
APPENDIX X3 INTERPERSONAL SKILLS
3/29/2013 5:05:22 PM
on
Learning elements
ly
CHAPTER 4 PROJECT ORGANISATIONAL STRUCTURES AND CULTURES
Understand stand the different project organisational structures that broadly define how the project fits with the organisational structures that may already exist in an organisation.
4.2
Realise ealise the importance of an organisation’s culture and the effect it can have on the management of a project.
Sa m
In this chapter
pl
e
4.1
• Project management structures management structures
• What is the right project management right project management structure?
• Implications of organisational culture for organising projects • Summary
• Organisational culture Organisational culture
Introduction The previous chapter looked at the strategic alignment of investments (portfolios, programs and projects), and the prioritisation of programs and projects within a portfolio. The chapter closed with a resulting list of approved programs and projects to be delivered by the accountable business managers. The question this chapter seeks to answer is what project structures and organisational cultures does the project manager have options to operate within? This chapter examines three different project management structures used by firms to implement projects. These structures typically overlay the organisational structures already in place and are referred to in project management terminology as the functional organisational structure, the dedicated project team structure and the three types of matrix structures. Although not exhaustive, these structures and their variant forms represent the major approaches for organising projects in organisations. The advantages and disadvantages of each of these structures are discussed as well as some of the critical factors that might lead an organisation to choose one form over the others.
Pearson_Ch04.indd 79
4/1/2013 6:49:26 AM
80
PART 2 Positioning Projects
on
ly
Whether an organisation chooses to complete projects within the traditional functional organisation or through some form of matrix arrangement is only part of the story. Anyone who has worked for more than one organisation realises that there are often considerable differences in how projects are managed within certain organisations with similar structures. For example, working in a matrix system at AT&T is different from working in a matrix environment at Hewlett-Packard. Many researchers attribute these differences to the organisational culture at AT&T and Hewlett-Packard. A simple explanation of organisational culture is that it reflects the ‘personality’ of an organisation. Just as each individual has a unique personality, so each organisation has a unique culture. Toward the end of this chapter, we examine in more detail what organisational culture is and the impact that the culture of the parent organisation has on organising and managing projects. Both the project management structure and the culture of the organisation constitute major elements of the environment in which projects are implemented. It is important for project managers and participants to know the ‘lay of the land’ so that they can avoid obstacles and take advantage of pathways to complete their projects. Although the culture within which the project occurs is not formally documented, the project organisational structure is documented within the Scope document and/or the Human Resource Management Plan, thus providing a clear indication of how the project team is structured. The project organisational chart will also outline the interactions in terms of resources committed and governance committees.
pl
e
Project management structures structures
Sa m
A project management system provides a framework for launching and implementing project activities within a parent organisation. A good system appropriately balances the needs of both the parent organisation and the project by defining the interface between the project and parent organisation in terms of authority, allocation of resources and eventual integration of project outcomes into mainstream operations. ACME Services Pty Ltd CEO
Project coordination
Marketing
Domestic sales
Finance and administration
Engineering
Electronics engineering
Customer service
Human resources
Software engineering
International sales
Mechanical engineering
M
Design
Fabrication
Figure 4.1 Functional organisations
Pearson_Ch04.indd 80
4/1/2013 6:49:27 AM
Assemb
chAPTeR 4 Project Organisational Structures and Cultures
81
Many business organisations have struggled with creating a system for organising projects while managing ongoing operations. One of the major reasons for this struggle is that projects contradict fundamental design principles associated with traditional organisations. Projects are unique, one-time efforts with a distinct beginning and end. Most organisations are designed to efficiently manage ongoing activities. Efficiency is achieved primarily by breaking down complex tasks into simplified, repetitive processes, as symbolised by assembly-line production methods. Projects are not routine and therefore can be like ducks out of water in these work environments. With this in mind, we will start the discussion of project management structures.
ORgAnISIng PROjecTS WIThIn The FuncTIOnAl ORgAnISATIOn
ACME Services Pty Ltd CEO
anical eering
Sa m
pl
e
on
ly
One approach to organising projects is to simply manage them within the existing functional hierarchy of the organisation. Once management decides to implement a project, the different segments of the project are delegated to the respective functional units with each unit responsible for completing its segment of the project (see Figure 4.1). Coordination is maintained through normal line management channels. For example, a tool manufacturing firm decides to differentiate its product line by offering a series of tools specially designed for lefthanded individuals. Top management decides to implement the project, and different segments of the project are distributed to appropriate areas. The industrial design department is responsible for modifying specifications to conform to the needs of left-handed users. The production department is responsible for devising the means for producing new tools according to these new design specifications. The marketing department is responsible for gauging demand and price as well as identifying distribution outlets. The overall project will be managed within the normal hierarchy, with the project being part of the working agenda of top management. The functional organisation is also commonly used when, given the nature of the project, one functional area plays a dominant role in completing the project or has a dominant interest in the success of the project. Under these circumstances, a high-ranking manager in that area is given the responsibility of coordinating the project. For example, the transfer of equipment and personnel to a new office would be managed by a senior manager in the firm’s facilities department. Likewise, a project involving the upgrading of the Management Information System (MIS) would be managed by the Information Systems Department. In both cases, most of the project work would be done within the specified department and coordination with other departments would occur through normal channels. There are advantages and disadvantages for using the existing functional organisation to administer and complete projects. The major advantages include the following:
Finance and administration
Manufacturing
Purchasing
Design
Fabrication
Pearson_Ch04.indd 81
Procurement
Assembly
Testing
Receiving and inspection
Production scheduling
4/1/2013 6:49:27 AM
82
PART 2 Positioning Projects
1 2
3 4
No change to the existing functional organisational structure. Projects are completed within the basic functional structure of the organisation. There is no radical alteration in the design and operation of the organisation to facilitate the delivery of the project. Flexibility. There is maximum flexibility in the use of staff. Appropriate specialists in different functional units can temporarily be assigned to work on the project and then return to their normal work. With a broad base of technical personnel available within each functional department, people can be switched among different projects with relative ease. In-depth expertise. If the scope of the project is narrow and the proper functional unit is assigned primary responsibility, then in-depth expertise can be brought to bear on the most crucial aspects of the project. Easy post-project transition. Normal career paths within a functional division are maintained. While specialists can make significant contributions to projects, their functional field is their professional home and the focus of their professional growth and advancement.
4
on
e
3
pl
2
Lack of focus.. Each functional unit has its own core routine work to do; sometimes project responsibilities get pushed aside to meet primary operational obligations. This difficulty is compounded when the project has different priorities for different units. For example, the marketing department may consider the project urgent while the operations people considered it only of secondary importance. Imagine the tension if the marketing people have to wait for the operations people to complete their segment of the project before they proceed. Poor integration.. There may be poor integration across functional units. Functional specialists tend to be concerned only with their segment of the project and not with what is best for the total project. Slow.. It generally takes longer to complete projects through this functional arrangement. This is in part attributable to slow response time; project information and decisions have to be circulated through normal management channels. Furthermore, the lack of horizontal, direct communication among functional groups contributes to rework as specialists realise the implications of others’ actions after the fact. Lack of ownership.. The motivation of people assigned to the project can be weak. The project may be seen as an additional burden that is not directly linked to their professional development or advancement. Furthermore, because they are working on only a segment of the project, professionals do not identify with the project. Lack of ownership discourages strong commitment to project-related activities.
Sa m
1
ly
Just as there are advantages for organising projects within the existing functional organisation, there are also disadvantages. These disadvantages are particularly pronounced when the scope of the project is broad and one functional department does not take the dominant technological and managerial lead on the project:
ORgAnISIng PROjecTS AS dedIcATed TeAmS PROjecTS AS PROjec TS AS ded dedII At the other end of the structural spectrum is the creation of dedicated project teams. These teams operate as separate units from the rest of the parent organisation. Usually a full-time project manager is designated to pull together a core group of specialists who work full time on the project. The project manager recruits necessary personnel from both within and outside the parent company. The subsequent team is physically separated from the parent organisation and given marching orders to complete the project (see Figure 4.2). The interface between the parent organisation and the project teams will vary. In some cases, the parent organisation maintains a tight rein through financial controls. In other cases, firms grant the project manager maximum freedom to get the project done as they see fit. In the case of firms where projects are the dominant form of business, such as a construction firm or a consulting firm, the entire organisation is designed to support project teams. Instead of one or two special projects, the organisation consists of sets of quasi-independent teams working on specific projects. The main responsibility of traditional functional departments is to assist and support these project teams. For example, the marketing department is directed at generating new business that will lead to more projects, while the human resource department is responsible for managing a variety of personnel issues as well as recruiting and training new employees. This type of organisation is referred to in the project management literature as a projectised organisation and is graphically portrayed in Figure 4.3. It is important to note that not all projects are dedicated project teams; personnel can work part-time on several projects.
Pearson_Ch04.indd 82
4/1/2013 6:49:28 AM
83
chAPTeR 4 Project Organisational Structures and Cultures
ACME Services Pty Ltd CEO
Human resources
Marketing
Finance and administration
Engineering
Manufacturing
Procurement
ly
Project manager
on
Figure 4.2 Dedicated project team
Project team
As in the case of functional organisation, the dedicated project team approach has strengths and weaknesses. The following are recognised as strengths:
Other projects
Sa m
pl
2
Simple. Other than taking away resources in the form of specialists assigned to the project, the functional organisation remains intact with the project team operating independently. Fast. Projects tend to get done more quickly when participants devote their full attention to the project and are not distracted by other obligations and duties. Furthermore, response time tends to be quicker
e
1
ACME Services Pty Ltd CEO
Marketing
Human resources
Finance and administration
Legal
Alpha Project Project Manager
Engineering
Manufacturing
Electrical Mechanical Software
Fabrication Assembly Test
Beta Project Project Manager
Procurement
Engineering Systems Hardware Software Manufacturing
Figure 4.3 Projectised organisational structure
Pearson_Ch04.indd 83
Other projects
Subcontractors Subcontractor X Subcontractor Y Subcontractor Z Procurement
Assembly Test
4/1/2013 6:49:28 AM
84
PART 2 Positioning Projects
3 4
under this arrangement because most decisions are made within the team and are not deferred up the hierarchy. Cohesive. A high level of motivation and cohesiveness often emerges within the project team. Participants share a common goal and personal responsibility toward the project and the team. Cross-functional integration. Specialists from different areas work closely together and, with proper guidance, become committed to optimising the project, not their respective areas of expertise.
In many cases, the project team approach is the optimum approach for completing a project when you view it solely from the standpoint of what is best for completing the project. Its weaknesses become more evident when the needs of the parent organisation are taken into account: 1
e
3
on
ly
2
Expensive. Not only have you created a new management position (project manager), but resources are also assigned on a full-time basis. This can result in duplication of efforts across projects and a loss of economies of scale. Internal strife.. Sometimes dedicated project teams take on an entity of their own and a disease known as ‘projectitis’ develops. See Snapshot from practice: Projectitis: the dark side to project teams. teams A strong we–they divisiveness emerges between the project team and the parent organisation. This divisiveness can undermine not only the integration of the eventual outcomes of the project into mainstream operations, but also the assimilation of project team members back into their functional units once the project is completed. Limited technological expertise.. Creating self-contained teams inhibits maximum technological expertise being brought to bear on problems. Technical expertise is limited somewhat to the talents and experience of the specialists assigned to the project. While nothing prevents specialists from
pl
SNAPSHOT FROM PRACTICEP Projectitis: rojectitis: the dark side to project teams
Sa m
One of the advantages of creating dedicated project teams is that project participants from different functional areas can develop into a highly cohesive work team that is strongly committed to completing the project. While such teams often produce Herculean efforts in pursuit of project completion, there is a negative dimension to this commitment that is often referred to in the literature as projectitis. A we–they attitude can emerge between project team members and the rest of the organisation. The project team succumbs to hubris and develops a holier-than-thou attitude that antagonises the parent organisation. People not assigned to the project become jealous of the attention and prestige being showered on the project team, especially when they believe that it is their hard work that is financing the endeavour. The tendency to assign project teams exotic titles such as ‘Silver Bullets’ and ‘Tiger Teams’, as well as give them special perks, tends to intensify the gap between the project team and the parent organisation. Such appears to have been the case with Apple’s highly successful Macintosh development team. Steve Jobs, who at the time was both the chairman of Apple and the project manager for the Mac team, pampered his team with perks including at-the-desk massages, coolers stocked with freshly squeezed orange juice, a Bosendorfer grand piano and first-class plane tickets. No other employees at Apple got to travel first class. Jobs considered his team to be the elite of Apple and had a tendency to refer to everyone else as ‘Bozos’ who ‘didn’t get it’. Engineers from the Apple II division, which was the bread and butter of Apple’s sales, became incensed with the special treatment their colleagues were getting. One evening at Ely McFly’s, a local watering hole, the tensions between Apple II engineers seated at one table and those of a Mac team at another boiled over. Aaron Goldberg, a long-time industry consultant, watched from his barstool as the squabbling escalated. ‘The Mac guys were screaming, “We’re the future!” The Apple II guys were screaming, “We’re the money!” Then there was a geek brawl. Pocket protectors and pens were flying. I was waiting for a notebook to drop, so they would stop and pick up the papers.’ Although comical from a distance, the discord between the Apple II and Mac groups severely hampered Apple’s performance during the 1980s. John Sculley, who replaced Steve Jobs as chairman of Apple, observed that Apple had evolved into two ‘warring companies’ and referred to the street between the Apple II and Macintosh buildings as ‘the DMZ’ (demilitarised zone). Source: J. Carlton, Apple: The Inside Story of Intrigue, Egomania, and Business Blunders (New York: Random House, 1997), pp. 13–14; J. Sculley, Odyssey: Pepsi to Apple . . . A Journey of Adventure, Ideas, and the Future (New York: Harper & Row, 1987), pp. 270–9.
Pearson_Ch04.indd 84
4/1/2013 6:49:29 AM
chAPTeR 4 Project Organisational Structures and Cultures
4
85
consulting with others in the functional division, the we–they syndrome and the fact that such help is not formally sanctioned by the organisation discourage this from happening. Difficult post-project transition. Assigning full-time personnel to a project creates the dilemma of what to do with personnel after the project is completed. If other project work is not available, then the transition back to their original functional departments may be difficult because of their prolonged absence and the need to catch up with recent developments in their functional area. For example, an employee may be ‘seconded’ to a project from the business. The seconded person’s role may have then been backfilled with a temporary employee; when the seconded person is returned to the business careful planning with HR would be required in order that the temporary employee is released before the ‘seconded’ person is able to return to their substantive position within the business.
ORgAnISIng PROjecTS WIThIn A mATRIx ARRAngemenT
Sa m
pl
e
on
ly
Matrix management is a hybrid organisational form in which a horizontal project management structure is ‘overlaid’ on top of the normal functional hierarchy. In a matrix system, there are usually two chains of command, one along functional lines (reporting to the line manager) and the other along project lines (reporting to the project manager). Instead of delegating segments of a project to different units or creating an autonomous team, project participants report simultaneously to both functional and project managers. Companies apply this matrix arrangement in a variety of different ways. Some organisations set up temporary matrix systems to deal with specific projects, while the ‘matrix’ structure may be a permanent fixture in other organisations. Let us first look at its general application and then proceed to a more detailed discussion of finer points. Consider Figure 4.4. There are three projects currently under way: A, B and C. All three projects have a dedicated project manager reporting to the director of project management, who supervises all projects. Each project has an administrative assistant, although the one for project C is only part time. Project A involves the design and expansion of an existing production line to accommodate new metal alloys. To accomplish this objective, project A has assigned to it 4.5 people from manufacturing and 6 people from engineering. These individuals are assigned to the project on a part-time or full-time basis, depending on the project’s needs during various phases of the project. Project B involves the development of a new product that requires the heavy representation of engineering, manufacturing and marketing. Project C involves forecasting changing needs of an existing customer base. While these three projects, as well as others, are being completed, the functional divisions continue performing their basic, core activities. The matrix structure is designed to optimally utilise resources by having individuals work on multiple projects as well as being capable of performing normal functional duties. At the same time, the matrix approach attempts to achieve greater integration by creating and legitimising the authority of a project manager. In theory, the matrix approach provides a dual focus between functional/technical expertise and project requirements that is missing in either the dedicated project team or functional approach to project management as outlined previously. This focus can most easily be seen in the relative input of functional managers and project managers over key project decisions (see Table 4.1).
dIFFeRenT mATRIx FORmS In practice there are three key kinds of matrix systems, depending on the relative authority of the project and functional managers. The following is an outline of the three kinds of matrix forms:
•
•
Pearson_Ch04.indd 85
Weak matrix. This form is very similar to a functional approach with the exception that there is a formally designated project manager responsible for coordinating project activities. Functional managers are responsible for managing their segment of the project. The project manager basically acts as a staff assistant who draws the schedules and checklists, collects information on status of work and facilitates project completion. The project manager has indirect authority to expedite and monitor the project. Functional managers call most of the shots and decide who does what and when the work is completed. Balanced matrix. This is the classic matrix in which the project manager is responsible for defining what needs to be accomplished while the functional managers are concerned with how it will be accomplished. More specifically, the project manager establishes the overall plan for completing the project, integrates the contribution of the different disciplines, sets schedules and monitors progress. The functional managers are responsible for assigning personnel and executing their segment of the project according
4/1/2013 6:49:29 AM
86
PART 2 Positioning Projects
ACME Services Pty Ltd CEO
Human resources
Financ
Director of projects
Engineering
Project C project manager
2
1
3
1
1
Software engineering
2
Project A team
1 Project B team
1/2
1
Project C team
Technical documentation
1
1
Assembly
Testing
1
2
1/2
1
1
1
pl
Figure 4.4 Matrix organisational structure
Mechanical engineering
on
Project B project manager
Electronics engineering
e
Project A project manager
Design engineering
ly
Project administration
Manufacturing
Sa m
Table 4.1 Division ivision of project manager and functional manager responsibilities in a matrix structure PROjecT mAnAgeR
negOTIATed ISSueS neg egOTIAT OTIATed OTIAT ed ISS
FuncTIOnAl mAnAgeR
What has to be done?
Who will do the task?
How will it be done?
When should the task be done?
Where will the task be done?
How will the project involvement impact normal functional activities?
How much money is available to do the task?
Why will the task be done?
How well has the functional input been integrated?
How well has the total project been done?
Is the task satisfactorily completed?
•
Pearson_Ch04.indd 86
to the standards and schedules set by the project manager. The merger of ‘what and how’ requires both parties to work closely together and jointly approve technical and operational decisions. Strong matrix. This form attempts to create the ‘feel’ of a project team within a matrix environment. The project manager controls most aspects of the project, including scope trade-offs and assignment of functional personnel. The project manager controls when and what specialists do and has final say on major project decisions. The functional manager has title over her people and is consulted on a need basis. In some situations a functional manager’s department may serve as a ‘subcontractor’ for the project, in which case they have more control over specialised work. For example, the development of a new series of laptop computers may require a team of experts from different disciplines working on the basic design and performance requirements within a project matrix arrangement. Once the
4/1/2013 6:49:30 AM
chAPTeR 4 Project Organisational Structures and Cultures
87
ACME Services Pty Ltd CEO
Finance
Manufacturing
Assembly
Testing
Customer service
Quality
1
2
1/2
1
1
1
1
1
1
International sales
1
2
1
1/2
2
2
pl
e
2
Domestic sales
ly
Technical documentation
on
Mechanical engineering
Marketing
specifications have been determined, final design and production of certain components (e.g. power source) may be assigned to respective functional groups to complete.
1 2 3 4
Sa m
Matrix management both in general and in its specific forms has unique strengths and weaknesses. The advantages and disadvantages of matrix organisations in general are noted below, while only briefly highlighting specifics concerning different forms: Efficient.. Resources can be shared across multiple projects as well as within functional divisions. Individuals can divide their energy across multiple projects on an as-needed basis. This reduces duplication required in a projectised structure. Strong trong project focus. focus. A stronger project focus is provided by having a formally designated project manager who is responsible for coordinating and integrating the contributions of different units. This helps sustain a holistic approach to problem solving that is often missing in the functional organisation. Easier post-project transition. Because the project organisation is overlaid on the functional divisions, specialists maintain ties with their functional group, so they have a substantive role to return to once the project is complete. Flexible. Matrix arrangements provide for flexible utilisation of resources and expertise within the firm. In some cases functional units may provide individuals who are managed by the project manager. In other cases the functional manager monitors the contributions.
The strengths of the matrix structure are considerable. Unfortunately, so are the potential weaknesses. This is due in large part to the fact that a matrix structure is more complicated and the creation of multiple bosses represents a radical departure from the traditional hierarchical authority system. Furthermore, one does not install a matrix structure overnight. Experts argue that it takes three to five years for a matrix system to fully mature. So many of the problems described below represent growing pains. 1
Pearson_Ch04.indd 87
Dysfunctional conflict. The matrix approach is predicated on tension between functional managers and project managers who bring critical expertise and perspectives to the project. Such tension is viewed
4/1/2013 6:49:30 AM
88
PART 2 Positioning Projects
2 3
ly
4
as a necessary mechanism for achieving an appropriate balance between complex technical issues and unique project requirements. While the intent is noble, the effect is sometimes analogous to opening Pandora’s box. Legitimate conflict can spill over to a more personal level, resulting from conflicting agendas and accountabilities. Worthy discussions can degenerate into heated arguments that engender animosity among the managers involved. Infighting. Any situation in which equipment, resources and people are being shared across projects and functional activities lends itself to conflict and competition for scarce resources. Infighting can occur among project managers, who are primarily interested in what is best for their project. Stressful. Matrix management violates the management principle of unity of command. Project participants have at least two bosses—their functional manager and one or more project managers. Working in a matrix environment can be extremely stressful. Imagine what it would be like to work in an environment in which you are being told to do three potentially conflicting things by three different managers. Slow.. In theory, the presence of a project manager to coordinate the project should accelerate the completion of the project. In practice, decision-making can get bogged down as agreements have to be forged across multiple functional groups. This is especially true for the balanced matrix.
pl
e
on
When the three variant forms of the matrix approach are considered, we can see that advantages and disadvantages are not necessarily true for all three forms of matrix. The strong matrix is likely to enhance project integration, diminish internal power struggles and ultimately improve control of project activities and costs. On the downside, technical quality may suffer because functional areas have less control over their contributions. Finally, projectitis may emerge as the members develop a strong team identity. The weak matrix is likely to improve technical quality as well as provide a better system for managing conflict across projects because the functional manager assigns personnel to different projects. The problem is that functional control is often maintained at the expense of poor project integration. The balanced matrix can achieve better balance between technical and project requirements, but it is a very delicate system to manage and is more likely to succumb to many of the problems associated with the matrix approach.
Sa m
What is the right project management structure? project management There is growing empirical evidence that project success is directly linked to the amount of autonomy and authority project managers have over their projects. However, most of this research is based on what is best for managing specific projects. It is important to remember what was stated in the beginning of the chapter—that the best system balances the needs of the project with those of the parent organisation. So what project structure should an organisation use? This is a complicated question with no precise answers. A number of issues need to be considered at both the organisation and project level.
ORgAnISATIOnAl cOnSIdeRATIOnS cO c On nSI SIde de At the organisation level, the first question that needs to be asked is how important is project management to the success of the firm? What percentage of core work involves projects? If over 75 per cent of work involves projects, then an organisation should consider a fully projectised organisation. If an organisation has both operations and projects, then a matrix arrangement would appear to be appropriate. If an organisation has very few projects, then a less formal arrangement is probably all that is required. Dedicated teams could be created on an as-needed basis and the organisation could outsource project work. A second key question is resource availability. Remember, matrix evolved out of the necessity to share resources across multiple projects and functional domains while at the same time creating legitimate project leadership. For organisations that cannot afford to tie up critical personnel on individual projects, a matrix system would appear to be appropriate. An alternative would be to create a dedicated team but outsource project work when resources are not available internally. Within the context of the first two questions, an organisation needs to assess current practices and what changes are needed to more effectively manage projects. A strong project matrix is not installed overnight. The shift toward a greater emphasis on projects has a host of political implications that need to be worked through, requiring time and strong leadership. For example, we have observed many companies that make the transition
Pearson_Ch04.indd 88
4/1/2013 6:49:30 AM
chAPTeR 4 Project Organisational Structures and Cultures
89
from a functional organisation to a matrix organisation begin with a weak functional matrix. This is due in part to resistance by functional and department managers toward transferring authority to project managers. With time, these matrix structures eventually evolve into a project matrix. Many organisations have created project management offices (PMO) (as introduced in Chapter 2) to support project management efforts. See Snapshot from practice: Project management offices.
PROjecT cOnSIdeRATIOnS
1 2 3 4 5 6 7
size of project strategic importance novelty and need for innovation need for integration (number of departments involved) environmental complexity (number of external interfaces) budget and time constraints stability of resource requirements.
ly
At the project level, the question is how much autonomy the project needs in order to be successfully completed. Hobbs and Ménard (1993) identified seven factors that should influence the choice of project management structure as:
e
on
The higher the levels of these seven factors, the more autonomy and authority the project manager and project team need to be successful. This translates into using either a dedicated project team or a project matrix structure. For example, these structures should be used for large projects that are strategically critical and are new to the company, thus requiring much innovation. These structures would also be appropriate for complex, multidisciplinary projects that require input from many departments, as well as for projects that require constant contact with customers to
pl
SNAPSHOT FROM PRACTICEP Project roject management offices
Sa m
Project management offices (PMOs) were originally developed as a response to the poor track record many companies had in completing projects on time, within budget and according to plan. They were often established to help matrix systems mature into more effective project delivery platforms. Today, PMOs come in many different shapes and forms. One interesting way of classifying PMOs was set forth by Casey and Peck, who describe certain PMOs in terms of being (1) a weather station, (2) a control tower or (3) a resource pool. Each of these models performs a very different function for its organisation. • Weather station. station. The primary function of the weather station PMO is to track and monitor project performance. It is typically created to satisfy top management’s need to stay on top of the portfolio of programs and projects under way in the firm. Staff provides an independent forecast of project performance. The questions answered for specific projects include: • How are our projects progressing? Which ones are on track? Which ones are not? • How are we doing in terms of cost? Which projects are over or under budget? • What are the major problems confronting projects? Are contingency plans in place? What can the organisation do to help the project? • Control tower. The primary function of the control tower PMO is to improve project execution. It considers project management as a profession to be protected and advanced. The PMO identifies best practices and standards for project management excellence. They work as consultants and trainers to support project managers and their teams. • Resource pool. The goal of the resource pool PMO is to provide the organisation with a cadre of trained project managers and professionals. It operates like an academy for continually upgrading the skills of a firm’s project professionals. In addition to training, this kind of PMO also serves to elevate the stature of project management within the organisation. Source: W. Casey and W. Peck, ‘Choosing the Right PMO Setup,’ PM Network, vol. 15, no. 2(2001), pp. 40–47. In practice your PMO may offer all three of these functions and more.
Pearson_Ch04.indd 89
4/1/2013 6:49:31 AM
90
PART 2 Positioning Projects
ly
assess their expectations. Dedicated project teams should also be used for urgent projects in which the nature of the work requires people working steadily from beginning to end. Many firms that are heavily involved in project management have created a flexible management system that organises projects according to project requirements. For example, Chaparral Steel, a mini-mill that produces steel bars and beams from scrap metal, classifies projects into three categories: advanced development, platform and incremental. Advanced development projects are high-risk endeavours involving the creation of a breakthrough product or process. Platform projects are medium-risk projects involving system upgrades that yield new products and processes. Incremental projects are low-risk, short-term projects that involve minor adjustments in existing products and processes. At any point in time, Chaparral might have 40–50 projects under way, of which only one or two are advanced, three to five are platform projects and the remainder are small, incremental projects. The incremental projects are almost all done within a weak matrix with the project manager coordinating the work of functional subgroups. A strong matrix is used to complete the platform projects, while dedicated project teams are typically created to complete the advanced development projects. More and more companies are using this ‘mix and match’ approach to managing projects. A further discussion of project organisational structures can be found in PMBoK. Refer to pages 19–26 of the fifth edition.
on
Organisational culture
Sa m
pl
e
So how does the organisational culture affect the selection of which project organisation to apply? Let’s look at two organisations, one a long-established government department and the other a commercial organisation that prides itself on the ability to get products to market quickly. In the first organisation (a long-established government organisation), people are tasked to both operational day-to-day activities (on tightly defined employment contracts under the auspice of an Enterprise Bargaining Agreement) and also, for a percentage of their time, to projects. As the projects cannot be organised (or funded) with dedicated project personnel, the project managers and the employees resourced to the projects come from across the business and a weak matrix organisational structure takes shape. The managers, who are also the project managers, closely manage the workload of the employees to ensure that both the operational day-to-day activities are carried out as well as tasks allocated to the employees in respect to delivering the projects. The arrangement works well as the department has no pressures upon it to bring products to market (although projects do have to be completed to the agreed schedule), so the daily customer facing activities can be met. The commercial organisation has great success in using dedicated project teams, is resourced to carry out all aspects of the project and reports to a full-time project manager who is fully engaged to deliver the project in the most efficient manner possible. The support functions within the business provide services to the project, such as human resource and procurement services. The culture of the organisation is to rotate project resources around the projects and to give the project employees a choice of which projects to participate in. This works well for the organisation, as there are more projects in the pipeline than there are people to carry out the projects. The project employees get to choose the subject nature of the project they wish to be involved in (as opposed to being allocated on a prearranged basis) and the organisation, in most cases, fills the project roles with employees who are interested and passionate about the project. Gaining efficiencies in the ‘marriage’ between the organisation’s culture, the organisational structure and the project structure is often a learning exercise and one structure (solution) may not fit all projects. Smaller projects could be delivered within a weak matrix structure; however, larger complex projects often require dedicated project structures.
WhAT IS ORgAnISATIOnAl culTuRe? Organisational culture refers to a system of shared norms, beliefs, values and assumptions that bind people together, thereby creating shared meanings. This system is manifested by customs and habits that exemplify the values and beliefs of the organisation. For example, egalitarianism may be expressed in the informal dress worn at a high-tech firm. Conversely, mandated uniforms at a department store reinforce respect for the hierarchy.
Pearson_Ch04.indd 90
4/1/2013 6:49:31 AM
chAPTeR 4 Project Organisational Structures and Cultures
91
Culture reflects the personality of the organisation and, similar to an individual’s personality, can enable us to predict attitudes and behaviours of employees. Culture is also one of the defining aspects of an organisation that sets it apart from other organisations, even in the same industry. Research suggests that there are ten primary characteristics which, in aggregate, capture the essence of an organisation’s culture:
on
ly
1 Member identity. The degree to which employees identify with the organisation as a whole rather than with their type of job or field of professional expertise. 2 Team emphasis. The degree to which work activities are organised around groups rather than individuals. 3 Management focus. The degree to which management decisions take into account the effect of outcomes on people within the organisation. 4 Unit integration. The degree to which units [departments] within the organisation are encouraged to operate in a coordinated or interdependent manner. 5 Control. The degree to which rules, policies and direct supervision are used to oversee and control employee behaviour. 6 Risk tolerance. The degree to which employees are encouraged to be aggressive, innovative and risk seeking. 7 Reward criteria. The degree to which rewards such as promotion and salary increases are allocated according to employee performance rather than seniority, favouritism or other non-performance factors. 8 Conflict tolerance.. The degree to which employees are encouraged to air conflicts and criticisms openly. 9 Means versus end orientation. The degree to which management focuses on outcomes rather than on techniques and processes used to achieve those results. 10 Open-systems focus.. The degree to which the organisation monitors and responds to changes in the external environment.
Sa m
pl
e
As shown in Figure 4.5, each of these dimensions exists on a continuum. Assessing an organisation according to these ten dimensions provides a composite picture of the organisation’s culture. This picture becomes the basis for feelings of shared understanding that the members have about the organisation, how things are done and the way members are supposed to behave. Culture performs several important functions in organisations. 1. Member identity Job Organisation An organisation’s culture provides a sense of identity for its members. 2. Team emphasis The more clearly an organisation’s shared perceptions and values are Individual Group stated, the more strongly people can identify with their organisation 3. Management focus Task People and feel a vital part of it. Identity generates commitment to the 4. Unit integration organisation and reasons for members to devote energy and loyalty Independent Interdependent to the organisation. 5. Control Loose Tight A second important function is that culture helps legitimise 6. Risk tolerance the management system of the organisation. Culture helps clarify Low High authority relationships. It provides reasons why people are in a 7. Reward criteria Performance Other position of authority and why their authority should be respected. 8. Conflict tolerance Most importantly, organisational culture clarifies and reinforces Low High standards of behaviour. Culture helps define what is permissible 9. Means-ends orientation Means Ends and inappropriate behaviour. These standards span a wide range of 10. Open-system focus behaviour from dress code and working hours to challenging the Internal External judgment of superiors and collaborating with other departments. Ultimately, culture helps create social order within an organisation. Figure 4.5 Key dimensions defining an organisation’s culture Imagine what it would be like if members didn’t share similar beliefs, values and assumptions—chaos! The customs, norms and ideals conveyed by the culture of an organisation provide the stability and predictability in behaviour that is essential for an effective organisation. See Snapshot from practice: Real-life project teams for an example of this. Although our discussion of organisational culture may appear to suggest one culture dominates the entire organisation, in reality this is rarely the case. ‘Strong’ or ‘thick’ are adjectives used to denote a culture in which the organisation’s core values and customs are widely shared within the entire organisation. Conversely, a ‘thin’ or ‘weak’ culture is one that is not widely shared or practised within a firm.
Pearson_Ch04.indd 91
4/1/2013 6:49:32 AM
92
PART 2 Positioning Projects
SNAPSHOT FROM PRACTICEReal-life project teams
Sa m
pl
e
on
ly
While working for Oracle Corporation®, both in the UK and the USA, the author had the opportunity to work in various areas of the business, enabling him to experience both leadership and membership of a number of different project teams. Some of the larger projects, for example back-office system consolidations, were run by a small ‘core’ team of full-time project staff, comprising the project manager, communications and change manager and business analysts. However, the majority of other employees utilised by the project were seen as transient and, typically, Subject Matter Experts (SME) were drawn in from across the business as and when needed. SMEs ranged from a variety of technical experts to local (in-country) business representatives. The SMEs retained their functional position in the organisation but also reported to the project manager in regard to assigned project activities Figure 4.6 Real-life team projects vand tasks. This hybrid structure worked well for the organisation and Source: istock the delivery of projects. The culture of the organisation was ‘empowerment’. Everyone knew what their role was, and they were suitably empowered to carry out their role. The environment was very positive and the SMEs, project managers and others involved supported each other in a collective, collaborative manner. The author experienced a different situation at an energy utility company in Australia. There was a complex political culture with a predominantly ‘command and control’ ethos. The organisation was (outside of operations) a projectised organisation with many large and small projects being attended to in a true projectised nature. As an example of a project structure in practice, imagine a project designed to deliver changes to core aspects of the business model. Included in the scope of this project was the redesign of the following business processes: strategic planning, business planning, performance management, benefits management and portfolio/program/project management. This, as can be imagined, touched on all the senior positions and players in the organisation and was run as a full-time project with a project manager, SMEs, business analysts, a part-time organisational change manager and a full-time project administrator. The focus of the project was stakeholder management and communications. The project was well supported by other functional departments in terms of human resources, procurement and corporate communications (these functional departments supporting the day-to-day activities of the business, as well as most large or small projects). These two examples show the range of differing cultures and project structures that can typically be found across organisations. As a project manager (contract or permanent), you have to quickly be able to adapt to the organisation’s culture and to the preferred style of project structure: functional, matrix or projectised.
Even within a strong organisational culture, there are likely to be subcultures often aligned within specific departments or specialty areas. As noted earlier in our discussion of project management structures, it is not uncommon for norms, values and customs to develop within a specific field or profession such as marketing, finance or operations. People working in the marketing department may have a different set of norms and values than those working in finance. Countercultures sometimes emerge within organisations that embody a different set of values, beliefs and customs—often in direct contradiction with the culture espoused by top management. How pervasive these subcultures and countercultures are affect the strength of the culture of the organisation and the extent to which culture influences members’ actions and responses.
IdenTIFyIng culTuRAl chARAcTeRISTIcS Deciphering an organisation’s culture is a highly interpretative, subjective process that requires assessment of both current and past history. The student of culture cannot simply rely on what people report about their culture. The physical environment in which people work, as well as how people act and respond to different events that occur, must be examined. Figure 4.7 contains a checklist for the basic analysis of the culture of an organisation. Although by no means exhaustive, the checklist often yields clues about the norms, customs and values of an organisation:
Pearson_Ch04.indd 92
4/1/2013 6:49:35 AM
chAPTeR 4 Project Organisational Structures and Cultures
93
nATIOnAl AuSTRAlIA BAnk (nAB) I. Physical characteristics: Head Office, 8-storey modern building, located at the Docklands in Melbourne, Australia Smart business attire, banking formalities. II. Public documents: Annual reports (financial statement), sustainability reports, investor reports, risk and capital reports. Strategy, Focus on the strong Australian franchise and manage international positions for value, Maintain balance sheet strength, Reduce complexity and cost, Enhance our reputation. III. Behaviour: Investing in the skills and capabilities of employees, Organisational Culture, Diversity and Inclusion, Talent Management, Health and Wellbeing, Learning and Development, Performance and Reward, Industrial Relations, Flexible Working. IV. Folklore: Stories, anecdotes and history evidenced. Source: National Australia Bank, Annual Review 2011
Study the physical characteristics of an organisation.. What does the external architecture look like? What image does it convey? Is it unique? Are the buildings and offices the same quality for all employees? Or are modern buildings and fancier offices reserved for senior executives or managers from a specific department? What are the customs concerning dress? What symbols does the organisation use to signal authority and status within the organisation? These physical characteristics can shed light on who has real power within the organisation, the extent to which the organisation is internally differentiated and how formal the organisation is in its business dealings. Read about the organisation.. Examine annual reports, mission statements, press releases and internal newsletters. What do they describe? What principles are espoused in these documents? Do the reports emphasise the people who work for the organisation and what they do or the financial performance of the firm? Each emphasis reflects a different culture. The first demonstrates concern for the people who make up the company. The second may suggest a concern for results and the bottom line. Observe bserve how people interact within the organisation organisation. What is their pace—is it slow and methodical or urgent and spontaneous? What rituals exist within the organisation? What values do they express? Meetings can often yield insightful information. Who are the people at the meetings? Who does the talking? To whom do they talk? How candid is the conversation? Do people speak for the organisation or for the individual department? What is the focus of the meetings? How much time is spent on various issues? Issues that are discussed repeatedly and at length are clues about the values of the organisation’s culture. Interpret nterpret stories and folklore surrounding the organisation. organisation Look for similarities among stories told by different people. The subjects highlighted in recurring stories often reflect what is important to an organisation’s culture. For example, many of the stories that are repeated at Versatec, a Xerox subsidiary that makes graphic plotters for computers, involve their flamboyant cofounder, Renn Zaphiropoulos. According to company folklore, one of the very first things Renn did when the company was formed was to assemble the top management team at his home. They then devoted the weekend to hand-making a beautiful teak conference table around which all future decisions would be made. This table came to symbolise the importance of teamwork and maintaining high standards of performance, two essential qualities of the culture at Versatec. Try to identify who the heroes and villains are in the folklore company. What do they suggest about the culture’s ideals? Returning to the Versatec story, when the company was eventually purchased by Xerox many employees expressed concern that Versatec’s informal play hard/ work hard culture would be overwhelmed by the bureaucracy at Xerox. Renn rallied the employees to superior levels of performance by arguing that if they exceeded Xerox’s expectations they would be left alone. Autonomy has remained a fixture of Versatec’s culture long after Renn’s retirement.
3
4
Sa m
pl
2
e
on
1
ly
Figure 4.7 Organisational culture analysis
It is also important to pay close attention to the basis for promotions and rewards. What do people see as the keys to getting ahead within the organisation? What contributes to downfalls? These last two questions can yield important insights into the qualities and behaviours which the organisation honours as well as the cultural taboos
Pearson_Ch04.indd 93
4/1/2013 6:49:35 AM
94
PART 2 Positioning Projects
and behavioural land mines that can derail a career. For example, one project manager confided that a former colleague was sent to project management purgatory soon after publicly questioning the validity of a marketing report. From that point on, the project manager was extra careful to privately consult the marketing department whenever she had questions about their data. With practice an observer can assess how strong the dominant culture of an organisation is and the significance of subcultures and countercultures. Furthermore, learners can discern and identify where the culture of an organisation stands on the ten cultural dimensions presented earlier and, in essence, begin to build a cultural profile for a firm. Based on this profile, conclusions can be drawn about specific customs and norms that need to be adhered to as well as those behaviours and actions that violate the norms of a firm.
Implications of organisational culture for organising projects
Sa m
pl
e
on
ly
Project managers have to be able to operate in several, potentially diverse, organisational cultures. First, they have to interact with the culture of their parent organisation as well as the subcultures of various departments (e.g. marketing, accounting). Second, they have to interact with the project’s client or customer organisations. Finally, they have to interact in varying degrees with a host of other organisations connected to the project. These organisations include suppliers and vendors, subcontractors, consulting firms, government and regulatory agencies and, in many cases, community groups. Many of these organisations are likely to have very different cultures. Project managers have to be able to read and speak the culture they are working in to develop strategies, plans and responses 1. Member identity that are likely to be understood and accepted. Still, the emphasis of Job Organisation 2. Team emphasis this chapter is on the relationship between organisational culture and Individual Group project management structure, and it is necessary to defer further 3. People focus discussion of these implications until Chapter 11, which focuses Task People 4. Unit integration on leadership, team building and the human dimensions of project Independent Interdependent management. 5. Control Earlier we stated that we believe there are strong relationships Loose Tight 6. Risk tolerance among project management structure, organisational culture and Low High successful project management. To explore these relationships 7. Reward criteria further, let us return to the dimensions that can be used to Performance Other 8. Conflict tolerance characterise the culture of an organisation. When examining these Low High dimensions we could hypothesise that certain aspects of the culture of 9. Means-ends orientation an organisation would support successful project management while Means Ends 10. Open-system focus other aspects would deter or interfere with effective management. Internal External Figure 4.8 attempts to identify which cultural characteristics create an environment conducive to completing most complex projects Figure 4.8 Cultural dimensions of an organisation supportive involving people from different disciplines. of project management Note that, in many cases, the ideal culture is not at either extreme. For example, a fertile project culture would likely be one in which management balances its focus on the needs of both the task and the people. An optimal culture would balance concern with output (ends) and processes to achieve those outcomes (means). In other cases, the ideal culture would be on one end of a dimension or the other. For example, because most projects require collaboration across disciplines, it would be desirable that the culture of the organisation emphasise working in teams and identifying with the organisation, not just the professional domain. Likewise it is important that the culture support a certain degree of risk taking and a tolerance for constructive conflict. One organisation that appears to fit this ideal profile is 3M. 3M has received acclaim for creating an entrepreneurial culture within a large corporate framework. The essence of its culture is captured in phrases that have been chanted often by 3Mers throughout its history: ‘Encourage experimental doodling.’ ‘Hire good people and leave them alone.’ ‘If you put fences around people, you get sheep. Give people the room they need.’ Freedom and autonomy to experiment are reflected in the ‘15 per cent rule’, which encourages technical people to spend up
Pearson_Ch04.indd 94
4/1/2013 6:49:36 AM
chAPTeR 4 Project Organisational Structures and Cultures
95
Sa m
pl
e
on
ly
to 15 per cent of their time on projects of their own choosing and initiative. This fertile culture has contributed to 3M’s branching out into more than 60 000 products and 35 separate business units. Google applies a similar scenario with the ‘Google 20’, where employees are encouraged to spend 20 per cent of paid time working on ideas that may (or may not) materialise into that next ground-breaking product for the organisation. The metaphor we choose to describe the relationship between organisational culture and project management is that of a riverboat trip. Culture is the river and the project is the boat. Organising and completing projects within an organisation in which the culture is conducive to project management is like paddling downstream: much less effort is required. In many cases, the current can be so strong that steering is all that is required. Such is the case for projects that operate in a project-friendly environment where teamwork and cross-functional cooperation are the norms, where there is a deep commitment to excellence and where healthy conflict is voiced and dealt with quickly and effectively. Conversely, trying to complete a project in a toxic culture is like paddling upstream: much more time, effort and attention are needed to reach the destination. This would be the situation in cultures that discourage teamwork and cooperation, that have a low tolerance for conflict and where getting ahead is based less on performance and more on cultivating favourable relationships with superiors. In such cases, the project manager and his or her people not only have to overcome the natural obstacles of the project but also have to overcome the prevailing negative forces inherent in the culture of the organisation. The implications of this metaphor are important. Greater project authority and time are necessary to complete projects that encounter a strong, negative cultural current. Conversely, less formal authority and fewer dedicated resources are needed to complete projects in which the cultural currents generate behaviour and cooperation essential to project success. The key issue is the degree of interdependency between the parent organisation and the project team. In cases where the prevalent organisational culture supports the behaviours essential to project completion, a weaker, more flexible project management structure can be effective. For example, one of the major reasons Chaparral Steel is able to use a functional matrix to successfully complete incremental projects is that its culture contains strong norms for cooperation. See the Research highlight: The secret of success for another example of how culture supports successful project management. When the dominant organisational culture inhibits collaboration and innovation, it is advisable to insulate the project team from the dominant culture. Here it becomes necessary to create a self-sufficient project team. If a dedicated project team is impossible because of resource constraints, then at least a project matrix should be used where the project manager has dominant control over the project. In both cases, the managerial strategy is to create a distinct team subculture in which a new set of norms, customs and values evolve that will be conducive to project completion.
RESEARCH HIGHLIGHT The secret of success In The Secret of Success: The Double Helix of Formal and Informal Structures in an R&D Laboratory, Polly Rizova revealed the results of a year-long investigation into the inner workings of a Fortune 500 R&D Lab. Through interviews with key participants and analysis of social networking data, Rizova assessed the efficacy of six high-tech development projects. Four critical success factors emerged from her research. One element that is crucial to success is a heavy reliance on open and unrestricted patterns of communication, coupled with a low degree of formal reporting. In other words, team members freely interacted with each other regardless of title, experience or discipline. A second key is having individuals on the project who are highly respected across the laboratory for their exceptional technical skills and experience. Similarly, it is also vital to have individuals involved in the project who are highly respected for their organisational expertise and experience. Having both ‘technical stars’ and ‘organisational stars’ on the project team was essential to success. The final factor is a strong and sustained support for the project from the company’s corporate management. What’s more, her analysis revealed the interactive nature of the four conditions; namely that no one condition was likely to produce successful outcomes on its own, but only when put together in a way in which they reinforce each other. Here the culture of the laboratory was seen as the key catalyst. continued
Pearson_Ch04.indd 95
4/1/2013 6:49:36 AM
96
PART 2 Positioning Projects
Continued Rizova describes a matrix system in which people work on multiple projects simultaneously but with a different wrinkle. Individuals occupy different positions and play different roles depending upon the project. For example, it is common for a senior engineer to be the manager of one project and a researcher on another that is led by his or her subordinate. In essence one must ‘boss’ his or her own boss. At first glance this formal structure should create destructive tensions. However, Rizova argues that the organisational culture of the lab is the glue that keeps things running smoothly. She described a culture in which the social norms of cooperation, respect and civility are upheld and reproduced. It is a culture characterised by trust and a strong drive toward superior individual and organisational learning and achievement. The culture is captured in the comments of researchers:
ly
That is one of the nicest things around here. Your opinions are listened to. Superiors consider our advice. You will find that most of the projects here are a team effort. What I like most is the positive thinking and the ‘whatever it takes’ attitude. Personality conflicts can be devastating. Here everyone helps you and supports you. There is no ‘I’ in the word team. Very friendly environment. . . I met new people and learned a lot from them. They hey do not mind sharing their expertise.
e
on
Source: Polly S. Rizova, The Secret of Success: The Double Helix of Formal and Informal Structures in an R&D Laboratory Laboratory. (Stanford, CA: Stanford University Press, 2007.)
pl
Summary
Sa m
This his chapter examined two major characteristics of the parent organisation that affect the implementation and completion of projects. The he first is the formal structure of the organisation and how it chooses to organise and manage projects. Although lthough the individual project manager may have very little say as to how the firm chooses to manage projects, he or she must be able to recognise the options available as well as the inherent strengths and weaknesses of different approaches. hree basic project management structures were described and assessed as to their weaknesses and Three strengths. Only nly under unique circumstances can a case be made for managing a project within the normal functional hierarchy. When thinking only in terms of what is best for the project, the creation of an independent project team is clearly favoured. However, the most effective project management system appropriately balances the needs of the project with those of the parent organisation. Matrix structures emerged out of the parent organisation’s need to share personnel and resources across multiple projects and operations while creating legitimate project focus. The matrix approach is a hybrid organisational form that combines elements of both the functional and project team forms in an attempt to realise the advantages of both. The second major characteristic of the parent organisation that was discussed in this chapter is the concept of organisational culture. Organisational culture is the pattern of beliefs and expectations shared by an organisation’s members. Culture includes the behavioural norms, customs, shared values and the ‘rules of the game’ for getting along and getting ahead within the organisation. It is important for project managers to be ‘culture sensitive’ so that they can develop appropriate strategies and responses and avoid violating key norms that would jeopardise their effectiveness within the organisation. The interaction between project management structure and organisational culture is a complicated one. We have suggested that in certain organisations, culture encourages the implementation of projects. In this environment the project management structure used plays a less decisive role in the success of the project. Conversely, for other organisations in which the culture stresses internal competition and differentiation, just the opposite may be true. The prevailing norms, customs and attitudes inhibit effective project management, and the project management structure plays a more decisive role in the successful implementation of projects.
Pearson_Ch04.indd 96
4/1/2013 6:49:36 AM
chAPTeR 4 Project Organisational Structures and Cultures
97
At a minimum, under adverse cultural conditions, the project manager needs to have significant authority over the project team; under more extreme conditions firms should use dedicated project teams to complete critical projects. In both cases, the managerial strategy should be to insulate project work from the dominant culture so that a more positive ‘subculture’ can emerge among project participants. The project management structure of the organisation and the culture of the organisation are major elements of the environment in which a project is initiated. Subsequent chapters will examine how project managers and professionals work within this environment to successfully complete projects.
key TeRmS Project Management Office (PMO), 89 strong matrix, 88 balanced matrix, 88 weak matrix, 88
on
ly
dedicated project team, 79 functional structure, 82 organisational culture, 90 projectitis, 84 projectised organisation, 82
ReVIeW queSTIOnS
6 7
e
pl
2 3 4 5
What are e the relative advantages and disadvantages of the functional, matrix and dedicated team approaches to managing projects? eak matrix from a strong matrix? What distinguishes a weak Under nder what conditions would it be advisable to use a strong matrix instead of a dedicated project team? How w can project management offices (PMO (PMOs) (PM Os) s) support effective project management? Whyy is it important to assess the culture of an organisation before deciding what project management structure should be used to complete a project? Other ther than culture, what other organisational factors should be used to determine which project management structure should be used? What do you ou believe is more important for successfully completing a project—the formal project management structure or the culture of the parent organisation?
Sa m
1
exeRcISeS 1
2
3
4
Pearson_Ch04.indd 97
Going oing to university is analogous to working in a matrix environment in that most students take more than one classs and must distribute their time across multiple classes. What problems does this situation create for you? How does it affect your performance? How could the system be better managed to make your life less difficult and more productive? us Metals, which manuf You work for Aus manufactures high-precision parts for the mining industry. Aus Metals has been the market leader for the past 20 years and has decided to diversify by applying its technology to develop a production line to produce a variety of widgets for Toyota, which in recent years has been investing in car production within Australia. What kind of project management structure would you recommend for this project? What information would you like to have to make this recommendation, and why? You work for Portable Path. Your R&D people believe they have come up with an affordable technology that will revolutionise portable pathology and take it to the patients, rather than the pathology labs. The project has been named ‘revolve’. What kind of project management structure would you recommend for the ‘revolve’ project? What information would you like to have to make this recommendation and why? This chapter discussed the role of values and beliefs in forming an organisation’s culture. The topic of organisational culture is big business on the internet. Many companies use their web pages to describe their mission, vision and corporate values and beliefs. There also are many consulting firms that advertise how they help organisations to change their culture. The purpose of this exercise is for you to obtain
4/1/2013 6:49:36 AM
PART 2 Positioning Projects
5
information pertaining to the organisational culture for two different companies. You can go about this task by simply searching on the key words ‘organisational culture’ or ‘corporate vision and values’. This search will identify numerous companies for you to use to answer the following questions. You may want to select companies that you would like to work for in the future. a What are the espoused values and beliefs of the companies? b How do you think the organisation would deliver projects within this culture? Use the cultural dimensions listed in Figure 4.5 to assess the culture of your organisation. a Which dimensions were easy to evaluate and which ones were not? b How strong is the culture of your organisation? c What functions does the culture serve for your organisation? d What kind of projects are easy to implement in your organisation and why do you think this is so? e From om your experience, what kind of projects would be difficult to implement given the structure and culture of your organisation?
ly
98
on
case ORIOn SySTemS (A)
Sa m
pl
e
The office erupted into cheers when it was announced over the PA A system that ORION had just been awarded the government contract to build the next generation of high-speed, light-rail trains. Everyone came over to shake Mike Rosas’s hand and congratulate him. Itt was well known that Rosas osas would would be the project manager for this important project, which would be code named Jaguar. JJaguar aguar. Once aguar. Once the celebration subsided, Rosas gazed out the window and thought about what he had just taken on. The Jaguar project oject would be a high-profile project that would affect procurement of future contracts with the government. Increased ncreased competition had raised performance expectations regarding completion time, quality, reliability and cost. He knew that major changes in how ORION organised and managed projects would be aguar project. project. necessary to meet the expectations of the JJaguar Project manager
Deputy planning and control management
Electronics system engineer
Mechanics system engineer
Team leader
Team leader
Team leader
Team leader
Figure 4.9 Organisation of product development projects at ORION
Pearson_Ch04.indd 98
PROjecT mAnAgemenT AT ORIOn ORION was a division of a large aerospace company with 7000 employees. ORION evolved from a project organisation into a matrix structure to conserve costs and better utilise limited resources. At any point in time, ORION could be working on three to five large projects such as the Jaguar project and 30 to 50 smaller projects. Project managers negotiated personnel assignments with the VP of operations, who ultimately decided project assignments. It was not uncommon for an engineer to be working on two to three projects during a week. Figure 4.9 portrays how new-product development projects were organised at ORION. Project management was limited only to the design and development of the new product. Once the final design and prototype were completed, they were turned over to
4/1/2013 6:49:38 AM
chAPTeR 4 Project Organisational Structures and Cultures
99
manufacturing for production and delivery to the customer. A four-person management team oversaw the completion of the project and their responsibilities are briefly described here: • •
• •
project manager—responsible for all aspects of design and development of the product planning and control manager—responsible for building an overall project network, scheduling, managing the budget, controlling and evaluating the design and development program, and preparing status reports electronics system engineer—responsible for providing technical expertise on electronic systems issues mechanics system engineer—responsible for providing technical expertise on mechanical system issues.
Sa m
pl
e
on
ly
The core work was completed by 12 to 20 design teams. Each ach team had a leader, who was responsible for designing, developing, building and testing a specific subsystem of the product. T The he size of individual teams varied from 5 to 15 engineers, depending on the scope of their work. These hese engineers split time across multiple projects. Design engineers ran the show at ORION,, and manufacturing, marketing and other groups were expected to follow their lead. The he special status of the design engineers was reinforced by the fact that they were actually paid on higher pay curves than the manufacturing engineers. The he overall product development and manufacturing process is captured in the master plan chart (Figure 4.10). New-product ew-product design and development evolved around five major reviews: system design review (SDR), preliminary design review (PDR), ), critical design review (CDR), (CDR), (CDR ), test readiness review ((TRR) and production readiness review (PRR). Design esign and development work began within the laboratory and progressed to field tests of specific subsystems and ultimately final product prototypes. Once Once completed, the design and prototype were turned over to manufacturing, which began building the production line for the new product. Manufacturing also developed the necessary test equipment to confirm that manufactured components perform correctly. During this time, integrated logistical support (ILS ((ILS) ILS)) teams prepared product documentation, users’ manuals, maintenance programs and training programs for the customers who would be using the product. It typically takes ORION six to seven years to develop and manufacture a product such as the Jaguar. ORION just completed a major assessment of how projects are managed. Below is a brief description of some of the major problems that were identified:
Activities/time Design reviews Design and development
5–7 years SDR
PDR
Laboratory tests
CDR
1–4 years
TRR
PRR
Environmental tests
Production and delivery ILS
Build production line
Production
and test equipment
and delivery
Documentation and
Training
training program
Figure 4.10 Traditional master plan at ORION
Pearson_Ch04.indd 99
4/1/2013 6:49:38 AM
100
PART 2 Positioning Projects
•
•
•
•
on
ly
•
Higher than expected production costs. Once products were developed, there was a tendency for them to be ‘thrown over the wall’ to manufacturing to produce. Very little design for manufacturability was done, and the production ramp was complicated, inefficient and stressful to the people in the plant. Quality concerns. Increased competition had raised customer expectations with regard to quality. Customers expected fewer defects and longer replacement schedules. ORION had a tendency to deal with quality issues after the fact, initiating quality improvements after the production process was set up. Not enough attention was devoted to incorporating quality considerations into the original design of products. Problems with customer support. User manuals and technical documentation sometimes failed to address all of a customer’s concerns, and the follow-up training was not always adequately prepared. These problems contributed to increased costs in customer service and a decline in customer satisfaction. Lack of strong project ownership. While everyone accepted that a matrix arrangement was the only way to accommodate all the projects at ORION,, the shifting back and forth of personnel across multiple projects took its toll on the progress of individual projects. Members often failed to identify with individual projects and develop the sense of excitement that contributed to superior performance. The shuffling of personnel slowed down progress because additional time had to be devoted to bringing returning members up to speed on current developments. Scope creep. ORION was renowned for its engineering prowess. However, there was a tendency for design engineers to get so absorbed with the science of the project that they lost focus on the practical considerations. This his led to costly delays and sometimes design modifications that were inconsistent with customer requirements.
What recommendations organising the Jaguar project, and why? ecommendations would you make to R Rosas osas about or How w would you change the organisational chart and master plan to reflect these changes?
pl
1 2
e
Rosas was aware e of these and other concerns as he sat down with his staff to figure out the best way to organise the new Jaguar project.
Sa m
Source: Prepared by and used with permission of S Shlomo hlomo Cohen
The second part of this this case case, case, , ORIO ORIOn n S Systems ystems (B): Rosas’s Plan, can be viewed online. The moss and Accounting Firm case, relevant mcAdams Accounting Firm case, relevant to this chapter, is also available online.
Pearson_Ch04.indd 100
4/1/2013 6:49:38 AM
CHAPTER 6 ESTIMATING TIME, COSTS AND RESOURCES
ly
Learning elements Understand stand that estimating can be carried out to differing levels of detail and accuracy.
6.2
Apply anyy number of estimating techniques to assist in scoping and planning a project.
6.3
stand the concept of contingency versus padding. Understand
on
6.1
• Factors influencing the quality of estimates quality of estimates
Sa m
• What is being estimated?
Methods for estimating project costs, times • Methods and resources and
pl
• Introduction
e
In this chapter
• Estimating guidelines for time, costs and guidelines for time, costs and resources
• Level Level of detail in estimating • Refining estimates • Summary
• Top-down versus bottom-up estimating versus bottom-up estimating
Introduction Given the urgency to start work on a project, managers sometimes minimise or avoid the effort to follow through on estimating project time and cost. This attitude is a huge and costly mistake. As discussed in the previous chapter, estimating should be a part of the scoping activities in the Initiating phase of the project. There are important reasons to make the effort and incur the cost (time) of estimating your project. Figure 6.1 summarises some key reasons. Estimating is the process of forecasting or approximating the time and cost of completing project deliverables. Estimating processes are frequently classified as top-down and bottom-up. The time available and your role in the project often influence whether top-down or bottom-up estimates are utilised. Top-down estimates are usually applied by project managers when time is short or when in the Initiating phase of the project. Management will often derive estimates from analogy, group consensus or mathematical relationships. The people who are doing the work typically perform bottom-up estimates (when time has been allowed for the extra detail to be
Pearson_Ch06.indd 130
4/2/2013 4:53:48 PM
CHAPTER 6 Estimating Time, Costs and Resources
131
appropriately researched). Their estimates are based on estimates of each element found in the work breakdown structure (WBS), usually at the lowest level (work package). Bottom-up estimating is normally carried out in the Planning phase of the project to ensure that estimates of the project are as accurate as possible. All project stakeholders prefer accurate resource, cost and time estimates, but they also understand the inherent uncertainty in all projects and the time ‘estimating’ often consumes. Inaccurate estimates lead to false expectations and customer dissatisfaction. Accuracy is improved with greater effort, but is it worth the time and cost—estimating costs money! Project estimating becomes a trade-off, balancing the benefits of better accuracy against the costs for securing increased accuracy.
e
on
support good decisions determine whether the project is worth doing determine how long the project should take and its overall cost its overall cost schedule work determine the resource required (human and other) and other) develop time-phased budgets (cash flow) flow) establish the project baseline (at the end of the Planning phase) the end of the Planning phase) determine how well the project is progressing. is progressing.
pl
• • • • • • • •
ly
Estimates are needed to:
Figure 6.1 Why estimating time, cost and resources is important
Sa m
Cost, time and resource estimates are the lifeline for control; they serve as the standard for comparison of actual and planned costs throughout the life of the project. Project status reports depend on reliable estimates as the major input for measuring variances and taking corrective action Estimates become the planned baseline value at project execution. Ideally, the project manager, and in most cases the customer, would prefer to have a database of detailed schedule, resource and cost estimates for every work package in the project. Regrettably, such detailed data gathering is not always possible or practical and other methods are used to develop project estimates. Project estimating is a complex process. The quality of time, cost and resource estimates can be improved when these variables are considered in making the estimates. Estimates of resources, time and cost together allow the manager to develop a time-phased budget, which is imperative for project control. Therefore, the structure of this chapter is:
• • • •
an overview discussion on what is being estimated a look at the estimating guidelines to remind us of some of the important ‘rules of the game’ that can improve estimating a discussion on estimating methods for resources, time (durations) and costs a detailed look at some of the tools and techniques for estimating.
Factors influencing the quality of estimates A typical statement in the field is the desire to ‘have a 95 per cent probability of meeting time and cost estimates’. Past experience is a good starting point for developing time and cost estimates. But past experience estimates must almost always be refined by other considerations to reach the 95 per cent probability level. Factors related to the
Pearson_Ch06.indd 131
4/2/2013 4:53:48 PM
132
PART 3 Defining and Managing Projects
uniqueness of the project will have a strong influence on the accuracy of estimates. Project, people and external factors all need to be considered to improve quality of estimates for project times and costs.
PLAnning HoRizon The quality of the estimate depends on the planning horizon: estimates of current events are close to 100 per cent accurate but accuracy is reduced the more distant the events. The accuracy of time and cost estimates should improve as you move from the Initiating phase to the point where individual work packages are defined within the Planning phase. The estimating trumpet provides an industry standard for the expectations which not only prevail in industry, but which should also be set as expectations with executive management, sponsors, steering committees and customers. (See Figure 6.2).
PRojECT duRATion
an
Most Probable Final Cost
3 5
Parametric rametric –15% to +25%
5
Sa m
it
25 20 15 10
Ideal Target Cost
100% design –5% to +10%
lim
60% review –6% to +12%
ce
Order of magnitude –25% to +75%
Approx. % estimate value range (ratio scale)
50
30% design review –8% to +15%
rv ari
pl
pe
75
Composite –10% to +20%
Up
e
on
ly
Long projects experience the most problems when estimates have been prepared months and sometimes years in advance. If these estimates do not include a stated factor for potential increases to durations, this can affect accuracy. Some projects have failed to consider, for example, changes to workplace health and safety legislation—this has then later extended durations of some activities and introduced new activities into the overall project. Another example could be the time required to implement a new technology project— technology projects have a habit of expanding in an increasing, non-linear fashion. Sometimes poorly written scope specifications for new technology result in errors in estimating time and cost. Remember that generally, long-duration projects increase the uncertainty in estimates—and careful consideration should be given to the approach of such projects; breaking into stages and/or splitting into multiple projects, where estimating is carried out for the immediate work.
10 15 20 25
nce
aria er v
t
limi
Low 5 10 15 25 50 80 85 Increasing estimating information as a % of total finished project information (ratio scale)
Economic studies
Feasibility studies
Detailed design
Committed
Figure 6.2 The estimating trumpet Source: © AEW Services, 2002
Pearson_Ch06.indd 132
4/2/2013 4:53:49 PM
CHAPTER 6 Estimating Time, Costs and Resources
133
PEoPLE The people factor can also introduce errors in estimating time and cost. For example, accuracy of estimates depends on the skills of the people making the estimates. A close match of people skills to the task will influence productivity and learning time. Similarly, whether members of the project team have worked together before on similar projects will influence the time it takes to coalesce into an effective team. Sometimes, factors such as staff turnover can influence estimates. It should be noted that adding new people to a project increases time spent communicating. Typically, people have only five to six productive hours available for each working day; the other hours are taken up with indirect work, such as meetings, paperwork and answering email.
PRojECT STRuCTuRE And oRgAniSATion
ly
The project structure chosen to manage the project will influence time and cost estimates. One of the major advantages of a dedicated project team discussed in Chapter 4 is the speed gained from concentrated focus and localised project decisions. This speed comes at an additional cost of tying up personnel full time. Conversely, projects operating in a matrix environment may reduce costs by more efficiently sharing personnel across projects but may take longer to complete since attention is divided and coordination demands are higher.
PAdding ESTiMATES
Sa m
pl
e
on
In some cases, people are inclined to pad estimates. For example, if you are asked how long it takes you to drive to the airport, you might give an average time of 30 minutes, assuming a 50 per cent chance of getting there in 30 minutes. If you are asked the fastest you could possibly get there, you might reduce the driving time to 20 minutes. Finally, if you are asked how long the drive would take if you absolutely had to be there to meet with your customer, it is likely you would increase the estimate to say 50 minutes to ensure not being late. In work situations where you are asked for resource, time and cost estimates, most of us are inclined to add a little padding to increase the probability and reduce the risk of being late. If everyone at all levels of the project adds a little padding to reduce risk, the project duration and cost are seriously overstated. This phenomenon causes some managers or customers to call for a 10–15 per cent cut in time and/or cost for the project. Of course, the next time the game is played, the person estimating cost and/or time will pad the estimate to 20 per cent or more. Clearly, such games defeat chances for realistic estimates, which is what is needed to be competitive. As a professional of the discipline, it is the project manager’s responsibility to ensure that clear governance is established around the use of ‘padding’. Some project managers establish a clear policy of no-padding, stating that an appropriate contingency will be added to the overall project. Contingency is typically held by the sponsor or PMO and to gain access to ‘funds’ sitting in the contingency account, the project manager has to make use of the change/variation process (outlined in Chapter 5).
oRgAniSATionAL CuLTuRE AL Cu AL C uLT LTu uRE RE
Organisational culture can significantly influence project estimates. In some organisations, padding estimates is tolerated and even privately encouraged. Other organisations place a premium on accuracy and strongly discourage estimating gamesmanship. Organisations vary in the importance they attach to estimates. The prevailing belief in some organisations is that detailed estimating takes too much time and is not worth the effort or that it’s impossible to predict the future. Other organisations subscribe to the belief that accurate estimates are the bedrock of effective project management. Organisational culture shapes every dimension of project management; estimating is not immune to this influence.
oTHER FACToRS Finally, non-project factors can impact time and cost estimates. For example, equipment downtime can alter time estimates. Recognised public holidays, employees’ leave and the red tape of legal limitations can influence project estimates. Project priority can influence resource assignment and therefore can impact on time and costs.
Pearson_Ch06.indd 133
4/2/2013 4:53:50 PM
134
PART 3 Defining and Managing Projects
What is being estimated? Before looking into a number of estimating approaches, tools and techniques, we must first consider what is being estimated against each of the tasks, sub-tasks or work packages. When a project manager estimates a work package they would consider what resources are required, how long these resources are required (the duration) and the cost of these resources.
RESouRCES A resource is the generic term used in project management for any item that is consumed by the project; the range of potential resources is vast and almost impossible to document. Some common resource types that are typically allocated to a project (and the qualities of which need to be estimated) can be found in Table 6.1. Table 6.1 Typical types of resources Internal employees (full or part time), contractors, temps, consultants
Tools
Testing equipment, compressors, laths, drills, computers, telephones, tablet computers
Plant
Office facilities, warehouse (storage) space, production lines
Equipment
Utes, cars, hoists, scissor lifts, trucks. More commonly an apportioned cost to the project as these often-expensive items will already exist in the organisation
Raw material/s
Concrete, fill, steel, roofing tiles, fencing panels, circuit boards, plastic pellets
Capital
Funding sources, cash flow into the project and loans
Services
Consultancy, maintenance, cleaning
other
Paper, printers, books, insurance, training, consumables
pl
e
on
ly
Human resources (people)
Sa m
As the project manager builds out the work packages and starts to estimate the resources required to complete each work package, the range of resource types will be refined. Additionally, each human resource identified is often captured in the project resource/skills matrix for further analysis (see Chapter 11), whereas the cost information has implications for the project budget (see Chapter 8) and the time information for the project network/schedule (see Chapter 7). This illustrates the integrative nature of project management and the complexity of juggling the many dimensions of the project.
duRATionS
Once resources have been identified against items within each work package, the required durations of the resources would also be captured (estimated). For some kinds of resources this is a relatively simple task; for example, a specialist contractor is required for ten workdays of effort or a cement pump is required for two weeks on site. Other costs, such as human resource costs or costs associated with equipment that is used ad hoc over an extended period of time, require a more holistic consideration. The question driving these resources (and the duration) required, is, ‘Is it most cost efficient to deploy the resource to only the required tasks it has been identified against, or is it more efficient to keep the resource for a longer duration, or even an entire phase of the whole project?’ For example, with plant and equipment there are costs associated with bringing the item on site, setup times, tear-down time and transport costs. Does carrying out this sequence multiple times on a project exceed the cost of retaining the equipment on site for a longer duration of time? The same applies to human resources. If an electrical tester is required for several activities towards the end of the project, does the project manager pay a higher day rate and take the risk on obtaining availability of the resource after it has been released for that task, or would it be more efficient for the project to place the resource on a short-term contract? The project manager will only be able to make these efficiency decisions once estimating of resources across the whole project has taken place.
Pearson_Ch06.indd 134
4/2/2013 4:53:50 PM
CHAPTER 6 Estimating Time, Costs and Resources
135
CoSTS From the work packages, detailed cost estimates can be made. Typical kinds of costs found in a project include:
•
direct costs labour materials equipment tools other
– – – – – •
•
direct project overhead costs
– office space – ICT costs – project manager
indirect costs—also referred to as general and administrative (G&A) or overhead costs telephones employer super contributions management time, sponsor time PMO administration.
on
ly
– – – –
e
The total project cost estimate can be broken down in this fashion to focus the control process and improve decision making, i.e. it is clearer to see where costs are being allocated at a high level. Often the organisations will have a structure around how the project should account for costs incurred, such as a chart of accounts or standard cost structures. The project manager should seek advice from the finance department about how to allocate and record costs within their project environment.
pl
Direct costs
Sa m
These costs are clearly chargeable to a specific work package. Direct costs can be influenced by the project manager, project team and individuals implementing the work package. These costs represent real cash outflows and must be paid as the project progresses; therefore, direct costs are usually separated from overhead costs. Lower-level project rollups frequently include only direct costs.
Direct irect project overhead costs
Direct project overhead costs can be tied to project deliverables or work packages. Examples include the salary of the project manager and the temporary rental of office space for the project team. Although overhead is not an immediate out-of-pocket expense, it is real and must be covered in the long run if the firm is to remain viable. These rates are usually a ratio of the dollar value of the resources used—e.g. direct labour, materials, equipment. For example, a direct labour burden rate of 20 per cent would add a direct overhead charge of 20 per cent to the direct labour cost estimate. A direct charge rate of 50 per cent for materials would carry an additional 50 per cent charge to the material cost estimate. Selective direct overhead charges provide a more accurate project (job or work package) cost, rather than using a blanket overhead rate for the whole project.
Indirect costs or G&A costs Indirect costs, also referred to as general and administrative (G&A) or overhead costs, represent organisation costs that are not directly linked to a specific project. These costs are carried for the duration of the project. Examples include organisational costs across all products and projects such as advertising, accounting and senior management time above the project level. Allocation of G&A costs varies from organisation to organisation. However, G&A costs are usually allocated as a percentage of total direct cost, or a percentage of the total of a specific direct cost such as labour, materials or equipment. Given the totals of direct and overhead costs for individual work packages, it is possible to cumulate the costs for any deliverable or for the entire project. A percentage can be added for profit if you are a contractor. A breakdown of costs for a proposed contract bid is presented in Table 6.2. Perceptions of costs and budgets vary depending on their users. The project manager must be very aware of these differences when setting up the project budget and when communicating these differences to others.
Pearson_Ch06.indd 135
4/2/2013 4:53:50 PM
136
PART 3 Defining and Managing Projects
Table 6.2 Contract bid summary costs
6,000
5,000
Costs $' 000
4,000
3,000
2,000
Direct costs
$80,000
Direct overhead
$20,000
Total direct costs
$100,000
G&A (20%)
$20,000
Total costs
$120,000
Profit (20%)
$24,000
Total bid
$144,000
Committed 1,000
Actual cost
Figure 6.3 depicts these different perceptions. The project manager can commit costs months before the resource is used. This information is also useful to the financial officer of the Project duration organisation in forecasting future cash outflows. The project manager is interested in when the budgeted (planned) cost Figure 6.3 Three views of cost is expected to occur, and when the budgeted cost actually is charged (earned); the respective timings of these two cost figures are used to measure project schedule and cost variances. From an estimating perspective, successfully capturing lessons learned about why costs have varied from what was planned (estimated) and agreed upon compared to what actually occurred forms a key take-away from this discussion. The difference between planned and actual costs is revisited in Chapter 9, when the technique of Earned Value Management (EVM), otherwise known as Earned Value Analysis (EVA), is discussed.
e
on
ly
Scheduled budget
pl
Estimating guidelines for time, cost and resources guidelines for time, cost
1
2
3
Pearson_Ch06.indd 136
Sa m
Managers recognise time, cost and resource estimates must be accurate to propose (Initiation phase), refine (Planning phase) and track (Execution phase) the performance of the project. However, there is substantial evidence suggesting poor estimates are a major contributor to projects that have failed. Therefore, every effort should be made to see that initial estimates are as accurate as possible since the choice of no estimates leaves a great deal to luck and is not acceptable to most professional project managers. Even though a project has never been done before, a manager can follow eight guidelines to develop useful work package estimates. Responsibility. esponsibility. At the work package level, estimates should be made by the person(s) most familiar with the task. Draw on their subject matter expertise; this is why these stakeholders are termed SMEs! Except for super-technical tasks, those responsible for getting the job done on schedule and within budget are usually first-line supervisors or technicians who are experienced and familiar with the type of work involved. These people will not have some preconceived, imposed duration for a deliverable in mind. They will give an estimate based on experience and best judgment. A secondary benefit of using those responsible is the hope they will ‘buy-in’ to seeing that the estimate materialises when they implement the work package. If those involved are not consulted, it will be difficult to hold them responsible for failure to achieve the estimated time. Finally, drawing on the expertise of team members who will be responsible helps to build communication channels early. Use several people to estimate. It is well known that a cost or time estimate usually has a better chance of being reasonable and realistic when several people with relevant experience and/or knowledge of the task are consulted. True, people bring different biases based on their experience, but discussion of the individual differences in their estimates leads to consensus and tends to eliminate extreme estimate errors. Normal conditions. When task time, cost and resource estimates are determined, they are based on certain assumptions. Estimates should be based on normal conditions, efficient methods and a normal level of resources. Normal conditions are sometimes difficult to discern, but it is necessary to have a consensus in the organisation as to what normal conditions mean in this project. If the normal workday is eight hours,
4/2/2013 4:53:51 PM
CHAPTER 6 Estimating Time, Costs and Resources
the time estimate should be based on an eight-hour day. Similarly, if the normal workday is two shifts, the time estimate should be based on a two-shift workday. Any time estimate should reflect efficient methods for the resources normally available. The time estimate should represent the normal level of resources, people or equipment. For example, if three programmers are available for coding or two road graders are available for road construction, time and cost estimates should be based on these normal levels of resources unless it is anticipated the project will change what is currently viewed as ‘normal’. In addition, possible conflicts in demand for resources on parallel or concurrent activities should not be considered at this stage. The need for adding resources will be examined when resource scheduling is discussed in Chapter 7. Time units. Specific time units to use should be selected early in the Initiation phase of the project. All task time estimates need consistent time units. Estimates of time must consider whether normal time is represented by calendar days, workdays, work-weeks, person days, single shift, hours, and so on. In practice, the use of ‘workdays’ is the dominant choice for expressing task duration. However, in projects such as a heart transplant operation, minute increments would probably be more appropriate as a time unit. One such project that used minutes as the time unit was the movement of patients from an old hospital to an elegant new hospital across town. Since there were several life-endangering moves, minutes were used to ensure patient safety so proper emergency life-support systems would be available if needed. The point is, network analysis requires a standard unit of time. When software programs allow more than one option, some notation should be made of any variance from the standard unit of time. If the standard unit of time is a five-day work-week and the estimated activity duration is in calendar days, it must be converted to the normal work-week. Independence.. Estimators should treat each task as independent of other tasks that might be integrated by the WBS. Use of first-line managers usually results in considering tasks independently; this is good. Top managers are prone to aggregate many tasks into one time estimate and then deductively make the individual task time estimates add to the total. If tasks are in a chain and performed by the same group or department, it is best not to ask for all the time estimates in the sequence at once to avoid the tendency for a planner or a supervisor to look at the whole path and try to adjust individual task times in the sequence to meet an arbitrarily imposed schedule or some rough ‘guesstimate’ of the total time for the whole path or segment of the project. This tendency does not reflect the uncertainties of individual activities and generally results in optimistic task time estimates. In summary, each task time estimate should be considered independently of other activities. Contingencies.. Depending on your project/organisational policy, in general work package estimates should not include allowances for contingencies. The estimate should assume normal or average conditions even though every work package may not materialise as planned. For this reason, management (usually the sponsor) or the PMO needs to create an extra fund for contingencies that can be used to cover unforeseen events. The concept of contingency is further discussed in Chapter 8. Carrying arrying out a risk assessment of the estimate helps to avoid surprises. surprises It is obvious some tasks carry more time and cost risks than others. For example, a new technology usually carries more time and cost risks than a proven process. Simply identifying the degree of risk lets stakeholders consider alternative methods and alter process decisions. Refer to Chapter 14 for further discussion of project risk. Cost of Quality (CoQ). Quality affects many areas of a project. When estimating, quality should be a factor that is considered. Quality will affect the choice of equipment used, the people used and ultimately affect what and who is used in the project. Higher-quality materials and resources in general will affect who and what services are considered in estimating. Usually there is a higher cost to the project in considering the use of more expensive resources. For example, an estimate which is provided by lowercost providers will be of a lower cost than if higher-end (higher-quality) providers are used. Chapter 10 provides a more extensive discussion on quality and how it affects many aspects of a project.
7
8
Sa m
6
pl
e
5
on
ly
4
137
Top-down versus bottom-up estimating Since estimating efforts cost money, the time and detail devoted to estimating is an important decision. Yet, when estimating is considered, you as a project manager may hear statements such as these:
• •
Pearson_Ch06.indd 137
Rough order of magnitude is good enough. Spending time on detailed estimating wastes money Time is everything; our survival depends on getting there first! Time and cost accuracy is not an issue
4/2/2013 4:53:52 PM
138
PART 3 Defining and Managing Projects
• • •
The project is internal; we don’t need to worry about cost The project is so small; we don’t need to bother with estimates. Just do it We were burned once; I want a detailed estimate of every task by the people responsible.
Sa m
pl
e
on
ly
However, there are sound reasons for using top-down or bottom-up estimates. Table 6.3 depicts conditions that suggest when one approach is preferred over another. Top-down estimates are usually derived from someone who uses his or her subject matter experience and/or personal sources of information to determine the project duration, typical resources and therefore total cost. These estimates are sometimes carried out at a whole-of-project level, or maybe at the first two levels of the WBS. These estimates are often made by managers who have very little knowledge of the processes of project management. For example, a mayor of a major city making a speech noted that a new law building would be constructed at a cost of A$23 million and would be ready for occupancy in two years. Although the mayor probably asked for an estimate from someone, the estimate could have come from a luncheon meeting with a local contractor who wrote an estimate (guesstimate) on a napkin! This is an extreme example, but in a relative sense this scenario is frequently played out in practice. But the question is: Do these estimates represent low-cost, efficient methods? Do the top-down estimates of project time and cost become a self-fulfilling prophecy in terms of setting time and cost parameters? If possible and practical, you want to push the estimating process down to the work package level for bottom-up estimates, yet establish low-cost, efficient methods for doing this. This process can take place after the project has been defined in detail. Good sense suggests project estimates should come from the people most knowledgeable about the estimate needed. The use of several people with relevant experience with the task can improve the time and cost estimate. The bottom-up approach at the work package level can serve as a check on cost elements in the WBS by rolling up the work packages and associated cost accounts to major deliverables. Similarly, resource requirements can be checked. Later, the time, resource and cost estimates from the work packages can be consolidated into project schedules, resource schedules and the project budget; all of which are used to control the project during the Execution phase. The bottom-up approach also provides the customer with an opportunity to compare the low-cost, efficient method with any imposed restrictions. For example, if the project completion duration is imposed at two years and your bottom-up analysis tells you the project will take two years, the client can now consider the trade-off of the low-cost method versus compressing the project to two years or, in rare cases, cancelling the project. Similar trade-offs can be compared for different levels of resources or increases in technical performance. The assumption is that any movement away from the low-cost, efficient method will increase costs, e.g. overtime. The preferred approach in defining the project is to make rough top-down estimates, develop the WBS/ OBS, make bottom-up estimates, develop schedules and budgets, and reconcile differences between top-down and bottom-up estimates. Hopefully, these steps will be done before final negotiation with either an internal or external customer. In conclusion, the ideal approach is for the project manager to allow enough time for both the top-down and bottom-up estimates to be worked out so a complete plan based on reliable estimates can be offered to the Table 6.3 Conditions for preferring top-down or bottom-up time and cost estimates CondiTion Strategic decision making
ToP-doWn ESTiMATES X
Cost and time important
X
High uncertainty (risk)
X
Internal, small project
X
Fixed-price contract
X
Customer wants details
X
Unstable scope
Pearson_Ch06.indd 138
BoTToM-uP ESTiMATES
X
4/2/2013 4:53:52 PM
CHAPTER 6 Estimating Time, Costs and Resources
139
SNAPSHOT FROM PRACTICEMacmahon: Hope Downs rail project Macmahon Holdings, a Perth-based mining services and construction company, announced its CEO of 12 years was stepping down, in addition to slashing its profit forecast for the current year (2012–13). Why? ‘Macmahon chairman Mr Scott-MacKenzie said the company identified a number of issues with its Hope Downs 4 rail earthworks project that resulted in delays and additional costs to meet Rio Tinto’s track laying deadlines. The A$99 million contract was scheduled for completion in August or September this year [2012], but will now cost the company about A$500 000 a day until completion, according to Mr Scott-MacKenzie. “Following the management review of the Hope Downs 4 project a number of additional issues have been identified with earthworks productivities and the order in which the work must be now performed to meet the revised program,” he said... “These issues mean that additional costs will be incurred to ensure the client’s schedule for track laying is met and that the project is substantially completed in the first half of this financial year”’ (Wilson-Chapman, 2012). Where the failure in estimating actually occurred was not made clear, but the example demonstrates the clear costs of not attending to estimating correctly. Where do you think the process fell down?
on
ly
Source: Wilson-Chapman, A. (2012). Macmahon CEO gone, shares halved. News Limited. Accessed 3 October 2012, from http://m.news.com.au/ BusinessTopStories/pg/0/fi1761244.htm
customer. In this way, false expectations are minimised for all stakeholders and negotiation is reduced. Review Snapshot from practice: Macmahon: Hope Downs rail project.
A HyBRid APPRoACH: PHASE ESTiMATing ing
Sa m
pl
e
The hybrid approach begins with a top-down estimate for the project (typically in the Initiation phase), and then refines estimates for phases of the project in the Planning phase. Some projects, by their very nature, cannot be rigorously defined because of the uncertainty of design or the final product. These projects are often found in aerospace projects, IT projects, new technology projects and construction projects where design is incomplete and the previous phase informs the next phase of the project. In these projects, phase or lifecycle estimating is frequently used. Phase estimating is used when an unusual amount of uncertainty surrounds a project and it is impractical to estimate times and costs for the entire project. Phase estimating uses a two-estimate system over the life of the project. A detailed estimate is developed for the immediate phase and a macro estimate is made for the remaining phases of the project. Figure 6.4 depicts the phases of a project and the progression of estimates over its life. For example, when the project need is determined, a macro estimate of the project cost and duration is made so analysis and decisions can be made. Simultaneously, a detailed estimate is made for deriving project specifications and a macro estimate for the remainder of the project. As the project progresses and specifications are solidified, a detailed estimate for design is made and a macro estimate for the remainder of the project is computed. Clearly, as the project progresses through its life cycle and more information is available, the reliability of the estimates should be improving.
Phase 1 2 3 4
Need 1
Specifications 2
Design 3
Produce 4
Deliver 5
Macro estimate Detailed estimate
Macro estimate Detailed estimate
5
Macro estimate Detailed estimate
Macro estimate Detailed estimate
Figure 6.4 Phase estimating over project life cycle
Pearson_Ch06.indd 139
4/2/2013 4:53:53 PM
140
PART 3 Defining and Managing Projects
Phase estimating is preferred by those working on projects where the final product is not known and the uncertainty is very large; for example, the integration of wireless phones and computers. The commitment to cost and schedule is only necessary over the next phase of the project and commitment to unrealistic future schedules and costs based on poor information is avoided. This progressive macro/micro method provides a stronger basis for using schedule and cost estimates to manage progress during the next phase. Unfortunately, your customer (internal or external) will be pressing for an accurate estimate of schedule and cost the moment the decision is made to implement the project. Additionally, the customer who is paying for the project often perceives phase estimating as a blank cheque because costs and schedules are not firm over most of the project life cycle. Even though the reasons for phase estimating are sound and legitimate, most customers have to be sold on its legitimacy. A major advantage for the customer is the opportunity to change features, re-evaluate or even cancel the project in each new phase. In conclusion, phase estimating is very useful in projects that possess huge uncertainties concerning the final nature (shape, size, features) of the project.
ly
Methods for estimating project costs, time and time and resources
on
This next section reviews a number of the more common estimating tools and techniques used to carry out estimating (for costs, durations and resources). At the end of this section a table is presented which summarises which approach (top-down or bottom-up) the technique is most suited to, some techniques being equally relevant to both top-down and bottom-up approaches.
ConSEnSuS METHodS
Sa m
pl
e
This method simply uses the pooled experience (of managers) to estimate the total project duration and cost. This typically involves a meeting where experts discuss, argue and ultimately reach a decision as to their best guess estimate. Firms seeking greater rigour will use the Delphi Method Meth M ethod od to make these macro estimates. See Snapshot from practice: The Delphi Method. It is important to recognise that these first top-down estimates are only a rough cut and typically occur in the Initiation phase of the project. The top-down estimates are helpful in initial development of a complete plan. However, such estimates are sometimes significantly off the mark because little detailed information is gathered. At this level, individual work items are not identified or, in a few cases, the top-down estimates are not realistic because top management ‘wants the project’. Nevertheless, the initial top-down estimates are helpful in determining whether the project warrants more formal planning, which would include more detailed estimates. Be careful that macro estimates made by senior managers are not dictated to lower-level managers who might feel compelled to accept the estimates even if they believe resources are inadequate. Although the authors prefer to avoid the top-down approach if possible, we have witnessed surprising accuracy in estimating project duration and cost in isolated cases. Some examples are building a manufacturing plant, building a distribution warehouse, developing air control for skyscraper buildings and road construction. However, we have also witnessed some horrendous miscalculations, usually in areas where the technology is new and unproven. Top-down methods can be useful if experience and judgment have been accurate in the past.
ExPERT judgMEnT Similar to the consensus approach, here Subject Matter Experts (SMEs) are drawn into the estimating process. As a SME on a particular subject area, these people bring to the project a vast ‘knowledge base’ of past experience. Using SMEs to estimate components of the project can provide years of insights and experience on the item being estimated. Expert judgment can therefore provide a very useful source of information for estimating that the project manager or others in the project team would otherwise not have access to.
ALTERnATivE AnALySiS Alternative analysis considers the different alternatives that provide the same outcomes/outputs of the project. Alternative analysis can be applied at a higher-level in the project to determine which of a set of options could be
Pearson_Ch06.indd 140
4/2/2013 4:53:53 PM
CHAPTER 6 Estimating Time, Costs and Resources
141
SNAPSHOT FROM PRACTICEThe Delphi Method
on
ly
Originally developed by the RAND Corporation in 1969 for technological forecasting, the Delphi Method is a group decision process about the likelihood that certain events will occur. The Delphi Method makes use of a panel of experts familiar with the kind of project in question. The notion is that well-informed individuals, calling on their insights and experience, are better equipped to estimate project costs/times than theoretical approaches or statistical methods. Their responses to estimate questionnaires are anonymous, and they are provided with a summary of opinions. Experts are then encouraged to reconsider and, if appropriate, change their previous estimate in light of the replies of other experts. After two or three rounds it is believed that the group will converge toward the ‘best’ response through this consensus process. The midpoint of responses is statistically categorised by the median score. In each succeeding round of questionnaires, the range of responses by the panelists will presumably decrease and the median will move toward what is deemed to be the ‘correct’ estimate. One distinct advantage of the Delphi Method is that the experts never need to be brought together physically. The process also does not require complete agreement by all panelists, since the majority opinion is represented by the median. Since the responses are anonymous, the pitfalls of ego, domineering personalities and the ‘bandwagon or halo effect’ in responses are all avoided. On the other hand, future developments are not always predicted correctly by iterative consensus nor by experts, but at times by creative, ‘off the wall’ thinking.
Sa m
pl
e
the best choice; for example, whether an organisation buys in a software package to manage payroll, employs a service company to provide the payroll processing or the project develops a customised software solution in-house. Similarly, the alternative analysis might be considered in a bottom-up approach when estimating a discrete piece of work by simply asking, ‘What alternatives to achieving the same end-state exist?’ During the refurbishment of ore processing plants, the project has work packages defined that cover the refurbishment of a number of silos. What alternatives does the project manager have? Repair using traditional methods or cleaning down, preparing and painting or there might be alternatives in the market place that offer other solutions to the problem.
PARAMETRiC ESTiMATing MATing MAT ing
‘Parametric estimating is an estimating technique in which an algorithm is used to calculate cost or duration based on historical data and project parameters. Parametric estimating uses a statistical relationship between historical data and other variables (e.g., square footage in construction) to calculate an estimate for activity parameters, such as cost, budget, and duration.’ (PMI 2013, p. 170). For example, contractors frequently use the number of square metres to estimate the cost and time to build a house; that is, a house of 50 square metres might cost $1000 per square metre (50 square metres × $1000 per square metre equals $500 000). Likewise, knowing the square metres and dollars per square metre, experience suggests it should take approximately 100 days to complete. Just as parametric techniques such as cost per square metre can be the source of top-down estimates, the same technique can be applied to specific tasks at the work package level For example, as part of a Microsoft Office conversion project, 36 different computer workstations needed to be converted. Based on past conversion projects, the project manager determined that on average one person could convert three workstations per day. Therefore, the task of converting the 36 workstations would take three technicians four days [(36/3)/3]. Similarly, to estimate the wallpapering allowance on a house renovation, the contractor figured a cost of $5 per square metre of wallpaper and $2 per metre to install it, for a total cost of $7. By measuring the length and height of all the walls she was able to calculate the total area in square metres and multiply it by $7.
AnALogouS METHod Analogous means similar or alike in such a way as to permit the drawing of an analogy (a similarity between like features of two things). When applied to project management, we are usually comparing the estimates of the
Pearson_Ch06.indd 141
4/2/2013 4:53:54 PM
142
PART 3 Defining and Managing Projects
project (or components of a project) with past similar projects to obtain our estimates. The analogous method requires that good historical data is available to make comparisons against. ‘Analogous estimating is a technique for estimating the duration or cost of an activity or a project using historical data from a similar activity or project. Analogous estimating uses parameters from a previous, similar project, such as duration, budget, size, weight, and complexity, as the basis for estimating the same parameter or measure for a future project.’ (PMI 2013, p. 169). This method is suitable for use where the current project closely follows past projects in features and costs. Analogous estimates can be made quickly with little effort and reasonable accuracy. This method is very common in projects that are relatively standard but have some small variation or customisation.
3-PoinT ESTiMATE The PERT method (3-point estimate) has become a popular way to arrive at an average based on three estimates. The PERT formula considers three estimates: the Low (optimistic), the Average (most likely) and the High (pessimistic) estimates. The formula for the PERT methodology is:
ly
Optimistic + 4 × Most Likely + Pessimistic essimistic 6
on
When applied to the same data as the range method the results can be seen in Figure 6.5. The PERT formula typically results in a slightly higher estimate than would be achieved if the most likely option was selected. However, if all of these (typically) small increases were taken across the whole project, the result could be a noticeably higher overall project cost and/or time estimate for the project. The challenge here is in obtaining the number of estimates required and the time involved in obtaining them. Overall, this is seen to provide a more realistic estimate.
e
vEndoR Bid AnALySiS
Sa m
pl
Again, as with some of the other methods, the vendor bid method can be applied in both a top-down and bottomup fashion. Although mostly used to obtain quotes for work packages in a bottom-up approach, it can also be applied to a complete branch of the WBS at a higher level (this may be relevant when a whole part of the project is to be contracted out in some form). In this method, vendors are provided with the work package details and asked to provide details of costs and timing. Depending on which stage the project is at, this may influence the type of information requested. For example, during the project Initiation phase a Request for Information (RFI) or Request for Quote (RFQ) might
Figure 6.5 Estimating using the PERT methodology
Pearson_Ch06.indd 142
4/2/2013 4:53:55 PM
CHAPTER 6 Estimating Time, Costs and Resources
143
be an appropriate request to vendors; however, as the project moves into the Planning phase, a Request for Tender (RFT) would be a more appropriate request. Chapter 15 Project Procurement Management covers the types of tender in detail.
ESTiMATing TooLS And SySTEMS
e
on
ly
The best way to improve estimates is to collect and archive data on past project estimates and actuals. Saving historical data (estimates and actuals) provides a knowledge base for improving project time, resource and cost estimating. Creating an estimating database is a ‘best practice’ among leading project management organisations. Organisations that are disciplined about their estimating approach will often capture large amounts of data over a long time, and use this data to produce estimates of work. Internal estimating tools typically reside within spreadsheets and databases. For example, an energy utility company has vast amounts of historical data on completed projects, down to a work package level in the organisation. Each work package successfully captured details of the resources that were actually used, the durations and their associated costs. This data was mined so as to inform the estimate data for standard jobs. The standard jobs were the unit of estimating data for all initial customer requests (projects). Externally, estimating tools may be provided by companies for their customers to use in estimating (thus saving them time and money in estimating). Such tools are often seen on equipment hire websites, where the customer selects the required equipment, nominates the duration of the hire period, insurance level required, delivery charges and other selections as appropriate; the estimating tool then provides a quote. Remember two key rules in setting up estimating tools: the first is to ensure the data is maintained (remember the saying rubbish-in rubbish-out). The second is to allow for variables; for example, what if (in the case of the utility company example) the geological make-up of the ground for which the quote was prepared was unknown?
FunCTion PoinT METHodS FoR SoFTWARE And SySTEM PRojECTS oFTWARE A o FTWARE And nd S SyS Sy yS
Sa m
pl
In the software industry, software development projects are frequently estimated using weighted macro variables called function points or major parameters such as number of inputs, number of outputs, number of inquiries, number of data files and number of interfaces. These weighted variables are adjusted for a complexity factor and added. The total adjusted count provides the basis for estimating the labour effort and cost for a project (usually using a regression formula derived from data of past projects). This latter method assumes adequate historical data by type of software project for the industry—for example, MIS systems. In the US software industry, one-person month represents on average five function points. A person working one month can generate on average (across all types of software projects) about five function points. Of course, each organisation needs to develop its own average for its specific type of work. Such historical data provides a basis for estimating the project duration. Variations of this top-down approach are used by companies such as IBM, HP, AT&T, Ford Motors, GE, DuPont and many others. See Table 6.4 and Table 6.5 for a simplified example of function point count methodology.
Table 6.4 Simplified basic function point count process for a prospective project or deliverable CoMPLExiTy WEigHTing ELEMEnT
Pearson_Ch06.indd 143
LoW
AvERAgE
HigH
ToTAL
Number of inputs
_____ × 2 +
_____ × 3 +
_____ × 4
= _____
Number of outputs
_____ × 3 +
_____ × 6 +
_____ × 9
= _____
Number of inquiries
_____ × 2 +
_____ × 4 +
_____ × 6
= _____
Number of files
_____ × 5 +
_____ × 8 +
_____ × 12
= _____
Number of interfaces
_____ × 5 +
_____ × 10 +
_____ × 15
= _____
4/2/2013 4:53:55 PM
144
PART 3 Defining and Managing Projects
Table 6.5 Example of the function point count method SoFTWARE PRojECT 13: PATiEnT AdMiTTing And BiLLing 15
Inputs
Rated complexity as low
(2)
5
Outputs
Rated complexity as average
(6)
10
Inquiries
Rated complexity as average
(4)
30
Files
Rated complexity as high
(12)
20
Interfaces
Rated complexity as average
(10)
APPLiCATion oF CoMPLExiTy FACToR
Inputs
CounT
LoW
15
×2
AvERAgE
HigH
ToTAL = 30
5
×6
Inquiries
10
×4
Files
30
Interfaces
20
on
Outputs
ly
ELEMEnT
× 12
× 10
= 30 = 40 = 360 = 200
Total
660
Sa m
pl
e
From historical data, the organisation developed the weighting scheme for complexity found in Table 6.3. Function points are derived from multiplying the number of kinds of elements by weighted complexity. Table 6.4 shows the data collected for a specific task or deliverable: Patient Admitting and Billing—the number of inputs, outputs, inquiries, files and interfaces along with the expected complexity rating. Finally, the application of the element count is applied and the function point count total is 660. Given this count and the fact that one-person month has historically been equal to 5 function points, the job will require 132 person months (660/5 = 132). Assuming ssuming you have 10 programmers who can work on this task, the duration would be approximately 13 months. The cost is easily derived by multiplying the labour rate per month times 132 person months. For example, if the monthly programmer rate is $4000, then the estimated cost would be $528 000 (132 × $4000). Although lthough function point metrics are useful, their accuracy depends on adequate historical data, currency of data and relevancy of the project/deliverable to past averages.
LEARning CuRvES ES
Some projects require that the same task, group of tasks or product be repeated several times. Managers know intuitively that the time to perform a task improves with repetition. This phenomenon is especially true of tasks that are labour intensive. In these circumstances, the pattern of improvement phenomenon can be used to predict the reduction in time to perform the task. From empirical evidence across all industries, the pattern of this improvement has been quantified in the learning curve (also known as improvement curve, experience curve and industrial progress curve), which is described by the following relationship: Each time the output quantity doubles, the unit labour hours are reduced at a constant rate. In practice the improvement ratio may vary from 60 per cent, representing very large improvement, to 100 per cent, representing no improvement at all. Generally, as the difficulty of the work decreases the expected improvement also decreases and the improvement ratio that is used becomes greater. One significant factor to consider is the proportion of labour in the task in relation to machine-paced work. Obviously, a lower percentage of improvement can occur only in operations with high labour content. (See Appendix 6.1.) The main disadvantage of top-down approaches to estimating is simply that the time and cost for a specific task are not considered. Grouping many tasks into a common basket encourages errors of omission and the use of imposed times and costs. Micro estimating methods (bottom-up) are usually more accurate than macro methods.
Pearson_Ch06.indd 144
4/2/2013 4:53:55 PM
CHAPTER 6 Estimating Time, Costs and Resources
145
TEMPLATE METHodS If the project is similar to past projects, the costs from past projects can be used as a starting point for the new project. Differences in the new project can be noted and past times and costs adjusted to reflect these differences. For example, a ship repair dry-dock firm has a set of standard repair projects (e.g. templates for overhaul, electrical, mechanical) that are used as starting points for estimating the cost and duration of any new project. Differences from the appropriate standardised project are noted (for times, costs and resources) and changes are made. This approach enables the firm to develop a potential schedule, estimate costs and develop a budget in a very short time span. Development of such templates in a database can quickly reduce estimate errors. These may appear as a Bill of Material (BoM) in some organisations.
RAngE ESTiMATing
Sa m
pl
e
on
ly
When do you use range estimating? Range estimating works best when work packages have significant uncertainty associated with the time or cost to complete. If the work package is routine and carries little uncertainty, using a person most familiar with the work package is usually the best approach. They know from experience or know where to find the information to estimate work package durations and costs. However, when work packages have significant uncertainty associated with the time or cost to complete, it is a prudent policy to require three time estimates—low, average and high. The low to high give a range within which the average estimate will fall. Determining the low and high estimates for the activity is influenced by factors such as complexity, technology, newness and familiarity. How do you get the estimates? Since range estimating works best for work packages that have significant uncertainty, having a group determine the low, average and high cost or duration gives best results. Group estimating tends to refine extremes by bringing more evaluative judgments to the estimate and potential risks. The judgment of others in a group helps to moderate extreme perceived risks associated with a time or cost estimate. Involving others in making activity estimates gains buy-in and credibility to the estimate. Figure 6.6 presents an abridged estimating template using three time estimates for work packages developed by a cross-functional group(s) of project stakeholders. The group estimates show the low, average and high for each work package. The risk level column is the group’s independent assessment of the degree of confidence that the actual time will be very close to the estimate. In a sense, this number represents the group’s evaluation of many factors (e.g. complexity, technology, experience) that might impact the average time estimate. In the PC example in Chapter 5, the group feels work packages (with the WBS IDs) 104, 108, 110, 111 and 114 have a high chance that the average time may vary from expected. Likewise, the group’s confidence feels the risk of work packages (with the WBS IDs) 102, 105 and 112 not materialising as expected is low.
Figure 6.6 Range estimating template
Pearson_Ch06.indd 145
4/2/2013 4:53:55 PM
146
PART 3 Defining and Managing Projects
How do you use the estimate? Group range estimating gives the project manager and owner an opportunity to assess the confidence associated with project times (and/or costs). The approach helps to reduce surprises as the project progresses. The range estimating method also provides a basis for assessing risk, managing resources and determining the project contingency fund. Range estimating is popular in software and new product projects where up-front requirements are fuzzy and not well known. Group range estimating is often used with phase estimating, which is discussed next. Obtaining accurate estimates is a challenge. Committed organisations accept the challenge of coming up with meaningful estimates and invest heavily in developing their capacity to do so. Accurate estimates reduce uncertainty and support a discipline for effectively managing projects. See Table 6.6 for a summary of the differences between top-down and bottom-up estimates. Table 6.6 Summary of estimating tools ToP-doWn
BoTToM-uP
Expert judgment
Applied to the top levels of the WBS.
Applied to items within each work package, to compare/validate against other methods.
Consensus methods and Delphi
Applied to the top levels of the WBS.
Applied to items within each work package.
Analogous estimating
Applied to the top levels of the WBS.
Applied to items within each work package, or at a work package level.
Parametric estimating
Applied to the top levels of the WBS.
Vendor bid analysis
On a section of the WBS which may be outsourced in its entirety.
3-point estimate
Can be applied to a section of the WBS when used in conjunction with other estimating techniques such as vendor bid analysis.
Applied to items within each work package.
Alternative analysis
Applied to the approach taken to accomplish the project at higher-levels of the WBS.
Applied to items within each work package, or at a work package level.
Template methods Range estimating Learning curves Apportion methods Function point methods for software and system projects
on
e
pl
Applied to items within each work package, or at a work package level. Applied to items within each work package, or at a work package level.
–
Applied to items within each work package, or at a work package level.
–
To well defined jobs within a work package.
–
Applied to items within each work package.
–
Applied to items within each work package, or at a work package level.
Sa m
Estimating tools and systems
ly
METHod/TECHniquE
Across all levels in the WBS. –
Across all levels in the WBS. Applied to items within each work package, or at a work package level.
Level of detail in estimating Top management interests usually centre on the total project and major milestone events that mark major accomplishments, for example ‘Build Oil Platform in the North Sea’ or ‘Complete Prototype’. Middle management might centre on one segment of the project or one milestone. First-line managers’ interests may be limited to one task or work package. One of the benefits of WBS is the ability to aggregate activity/task information so each level of management can have the kind of information necessary to make decisions. Getting the level of detail in the WBS to match management needs for effective implementation is crucial, but the delicate balance is difficult to find. See Snapshot from practice: Level of detail: rule of thumb. The level of detail in the WBS varies with the complexity of the project, the need for control, the project size, cost, duration and other factors. If the structure reflects excessive detail, there is a tendency to break the work effort
Pearson_Ch06.indd 146
4/2/2013 4:53:56 PM
CHAPTER 6 Estimating Time, Costs and Resources
147
into department assignments. This tendency can become a barrier to success, since the emphasis will be on departmental outcomes rather than on deliverable outcomes. Excessive detail also means more work, which may not be required given the factors noted previously. Note that if the level of the WBS is increased by one, the number of cost accounts may increase geometrically. On the other hand, if the level of detail is not adequate, an organisational unit may find the structure falls short of meeting its needs. Fortunately, the WBS has builtin flexibility. Participating departments may expand their portion of the structure to meet their special needs. For example, the engineering department may wish to further break down work on a deliverable into smaller packages by electrical, civil and mechanical. Similarly, the marketing department may wish to break a new product promotion into TV, radio, periodicals and newspapers.
SNAPSHOT FROM PRACTICELevel of detail: rule of thumb
Sa m
pl
e
on
ly
Practising project managers advocate keeping the level of detail to a minimum. But there are limits to this suggestion. One of the most frequent errors of new project managers is to forget that the task time estimate will be used to control schedule and cost performance. A frequent rule of thumb used by practising project managers says that task duration should not exceed five or at the most ten work days, if are the time units used for the project. Such a rule probably will result in a more detailed network, but the additional detail pays off in controlling schedule and cost as the project progresses. Suppose the task is ‘build prototype computer-controlled conveyor belt’, the time estimate is 40 working days and the budget $300 000. It may be better to divide the task into seven or eight smaller tasks for control purposes. If one of the smaller tasks gets behind because of problems or a poor time estimate, it will be possible to take corrective action quickly and avoid delaying successive tasks and the project. If the single task of 40 working days is used, it is possible that no corrective action would be taken until day 40, since many people have a tendency to ‘wait and see’ or avoid admitting they are behind or passing on bad news; the result may mean far more than five days behind schedule. The 5 to 10-day rule of thumb applies to cost and performance goals. If using the rule of thumb suggested above results in too many network tasks, an alternative is available, but it has conditions. The activity time can be extended beyond the 5- to 10-day rule only IF control monitoring checkpoints for segments of the task can be established so clear measures of progress can be identified by a specific percentage complete. This information is invaluable to the control process of measuring schedule and cost performance—for example, payments for contract work are paid on ‘per cent complete’ basis. Defining a task with clear definable start and end points and intermediate points enhances the chances of early detection of problems, corrective action and on-time project completion.
Refining estimates estimates
As described earlier, detailed work package estimates are aggregated and ‘rolled up’ by deliverable to estimate the total direct cost of the project. Similarly, estimated durations are entered into the project network to establish the project schedule and determine the overall duration of the project. Experience tells us that for many projects the total estimates do not materialise and the actual costs and schedule of some projects significantly exceed original work package estimates. See Snapshot from practice: How do you estimate the cost of a nuclear power plant? for a dramatic example of this. In order to compensate for the problem of actual cost and schedule exceeding estimates, some project managers adjust total costs by some multiplier (i.e. total estimated costs × 1.20). The practice of adjusting (padding) original estimates by 20 or even 100 per cent begs the question of why, after investing so much time and energy on detailed estimates, could the numbers be so far off? There are a number of reasons for this, most of which can be traced to the estimating process and the inherent uncertainty of predicting the future. Some of these reasons are discussed below:
•
Pearson_Ch06.indd 147
Interaction costs are hidden in estimates. According to the guidelines, each task estimate is supposed to be done independently. However, tasks are rarely completed in a vacuum. Work on one task is dependent upon prior tasks, and the hand-offs between tasks require time and attention. For example, people working on prototype development need to interact with design engineers after the design is completed,
4/2/2013 4:53:56 PM
PART 3 Defining and Managing Projects
•
•
on
•
whether to simply ask clarifying questions or to make adjustments in the original design. Similarly, the time necessary to coordinate activities is typically not reflected in independent estimates. Coordination is reflected in meetings and briefings as well as time necessary to resolve disconnects between tasks. Time, and therefore cost, devoted to managing interactions rises exponentially as the number of people and different disciplines involved increases on a project. Normal conditions do not apply. Estimates are supposed to be based on normal conditions. While this is a good starting point, it rarely holds true in real life. This is especially true when it comes to the availability of resources. Resource shortages, whether in the form of people, equipment or materials, can extend original estimates. For example, under normal conditions four bulldozers are typically used to clear a certain site size in five days, but the availability of only three bulldozers would extend the task duration to eight days. Similarly, the decision to outsource certain tasks can increase costs as well as extend task durations since time is added to acclimatising outsiders to the particulars of the project and the culture of the organisation. Things go wrong on projects.. Design flaws are revealed after the fact, extreme weather conditions occur, accidents happen and so forth. Although you shouldn’t plan for these risks to happen when estimating a particular task, the probability and impact of such events need to be considered. Changes in project scope and plans.. As one gets further and further into the project, a project manager obtains a better understanding of what needs to be done to accomplish the project. This may lead to major changes in project plans and costs. Likewise, if the project is a commercial project, changes often have to be made midstream to respond to new demands by the customer and/or competition. Unstable project scopes are a major source of cost overruns. While every effort should be made up front to nail down the project scope, it is becoming increasingly difficult to do so in our rapidly changing world.
ly
148
Sa m
pl
e
The reality is that for many projects not all of the information needed to make accurate estimates is available, and it is impossible to predict the future. The dilemma is that without solid estimates, the credibility of the project plan is eroded. Deadlines become meaningless, budgets become rubbery and accountability becomes problematic. Challenges similar to those described above will influence the final time and cost estimates. Even with the best estimating efforts, it may be necessary to revise estimates based on relevant information prior to establishing a baseline schedule and budget. Effective organisations adjust estimates of specific tasks once risks, resources and particulars of the situation have been more clearly defined. They recognise that the rolled up estimates generated from a detailed estimate
SNAPSHOT FROM P PRACTICE RACTIC R ACTICEHow do you estimate the cost of a nuclear power plant?
O.P. Kharbanda in his book (co-authored with Jeffrey Pinto) What Made Gertie Gallop: Learning from Project Failures makes the important point that estimating is as much an art as a skill. For example, early in his career (1960s), he was involved with the fabrication of a nuclear reactor in India at a time when the local facilities were not geared for such sophisticated jobs. Having had no experience in building complex equipment with (almost) unheard of tolerances and precision, it was virtually impossible to create a reasonable advance estimate of the cost. The estimators did the best they could, then added a little more than normal margin before quoting a price to the client. Soon after, Kharbanda happened to attend a week-long international nuclear power conference that included stalwarts in this field from all over the world. About midweek, he was fortunate to come face-to-face with the chief engineer of the company that had supplied the first reactor to India, identical in design to the one his company had recently bid on. This was the chance of a lifetime to finally get the inside information on accurate cost estimating. In fact, the expert confessed that his company lost ‘their shirt’ on the Indian reactor. Then in reply to the innocent question, ‘How do you estimate a nuclear reactor?’ the expert answered with cool confidence, ‘Do your normal cautious estimating, add more than normal margin and then after a short pause, double it!’ Kharbanda confessed that in their ignorance, they had skipped the last vital step, but this short, casual conversation proved most valuable. ‘We were forewarned, we took it seriously, and got forearmed. It saved us several millions of dollars.’
Pearson_Ch06.indd 148
4/2/2013 4:53:56 PM
CHAPTER 6 Estimating Time, Costs and Resources
149
ly
based on the WBS are just the starting point. As they delve further into the project-planning process, they make appropriate revisions both in the time and cost of specific activities. They factor the final assignment of resources into the project budget and schedule. For example, when they realise that only three instead of four bulldozers are available to clear a site, they adjust both the time and cost of that activity. They adjust estimates to account for specific actions to mitigate potential risks on the project. For example, to reduce the chances of design code errors, they would add the cost of independent testers to the schedule and budget. Finally, organisations adjust estimates to take into account abnormal conditions. For example, if soil samples reveal excessive ground water, then they adjust foundation costs and times. There will always be some mistakes, omissions and adjustments that will require additional changes in estimates. Fortunately, every project should have a change management system in place to accommodate these situations and any impact on the project baseline. The relationship between change management and contingency funds will be discussed further in Chapter 8.
on
Summary
Sa m
pl
e
Quality, realistic and reliable resource, time and cost estimates are the bedrock of project credibility. Past experience (including lessons learned from previous projects) is one of the best starting points for estimation. The he quality of estimates are influenced by other factors, such as the number of people, tools and time allowed for estimating in the project environment. The he key for achieving estimates that represent realistic average resources, time and costs is to have an organisational culture that understands why errors in estimates can occur, without incrimination. The he use of teams that are highly motivated can help in keeping task times and costs near the average. For this reason, it is crucial to get the team to buy into time and cost estimates. Using sing top-down estimates is good for initial and strategic decision-making or in situations where the costs associated with developing better estimates have little benefit or where time is of the essence. However, in most cases the bottom-up approach to estimating is preferred and more reliable as it assesses each work package, rather than the whole project, section or deliverable of a project. Estimating time and costs for each work package facilitates development of the project schedule and a time-phased budget, which are needed Using sing the estimating guidelines will help eliminate many common to control the project as it is implemented. U mistakes made by those unacquainted with estimating times and costs for project control. Establishing a time and cost estimating tool fits well with the learning organisation philosophy. The he level of time and cost detail should follow the old saying of ‘no more than is necessary and sufficient’. Project managers must remember to differentiate between committed outlays, actual costs and scheduled costs. Itt is well known that up-front efforts in clearly defining project objectives, scope and specifications vastly improve time and cost estimate accuracy. How estimates are gathered and how they are used can affect their usefulness for planning and control. The team climate, organisational culture and organisational structure can strongly influence the importance attached to time and cost estimates and how they are used in managing projects. This chapter has been dedicated to the concept of estimating and the associated tools and techniques available to the project manager. Estimating is carried out in relation to three key aspects:
• • •
resources—estimation of human resources, plant, equipment, raw material/s, capital and other time—the estimation of the duration of the individual resources committed will be required, and the overall durations of the work packages and tasks within the WBS costs—the estimation of the cost of resources and any other identified costs that must be considered to ensure a full and complete project budget can be proposed for approval.
The aspects of time and cost are covered in the next two chapters of this text.
Pearson_Ch06.indd 149
4/2/2013 4:53:56 PM
150
PART 3 Defining and Managing Projects
KEy TERMS learning curve, 144 padding estimates, 133 PERT method, 142 phase estimating, 139 range estimating, 145 resource types, 134 template method, 145 top-down estimates, 138
3-point estimate, 142 bottom-up estimates, 138 contingency, 133 Cost of Quality (CoQ), 137 Delphi Method, 141 direct costs, 135 estimating tools, 140 function points, 143 indirect costs (G&A or overhead costs), 135
EXERCISES
Pearson_Ch06.indd 150
Mrs Tolstoy oy and her husband, S Serge, erge, are planning their dream house. The lot for the house sits high on a hill with a beautiful view of the Blue M Mountains. The plans show the size of the house to be 500 square metres. The he average price for a lot and house similar to this one has been $700 per square metre. Fortunately, Serge erge is a retired plumber and feels he can save money by installing the plumbing himself. Mrs Tolstoy oy feels she can take care of the interior decorating. The he following average cost information is available from a local bank that makes loans to local contractors and disperses progress payments to contractors when specific tasks are verified as complete. • 24% Excavation and framing complete • 8% Roof oof and fireplace fireplace complete • 3% Wiring roughed in • 6% Plumbing roughed in • 5% Siding on • 17% Windows, insulation, walls, plaster and garage complete • 9% Furnace installed • 4% Plumbing fixtures installed
Sa m
1
pl
e
4 5 6
Whyy are accurate estimates critical to effective project management? w does the culture of an organisation influence the quality of estimates? How e the differences between bottom-up and top-down estimating approaches? Under what What are conditions would you prefer one over the other? What is your our understanding of the wider definition of resources? What are e the major types of costs? Which costs are controllable by the project manager? The he estimating trumpet illustrates the tolerances and expectations around levels of estimating accuracy across the life cycle. How do the tolerances resonate with your organisation’s expectations around estimating?
on
1 2 3
ly
REviEW quESTionS
• • • •
10% Exterior paint, light fixtures installed, finish hardware installed 6% Carpet and trim installed 4% Interior decorating 4% Floors laid and finished
a b
What is the estimated cost for the Tolstoy’s house if they use contractors to complete the entire house? Estimate what the cost of the house would be if the Tolstoys use their talents to do some of the work themselves.
4/2/2013 4:53:57 PM
CHAPTER 6 Estimating Time, Costs and Resources
2
3
151
You are about to embark on a project to introduce a project management information system that integrates the functions of scheduling, risk management, social media (blogs, forums and wikis) and additionally must allow contractors to log into the system to update work package performance status. How would the vendor bid analysis and expert judgment approaches be applied in this situation? What is the value in applying both techniques? What would be the downside of applying both techniques? Refer to one of your own recent projects and review the different estimating tools and techniques outlined in this chapter. Make recommendations as to which tools and techniques might have worked better. Also, identify the estimating techniques you chose and reflect on what led you to use them. Which tools might have worked better? What recommendations would you now make to the business?
ly
Case SHARP PRinTing, Ag
Sa m
pl
e
on
Three years ago the Sharp Printing (SP) P) strategic management group set a goal of having a colour laser printer available vailable for the consumer and small business market for less than $200. A few months later the senior management met off-site to discuss the new product. The he results of this meeting were a set of general technical specifications along with major deliverables, a product launch date and a cost estimate based on prior experience. Shortly hortly afterward, a meeting was arranged for middle management explaining the project goals, major responsibilities, the project start date and importance of meeting the product launch date within the cost embers of all departments involved attended the meeting. Excitement was high. Although everyone estimate. Members saw the risks as high, the promised rewards for the company and the personnel were emblazoned in their minds. A few participants questioned the legitimacy of the project duration and cost estimates. A couple of R&D people were worried about the technology required to produce the high-quality product for less than $200. But given the excitement of the moment, everyone agreed the project was worth doing and achievable. The colour laser printer project was to have the highest project priority in the company. Lauren was selected to be the project manager. She had 15 years of experience in printer design and manufacture, which included successful management of several projects related to printers for commercial ince she was one of those uncomfortable with the project cost and time estimates, she felt getting good markets. Since bottom-up time and cost estimates for the deliverables was her first concern. She quickly had a meeting with the WBS identifying the work packages and organisational unit responsible for significant stakeholders to create a WBS implementing the work packages. Lauren stressed she wanted time and cost estimates from those who would do the work or were the most knowledgeable, if possible. Getting estimates from more than one source was encouraged. Estimates were due in two weeks. The compiled estimates were placed in the WBS/OBS. The corresponding cost estimate seemed to be in error. The cost estimate was $1 250 000 over the senior management estimate; this represents about a 20 per cent overrun! The time estimate from the developed project network was only four months over the top management time estimate. Another meeting was scheduled with the significant stakeholders to check the estimates and to brainstorm for alternative solutions; the cost and time estimates appeared to be reasonable. Some of the suggestions for the brainstorming session were:
• • • • • •
Pearson_Ch06.indd 151
change scope outsource technology design use the project-scoring (priority) matrix to get top management to clarify their priorities partner with another organisation or build a research consortium to share costs and to share the newly developed technology and production methods cancel the project commission a break-even study for the laser printer.
4/2/2013 4:53:57 PM
152
PART 3 Defining and Managing Projects
Very little in the way of concrete savings was identified, although there was consensus that time could be compressed to the market launch date, but at additional costs. Lauren met with the marketing (Connor), production (Kim) and design (Gage) managers who yielded some ideas for cutting costs, but nothing significant enough to have a large impact. Gage remarked, ‘I wouldn’t want to be the one to deliver the message to top management that their cost estimate is $1 250 000 off! Good luck, Lauren’. 1 2 3
At this point, what would you do if you were the project manager? Was top management acting correctly in developing an estimate? What estimating techniques should be used for a mission-critical project such as this?
Sa m
pl
e
on
ly
Estimating, is available An appendix which is relevant to this chapter, Learning Curves for Estimating, is available online.
Pearson_Ch06.indd 152
4/2/2013 4:53:57 PM
View more...
Comments
