17,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Fachliteratur
- Sprache: Englisch
Stay on track and within budget with this accessible guide to project planning Project Management For Dummies guides you to a thorough understanding of how to successfully manage projects--and the people who work on them--even if you're brand new to the project management field. You'll learn the basic concepts, key tips and tricks for making things go smoothly, and updated information relevant to today's UK business practices. Even if you aren't entering a project management role, you'll need to learn project planning skills to stay competitive in today's employment market. Now revised with fresh content on everything from a project's start to its finish, this friendly Dummies title will teach you to manage projects large and small. * Learn the must-know concepts in project management * Discover planning techniques that will enhance your effectiveness * Manage projects with in-person or virtual teams * Avoid common mistakes and know what to do when the unexpected happens This guide is excellent for anyone in a project management role, students with an eye toward a career in project management, and anyone who needs to organize and complete large tasks.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 769
Veröffentlichungsjahr: 2023
Ähnliche
Project Management For Dummies®, 3rd Edition
Published by: John Wiley & Sons, Ltd., The Atrium, Southern Gate, Chichester,www.wiley.com
This edition first published 2023
© 2023 by John Wiley & Sons, Ltd., Chichester, West Sussex
Registered Office
John Wiley & Sons, Ltd., The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, United Kingdom
For details of our global editorial offices, for customer services and for information about how to apply for permission to reuse the copyright material in this book, please see our website at www.wiley.com.
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted by the UK Copyright, Designs and Patents Act 1988, without the permission of this publisher.
Designations used by companies to distinguish their products are often claimed as trademarks. All brand names and product names used in this book are trade names, service marks, trademarks or registered trademarks of their respective owners. The publisher is not associated with any product or vendor mentioned in this book.
LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: WHILE THE PUBLISHER AND AUTHORS HAVE USED THEIR BEST EFFORTS IN PREPARING THIS WORK, THEY MAKE NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES REPRESENTATIVES, WRITTEN SALES MATERIALS OR PROMOTIONAL STATEMENTS FOR THIS WORK. THE FACT THAT AN ORGANIZATION, WEBSITE, OR PRODUCT IS REFERRED TO IN THIS WORK AS A CITATION AND/OR POTENTIAL SOURCE OF FURTHER INFORMATION DOES NOT MEAN THAT THE PUBLISHER AND AUTHORS ENDORSE THE INFORMATION OR SERVICES THE ORGANIZATION, WEBSITE, OR PRODUCT MAY PROVIDE OR RECOMMENDATIONS IT MAY MAKE. THIS WORK IS SOLD WITH THE UNDERSTANDING THAT THE PUBLISHER IS NOT ENGAGED IN RENDERING PROFESSIONAL SERVICES. THE ADVICE AND STRATEGIES CONTAINED HEREIN MAY NOT BE SUITABLE FOR YOUR SITUATION. YOU SHOULD CONSULT WITH A SPECIALIST WHERE APPROPRIATE. FURTHER, READERS SHOULD BE AWARE THAT WEBSITES LISTED IN THIS WORK MAY HAVE CHANGED OR DISAPPEARED BETWEEN WHEN THIS WORK WAS WRITTEN AND WHEN IT IS READ. NEITHER THE PUBLISHER NOR AUTHORS SHALL BE LIABLE FOR ANY LOSS OF PROFIT OR ANY OTHER COMMERCIAL DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR OTHER DAMAGES.
For general information on our other products and services, please contact our Customer Care Department within the U.S. at 877-762-2974, outside the U.S. at 317-572-3993, or fax 317-572-4002. For technical support, please visit https://hub.wiley.com/community/support/dummies.
Wiley publishes in a variety of print and electronic formats and by print-on-demand. Some material included with standard print versions of this book may not be included in e-books or in print-on-demand. If this book refers to media such as a CD or DVD that is not included in the version you purchased, you may download this material at http://booksupport.wiley.com. For more information about Wiley products, visit www.wiley.com.
A catalogue record for this book is available from the British Library.
Library of Congress Control Number is available from the publisher.
ISBN 978-1-394-20188-4 (pbk); ISBN 978-1-394-20189-1 (ebk); ISBN 978-1-394-20190-7 (ebk)
Project Management For Dummies®
To view this book's Cheat Sheet, simply go to www.dummies.com and search for “Project Management For Dummies Cheat Sheet” in the Search box.
Table of Contents
Cover
Title Page
Copyright
Introduction
About This Book
Foolish Assumptions
Icons Used in This Book
Beyond the Book
Where to Go from Here
Part 1: Understanding Projects and What You Want to Achieve
Chapter 1: Success in Project Management
Taking on a Project
Avoiding the Pitfalls
Deciding Whether the Job is a Project
Defining the Project Manager’s Role
Deciding On Your Approach
Chapter 2: Thinking Through the Life of Your Project
Using a Set Approach
Breaking the Project Down into Stages
Understanding the Four Main Stages
Chapter 3: Defining the Scope and Producing a Business Case
Defining the Scope
Producing a Business Case
Going Back to the Scope
Getting to Grips with Techniques
Chapter 4: Knowing Your Project’s Stakeholders
Managing Stakeholders
Handling Opposition
Handling Multiple-Stakeholder Projects
Part 2: Planning Time: Determining What, When and How Much
Chapter 5: Planning with Deliverables First
Seeing the Logic of Product Planning
Knowing What a Product Is – and Isn’t
Finding Good Product Names
Using a Business Project Example
Using a Structured Product List
Unleashing the Power of the Work Flow Diagram
Chapter 6: Planning the Activities
Moving From Products to Activities
Drawing Up a First Activity Network
Understanding Float and Its Impact
Identifying the Critical Path
Being More Precise with Dependencies
Working with the Activity Network
Going for Gantt
Estimating Activity Durations
Chapter 7: Looking At Staff Resources
Seeing Why You Need to Plan Staff Use
Matching People to Tasks
Honing Your Task Duration Estimates
Smoothing the Resource
Chapter 8: Planning for Other Resources and Developing the Budget
Determining Physical Resource Needs
Preparing a Budget
Chapter 9: Planning at Different Times and Levels
Putting the Main Structure in Place
Working with Planning Levels
Chapter 10: Dealing with Risk and Uncertainty
Understanding Risks and Risk Management
Working Through the Risk Cycle
Documenting Risk
Getting Some Help from Techniques
Chapter 11: Controlling Quality
Understanding the Effects of Getting Quality Wrong
Defining Quality
Striking the Quality Balance
Spotting Quality Game-Playing and Working to Prevent It
Achieving a Culture of Quality
Getting On Top of Quality in Your Project
Delivering At the Right Level
Reviewing Products
Part 3: Putting Your Management Team Together
Chapter 12: Organising the Project
Designing the Project Organisation
Defining Organisational Structures
Chapter 13: Working With Teams and Specialists
Looking At the Team in Context
Working with Team Leaders
Accepting That People Are Different
Thinking About Suitable Team Members
Considering Performance
Working with Senior Staff
Working with Technical Specialists
Working with Supplier Teams
Dealing With Discipline
Changing Staff
Chapter 14: Being an Effective Leader
Practising Management and Leadership
Knowing What Motivates and What Demotivates
Developing Your Teams
Stoking the Boilers
Part 4: Steering the Project to Success
Chapter 15: Tracking Progress and Staying in Control
Understanding What Underpins Effective Progress Control
Harnessing Product Power for Progress Control
Taking Action When Things Go Off Track
Monitoring Work Effort and Costs
Dealing with Change and Avoiding Scope Creep
Handling Bad News
Chapter 16: Keeping Everyone Informed
Looking At Communications Failure
Communicating Effectively
Choosing the Appropriate Medium
Preparing a Communications Plan
Chapter 17: Closing Your Project
Staying the Course to Completion
Planning Closure
Providing a Good Transition for Team Members
Reviewing the Project
Planning for Things After the Project
Part 5: Taking Your Project Management to the Next Level
Chapter 18: Outlining the Cyclical (Agile) Approach
Understanding the Difference Between Linear and Cyclical Approaches
Seeing Beyond the Hype
Implementing a Cyclical Approach
Choosing The Right Approach for Your Project
Chapter 19: Managing Multiple Projects
Talking the Talk
Deciding on a Programme
Managing a Portfolio
Chapter 20: Using Technology to Up Your Game
Using Computer Software Effectively
Having Your Head in the Cloud
Getting Really Good Stuff for Free
Supporting Virtual Teams with Communication Technology
Saving Time with Software
Being Artificially Intelligent
Chapter 21: Monitoring Project Performance with Earned Value Management
Understanding EVM Terms and Formulas
Working with Ratios and Formulas
Investigating Variances
Deciding What to Measure for EVM
Chapter 22: Project Governance and Why It’s Really Important
Seeing Why It’s a No-brainer
Looking At Other Guidance
Understanding What’s Involved
Understanding the Organisational Level
Checking an Individual Project
Maintaining the ‘Big Divide’
Coordinating Your Project Training
Part 6: The Part of Tens
Chapter 23: Ten Questions to Ask Yourself as You Plan Your Project
What Are the Objectives of Your Project?
Who Do You Need to Involve?
What Will You Produce?
What Constraints Must You Satisfy?
What Assumptions Are You Making?
What Work Has to Be Done?
When Does Each Activity Start and End?
Who Will Perform the Project Work?
What Other Resources Do You Need?
What Can Go Wrong?
Chapter 24: Ten Tips for Writing a Convincing Business Case
Starting with a Bang
Spelling out the Benefits Clearly
Pointing Out the Non-quantifiables
Being Prudent
Considering Three-point Estimating
Making Sure Benefits Aren’t Features
Avoiding Benefits Contamination
Making Sure You Can Deliver Benefits
Supplying Evidence or Referencing It
Using Appendices
Chapter 25: Ten Tips for Being a Better Project Manager
Being a ‘Why’ Person
Being a ‘Can Do’ Person
Thinking about the Big Picture
Thinking in Detail
Assuming Cautiously
Viewing People as Allies Not Adversaries
Saying What You Mean, and Meaning What You Say
Respecting Other People
Acknowledging Good Performance
Being a Manager and a Leader
Index
About the Author
Connect with Dummies
End User License Agreement
List of Tables
Chapter 15
TABLE 15-1 The Work Checklist
List of Illustrations
Chapter 2
FIGURE 2-1: The stages of a project, with two delivery stages.
Chapter 3
FIGURE 3-1: Types of benefit.
FIGURE 3-2: The simple payback model.
FIGURE 3-3: Discounted cash flow.
Chapter 4
FIGURE 4-1: The Stakeholder Matrix.
FIGURE 4-2: Force Field Analysis.
Chapter 5
FIGURE 5-1: Work Flow Diagram – first attempt.
FIGURE 5-2: Work Flow Diagram – adjusted.
FIGURE 5-3: A product hierarchy diagram – the Work Breakdown Structure.
FIGURE 5-4: Creating a control bottleneck.
FIGURE 5-5: The Work Flow Diagram as a visual progress chart.
Chapter 6
FIGURE 6-1: Tasks entered against products on the Work Flow Diagram.
FIGURE 6-2: Tasks against products as a bottom level on the Work Breakdown Stru...
FIGURE 6-3: Basic activity dependency.
FIGURE 6-4: Double dependency.
FIGURE 6-5: Multiple feed.
FIGURE 6-6: The Activity Network based on the Work Flow Diagram.
FIGURE 6-7: Calculating the earliest finish date.
FIGURE 6-8: The forward pass to find the project duration.
FIGURE 6-9: The backwards pass.
FIGURE 6-10: The completed Activity Network.
FIGURE 6-11: A changing critical path.
FIGURE 6-12: The overlap.
FIGURE 6-13: The start to start.
FIGURE 6-14: The lag.
FIGURE 6-15: The finish to finish.
FIGURE 6-16: Activity Network (Precedence Network type) for the example project...
FIGURE 6-17: Moving from the Activity Network to a Gantt Chart.
FIGURE 6-18: The Gantt Chart for the example project.
Chapter 7
FIGURE 7-1: The impact of multi-tasking.
FIGURE 7-2: A Resource Histogram.
FIGURE 7-3: Staff loading information to plan time on several projects.
Chapter 9
FIGURE 9-1: Two options for stages of the same project.
FIGURE 9-2: How plans fit the project.
FIGURE 9-3: Plan types and levels.
FIGURE 9-4: Planning points in a project.
Chapter 10
FIGURE 10-1: A risk cycle example from the Project Techniques Toolbox.
FIGURE 10-2: The Probability–Impact Grid.
FIGURE 10-3: The Ishikawa (fishbone) diagram.
FIGURE 10-4: The decision tree.
Chapter 11
FIGURE 11-1: The quality balance.
FIGURE 11-2: The Graph of Good Intentions.
FIGURE 11-3: Solid and clear box quality.
Chapter 12
FIGURE 12-1: A simple organisation structure for a small project.
FIGURE 12-2: An example of project organisation.
Chapter 13
FIGURE 13-1: The Venn diagram for team management.
FIGURE 13-2: The Controller–Analyst Matrix.
Chapter 14
FIGURE 14-1: Motivation and the ‘potter line’.
FIGURE 14-2: Demotivation model – source unknown.
Chapter 15
FIGURE 15-1: Product delivery and percentage complete shown in combination.
FIGURE 15-2: A typical weekly time sheet.
FIGURE 15-3: A simple financial report.
FIGURE 15-4: The four control dogs.
Chapter 16
FIGURE 16-1: Typical dashboard diagrams.
FIGURE 16-2: Three communication areas in a project.
Chapter 18
FIGURE 18-1: Lists and cycles.
Chapter 19
FIGURE 19-1: Product interdependencies shown on Work Flow Diagrams.
FIGURE 19-2: Programme management example.
Chapter 21
FIGURE 21-1: Monitoring planned value, earned value and actual cost.
FIGURE 21-2: EVM key figures and variances.
Chapter 22
FIGURE 22-1: The project and points for governance checks.
FIGURE 22-2: The project organisation structure and the big divide.
Guide
Cover
Title Page
Copyright
Table of Contents
Begin Reading
Index
About the Author
Pages
i
ii
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
329
330
331
332
333
334
335
336
337
338
339
340
341
343
344
345
346
347
348
349
350
351
352
353
354
355
357
358
359
360
361
362
363
364
365
366
367
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
393
394
395
396
397
398
399
400
401
402
403
405
406
407
408
409
410
411
413
414
415
416
417
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
Introduction
For a very long time people have been running projects – even our prehistoric ancestors must have got organised and worked together to haul a tree trunk over a small river to make a bridge. In the time since, lots of people have come up with lots of ideas for doing things better and more easily with projects. Then they and others have enhanced and refined those ideas to make them even more useful and even more powerful.
So, if you are new to projects, or fairly new and are wondering if there is a better way of doing things, this book gives you two bits of very good news at the outset. First, you don’t have to reinvent the wheel. There is no need to struggle to come up with ways of planning and controlling a project when some really helpful things are already out there that do just what you need … and do it well. Second, using an orderly approach and effective techniques will make your project management life very much easier. This book gives you a sensible and flexible framework for you to plan and manage your project, together with a wealth of powerful and proven techniques, explained clearly and without assuming any previous knowledge of them.
As the management expert W. Edwards Deming said:
It’s not enough to do your best. You must know what to do, and then do your best.
Now, perhaps you are running a project, or are about to, because it’s part of your job, or you may have chosen to focus on this for a career. Either way, project management can be rewarding. There is a definite – and deserved – buzz when you deliver your project successfully and everything works.
Just in case you have heard bad things about some approaches to project management, this introduction also gives you some reassurance. The book is definitely not about making a ‘paper mountain’ of pointless documentation. Neither does it insist that you hold up your right hand and vow to stick to a long list of project rules and regulations. Instead you will find an emphasis on keeping your brain in gear and focusing on what is best and most appropriate for each individual project, even if that means doing something unusual.
Finally, if you are a bit nervous because you have seen or read about project failures both large and small then you can rest a bit easier. If you look at accounts of those projects you will find that many, if not most, of the failures were both predictable and preventable – as covered in Chapter 1! So, you really can be successful where so many others have fallen by the wayside.
About This Book
This book helps you recognise that the basic elements of successful project management are straightforward. The book provides information and explains powerful techniques that help you plan and manage projects successfully. That help includes how to lead and manage other people who are working with you on the project, some of whom may be senior to you in the organisation. You’ll find plenty of tips, hints and guidelines for both the hard skills such as planning and the soft skills for working with people in and around your project.
But knowledge alone won’t make you a successful Project Manager – you need to apply it. This book’s theme is that project management skills and techniques aren’t burdensome tasks you perform because some process requires it. Rather, they’re a way of thinking, communicating and behaving to help you achieve successful delivery.
Like all ‘For Dummies’ books, this one is written to be direct and easy to understand. But don’t be misled – the simple text still navigates all the critical tools and techniques you’ll need to support your project planning, scheduling, budgeting, organising and controlling.
You’ll find that the information is presented in a logical and modular progression. Hints and tips are plentiful, and there’s some attempt at humour from time to time to keep the writing down to earth. The idea is that you finish this book feeling that good project management is a necessity and that you’re determined to practise it!
Foolish Assumptions
When writing this book, I have assumed that a widely diverse group of people will read it, including the following:
Those who are completely new to project management.
Those who have some experience, but want to see if there are better ways of setting up and managing projects that they may have missed.
Senior managers who oversee projects and project managers.
People who’ve had years of real-world business and government experience, and people who’ve just started work.
Above all, I assume that you want to be successful in running projects! After reading this book, I hope you wonder (and rightfully so) why all projects aren’t well managed – because you’ll think these techniques are so logical, straightforward and easy to use. But I also assume you recognise the big difference between knowing what to do and doing it. You’ll have to work hard to overcome pressures that will work to dissuade you from using these tools and techniques. Pressures include any people senior to you who think that if you don’t plan and control a project, it all works out fine just the same, only you’ll have saved time and so deliver faster. Interestingly, the same people don’t take that view when organising their family holidays.
Finally, you’ll find that you can read this book repeatedly and find out something new each time. Think of this book as a comfortable resource that has more to share as you experience new situations.
Icons Used in This Book
The small icons in the left margins of the book are to alert you to special information in the text. Here’s what they mean:
This icon indicates a point that is key to making you effective as a project manager.
This icon to points out important information you want to keep in mind as you apply the techniques and approaches.
This icon helps you get to grips with ‘project speak’ terms or issues that are a bit more technical (or at least sound more technical until they’re explained).
This icon highlights something you can use to improve your project management practices.
This icon highlights potential pitfalls and dangers.
Beyond the Book
In addition to the abundance of information and guidance related to project management provided in this book, you get access to even more help and information online. Check out this book’s online Cheat Sheet. Just go to www.dummies.com and search for ‘Project Management For Dummies Cheat Sheet UK’, which reminds you of the most important points about the subject.
Where to Go from Here
You can read this book in many ways, depending on your own project management knowledge and experience and your current needs. However, it’s worth starting out by taking a minute to scan the table of contents and thumb through the sections of the book to get a feeling for the topics.
If you’re new to project management and are just starting to plan a project, first read Parts 1 and 2, which explain how to plan outcomes, activities, schedules and resources. If you want to find out how to identify and organise your project’s team and other key people, start with Chapter 12 and Part 3. Or feel free to jump back and forth, hitting the topics that interest you the most, or where you want to refresh your knowledge as you approach a particular stage of your project.
No matter how you make your way through this book, plan on reading all the chapters more than once – the more you read a chapter, the more sense its approaches and techniques will make and the more it will all just become the way that you think and work. And in all cases, have fun – project management really can be enjoyable!
Part 1
Understanding Projects and What You Want to Achieve
IN THIS PART …
Understand why projects go wrong, and see why you can succeed.
Answer the question ‘Is this really a project?’, because not everything is.
See how to specify the scope of the project and balance the control factors to ensure that it is achievable.
Recognise who’s likely to have an interest in your project, and how you have to manage them.
Chapter 1
Success in Project Management
IN THIS CHAPTER
Understanding what makes a project a project
Seeing what’s involved in project management
Coming to grips with the Project Manager’s role
Knowing what it takes to be a successful Project Manager
Organisations are constantly changing as they keep pace with new market conditions, new financial regulations, new business practices, new legal requirements and new technology. Then there is work such as upgrading or moving premises, installing new facilities, carrying out major maintenance, improving manufacturing processes and re-branding commercial products. A lot of that work is carried out with projects, and as a result people are needed who can manage those projects and manage them well.
Taking on a Project
Because you’re reading this book, the chances are that you’ve been asked to manage a project for the first time or that you’re already running projects and are looking to see whether you can find easier and better ways of doing things. If the project is indeed your first one, that’s a challenge and may well give you the chance to excel in something you haven’t done before; for many, managing a project even opens a door to a new career.
The really good news here, whether you’re completely new or have some experience, is that project management has been around for a very long time. In that time, Project Managers have come up with highly effective strategies and a range of very practical techniques. You can benefit from all that experience, and this book takes you through what you need to know. You may be a bit guarded even now because you’ve heard of, read about or even seen, a lot of project problems and failures. More really good news is that most project failure comes from well-known and avoidable problems; you really don’t have to be part of the failure statistics if you manage your project in the right way.
So, hang on tight – you’re going to need an effective set of skills and techniques to steer your projects to successful completion. This chapter gets you off to a great start by showing you what projects and project management really are and by helping you separate projects from non-project work. The chapter also gives you some insight into exactly why projects go wrong. That will help you become absolutely determined to do things right and succeed where so many others have failed.
This book offers a generic, introductory approach to project management and isn’t based on any one method. It describes a structure and techniques that are built into many ways of running projects, but it doesn’t cover the procedural detail of those methods. For that, and for help with any accompanying professional exams, you will also need to consult the relevant manuals and exam syllabuses.
Avoiding the Pitfalls
By following a sound approach to the project, you automatically avoid many of the pitfalls that continue to contribute to, or cause, project failure on a mind-boggling scale. You may ask why, if good ways of doing things are out there, people ignore them and then have their projects fail. Good question. People make the same project mistakes repeatedly, and they’re largely avoidable. You may have come across the joke by comedian Tommy Cooper:
I went to the doctor and said ‘Every time I do this, it hurts.’ The doctor said, ‘Well, don’t do it.’
The following list takes a quick look at the main causes of project failure; you’ll find the remedies in later chapters in the book. The list makes for depressing reading, particularly if you recognise some elements in parts of your own organisation. Nevertheless, it gives a good background against which to contrast successful project management and the approach and techniques set down in this book:
Lack of clear objectives:
Nobody’s really sure what the project is about, much less are people agreed on it.
Lack of risk management:
Things go wrong that someone could easily have foreseen and then controlled to some degree, or even prevented.
No senior management ‘buy in’:
Senior managers were never convinced and so never supported the project, leading to problems such as lack of resource. Neither did those managers exercise effective management oversight (good project governance) as they routinely do in their other areas of responsibility.
Poor planning:
Actually, that’s being kind, because often the problem is that no planning was done at all. It’s not surprising, then, when things run out of control, and not least because nobody knows where the project should be at this point anyway.
No clear progress milestones:
This follows on from poor planning. The lack of milestones means nobody sees when things are off track, and problems go unnoticed for a long time.
Understated scope:
The scope and the Project Plan are superficial and understate both what the project needs to deliver and the resource needed to deliver it. Project staff (often team members) then discover the hidden but essential components later in the project. The additional work that is necessary then takes the project out of control, causing delay to the original schedule and overspending against the original budget.
Poor communications:
Many projects fail because of communication breakdown, which can stem from unclear roles and responsibilities and from poor senior management attitudes, such as not wanting to hear bad news.
Unrealistic resource levels:
It just isn’t possible to do a project of the required scope with such a small amount of resource – staff, money or both.
Unrealistic timescales:
The project just can’t deliver by the required time, so it’s doomed to failure.
No change control:
People add in things bit by bit –
scope creep
. Then it slowly dawns on everyone that the project’s now grown so big that it can’t be delivered within the fixed budget or by the set deadline.
That’s ten reasons for failure, but you can probably think of a few more. The interesting thing about these problems is that avoiding them is, for the most part, actually not that difficult.
Deciding Whether the Job is a Project
Before you start to think too deeply about how to set up the project, the first thing to do is check whether it really is one. No matter what your job is, you handle lots of work each day: answer customer enquiries, hold a meeting, update the accounts, design a sales campaign or move to new offices. Not all of this work is a project. So what makes something a project?
Some people say that everything is a project, even making a cup of tea. Don’t listen to them. You can think about three things to determine whether a job is a project:
Is it a one-off job or something that’s ongoing? If the job is ongoing, like producing bars of soap on a production line or taking customer orders, then it’s business as usual, not a project.
Does the job justify project controls? Project management means incurring some overheads, although you can find advice in this book on how to keep overheads to the minimum. But the fact remains that there will be overheads in a project (such as for planning, approval and control) and some jobs are so small or straightforward that they just don’t justify that degree of control.
This last one may sound a little weird, and it certainly doesn’t fit with the formal definitions; it’s the question, ‘Do you want to handle the job as a project?’ You may choose to deal with a block of work as a project, but I wouldn’t – so, in some instances, you have a choice.
Understanding the four control areas
Different project approaches have slightly different definitions of a project; here’s one:
A project is a temporary undertaking performed to produce a unique product, service or result.
The ‘unique product’ is true, but don’t let that put you off setting up projects that are effectively repeated, such as organising the annual company conference. Although, strictly speaking, the task is unique each time, you will nevertheless find large areas of commonality with previous projects so you don’t need to reinvent the wheel. For example, you can probably adapt last year’s plans rather than starting from scratch.
Large or small, projects involve the following four areas of control:
Scope:
What the project will deliver
Time:
When the project will deliver
Quality:
So often forgotten, but an essential control dimension
Resource:
Necessary amounts of staff time, funds and other resources such as equipment and accommodation that the project needs
You need to balance these areas for each project, and you can see immediately why so many projects get into difficulties. You look at a project, think about the four control factors and say to yourself, ‘They want that scope, to that quality level, with just that resource and by then? They’ve got to be joking!’ Strangely, organisational managers often commit projects to failure by insisting on unachievable deadlines or unrealistic resources. What’s even more strange is that those same managers are then surprised and even angry when the projects inevitably get into difficulties and fail.
Getting the balance right in the early part of the project when you do the main scoping and planning is, obviously enough, essential. Jerry Madden of NASA, the American space agency, produced a great document called ‘One Hundred Rules for NASA Project Managers’. Rule 15 is:
The seeds of problems are laid down early. Initial planning is the most vital part of a project. The review of most failed projects or project problems indicate the disasters were well planned to happen from the start.
It’s also useful to think about the four areas of control when dealing with change in the project. Chapter 15 includes a ‘four dog’ model to help you think about the interaction. The four components are the basis of a project’s definition for the following reasons:
The only reason the project is run is in order to produce the results specified in its scope.
The project’s end date is often an essential part of defining what constitutes success. In some cases, the project must provide the result by a specified time in order to meet its goal (it’s
time-critical
).
The quality requirement is a vital part of the balance and may be the most important element, even though many organisational managers are preoccupied with time and cost.
The availability of resources can affect which products the project can produce and the timescale in which it can produce them.
Quality can be a very important factor, and is sometimes the most important. Unless the project is time-critical, it may be better for the project to deliver slightly late but where everything works properly, than to deliver on time but with lots of faults and problems.
Recognising the diversity of projects
Projects come in a wide assortment of shapes and sizes. For example, projects can:
Be large or small:
Building the new Elizabeth Line railway across London at a cost of around £19 billion and taking 13 years to construct.
Preparing the annual report for the organisation may take you six weeks to complete and may also be a project.
Involve many people or just you:
Training all 10,000 of your organisation’s sales staff worldwide in the working of a new product is a project.
Redecorating an office and updating the furniture and equipment is also a project.
Be defined by a legal contract or by an informal agreement:
A signed contract between you and a customer that requires you to build a house defines a project.
An informal agreement by the IT department to install new software in a business area defines a project.
Be business related or personal:
Conducting a sales practice review across all of the countries in your international organisation is a project.
Preparing for a family wedding is also a project – and a very much more pleasant one than the sales practice review.
No matter what the individual characteristics of your project are, you can use the same four elements of scope, time, quality and resource to think it through.
A PROJECT BY ANY OTHER NAME – JUST ISN’T A PROJECT
People often confuse the following two terms with project:
Process: A process is a series of routine steps to perform a particular function, such as a procurement process or a budget process. A process isn’t a one-time activity that achieves a specific result; instead, it defines how you do a particular function every time.Programme: A programme (overseen by a Programme Manager) is a set of projects that need to be coordinated in some way. Perhaps it’s a strategic programme to change the whole way the organisation works, or perhaps it’s a group of projects with significant interdependencies that all need to be managed so that they finish at the same time. See Chapter 19 for more on programmes.Understanding the four stages of a project
Every project, whether large or small, goes through a series of stages and this book will follow four. Other approaches may group things slightly differently, and start earlier with an initial idea for a project, but the sequence will still be pretty much the same.
In this book the successive sections of the project are referred to as stages. You may hear the term phases used sometimes, particularly in software, but don’t be thrown by that because it’s just an alternative name.
Starting the project:
This stage involves thinking through the project proposal at a high, ‘sketch’ level. That includes assessing the business need for the project and its overall characteristics, which will indicate how it should be run. For example, it may be business-critical or very high-risk. You must also give some thought on who should be involved in the project if it goes ahead and check whether those people are available. You’ll normally put all of this sketch-level information in a document called an
Outline Charter
(or just Outline for short), or your organisation may refer to it as a
Project Brief.
The stage will end with agreeing, or maybe not, to go on to the next stage and prepare a detailed Project Plan.
The planning stage – organising and preparing:
This stage includes developing a full Project Plan that specifies what the project will deliver, the work to be done and the time, cost and other resources required. Then you’ll need to work the Business Case up into full detail from the sketch version you prepared for the Outline. There will be other plans too, such as for how you will control risks and how you will manage stakeholders. You’ll normally produce two main planning documents in this stage. There’s the Project Charter which covers the strategic parts of the project such as the Business Case, and the PMP (Project Management Plan) which covers the more tactical things such as the Project Plan, the Risk Plan and the Quality Plan. Then you’ll need to produce a more detailed Stage Plan for the first delivery stage so the project can move on smoothly if the Charter and PMP are approved. If this all sounds a lot, don’t get too worried and that’s for two reasons. First, you need to think things through properly if the project is to run smoothly. Second, in a smaller project especially, these plans may be quite short.
Development stage(s) – carrying out the work:
This stage involves doing the planned work. You’ll normally split this up into a sequence of delivery stages, though in a very small project you might opt for having just one. During each delivery stage you’ll be monitoring and controlling performance to ensure that things are going to plan, and doing the more detailed planning of successive delivery stages as the project continues. Controls used during the stage may include things like progress checks, progress meetings, risk reports and verifying that the required quality is being achieved. Each stage will finish with a
Stage Gate
to check that everything is okay before going on to the next stage.
Closure stage:
This stage involves a clear shut-down of the project work and then assessing the results, assigning project team members to new work, closing financial accounts. You should always carry out an evaluation of how things went and measure the benefits achieved. However, as some benefits might not come on-stream for a while, you may also need one or more further reviews after the project to measure them. Outputs from this stage should also include identifying lessons learned (good and bad things) from this project to help future projects.
For small projects, this entire life-cycle can take a few days. For larger projects, it can take years! Chapter 2 goes though these stages – the life of your project – in more detail so you can see exactly what you need to be doing and when.
In a perfect world, projects run smoothly and always go exactly to plan. However, because you don’t live in a perfect world and because your project certainly won’t be running in one, you need to be flexible. When starting to think about your project, you need to allow for:
The unknown and uncertain:
Projects are rarely 100 per cent predictable. The normal territory of projects is that, to some extent at least, you’re going into the unknown. Therefore, your plans need to allow for things going off track. Sometimes the uncertain areas are predictable, which falls partly into the area of risk management (see
Chapter 10
for how to assess and manage risks). Sometimes the areas aren’t at all predictable, and that comes into the area of contingency. You need contingency; remember Murphy’s Law – ‘If it can go wrong, it will go wrong.’ You can find more about contingency in
Chapter 10
.
Learning by doing:
Despite doing your best to develop good plans at the front end of the project, you may find later on that you can’t achieve what you thought you could or in the way you thought you could. When this situation happens, you need to rethink in the light of the new information you’ve acquired. Sometimes you can see up front that you won’t know how a particular part of the project is going to work out until you get nearer to that point and better information is to hand. Don’t worry about that; just point it out clearly in the plans at the beginning.
Unexpected change:
Your initial feasibility and benefits assessments are sound, and your plan is detailed and realistic. However, certain key project team members leave the organisation without warning during the project. Or a new technology emerges, and it’s more appropriate to use than the one in your original plans. Perhaps the business environment changes and with it your organisation’s whole market strategy. You need to rethink and re-plan in light of these new realities because ignoring them may seriously threaten the successful delivery of your project.
Defining the Project Manager’s Role
The Project Manager’s job is to manage the project on a day-to-day basis to bring it to a successful conclusion. They will usually be accountable to a senior manager who’s the project Sponsor, or to a small group of managers who form a Project Steering Group (PSG) – sometimes known as a Project Board. The Project Manager’s job is challenging (for instance, to coordinate technically specialised professionals who may have limited experience of working together).
It’s important to understand that the Project Manager’s position is indeed a role; it’s not about status. That’s true of all roles in the project and there may, for example, be very senior people working as team members (such as a chief engineer and legal advisers) who are accountable to the Project Manager even though in the normal business they’re much more senior. Have a look at Chapter 13 to find out about managing very senior people in your project.
The role of Project Manager doesn’t include any of the technical work in the project. If that same person is involved in technical work then it’s with a different hat on – that of a team member. The distinction is important because if you’re doing teamwork as well as project managing, you must be clear about both roles and only wear one hat at a time. It’s all too easy to neglect the management and let the project run out of control because you’re so engrossed in the detail and challenges of your part of the technical work.
The Project Manager’s role requires ‘hard’ skills such as planning and costing, but also ‘soft’ people skills. You can’t specialise and cover only the hard skills, for example, with the excuse ‘I’m not really a people person’. The next sections cover the main tasks that a Project Manager handles and notes potential challenges.
Looking at the Project Manager’s tasks
Your role as the Project Manager is one of day-to-day responsibility for the project, and that might involve so much work that your job must necessarily be a full-time one. Or it may be that the project is smaller and less complicated and project management is just part of your job. Either way, the responsibilities are the same; it’s just the scale and complexity that are different.
Here’s a summary of the main tasks. Some things on the list involve consultation with others:
Sketch out initial ideas for the project, with the justification, outline costs and timescales.
Plan the project, including mapping out the controls that will be put in place, defining what quality the project needs and how it will be achieved, analysing risk and planning control actions.
Control the flow of work to teams (or perhaps just team members in a smaller project).
Motivate and support teams and team members.
Liaise with external suppliers.
Liaise with Project Managers of interfacing projects.
Liaise with programme management staff if the project is one of a group of projects being coordinated as a programme.
Ensure that the project deliverables are developed to the right level of quality.
Keep track of progress and adjust to correct any minor drifts off the plan.
Keep track of spending.
Go to others, such as the PSG, if things go more significantly off track (for example, the whole project is threatened).
Report progress to the PSG and perhaps to others too.
Keep track of risks and make sure that control actions are taken.
Deal with any problems, involving other people as necessary.
Decide on changes, getting approval from others where you don’t have personal authority to make a decision (for example, when changes involve very high cost).
Plan successive delivery stages in more detail.
Close the project down in an orderly way when everything’s done.
So, the tasks will keep you very busy but being a Project Manager can also be very enjoyable if you have things in control. And you get a real buzz when your project is delivered successfully.
Be proactive. Get out in front of the project and direct where it’s going. Don’t follow on behind the project being reactive and having to fire-fight countless problems because you didn’t see them coming.
Opposing opposition
Be prepared for other people to oppose your attempts to use proven project management approaches. The following list provides a few examples of excuses you may come across:
Excuse: Our projects are all to short deadlines; we have no time to plan.
Response: Unfortunately for the excuse giver, this logic is illogical! With a short deadline, you can’t afford to make many mistakes. If it doesn’t matter too much when the project delivers, you don’t need as good a plan as if it matters very much and time is short.
Excuse: Project management just means more overheads.
Response: So does corporate management, and that’s essential too! But in any case, if you don’t manage a project properly and it fails, how much will that cost in wasted time, money and lost benefits?
Excuse: These projects require creativity and new development. You can’t predict their outcomes with any certainty.
Response: You can predict some projects’ outcomes better than others. However, people awaiting the outcomes of any project still have expectations for what they’ll get and when. Therefore, a project with many uncertainties needs a manager to develop and share initial plans and then to assess and explain the effects of unexpected occurrences.
Avoiding ‘shortcuts’
The short-term pressures of your job, particularly if you’re fitting in project management alongside other work, may tempt you to cut corners. That’s not the same as adjusting the project management needs to the project, but rather missing stuff out altogether that you know you really should have done. Resist the temptation to cut corners, because usually doing so comes back and bites you later.
Don’t be seduced into seemingly easier shortcuts such as:
Jumping straight into building stuff (delivery):
Sounds good, but you haven’t defined the work to be done! A variation on this shortcut is: ‘This project’s been done before, so why bother with planning?’ Even though projects can be similar to past ones, some elements will be different. Always check the plan thoroughly.
Failing to check progress at frequent intervals:
Just as when you’re walking somewhere you need to check the map from time to time, so too you need to check the project. Otherwise you won’t see warning signs and may be a long way off track by the time you notice that something’s wrong.
Not keeping the plan up to date:
That includes logging
actuals
such as the time actually taken to do things and the money actually spent. Yes, it takes discipline to keep things up to date, but you’ll never be able to control the project if you don’t know where you are at the moment.
Not completing the closure stage:
At the end of one project, you can face pressure to move right on to the next. But you must check that the project has achieved what it was supposed to and that you and your organisation take on board any lessons, good and bad, for the future.
Deciding On Your Approach
Always do what’s best to bring your project to successful delivery. If you are using a particular approach, be prepared to modify it rather than follow it slavishly. If that means breaking some ‘rules’, then break them. That doesn’t mean cutting corners or being negligent, but rather agreeing with the PSG that this is best for the project.
Focus on the project, its characteristics and its control needs. Then decide how to approach the project management based on the specifics of that project. Don’t stretch your poor project around some inflexible standard approach carved in stone that doesn’t really work for it, either in whole or in part. Instead, fit your approach around the project.
As an example of blindly following a project approach, I once went onto a customer site where the organisation was using a very well-known one. A conversation went something like this, although my comments were phrased a little more carefully, being an invited consultant:
Customer:
We know it’s stupid for this project but [approach named] made us do this.
Me:
That approach is set down in a document. A document can’t jump off the table, beat you around the head and make you do something. Why did you do something on your project which you knew to be stupid?
In short, when running projects always keep your brain in gear and be prepared to do the unusual if necessary to help successful delivery.
Chapter 2
Thinking Through the Life of Your Project
IN THIS CHAPTER
Understanding the lifespan of the project
Seeing the different characteristics of each stage
Knowing what to do at each point in your project
Dealing with project documentation and not letting it take over
This chapter covers the lifespan of the project from the initial idea through to closure. Sometimes seeing how things such as business justification, planning and risk management fit into a project can be difficult until you have the big picture, so this chapter provides that big picture. It covers what you need to do and at what points, and it also explains a couple of key project documents that you may find helpful.
Using a Set Approach
A lot of projects have a sequence from the first idea through to closure, and this chapter provides you with a clear structure, although it is simple. An alternative is to take a cyclical approach where you develop things bit by bit rather than mostly planning it all up front and then developing it. There’s a brief explanation of the cyclical approach in Chapter 18.
If then, after reading this book, you want to move on to a more detailed approach, you can use a particular published one. Some are built into software tools like Microsoft Project while others are developed by consultancies for use with their clients. Then there are PMBoKs (Project Management Body of Knowledge) produced by project organisations with a professional membership; notably the Association for Project Management (APM) in the UK and the Project Management Institute (PMI) in the USA and worldwide.
In contrast, this book sets out the work of project planning and management in a simple and sequential way which suits a lot of projects, and particularly so in many business and technical environments where things must be thought through, constructed and delivered once, not repeatedly.
Breaking the Project Down into Stages
Just about all project management approaches break projects into stages, or you may have heard them called phases. Chapter 1 sets out the four main stages in any project:
Starting the project
The planning stage – organising and preparing
The delivery stage(s) – doing the work of the project
The closure stage – closing in an orderly way
The four stages are single ones with the exception of the delivery stage(s). You can have two or more of these. In a small project you may decide on a single delivery stage, but in most projects you have several. You can see a project example with two delivery stages in Figure 2-1.
© John Wiley & Sons Inc.
FIGURE 2-1: The stages of a project, with two delivery stages.
THE UNOFFICIAL STAGES OF A PROJECT
The origin of these unofficial stages is unknown, but they’re realistic for many organisations … though hopefully not yours!
EnthusiasmDisillusionmentPanicSearch for the guiltyPunishment of the innocentPraise and honour for the non-participantsSome say that the first stage, starting the project, isn’t part of the project but is rather preparation beforehand to include things such as checking to make sure that the project really is a project. That’s a logical argument, and Figure 2-1 reflects that view.
If you go with the idea of starting the project not actually being part of the project, then the project starts for real with the full planning in the second stage. Where you are working with formal budgets and budget codes, the work in starting a project is often financed out of a general fund, and if a project looks to be worthwhile, the specific budget code for that is opened for use from the beginning of the second stage.
Appreciating the advantages of stages
Breaking the project into stages has some big advantages; here are just four:
While not taking away from the big picture of the project, it allows everyone to concentrate on one part of the work at a time. One person described it as ‘looking at one stair instead of the whole staircase’.
It breaks up the detailed planning into convenient blocks, and you plan each delivery stage in detail just before that stage starts with the benefit of the very latest information available.
It allows the Sponsor or Project Steering Group (PSG) to stay in firm control of money and staff resource by authorising one stage at a time.
It provides a clear point when each stage ends, usually called a
Stage Gate
, for checking that the project is still in control, is heading in the right direction, and remains viable and worth continuing.
Deciding on the number of delivery stages
How many delivery stages should you have? Well, how long is a piece of string? Actually, you can answer the question about the string: it’s exactly twice as long as half a piece. As for the delivery stages, it all depends.
The first thing to say about delivery stages is that they’re not all the same length. They’re not timed units of, say, one month long. Rather, delivery stages reflect two main criteria:
