#3E-Publishing industry | Explore Tumblr Posts and Blogs

kakita-shisumo · 1 year

Text

In which I sound off for much too long about PF2 (and why I like it better than D&D 5E)

So, let me begin with a disclaimer here. I don’t hate 5E and I deeply despise edition warring. I like 5E, I enjoy playing it, and more, I think it’s an incredibly well-designed game, given what its design mandates were. This probably goes without saying but I wanted it on the record. While I will be comparing PF2 to D&D 5E in what follows and I’ve pretty much already spoiled the ending by the post title (that is, PF2 is going to come out ahead in these comparisons most of the time), I don’t want there to be any misunderstanding about my position or intention. My opinions do not constitute an attack on anybody. For that matter, things I might list as weaknesses in 5E or strengths of PF2 might be the exact opposite for other people, depending on what they want from their RPG experience.

As I said before, 5E is an exceedingly well-designed game that does an exceptional job of meeting its design goals. It just so happens that those design goals aren’t quite to my taste.

# A Brief History of the d20 RPG Universe #

I’m going to indulge myself in a little history for a second; some of it might even be relevant later, but for the most part, I just want to cover a little ground about how we got here. By the time the late ‘90s rolled around TSR and its flagship product, Dungeons and Dragons, were in trouble. D&D was well over two decades old by that point and showing its age. New ideas about what RPGs could and even should be had taken over the industry; TSR had finally lost its spot as best-selling RPG publisher to comparative upstart White Wolf and their World of Darkness games; the company even declared bankruptcy in 1997. Times were grim.

That, however, was when another comparative newcomer, Wizards of the Coast, popped up and bought TSR outright. Flush with MtG and Pokemon cash, they were excited to try to revitalize the D&D brand and began development on a new edition of D&D: third edition, releasing in August 2000.

Third edition was an almost literal revolution in D&D’s design, throwing a lot of “sacred cows” out and streamlining everywhere: getting rid of THAC0 and standardizing three kinds of base attack bonus progressions instead; cutting down to three, much more intuitive kinds of saving throws and standardizing them into two kinds of progression; integrating skills and feats into the core rules; creating the concept of prestige classes and expanding the core class selection. And of course, just making it so rolls were standardized as well, using a d20 for basically everything and making it so higher numbers are basically always better.

At the same time, WotC also developed the concept of the Open Gaming License (OGL), based on Open Source coding philosophies. The idea was that the core rules elements of the game could be offered with a free, open license to allow third-parties develop more content for the game than WotC would have the resources to do on their own. That would encourage more sales of the base game and other materials WotC released as well, creating a virtuous cycle of development and growing the industry for everyone.

Well, long story short (too late!), it worked like fucking gangbusters. 3E was explosive. It sold beyond anyone’s expectations, and the OGL fostered a massive cottage industry of third-party developers throwing out adventures, rules material, and even entire new game lines on the backs of the d20 system. A couple years later, 3.5 edition released, updating and streamlining further, and it was even more of a success than 3rd ed was.

At this point, we need turn for a moment to a small magazine publishing company called Paizo Publishing, staffed almost exclusively by former WotC writers and developers who had formed their own company to publish Dungeon and Dragon, the two officially-licensed monthly magazines (remember those?) for D&D. Dungeon focused on rules content, deep dives into new sourcebooks, etc., while Dragon was basically a monthly adventure drop. Both sold well and Paizo was a reasonably profitable company. Everything seemed to be going swimmingly.

Except. In 1999, WotC themselves were bought by board game heavyweight Hasbro, who wanted all that sweet, sweet Magic: the Gathering and Pokemon money. D&D was a tiny part of WotC at the time and the brand was moribund, so Hasbro’s execs hadn’t really cared if the weirdos in the RPG division wanted to mess around with Open Source licensing. It wasn’t like D&D was actually making money anyway… until it was. A lot of money. And suddenly Hasbro saw “their” money walking out the door to other publishers. So in 2007, WotC announced D&D 4th Ed, and unlike 3rd, it would not be released under an open license. Instead, it would be released under a much more restrictive, much more isolationist Gaming System License, which, among other things, prevented any licensee from publishing under the OGL and the GSL at the same time. They also canceled the licenses for Dungeon and Dragon, leaving Paizo Publishing without anything to, well, publish.

At first, Paizo opted to just pivot to adventure publishing under the OGL. Dungeon Magazine had found great success with a series of adventures over several issues that took PCs from 1st all the way to 20th level, something they were calling “Adventure Paths,” so Paizo said, “Well, we can just start publishing those! We’re good at it, the market’s there, it will be great!” And then, roughly four months after Paizo debuted its “Pathfinder Adventure Paths” line, WotC announced 4th Ed and the switch to the GSL. Paizo suddenly had a problem.

4th Ed wasn’t as big a change from 3rd Ed as 3rd Ed had been from AD&D, but it was still a major change, and a lot of 3rd Ed fans were decidedly unimpressed. Paizo’s own developers weren’t too keen on it either. So they made a fateful decision: they were going to use the OGL to essentially rewrite and update D&D 3.5 into an RPG line they owned: the Pathfinder Roleplaying Game. It was unprecedented. It was a huge freaking gamble. And it paid off more than anybody ever expected. Within two years Paizo was the second-largest RPG publisher in the industry, only behind WotC itself, and for one quarter late in 4E’s life, even managed to outsell D&D, however briefly. Ten years of gangbuster sales and rules releases followed, including 6 different monster books and something over 30 base classes when it was all said and done. It was good stuff and I played it loyally the whole time.

Eventually, though, time moves on and things have to change. The first thing that changed was 4E was replaced by D&D 5E in 2014, which was deliberately designed to walk back many of the changes in 4E that were so poorly received, keep a few of the better ones that weren’t, and in general make the game much more accessible to new players. It was a phenomenal success, buoyed by a resurgence of D&D in pop culture generally (Stranger Things and Critical Role both having large parts to play), and its dominance in the RPG arena hasn’t been meaningfully challenged since. It also returned to the use of the OGL, and a second boom of third-party publishers appeared and thrived for most of a decade.

The second thing was that PF1 was, itself, showing its age. RPGs have a pretty typical life cycle of editions and Pathfinder was reaching the end of one. It wasn’t much of a surprise, then, when, in 2018, Paizo announced Pathfinder 2nd Ed, which released in 2019 and will serve as the focus of the remainder of this post (yes, it’s taken me 1300 words to actually start doing the thing the post is supposed to be about, sue me).

There’s a coda to all of this in the form of the OGL debacle but I don’t intend to rehash any of it here - it was just like six months ago, come on - beyond what it specifically means for the future of PF2. That will come back up at the very end.

# Pathfinder 2E Basics #

So what, exactly, makes PF2 different from what has come before? There are, in my opinion, four fundamental answers to that question.

First: Unified math and proficiency progression. This piece is likely the part most familiar to 5E players, because 5E proficiency and PF2 proficiency both serve the same purpose, which is to tighten up the math of the game and make it so broken accumulations of bonuses aren’t really a thing. In contrast to 5E’s very limited proficiency, though, which just runs from +2 to +6 over the entire 20 levels of the game, Pathfinder’s scales from +0 to +28. Proficiency isn’t a binary yes/no, the way it is in 5E. PF2’s proficiency comes in five varieties: Untrained, Trained, Expert, Master, and Legendary. Your proficiency bonus is either +0 (Untrained) or your level + 2(Trained), +4 (Expert), +6 (Master) or +8 (Legendary). So if you were level five and Expert at something, your proficiency bonus would be level (5) plus Expert bonus (4) = +9.

Proficiency applies to everything in PF2, really - even more than 5E, if you can believe it, because it also goes into your Armor Class calculation. You can be Untrained, Trained, Expert, Master, or Legendary in various types of armor (or unarmored defense, especially relevant for many casters and monks), and your AC is calculated by your proficiency bonus + your Dex modifier + the armor’s own AC bonus, so AC scales just as attack rolls do. Once you get a handle on PF2 proficiency, you’ve grasped 95% of how any game statistic is calculated, including attacks, saves, skill checks, and AC.

Second: Three-Action Economy. Previous editions of D&D, including 5E, have used a “tiered” action system in combat, like 5E’s division between actions, moves, and bonus actions. PF2 has largely done away with that. At the start of your turn, you get three actions and a reaction, period (barring haste or slow or similar temporary effects). It takes one action to do one basic thing. “Attack” is an action. “Move your speed” is an action. “Ready a weapon” is an action. Searching for a hidden enemy is an action. Taking a guarded step is an action. Etc. The point being, you can do any of those as often as you have the actions for them. You can move three times, attack three times, move twice and attack once, whatever. Yes, this does mean you can attack three times in one turn at 1st level if you really want to (though there are reasons why you might not want to).

Some special abilities and most spells take more than one action to accomplish, so it’s not completely one-to-one, but it’s extremely easy to grasp and quite flexible at the same time. It’s probably my favorite of the innovations PF2 brought to the table.

Third: Deep Character Customization. So here’s where I am going to legitimately complain just a bit about 5E. I struggle with how little mechanical control I, as a player, have over how my character advances in 5E.

Consider an example. It’s common in a lot of 5E games to begin play at 3rd level, since you have a subclass by then, as well as a decent amount of hit points and access to 2nd level spells if you’re a caster. Let’s say you’re playing a fighter in a campaign that begins at 3rd level and is expected to run to 11th. That’s 8+ levels of play, a decent-length campaign by just about anyone’s standards. During that entire stretch of play, which would be a year or more depending on how often your group meets, your fighter will make exactly two (2) meaningful mechanical choices as part of their level-up process: the two points at 4th and 8th levels where you can boost a couple stats or get a feat. That’s it. Everything else is on rails, decided for you the moment you picked your subclass.

Contrast that with PF2. In that same level range, you would get to select: 4 class feats, 4 skill feats, two ancestry feats, two general feats, and four skill increases. At every level, a PF2 player gets to choose at least two things, in addition to whatever automatic bonuses they get from their class. These allow me to tailor my build quite tightly to whatever my idea for my character is and give me cool new things to play with every time I level up. This is true across character classes, casters and martials alike.

PF2 also handles multiclassing and the space that used to be occupied by prestige classes with its “pile o’ feats” approach. You can spend class feats from class A to get some features of class B, but it’s impossible for a multiclass build to just “steal” everything that makes a single class cool. A wizard/fighter will never be as good a fighter as a regular fighter is, and a fighter/wizard will never be the wizard’s match with magic.

Fourth: Four Degrees of Success. 5E applies its nat 20, nat 1, critical hits, etc. rules in a very haphazard fashion. PF2 standardizes this as well, in a way that makes your actual skill with whatever you’re doing matter for how well you do it. Any check in PF2 can produce one of four results: a critical success, a regular success, a regular failure, or a critical failure. In order to get a critical success on a roll, you have to exceed your target DC by 10 or more; in order to get a critical failure, you have to roll 10 or more less than the DC. Where do nat 20s and nat 1s come in? They respectively increase or decrease the level of success you rolled by one step. In practice, it works out a lot like you’re used to with a 5E game, but, for instance, if you have a +30 modifier and are rolling against a DC 18, rolling a nat 1 nets you a total of 31, exceeding the DC by more than 10 and earning you a critical success, which is then reduced to just a normal success by the fact of it being a nat 1. Conversely, rolling against a DC 40 with a +9 modifier can never succeed, because even a nat 20 only earns a 29, more than 10 below the DC and normally a crit failure, only increased to a regular failure by the nat 20.

Now, not every roll will make use of critical successes and critical failures. Attack rolls, for instance, don’t make any inherent distinction between failure and critical failure. (Though there are special abilities that do - try not to critically fail a melee attack against a swashbuckler. The results may be painful.) Skill rolls, however, often do, as do many spells with saving throws. Most spells that allow saves are only completely resisted if the target rolls a critical success. Even on a regular success, there is usually some effect, even on non-damaging rolls. That means that casters very rarely waste their turn on spells that get resisted and accomplish nothing at all. It also doubles the effect of any mechanical bonuses or penalties to a roll, because now there are two spots on a die per +1 or -1 that affect the outcome; a +1 might not only convert a failure to a success but might also convert a success to a crit success, or a crit fail to a regular fail.

# What About Everything Else? #

There is a lot more to it, of course. As a GM I find PF2 incredibly easy to run, even at the highest levels of game play, as compared to other d20 systems. The challenge level calculations work, meaning you can have a solo boss without having to resort to special boss monster rules to provide good challenges. I find the shift from “races” to “ancestries” much less problematic. PF2 has rules for how to handle non-combat time in the dungeon in ways that standardize common rules problems like “Well, you didn’t say you were looking for traps!” Everything using one proficiency calculation lets the game do weird things like having skill checks that target saves, or saves that target skill-based DCs. Inter-class balance, with some very specific exceptions, is beautifully tailored. Perception, always the uber-skill, isn’t a skill at all anymore: everyone is at least Trained in it, and every class reaches at least Expert in it by early double-digit levels. Opportunity Attacks (PF2 still uses the 3rd Ed “Attack of Opportunity” - but will soon be switching over to "Reactive Strike") isn’t an inherent ability of every character and monster, encouraging mobility during combats, and skill actions in combat can lower ACs, saves, attacks, and more, so there are more things to do for more kinds of characters. And so on.

Experiencing all of that is easiest just by playing the game, of course, but suffice it to say PF2 has a lot of QoL improvements for players and GMs alike in addition to the bigger, core-level mechanical differences.

# The OGL Thing #

Last thing, then. In the wake of the OGL shit in January, Paizo announced that it would no longer be releasing Pathfinder material under the OGL, opting instead to work with an intellectual property law firm to develop the Open RPG Creative (ORC) License that would do what the OGL could no longer be trusted to do: remain perpetually free and untouchable for anyone who wanted to publish under it. The ORC isn’t limited specifically to Paizo or to Pathfinder 2E or even to d20 games; any company can release any ruleset under it and allow third-party companies to develop and publish content for it.

Shifting away from the OGL, though, required making some changes to scrub out legacy material. A lot of the basic work was done when they shifted to 2E, but there are still a lot of concepts, terminologies, and potentially infringing ideas seeded throughout the system. These had to go.

Since this meant having to rewrite a lot of their core rules anyway, Paizo opted to not fight destiny and announced “Pathfinder 2nd Edition Remastered” in April. This is a kind of “2.25” edition, with a lot of small changes around the edges and a couple of larger ones to incorporate what they’ve learned since the game first launched four years ago. A couple classes are getting major updates, a ton of spells are either getting renamed or swapped out for non-OGL equivalents, and a couple big things: no more alignment and no more schools of magic.

The first book of the Remaster, Player Core 1, comes out in November, along with the GM Core. Next spring will see Monster Core and next summer will give us Player Core 2. That will complete the Remaster books; everything else is, according to Paizo, going to be compatible enough it won’t need but a few minor tweaks that can be handled via errata. So if you’re thinking about getting into PF2, I’d give serious thought to waiting until November at least, and maybe next summer if you want the whole Remastered package.

And that’s it. That’s my essay on PF2 and what I think makes it cool. The floor is open for questions and I am both very grateful and deeply apologetic to anyone who made it this far.

#RPGs #roleplaying games #d20 #d20 history #pathfinder #pathfinder 2e #pf2 #pf2e #dungeons and dragons #D&D #d&d 5e

117 notes · View notes

phantomtutor · 2 years

Text

SOLUTION AT Academic Writers Bay Project Management Processes, Methodologies, and Economics Third Edition Avraham Shtub Faculty of Industrial Engineering and Management The Technion–Israel Institute of Technology Moshe Rosenwein Department of Industrial Engineering and Operations Research Columbia University Boston Columbus San Francisco New York Hoboken Indianapolis London Toronto Sydney Singapore Tokyo Dubai Madrid Hong Kong Mexico City Munich Paris Amsterdam Cape Town Montreal Vice President and Editorial Director, Engineering and Computer Science: Marcia J. Horton Editor in Chief: Julian Partridge Executive Editor: Holly Stark Editorial Assistant: Amanda Brands Field Marketing Manager: Demetrius Hall Marketing Assistant: Jon Bryant Managing Producer: Scott Disanno Content Producer: Erin Ault Operations Specialist: Maura Zaldivar-Garcia Manager, Rights and Permissions: Ben Ferrini Cover Designer: Black Horse Designs Cover Photo: Vladimir Liverts/Fotolia Printer/Binder: RRD/Crawfordsville Cover Printer: Phoenix Color/Hagerstown Full-Service Project Management: SPi Global Composition: SPi Global Typeface: Times Ten LT Std Roman 10/12 Copyright © 2017, 2005, 1994 Pearson Education, Inc. Hoboken, NJ 07030. All rights reserved. Manufactured in the United States of America. This publication is protected by copyright and permissions should be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise. For information regarding permissions, request forms and the appropriate contacts within the Pearson Education Global Rights & Permissions department, please visit www.pearsoned.com/permissions/. Many of the designations by manufacturers and seller to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed in initial caps or all caps. The author and publisher of this book have used their best efforts in preparing this book. These efforts include the development, research, and testing of theories and programs to determine their effectiveness. The author and publisher make no warranty of any kind, expressed or implied, with regard to these programs or the documentation contained in this book. The author and publisher shall not be liable in any event for incidental or consequential damages with, or arising out of, the furnishing, performance, or use of these programs. Library of Congress Cataloging-in-Publication Data Names: Shtub, Avraham, author. | Rosenwein, Moshe, author. Title: Project management : processes, methodologies, and economics / Avraham Shtub, Faculty of Industrial Engineering and Management, The Technion-Israel Institute of Technology, Moshe Rosenwein, Department of Industrial Engineering and Operations Research, Columbia University. Other titles: Project management (Boston, Mass.) Description: 3E. | Pearson | Includes bibliographical references and index. Identifiers: LCCN 2016030485 | ISBN 9780134478661 (pbk.) Subjects: LCSH: Engineering—Management. | Project management. Classification: LCC TA190 .S583 2017 | DDC 658.4/04—dc23 LC record available at https://lccn.loc.gov/2016030485 10 9 8 7 6 5 4 3 2 1 ISBN-10: 0-13-447866-5 ISBN-13: 978-0-13-447866-1 This book is dedicated to my grandchildren Zoey, Danielle, Adam, and Noam Shtub. This book is dedicated to my wife, Debbie; my three children, David, Hannah, and Benjamin; my late parents, Zvi and Blanche Rosenwein; and my in-laws, Dr. Herman and Irma Kaplan. Contents 1. Nomenclature xv 2. Preface xvii 3. What’s New in this Edition xxi 4. About the Authors xxiii 1. 1 Introduction 1 1. 1.1 Nature of Project Management 1 2. 1.2 Relationship Between Projects and Other Production Systems 2 3. 1.3 Characteristics of Projects 4 1. 1.3.1 Definitions and Issues 5 2. 1.3.2 Risk and Uncertainty 7 3. 1.3.3 Phases of a Project 9 4.

1.3.4 Organizing for a Project 11 4. 1.4 Project Manager 14 1. 1.4.1 Basic Functions 15 2. 1.4.2 Characteristics of Effective Project Managers 16 5. 1.5 Components, Concepts, and Terminology 16 6. 1.6 Movement to Project-Based Work 24 7. 1.7 Life Cycle of a Project: Strategic and Tactical Issues 26 8. 1.8 Factors that Affect the Success of a Project 29 9. 1.9 About the book: Purpose and Structure 31 1. Team Project 35 2. Discussion Questions 38 3. Exercises 39 4. Bibliography 41 5. Appendix 1A: Engineering Versus Management 43 6. 1A.1 Nature of Management 43 7. 1A.2 Differences between Engineering and Management 43 8. 1A.3 Transition from Engineer to Manager 45 9. Additional References 45 2. 2 Process Approach to Project Management 47 1. 2.1 Introduction 47 1. 2.1.1 Life-Cycle Models 48 2. 2.1.2 Example of a Project Life Cycle 51 3. 2.1.3 Application of the Waterfall Model for Software Development 51 2. 2.2 Project Management Processes 53 1. 2.2.1 Process Design 53 2. 2.2.2 PMBOK and Processes in the Project Life Cycle 54 3. 2.3 Project Integration Management 54 1. 2.3.1 Accompanying Processes 54 2. 2.3.2 Description 56 4. 2.4 Project Scope Management 60 1. 2.4.1 Accompanying Processes 60 2. 2.4.2 Description 60 5. 2.5 Project Time Management 61 1. 2.5.1 Accompanying Processes 61 2. 2.5.2 Description 62 6. 2.6 Project Cost Management 63 1. 2.6.1 Accompanying Processes 63 2. 2.6.2 Description 64 7. 2.7 Project Quality Management 64 1. 2.7.1 Accompanying Processes 64 2. 2.7.2 Description 65 8. 2.8 Project Human Resource Management 66 1. 2.8.1 Accompanying Processes 66 2. 2.8.2 Description 66 9. 2.9 Project Communications Management 67 1. 2.9.1 Accompanying Processes 67 2. 2.9.2 Description 68 10. 2.10 Project Risk Management 69 1. 2.10.1 Accompanying Processes 69 2. 2.10.2 Description 70 11. 2.11 Project Procurement Management 71 1. 2.11.1 Accompanying Processes 71 2. 2.11.2 Description 72 12. 2.12 Project Stakeholders Management 74 1. 2.12.1 Accompanying Processes 74 2. 2.12.2 Description 75 13. 2.13 The Learning Organization and Continuous Improvement 76 1. 2.13.1 Individual and Organizational Learning 76 2. 2.13.2 Workflow and Process Design as the Basis of Learning 76 1. Team Project 77 2. Discussion Questions 77 3. Exercises 78 4. Bibliography 78 3. 3 Engineering Economic Analysis 81 1. 3.1 Introduction 81 1. 3.1.1 Need for Economic Analysis 82 2. 3.1.2 Time Value of Money 82 3. 3.1.3 Discount Rate, Interest Rate, and Minimum Acceptable Rate of Return 83 2. 3.2 Compound Interest Formulas 84 1. 3.2.1 Present Worth, Future Worth, Uniform Series, and Gradient Series 86 2. 3.2.2 Nominal and Effective Interest Rates 89 3. 3.2.3 Inflation 90 4. 3.2.4 Treatment of Risk 92 3. 3.3 Comparison of Alternatives 92 1. 3.3.1 Defining Investment Alternatives 94 2. 3.3.2 Steps in the Analysis 96 4. 3.4 Equivalent Worth Methods 97 1. 3.4.1 Present Worth Method 97 2. 3.4.2 Annual Worth Method 98 3. 3.4.3 Future Worth Method 99 4. 3.4.4 Discussion of Present Worth, Annual Worth and Future Worth Methods 101 5. 3.4.5 Internal Rate of Return Method 102 6. 3.4.6 Payback Period Method 109 5. 3.5 Sensitivity and Breakeven Analysis 111 6. 3.6 Effect of Tax and Depreciation on Investment Decisions 114 1. 3.6.1 Capital Expansion Decision 116 2. 3.6.2 Replacement Decision 118 3. 3.6.3 Make-or-Buy Decision 123 4. 3.6.4 Lease-or-Buy Decision 124 7. 3.7 Utility Theory 125 1. 3.7.1 Expected Utility Maximization 126 2. 3.7.2 Bernoulli’s Principle 128 3. 3.7.3 Constructing the Utility Function 129 4. 3.7.4 Evaluating Alternatives 133 5. 3.7.5 Characteristics of the Utility Function 135 1. Team Project 137 2. Discussion Questions 141 3. Exercises 142 4. Bibliography 152 4. 4 Life-Cycle Costing 155 1. 4.1 Need for Life-Cycle Cost Analysis 155 2. 4.2 Uncertainties in Life-Cycle Cost Models 158 3. 4.3 Classification of Cost Components 161 4. 4.4 Developing the LCC Model 168 5. 4.5 Using the Life-Cycle Cost Model 175 1. Team Project 176 2. Discussion Questions 176 3.

Exercises 177 4. Bibliography 179 5. 5 Portfolio Management—Project Screening and Selection 181 1. 5.1 Components of the Evaluation Process 181 2. 5.2 Dynamics of Project Selection 183 3. 5.3 Checklists and Scoring Models 184 4. 5.4 Benefit-Cost Analysis 187 1. 5.4.1 Step-By-Step Approach 193 2. 5.4.2 Using the Methodology 193 3. 5.4.3 Classes of Benefits and Costs 193 4. 5.4.4 Shortcomings of the Benefit-Cost Methodology 194 5. 5.5 Cost-Effectiveness Analysis 195 6. 5.6 Issues Related to Risk 198 1. 5.6.1 Accepting and Managing Risk 200 2. 5.6.2 Coping with Uncertainty 201 3. 5.6.3 Non-Probabilistic Evaluation Methods when Uncertainty Is Present 202 4. 5.6.4 Risk-Benefit Analysis 207 5. 5.6.5 Limits of Risk Analysis 210 7. 5.7 Decision Trees 210 1. 5.7.1 Decision Tree Steps 217 2. 5.7.2 Basic Principles of Diagramming 218 3. 5.7.3 Use of Statistics to Determine the Value of More Information 219 4. 5.7.4 Discussion and Assessment 222 8. 5.8 Real Options 223 1. 5.8.1 Drivers of Value 223 2. 5.8.2 Relationship to Portfolio Management 224 1. Team Project 225 2. Discussion Questions 228 3. Exercises 229 4. Bibliography 237 5. Appendix 5A: Bayes’ Theorem for Discrete Outcomes 239 6. 6 Multiple-Criteria Methods for Evaluation and Group Decision Making 241 1. 6.1 Introduction 241 2. 6.2 Framework for Evaluation and Selection 242 1. 6.2.1 Objectives and Attributes 242 2. 6.2.2 Aggregating Objectives Into a Value Model 244 3. 6.3 Multiattribute Utility Theory 244 1. 6.3.1 Violations of Multiattribute Utility Theory 249 4. 6.4 Analytic Hierarchy Process 254 1. 6.4.1 Determining Local Priorities 255 2. 6.4.2 Checking for Consistency 260 3. 6.4.3 Determining Global Priorities 261 5. 6.5 Group Decision Making 262 1. 6.5.1 Group Composition 263 2. 6.5.2 Running the Decision-Making Session 264 3. 6.5.3 Implementing the Results 265 4. 6.5.4 Group Decision Support Systems 265 1. Team Project 267 2. Discussion Questions 267 3. Exercises 268 4. Bibliography 271 5. Appendix 6A: Comparison of Multiattribute Utility Theory with the AHP: Case Study 275 6. 6A.1 Introduction and Background 275 7. 6A.2 The Cargo Handling Problem 276 1. 6A.2.1 System Objectives 276 2. 6A.2.2 Possibility of Commercial Procurement 277 3. 6A.2.3 Alternative Approaches 277 8. 6A.3 Analytic Hierarchy Process 279 1. 6A.3.1 Definition of Attributes 280 2. 6A.3.2 Analytic Hierarchy Process Computations 281 3. 6A.3.3 Data Collection and Results for AHP 283 4. 6A.3.4 Discussion of Analytic Hierarchy Process and Results 284 9. 6A.4 Multiattribute Utility Theory 286 1. 6A.4.1 Data Collection and Results for Multiattribute Utility Theory 286 2. 6A.4.2 Discussion of Multiattribute Utility Theory and Results 290 10. 6A.5 Additional Observations 290 11. 6A.6 Conclusions for the Case Study 291 12. References 291 7. 7 Scope and Organizational Structure of a Project 293 1. 7.1 Introduction 293 2. 7.2 Organizational Structures 294 1. 7.2.1 Functional Organization 295 2. 7.2.2 Project Organization 297 3. 7.2.3 Product Organization 298 4. 7.2.4 Customer Organization 298 5. 7.2.5 Territorial Organization 299 6. 7.2.6 The Matrix Organization 299 7. 7.2.7 Criteria for Selecting an Organizational Structure 302 3. 7.3 Organizational Breakdown Structure of Projects 303 1. 7.3.1 Factors in Selecting a Structure 304 2. 7.3.2 The Project Manager 305 3. 7.3.3 Project Office 309 4. 7.4 Project Scope 312 1. 7.4.1 Work Breakdown Structure 313 2. 7.4.2 Work Package Design 320 5. 7.5 Combining the Organizational and Work Breakdown Structures 322 1. 7.5.1 Linear Responsibility Chart 323 6. 7.6 Management of Human Resources 324 1. 7.6.1 Developing and Managing the Team 325 2. 7.6.2 Encouraging Creativity and Innovation 329 3. 7.6.3 Leadership, Authority, and Responsibility 331 4. 7.6.4 Ethical and Legal Aspects of Project Management 334 1. Team Project 335 2. Discussion Questions 336 3. Exercises 336 4. Bibliography 338 8. 8 Management of Product, Process, and Support Design 341 1. 8.1 Design of Products, Services, and Systems 341 1.

8.1.1 Principles of Good Design 342 2. 8.1.2 Management of Technology and Design in Projects 344 2. 8.2 Project Manager’s Role 345 3. 8.3 Importance of Time and the Use of Teams 346 1. 8.3.1 Concurrent Engineering and Time-Based Competition 347 2. 8.3.2 Time Management 349 3. 8.3.3 Guideposts for Success 352 4. 8.3.4 Industrial Experience 354 5. 8.3.5 Unresolved Issues 355 4. 8.4 Supporting Tools 355 1. 8.4.1 Quality Function Deployment 355 2. 8.4.2 Configuration Selection 358 3. 8.4.3 Configuration Management 361 4. 8.4.4 Risk Management 365 5. 8.5 Quality Management 370 1. 8.5.1 Philosophy and Methods 371 2. 8.5.2 Importance of Quality in Design 382 3. 8.5.3 Quality Planning 383 4. 8.5.4 Quality Assurance 383 5. 8.5.5 Quality Control 384 6. 8.5.6 Cost of Quality 385 1. Team Project 387 2. Discussion Questions 388 3. Exercises 389 4. Bibliography 389 9. 9 Project Scheduling 395 1. 9.1 Introduction 395 1. 9.1.1 Key Milestones 398 2. 9.1.2 Network Techniques 399 2. 9.2 Estimating the Duration of Project Activities 401 1. 9.2.1 Stochastic Approach 402 2. 9.2.2 Deterministic Approach 406 3. 9.2.3 Modular Technique 406 4. 9.2.4 Benchmark Job Technique 407 5. 9.2.5 Parametric Technique 407 3. 9.3 Effect of Learning 412 4. 9.4 Precedence Relations Among Activities 414 5. 9.5 Gantt Chart 416 6. 9.6 Activity-On-Arrow Network Approach for CPM Analysis 420 1. 9.6.1 Calculating Event Times and Critical Path 428 2. 9.6.2 Calculating Activity Start and Finish Times 431 3. 9.6.3 Calculating Slacks 432 7. 9.7 Activity-On-Node Network Approach for CPM Analysis 433 1. 9.7.1 Calculating Early Start and Early Finish Times of Activities 434 2. 9.7.2 Calculating Late Start and Late Finish Times of Activities 434 8. 9.8 Precedence Diagramming with Lead–Lag Relationships 436 9. 9.9 Linear Programming Approach for CPM Analysis 442 10. 9.10 Aggregating Activities in the Network 443 1. 9.10.1 Hammock Activities 443 2. 9.10.2 Milestones 444 11. 9.11 Dealing with Uncertainty 445 1. 9.11.1 Simulation Approach 445 2. 9.11.2 Pert and Extensions 447 12. 9.12 Critique of Pert and CPM Assumptions 454 13. 9.13 Critical Chain Process 455 14. 9.14 Scheduling Conflicts 457 1. Team Project 458 2. Discussion Questions 459 3. Exercises 460 4. Bibliography 467 5. Appendix 9A: Least-Squares Regression Analysis 471 6. Appendix 9B: Learning Curve Tables 473 7. Appendix 9C: Normal Distribution Function 476 10. 10 Resource Management 477 1. 10.1 Effect of Resources on Project Planning 477 2. 10.2 Classification of Resources Used in Projects 478 3. 10.3 Resource Leveling Subject to Project Due-Date Constraints 481 4. 10.4 Resource Allocation Subject to Resource Availability Constraints 487 5. 10.5 Priority Rules for Resource Allocation 491 6. 10.6 Critical Chain: Project Management by Constraints 496 7. 10.7 Mathematical Models for Resource Allocation 496 8. 10.8 Projects Performed in Parallel 499 1. Team Project 500 2. Discussion Questions 500 3. Exercises 501 4. Bibliography 506 11. 11 Project Budget 509 1. 11.1 Introduction 509 2. 11.2 Project Budget and Organizational Goals 511 3. 11.3 Preparing the Budget 513 1. 11.3.1 Top-Down Budgeting 514 2. 11.3.2 Bottom-Up Budgeting 514 3. 11.3.3 Iterative Budgeting 515 4. 11.4 Techniques for Managing the Project Budget 516 1. 11.4.1 Slack Management 516 2. 11.4.2 Crashing 520 5. 11.5 Presenting the Budget 527 6. 11.6 Project Execution: Consuming the Budget 529 7. 11.7 The Budgeting Process: Concluding Remarks 530 1. Team Project 531 2. Discussion Questions 531 3. Exercises 532 4. Bibliography 537 5. Appendix 11A: Time–Cost Tradeoff with Excel 539 12. 12 Project Control 545 1. 12.1 Introduction 545 2. 12.2 Common Forms of Project Control 548 3. 12.3 Integrating the OBS and WBS with Cost and Schedule Control 551 1. 12.3.1 Hierarchical Structures 552 2. 12.3.2 Earned Value Approach 556 4. 12.4 Reporting Progress 565 5. 12.5 Updating Cost and Schedule Estimates 566 6. 12.6 Technological Control: Quality and Configuration 569 7. 12.7 Line of Balance 569 8.

12.8 Overhead Control 574 1. Team Project 576 2. Discussion Questions 577 3. Exercises 577 4. Bibliography 580 13. Appendix 12A: Example of a Work Breakdown Structure 581 14. Appendix 12B: Criteria 583 15. 13 Department of Energy Cost/Schedule Control Systems Research and Development Projects 587 1. 13.1 Introduction 587 2. 13.2 New Product Development 589 1. 13.2.1 Evaluation and Assessment of Innovations 589 2. 13.2.2 Changing Expectations 593 3. 13.2.3 Technology Leapfrogging 593 4. 13.2.4 Standards 594 5. 13.2.5 Cost and Time Overruns 595 3. 13.3 Managing Technology 595 1. 13.3.1 Classification of Technologies 596 2. 13.3.2 Exploiting Mature Technologies 597 3. 13.3.3 Relationship Between Technology and Projects 598 4. 13.4 Strategic R&D Planning 600 1. 13.4.1 Role of R&D Manager 600 2. 13.4.2 Planning Team 601 5. 13.5 Parallel Funding: Dealing with Uncertainty 603 1. 13.5.1 Categorizing Strategies 604 2. 13.5.2 Analytic Framework 605 3. 13.5.3 Q-Gert 606 6. 13.6 Managing the R&D Portfolio 607 1. 13.6.1 Evaluating an Ongoing Project 609 2. 13.6.2 Analytic Methodology 612 1. Team Project 617 2. Discussion Questions 618 3. Exercises 619 4. Bibliography 619 5. Appendix 13A: Portfolio Management Case Study 622 16. 14 Computer Support for Project Management 627 1. 14.1 Introduction 627 2. 14.2 Use of Computers in Project Management 628 1. 14.2.1 Supporting the Project Management Process Approach 629 2. 14.2.2 Tools and Techniques for Project Management 629 3. 14.3 Criteria for Software Selection 643 4. 14.4 Software Selection Process 648 5. 14.5 Software Implementation 650 6. 14.6 Project Management Software Vendors 656 1. Team Project 657 2. Discussion Questions 657 3. Exercises 658 4. Bibliography 659 5. Appendix 14A: PMI Software Evaluation Checklist 660 6. 14A.1 Category 1: Suites 660 7. 14A.2 Category 2: Process Management 660 8. 14A.3 Category 3: Schedule Management 661 9. 14A.4 Category 4: Cost Management 661 10. 14A.5 Category 5: Resource Management 661 11. 14A.6 Category 6: Communications Management 661 12. 14A.7 Category 7: Risk Management 662 13. 14A.8 General (Common) Criteria 662 14. 14A.9 Category-Specific Criteria Category 1: Suites 663 15. 14A.10 Category 2: Process Management 663 16. 14A.11 Category 3: Schedule Management 664 17. 14A.12 Category 4: Cost Management 665 18. 14A.13 Category 5: Resource Management 666 19. 14A.14 Category 6: Communications Management 666 20. 14A.15 Category 7: Risk Management 668 17. 15 Project Termination 671 1. 15.1 Introduction 671 2. 15.2 When to Terminate a Project 672 3. 15.3 Planning for Project Termination 677 4. 15.4 Implementing Project Termination 681 5. 15.5 Final Report 682 1. Team Project 683 2. Discussion Questions 683 3. Exercises 684 4. Bibliography 685 18. 16 New Frontiers in Teaching Project Management in MBA and Engineering Programs 687 1. 16.1 Introduction 687 2. 16.2 Motivation for Simulation-Based Training 687 3. 16.3 Specific Example—The Project Team Builder (PTB) 691 4. 16.4 The Global Network for Advanced Management (GNAM) MBA New Product Development (NPD) Course 692 5. 16.5 Project Management for Engineers at Columbia University 693 6. 16.6 Experiments and Results 694 7. 16.7 The Use of Simulation-Based Training for Teaching Project Management in Europe 695 8. 16.8 Summary 696 1. Bibliography 697 1. Index 699 Nomenclature AC annual cost ACWP actual cost of work performed AHP analytic hierarchy process AOA activity on arrow AON activity on node AW annual worth BAC budget at completion B/C benefit/cost BCWP budgeted cost of work performed BCWS budgeted cost of work scheduled CBS cost breakdown structure CCB change control board CCBM critical chain buffer management CDR critical design review CE certainty equivalent, concurrent engineering C-E cost-effectiveness CER cost estimating relationship CI cost index; consistency index; criticality index CM configuration management COO chief operating officer CPIF cost plus incentive fee CPM critical path method CR capital

recovery, consistency ratio C/SCSC cost/schedule control systems criteria CV cost variance DOD Department of Defense DOE Department of Energy DOH direct overhead costs DSS decision support system EAC estimate at completion ECO engineering change order ECR engineering change request EMV expected monetary value EOM end of month EOY end of year ERP enterprise resource planning ETC estimate to complete ETMS early termination monitoring system EUAC equivalent uniform annual cost EV earned value EVPI expected value of perfect information EVSI expected value of sample information FFP firm fixed price FMS flexible manufacturing system FPIF fixed price incentive fee FW future worth GAO General Accounting Office GDSS group decision support system GERT graphical evaluation and review technique HR human resources IPT integraded product team IRR internal rate of return IRS Internal Revenue Service ISO International Standards Organization IT information technology LCC life-cycle cost LOB line of balance LOE level of effort LP linear program LRC linear responsibility chart MACRS modified accelerated cost recovery system MARR minimum acceptable (attractive) rate of return MAUT multiattribute utility theory MBO management by objectives MIS management information system MIT Massachusetts Institute of Technology MPS master production schedule MTBF mean time between failures MTTR mean time to repair NAC net annual cost NASA National Aeronautics and Space Administration NBC nuclear, biological, chemical NPV net present value OBS organizational breakdown structure O&M operations and maintenance PDMS product data management system PDR preliminary design review PERT program evaluation and review technique PMBOK project management body of knowledge PMI Project Management Institute PMP project management professional PO project office PT project team PV planned value PW present worth QA quality assurance QFD quality function deployment RAM reliability, availability, and maintainability; random access memory R&D research and development RDT&E research, development, testing, and evaluation RFP request for proposal ROR rate of return SI schedule index SOW statement of work SOYD sum-of-the-years digits SV schedule variance TQM total quality management WBS work breakdown structure WP work package WR work remaining Preface We all deal with projects in our daily lives. In most cases, organization and management simply amount to constructing a list of tasks and executing them in sequence, but when the information is limited or imprecise and when cause-and-effect relationships are uncertain, a more considered approach is called for. This is especially true when the stakes are high and time is pressing. Getting the job done right the first time is essential. This means doing the upfront work thoroughly, even at the cost of lengthening the initial phases of the project. Shaving expenses in the early stages with the intent of leaving time and money for revisions later might seem like a good idea but could have consequences of painful proportions. Seasoned managers will tell you that it is more cost-effective in the long run to add five extra engineers at the beginning of a project than to have to add 50 toward the end. The quality revolution in manufacturing has brought this point home. Companies in all areas of technology have come to learn that quality cannot be inspected into a product; it must be built in. Recalling the 1980s, the global competitive battles of that time were won by companies that could achieve cost and quality advantages in existing, well-defined markets. In the 1990s, these battles were won by companies that could build and dominate new markets. Today, the emphasis is partnering and better coordination of the supply chain. Planning is a critical component of this process and is the foundation of project management. Projects may involve dozens of firms and hundreds of people who need to be managed and coordinated. They need to know what has to

be done, who is to do it, when it should be done, how it will be done, and what resources will be used. Proper planning is the first step in communicating these intentions. The problem is made difficult by what can be characterized as an atmosphere of uncertainty, chaos, and conflicting goals. To ensure teamwork, all major participants and stakeholders should be involved at each stage of the process. How is this achieved efficiently, within budget, and on schedule? The primary objective in writing our first book was to answer this question from the perspective of the project manager. We did this by identifying the components of modern project management and showing how they relate to the basic phases of a project, starting with conceptual design and advanced development, and continuing through detailed design, production, and termination. Taking a practical approach, we drew on our collective experience in the electronics, information services, and aerospace industries. The purpose of the second edition was to update the developments in the field over the last 10 years and to expand on some of the concerns that are foremost in the minds of practitioners. In doing so, we have incorporated new material in many of the chapters specifically related to the Project Management Body of Knowledge (PMBOK) published by the Project Management Institute. This material reflects the tools, techniques, and processes that have gained widespread acceptance by the profession because of their proven value and usefulness. Over the years, numerous books have been written with similar objectives in mind. We acknowledge their contribution and have endeavored to build on their strengths. As such in the third edition of the book, we have focused on integrative concepts rather than isolated methodologies. We have relied on simple models to convey ideas and have intentionally avoided detailed mathematical formulations and solution algorithms––aspects of the field better left to other parts of the curriculum. Nevertheless, we do present some models of a more technical nature and provide references for readers who wish to gain a deeper understanding of their use. The availability of powerful, commercial codes brings model solutions within reach of the project team. To ensure that project participants work toward the same end and hold the same expectations, short- and long-term goals must be identified and communicated continually. The project plan is the vehicle by which this is accomplished and, once approved, becomes the basis for monitoring, controlling, and evaluating progress at each phase of the project’s life cycle. To help the project manager in this effort, various software packages have been developed; the most common run interactively on microcomputers and have full functional and report-generating capabilities. In our experience, even the most timid users are able to take advantage of their main features after only a few hours of hands-on instruction. A second objective in writing this book has been to fill a void between texts aimed at low- to mid-level managers and those aimed at technical personnel with strong analytic skills but little training in or exposure to organizational issues. Those who teach engineering or business students at both the late undergraduate and early graduate levels should find it suitable. In addition, the book is intended to serve as a reference for the practitioner who is new to the field or who would like to gain a surer footing in project management concepts and techniques. The core material, including most of the underlying theory, can be covered in a one-semester course. At the end of Chapter 1, we outline the book’s contents. Chapter 3 deals with economic issues, such as cash flow, time value of money, and depreciation, as they relate to projects. With this material and some supplementary notes, coupled with the evaluation methods and multiple criteria decision-making techniques discussed in Chapters 5 and 6,

respectively, it should be possible to teach a combined course in project management and engineering economy. This is the direction in which many undergraduate engineering programs are now headed after many years of industry prodding. Young engineers are often thrust into leadership roles without adequate preparation or training in project management skills. Among the enhancements in the Third Edition is a section on Lean project management, discussed in Chapter 8, and a new Chapter 16 on simulationbased training for project management. Lean project management is a Quality Management initiative that focuses on maximizing the value that a project generates for its stakeholders while minimizing waste. Lean project management is based on the Toyota production system philosophy originally developed for a repetitive environment and modified to a nonrepetitive environment to support project managers and project teams in launching, planning, executing, and terminating projects. Lean project management is all about people—selecting the right project team members, teaching them the art and science of project management, and developing a highly motivated team that works together to achieve project goals. Simulation-based training is a great tool for training project team members and for team development. Chapter 16 discusses the principles of simulation- based training and its application to project management. The chapter reports on the authors’ experience in using simulation-based training in leading business schools, such as members of the Global Network for Advanced Management (GNAM), and in leading engineering schools, such as the Columbia University School of Engineering and the Technion. The authors also incorporated feedback received from European universities such as Technische Universität München (TUM) School of Management and Katholieke Universiteit Leuven that used the Project Team Builder (PTB) simulation-based training environment. Adopters of this book are encouraged to try the PTB—it is available from http://www.sandboxmodel.com/—and to integrate it into their courses. Writing a textbook is a collaborative effort involving many people whose names do not always appear on the cover. In particular, we thank all faculty who adopted the first and second editions of the book and provided us with their constructive and informative comments over the years. With regard to production, much appreciation goes to Lillian Bluestein for her thorough job in proofreading and editing the manuscript. We would also like to thank Chen Gretz-Shmueli for her contribution to the discussion in the human resources section. Finally, we are forever grateful to the phalanx of students who have studied project management at our universities and who have made the painstaking efforts of gathering and writing new material all worthwhile. Avraham Shtub Moshe Rosenwein What’s New in this Edition The purpose of the new, third edition of this book is to update developments in the project management field over the last 10 years and to more broadly address some of the concerns that have increased in prominence in the minds of practitioners. We incorporated new material in many of the chapters specifically related to the Project Management Body of Knowledge (PMBOK) published by the Project Management Institute. This material reflects the tools, techniques, and processes that have gained widespread acceptance by the profession because of their proven value and usefulness. Noteworthy enhancements in the third edition include: An expanded section regarding Lean project management in Chapter 8; A new chapter, Chapter 16, discussing the use of simulation and the Project Team Builder software; A detailed discussion on activity splitting and its advantages and disadvantages in project management; Descriptions, with examples, of resource-scheduling heuristics such as the longest-duration first heuristic and the Activity Time (ACTIM) algorithm; Examples that demonstrate

the use of Excel Solver to model project management problems such as the time–cost tradeoff; A description of project management courses at Columbia University and the Global Network of Advanced Management. About the Authors Professor Avraham Shtub holds the Stephen and Sharon Seiden Chair in Project Management. He has a B.Sc. in Electrical Engineering from the Technion–Israel Institute of Technology (1974), an MBA from Tel Aviv University (1978), and a Ph.D. in Management Science and Industrial Engineering from the University of Washington (1982). He is a certified Project Management Professional (PMP) and a member of the Project Management Institute (PMI-USA). He is the recipient of the Institute of Industrial Engineering 1995 Book of the Year Award for his book Project Management: Engineering, Technology, and Implementation (coauthored with Jonathan Bard and Shlomo Globerson), Prentice Hall, 1994. He is the recipient of the Production Operations Management Society Wick Skinner Teaching Innovation Achievements Award for his book Enterprise Resource Planning (ERP): The Dynamics of Operations Management. His books on Project Management were published in English, Hebrew, Greek, and Chinese. He is the recipient of the 2008 Project Management Institute Professional Development Product of the Year Award for the training simulator “Project Team Builder – PTB.” Professor Shtub was a Department Editor for IIE Transactions, he was on the Editorial Boards of the Project Management Journal, The International Journal of Project Management, IIE Transactions, and the International Journal of Production Research. He was a faculty member of the department of Industrial Engineering at Tel Aviv University from 1984 to 1998, where he also served as a chairman of the department (1993–1996). He joined the Technion in 1998 and was the Associate Dean and head of the MBA program. He has been a consultant to industry in the areas of project management, training by simulators, and the design of production—operation systems. He was invited to speak at special seminars on Project Management and Operations in Europe, the Far East, North America, South America, and Australia. Professor Shtub visited and taught at Vanderbilt University, The University of Pennsylvania, Korean Institute of Technology, Bilkent University in Turkey, Otego University in New Zealand, Yale University, Universitat Politécnica de Valencia, and the University of Bergamo in Italy. Dr. Moshe Rosenwein has a B.S.E. from Princeton University and a Ph.D. in Decision Sciences from the University of Pennsylvania. He has worked in the industry throughout his professional career, applying management science modeling and methodologies to business problems in supply chain optimization, network design, customer relationship management, and scheduling. He has served as an adjunct professor at Columbia University on multiple occasions over the past 20 years and developed a project management course for the School of Engineering that has been taught since 2009. He has also taught at Seton Hall University and Rutgers University. Dr. Rosenwein has published over 20 refereed papers and has delivered numerous talks at universities and conferences. In 2001, he led an industry team that was awarded a semi-finalist in the Franz Edelman competition for the practice of management science. Chapter 1 Introduction 1.1 Nature of Project Management Many of the most difficult engineering and business challenges of recent decades have been to design, develop, and implement new systems of a type and complexity never before attempted. Examples include the construction of oil drilling platforms in the North Sea off the coast of Great Britain, the development of the manned space program in both the United States and the former Soviet Union, and the worldwide installation of fiber optic lines for broadband telecommunications. The creation of these systems with performance capabilities not previously available and within

acceptable schedules and budgets has required the development of new methods of planning, organizing, and controlling events. This is the essence of project management. A project is an organized endeavor aimed at accomplishing a specific nonroutine or low-volume task. Although projects are not repetitive, they may take significant amounts of time and, for our purposes, are sufficiently large or complex to be recognized and managed as separate undertakings. Teams have emerged as the way of supplying the needed talents. The use of teams complicates the flow of information and places additional burdens on management to communicate with and coordinate the activities of the participants. The amount of time in which an individual or an organizational unit is involved in a project may vary considerably. Someone in operations may work only with other operations personnel on a project or may work with a team composed of specialists from various functional areas to study and solve a specific problem or to perform a secondary task. Management of a project differs in several ways from management of a typical organization. The objective of a project team is to accomplish its prescribed mission and disband. Few firms are in business to perform just one job and then disappear. Because a project is intended to have a finite life, employees are seldom hired with the intent of building a career with the project. Instead, a team is pulled together on an ad-hoc basis from among people who normally have assignments in other parts of the organization. They may be asked to work full time on the project until its completion; or they may be asked to work only part time, such as two days a week, on the project and spend the rest of the time at their usual assignments. A project may involve a short-term task that lasts only a matter of days, or it may run for years. After completion, the team normally disperses and its members return to their original jobs. The need to manage large, complex projects, constrained by tight schedules and budgets, motivated the development of methodologies different from those used to manage a typical enterprise. The increasingly complex task of managing large-scale, enterprise-wide projects has led to the rise in importance of the project management function and the role of the project manager or project management office. Project management is increasingly viewed in both industry and government as a critical role on a project team and has led to the development of project management as a profession (much like finance, marketing, or information technology, for example). The Project Management Institute (PMI), a nonprofit organization, is in the forefront of developing project management methodologies and of providing educational services in the form of workshops, training, and professional literature. 1.2 Relationship Between Projects and Other Production Systems Operations and production management contains three major classes of systems: (1) those designed for mass production, (2) those designed for batch (or lot) production, and (3) those designed for undertaking nonrepetitive projects common to construction and new product development. Each of these classes may be found in both the manufacturing and service sectors. Mass production systems are typically designed around the specific processes used to assemble a product or perform a service. Their orientation is fixed and their applications are limited. Resources and facilities are composed of special-purpose equipment designed to perform the operations required by the product or the service in an efficient way. By laying out the equipment to parallel the natural routings, material handling and information processing are greatly simplified. Frequently, material handling is automated and the use of conveyors and monorails is extensive. The resulting system is capital intensive and very efficient in the processing of large quantities of specific products or services for which relatively little management and control are necessary.

However, these systems are very difficult to alter should a need arise to produce new or modified products or to provide new services. As a result, they are most appropriate for operations that experience a high rate of demand (e.g., several hundred thousand units annually) as well as high aggregate demand (e.g., several million units throughout the life cycle of the system). Batch-oriented systems are used when several products or services are processed in the same facility. When the demand rate is not high enough or when long-run expectations do not justify the investment in special-purpose equipment, an effort is made to design a more flexible system on which a variety of products or services can be processed. Because the resources used in such systems have to be adjusted (set up) when production switches from one product to another, jobs are typically scheduled in batches to save setup time. Flexibility is achieved by using general-purpose resources that can be adjusted to handle different processes. The complexity of operations planning, scheduling, and control is greater than in mass production systems as each product has its own routing (sequence of operations). To simplify planning, resources are frequently grouped together based on the type of processes that they perform. Thus, batch-oriented systems contain organizational units that specialize in a function or a process, as opposed to product lines that are found in mass production systems. Departments such as metal cutting, painting, testing, and packaging/shipping are typical examples from the batch-oriented manufacturing sector, whereas word processing centers and diagnostic laboratories are examples from the service sector. In the batch-oriented system, it is particularly important to pay attention to material handling needs because each product has its specific set of operations and routings. Material handling equipment, such as forklifts, is used to move in-process inventory between departments and work centers. The flexibility of batch-oriented systems makes them attractive for many organizations. In recent years, flexible manufacturing systems have been quick to gain acceptance in some industrial settings. With the help of microelectronics and computer technology, these systems are designed to achieve mass production efficiencies in low-demand environments. They work by reducing setup times and automating material handling operations but are extremely capital intensive. Hence they cannot always be justified when product demand is low or when labor costs are minimal. Another approach is to take advantage of local economies of scale. Group technology cells, which are based on clustering similar products or components into families processed by dedicated resources of the facility, are one way to implement this approach. Higher utilization rates and greater throughput can be achieved by processing similar components on dedicated machines. By way of contrast, systems that are subject to very low demand (no more than a few units) are substantially different from the first two mentioned. Because of the nonrepetitive nature of these systems, past experience may be of limited value so little learning takes place. In this environment, extensive management effort is required to plan, monitor, and control the activities of the organization. Project management is a direct outgrowth of these efforts. It is possible to classify organizations based on their production orientation as a function of volume and batch size. This is illustrated in Figure 1.1. Figure 1.1 Classification of production systems. Figure 1.1 Full Alternative Text The borderlines between mass production, batch-oriented, and projectoriented systems are hard to define. In some organizations where the project approach has been adopted, several units of the same product (a batch) are produced, whereas other organizations use a batch-oriented system that produces small lots (the just-in-time approach) of very large volumes of products.

To better understand the transition between the three types of systems, consider an electronics firm that assembles printed circuit boards in small batches in a job shop. As demand for the boards picks up, a decision is made to develop a flow line for assembly. The design and implementation of this new line is a project. 1.3 Characteristics of Projects Although the Manhattan project—the development of the first atomic bomb —is considered by many to be the first instance when modern project management techniques were used, ancient history is replete with examples. Some of the better known ones include the construction of the Egyptian pyramids, the conquest of the Persian Empire by Alexander the Great, and the building of the Temple in Jerusalem. In the 1960s, formal project management methods received their greatest impetus with the Apollo program and a cluster of large, formidable construction projects. Today, activities such as the transport of American forces in Operations in Iraq and Afghanistan, the pursuit of new treatments for AIDS and Ebola, and the development of the joint U.S.–Russian space station and the manned space mission to Mars are examples of three projects with which most of us are familiar. Additional examples of a more routine nature include: Selecting a software package Developing a new office plan or layout Implementing a new decision support system Introducing a new product to the market Designing an airplane, supercomputer, or work center Opening a new store Constructing a bridge, dam, highway, or building Relocating an office or a factory Performing major maintenance or repair Starting up a new manufacturing or service facility Producing and directing a movie 1.3.1 Definitions and Issues As the list above suggests, a project may be viewed or defined in several different ways: for example, as “the entire process required to produce a new product, new plant, new system, or other specified results” (Archibald 2003) or as “a narrowly defined activity which is planned for a finite duration with a specific goal to be achieved” (General Electric Corporation 1983). Generally speaking, project management occurs when emphasis and special attention are given to the performance of nonrepetitive activities for the purpose of meeting a single set of goals, typically under a set of constraints such as time and budget constraints. By implication, project management deals with a one-time effort to achieve a focused objective. How progress and outcomes are measured, though, depends on a number of critical factors. Typical among these are technology (specifications, performance, quality), time (due dates, milestones), and cost (total investment, required cash flow), as well as profits, resource utilization, market share, and market acceptance. These factors and their relative importance are major issues in project management. These factors are based on the needs and expectations of the stakeholders. Stakeholders are individuals and parties interested in the problem the project is designed to solve or in the solution selected. With a well-defined set of goals, it is possible to develop appropriate performance measures and to select the right technology, the organizational structure, required resources, and people who will team up to achieve these goals. Figure 1.2 summarizes the underlying processes. As illustrated, most projects are initiated by a need. A new need may be identified by stakeholders such as a customer, the marketing department, or any member of an organization. When management is convinced that the need is genuine, goals may be defined, and the first steps may be taken toward putting together a project team. Most projects have several goals covering such aspects as technical and operational requirements, delivery dates, and cost. A set of potential projects to undertake should be ranked by stakeholders based on the relative importance of the goals and the perceived probability of each potential project to achieve each of the individual goals.

Figure 1.2 Major processes in project management. Figure 1.2 Full Alternative Text On the basis of these rankings and a derived set of performance measures for each goal, the technological alternatives are evaluated and a concept (or initial design) is developed along with a schedule and a budget for the project. This early phase of the project life cycle is known as the initiation phase, the front end of the project, or the conceptual phase. The next step is to integrate the design, the schedule, and the budget into a project plan specifying what should be done, by whom, at what cost, and when. As the plan is implemented, the actual accomplishments are monitored and recorded. Adjustments, aimed at keeping the project on track, are made when deviations or overruns appear. When the project terminates, its success is evaluated based on the predetermined goals and performance measures. Figure 1.3 compares two projects with these points in mind. In project 1, a “design to cost” approach is taken. Here, the budget is fixed and the technological goals are clearly specified. Cost, performance, and schedule are all given equal weight. In project 2, the technological goals are paramount and must be achieved, even if it means compromising the schedule and the budget in the process. Figure 1.3 Relative importance of goals. Figure 1.3 Full Alternative Text The first situation is typical of standard construction and manufacturing projects, whereby a contractor agrees to supply a system or a product in accordance with a given schedule and budget. The second situation is typical of “cost plus fixed fee” projects where the technological uncertainties argue against a contractor’s committing to a fixed cost and schedule. This arrangement is most common in a research and development (R&D) environment. A well-designed organizational structure is required to handle projects as a result of their uniqueness, variety, and limited life span. In addition, special skills are required to manage them successfully. Taken together, these skills and organizational structures have been the catalyst for the development of the project management discipline. Some of the accompanying tools and techniques, though, are equally applicable in the manufacturing and service sectors. Because projects are characterized by a “one-time only” effort, learning is limited and most operations never become routine. This results in a need for extensive management involvement throughout the life cycle of the project. In addition, the lack of continuity leads to a high degree of uncertainty. 1.3.2 Risk and Uncertainty In project management, it is common to refer to very high levels of uncertainty as sources of risk. Risk is present in most projects, especially in the R&D environment. Without trying to sound too pessimistic, it is prudent to assume that what can go wrong will go wrong. Principal sources of uncertainty include random variations in component and subsystem performance, inaccurate or inadequate data, and the inability to forecast satisfactorily as a result of lack of experience. Specifically, there may be 1. Uncertainty in scheduling. Changes in the environment that are impossible to forecast accurately at the outset of a project are likely to have a critical impact on the length of certain activities. For example, subcontractor performance or the time it takes to obtain a long-term loan is bound to influence the length of various subtasks. The availability of scarce resources may also add to uncertainty in scheduling. Methods are needed to deal with problematic or unstable time estimates. Probability theory and simulation both have been used successfully for this purpose, as discussed in Chapter 9. 2. Uncertainty in cost. Limited information on the duration of activities makes it difficult to predict the amount of resources needed to complete them on schedule. This translates directly into an uncertainty in cost. In addition, the expected hourly rate of resources and

the cost of materials used to carry out project tasks may possess a high degree of variability. 3. Technological uncertainty. This form of uncertainty is typically present in R&D projects in which new (not thoroughly tested and approved) technologies, methods, equipment, and systems are developed or used. Technological uncertainty may affect the schedule, the cost, and the ultimate success of the project. The integration of familiar technologies into one system or product may cause technological uncertainty as well. The same applies to the development of software and its integration with hardware. There are other sources of uncertainty, including those of an organizational and political nature. New regulations might affect the market for a project, whereas the turnover of personnel and changes in the policies of one or more of the participating organizations may disrupt the flow of work. To gain a better understanding of the effects of uncertainty, consider the three projects mentioned earlier. The transport of American armed forces in Operation Iraqi Freedom faced extreme political and logistical uncertainties. In the initial stages, none of the planners had a clear idea of how many troops would be needed or how much time was available to put the troops in place. Also, it was unknown whether permission would be granted to use NATO air bases or even to fly over European and Middle Eastern countries, or how much tactical support would be forthcoming from U.S. allies. The development of a treatment for AIDS is an ongoing project fraught with technological uncertainty. Hundreds of millions of dollars have already been spent with little progress toward a cure. As expected, researchers have taken many false steps, and many promising paths have turned out to be dead ends. Lengthy trial procedures and duplicative efforts have produced additional frustration. If success finally comes, it is unlikely that the original plans or schemes will have predicted its form. The design of the U.S.–Russian space station is an example in which virtually every form of uncertainty is present. Politicians continue to play havoc with the budget, while other stakeholders like special interest groups (both friendly and hostile) push their individual agendas; schedules get altered and rearranged; software fails to perform correctly; and the needed resources never seem to be available in adequate supply. Inflation, high turnover rates, and scaled-down expectations take their toll on the internal workforce, as well as on the legion of subcontractors. The American Production and Inventory Control Society has, tongue-incheek, fashioned the following laws in an attempt to explain the consequences of uncertainty on project management. Laws of Project Management 1. No major project is ever installed on time, within budget or with the same staff that started it. Yours will not be the first. 2. Projects progress quickly until they become 90% complete, then they remain at 90% complete forever. 3. One advantage of fuzzy project objectives is that they let you avoid the embarrassment of estimating the corresponding costs. 4. When things are going well, something will go wrong. When things just cannot get any worse, they will. When things seem to be going better, you have overlooked something. 5. If project content is allowed to change freely, then the rate of change will exceed the rate of progress. 6. No system is ever completely debugged. Attempts to debug a system inevitably introduce new bugs that are even harder to find. 7. A carelessly planned project will take three times longer to complete than expected; a carefully planned project will take only twice as long. 8. Project teams detest progress reporting because it vividly manifests their lack of progress. 1.3.3 Phases of a Project A project passes through a life cycle that may vary with size and complexity and with the style established by the organization. The names of the various phases may differ but typically include those shown in Figure 1.

4. To begin, there is an initiation or a conceptual design phase during which the organization realizes that a project may be needed or receives a request from a customer to propose a plan to perform a project; at this phase alternative technologies and operational solutions are evaluated and the most promising are selected based on performances, cost, risk, and schedule considerations. Next there is an advanced development or preliminary system design phase in which the project manager (and perhaps a staff if the project is complex) plans the project to a level of detail sufficient for initial scheduling and budgeting. If the project is approved, it then will enter a more detailed design phase, a production phase, and a termination phase. Figure 1.4 Relationship between project life cycle and cost. Figure 1.4 Full Alternative Text In Figure 1.4, the five phases in the life cycle of a project are presented as a function of time. The cost during each phase depends on the specifics, but usually the majority of the budget is spent during the production phase. However, most of this budget is committed during the advanced development phase and the detailed design phase before the actual work takes place. Management plays a vital role during the conceptual design phase, the advanced development phase, and the detailed design phase. The importance of this involvement in defining goals, selecting performance measures, evaluating alternatives (including the no-go or not to do the project), selecting the most promising alternative and planning the project cannot be overemphasized. Pressures to start the “real work” on the project, that is, to begin the production (or execution) phase as early as possible, may lead to the selection of the wrong technological or operational alternatives and consequently to high cost and schedule risks as a result of the commitment of resources without adequate planning. In most cases, a work breakdown structure (WBS) is developed during the conceptual design phase. The WBS is a document that divides the project work into major hardware, software, data, and service elements. These elements are further divided and a list is produced identifying all tasks that must be accomplished to complete the project. The WBS helps to define the work to be performed and provides a framework for planning, budgeting, monitoring, and control. Therefore, as the project advances, schedule and cost performance can be compared with plans and budgets. Table 1.1 shows an abbreviated WBS for an orbital space laboratory vehicle. TABLE 1.1 Partial WBS for Space Laboratory Index Work element 1.0 Command module 2.0 Laboratory module 3.0 Main propulsion system 3.1 Fuel supply system 3.1.1 Fuel tank assembly 3.1.1.1 Fuel tank casing 3.1.1.2 Fuel tank insulation 4.0 5.0 6.0 7.0 Guidance system Habitat module Training system Logistic support system The detailed project definition, as reflected in the WBS, is examined during the advanced development phase to determine the skills necessary to achieve the project’s goals. Depending on the planning horizon, personnel from other parts of the organization may be used temporarily to accomplish the project. However, previous commitments may limit the availability of these resources. Other strategies might include hiring new personnel or subcontracting various work elements, as well as leasing equipment and facilities. 1.3.4 Organizing for a Project A variety of structures are used by organizations to perform project work. The actual arrangement may depend on the proportion of the company’s business that is project oriented, the scope and duration of the underlying tasks, the capabilities of the available personnel, preferences of the decision makers, and so on. The following five possibilities range from no special structure to a totally separate project organization. 1. Functional organization. Many companies are organized as a hierarchy with functional departments that specialize in a particular type of work, such as engineering or sales (see Figure 1.

5). These departments are often broken down into smaller units that focus on special areas within the function. Upper management may divide a project into work tasks and assign them to the appropriate functional units. The project is then budgeted and managed through the normal management hierarchy. Figure 1.5 Portion of a typical functional organization. Figure 1.5 Full Alternative Text 2. Project coordinator. A project may be handled through the organization as described above, but with a special appointee to coordinate it. The project is still funded through the normal channels and the functional managers retain responsibility and authority for their portion of the work. The coordinator meets with the functional managers and provides direction and impetus for the project and may report its status to higher management. 3. Matrix organization. In a matrix organization, a project manager is responsible for completion of the project and is often assigned a budget. The project manager essentially contracts with the functional managers for completion of specific tasks and coordinates project efforts across the functional units. The functional managers assign work to employees and coordinate work within their areas. These arrangements are depicted schematically in Figure 1.6. 4. Project team. A particularly significant project (development of a new product or business venture) that will have a long duration and requires the full-time efforts of a group may be supervised by a project team. Full-time personnel are assigned to the project and are physically located with other team members. The project has its own management structure and budget as though it were a separate division of the company. 5. Projectized organization. When the project is of strategic importance, extremely complex and of long duration, and involves a number of disparate organizations, it is advisable to give one person complete control of all the elements necessary to accomplish the stated goals. For example, when Rockwell International was awarded two multimilliondollar contracts (the Apollo command and service modules, and the second stage of the Saturn launch vehicle) by NASA, two separate programs were set up in different locations of the organization. Each program was under a division vice president and had its own manufacturing plant and staff of specialists. Such an arrangement takes the idea of a self-sufficient project team to an extreme and is known as a projectized organization. Table 1.2 enumerates some advantages and disadvantages of the two extremes—the functional and projectized organizations. Companies that are frequently involved in a series of projects and occasionally shift around personnel often elect to use a matrix organization. This type of organization provides the flexibility to assign employees to one or more projects. In this arrangement, project personnel maintain a permanent reporting relationship that connects vertically to a supervisor in a functional area, who directs the scope of their work. At the same time, each person is assigned to one or more projects and has a horizontal reporting relationship to the manager of a particular project, who coordinates his or her participation in that project. Pay and career advancement are developed within a particular discipline even though a person may be assigned to different projects. At times, this dual reporting relationship can give rise to a host of personnel problems and creates conflicts. Figure 1.6 Typical matrix organization. Figure 1.6 Full Alternative Text TABLE 1.2 Advantages and Disadvantages of Two Organizational Structures Functional organization Projectized organization Advantages Efficient use of technical personnel Good project schedule and cost control Career continuity and growth for Single point for customer contact technical personnel Good technology transfer between Rapid reaction time possible projects Simpler project communication Good stability, security, and morale

Training ground for general management Disadvantages Weak customer interface Uncertain technical direction Weak project authority Inefficient use of specialists Insecurity regarding future job Poor horizontal communications assignments Discipline (technology) oriented Poor crossfeed of technical rather than program oriented information between projects Slower work flow 1.4 Project Manager The presence of uncertainty coupled with limited experience and hard-to-find data makes project management a combination of art, science, and, most of all, logical thinking. A good project manager must be familiar with a large number of disciplines and techniques. Breadth of knowledge is particularly important because most projects have technical, financial, marketing, and organizational aspects that inevitably conspire to derail the best of plans. The role of the project manager may start at different points in the life cycle of a project. Some managers are involved from the beginning, helping to select the best technological and operational alternatives for the project, form the team, and negotiate the contracts. Others may begin at a later stage and be asked to execute plans that they did not have a hand in developing. At some point, though, most project managers deal with the basic issues: scheduling, budgeting, resource allocation, resource management, stakeholder management (e.g., human relations and negotiations). It is an essential and perhaps the most difficult part of the project manager’s job to pay close attention to the big picture without losing sight of critical details, no matter how slight. In order to efficiently and effectively achieve high-level project goals, project managers must prioritize concerns key stakeholders while managing change that inevitably arises during a project’s life cycle. A project manager is an integrator and needs to trade off different aspects of the project each time a decision is called for. Questions such as, “How important is the budget relative to the schedule?” and “Should more resources be acquired to avoid delays at the expense of a budget overrun, or should a slight deviation in performance standards be tolerated as long as the project is kept on schedule and on budget?” are common. Some skills can be taught, other skills are acquired only with time and experience, and yet other skills are very hard to learn or to acquire, such as the ability to lead a team without formal authority and the ability to deal with high levels of uncertainty without panic. We will not dwell on these but simply point them out, as we define fundamental principles and procedures. Nevertheless, one of our basic aims is to highlight the practical aspects of project management and to show how modern organizations can function more effectively by adopting them. In so doing, we hope to provide all members of the project team with a comprehensive view of the field. 1.4.1 Basic Functions The PMI (2012) identifies ten knowledge areas that the discipline must address: 1. Integration management 2. Scope management 3. Time management 4. Cost management 5. Quality management 6. Human resource management 7. Communication management 8. Risk management 9. Procurement management 10. Stakeholders management Managing a project is a complex and challenging assignment. Because projects are one-of-a-kind endeavors, there is little in the way of experience, normal working relationships, or established procedures to guide participants. A project manager may have to coordinate many diverse efforts and activities to achieve project goals. People from various disciplines and from various parts of the organization who have never worked together may be assigned to a project for different spans of time. Subcontractors who are unfamiliar with the organization may be brought in to carry out major tasks. A project may involve thousands of interrelated activities performed by people who are employed by any one of several different subcontractors or by the sponsoring organization.

Project leaders must have an effective means of identifying and communicating the planned activities and their interrelationships. A computer-based scheduling and monitoring system is usually essential. Network techniques such as CPM (critical path method) and PERT (program evaluation and review technique) are likely to figure prominently in such systems. CPM was developed in 1957 by J.E. Kelly of Remington-Rand and M.R. Walker of Dupont to aid in scheduling maintenance shutdowns of chemical plants. PERT was developed in 1958 under the sponsorship of the U.S. Navy Special Projects Office, as a management tool for scheduling and controlling the Polaris missile program. Collectively, their value has been demonstrated time and again during both the planning and the execution phases of projects. 1.4.2 Characteristics of Effective Project Managers The project manager is responsible for ensuring that tasks are completed on time and within budget, but often has no formal authority over those who actually perform the work. He or she, therefore, must have a firm understanding of the overall job and rely on negotiation and persuasion skills to influence the array of contractors, functionaries, and specialists assigned to the project. The skills that a typical project manager needs are summarized in Figure 1.7; the complexity of the situation is depicted in Figure 1.8, which shows the interactions between some of the stakeholders: client, subcontractor, and top management. The project manager is a lightning rod, frequently under a storm of pressure and stress. He or she must deal effectively with the changing priorities of the client, the anxieties of his or her own management ever fearful of cost and schedule overruns or technological failures, and the divided loyalties of the personnel assigned to the team. The ability to trade off conflicting goals and to find the optimal balance between conflicting positions is probably the most important skill of the job. In general, project managers require enthusiasm, stamina, and an appetite for hard work to withstand the onslaught of technical and political concerns. Where possible, they should have seniority and position in the organization commensurate with that of the functional managers with whom they must deal. Regardless of whether they are coordinators within a functional structure or managers in a matrix structure, they will frequently find their formal authority incomplete. Therefore, they must have the blend of technical, administrative, and interpersonal skills as illustrated in Figure 1.7 to furnish effective leadership. 1.5 Components, Concepts, and Terminology Although each project has a unique set of goals, there is enough commonality at a generic level to permit the development of a unified framework for planning and control. Project management techniques are designed to handle the common processes and problems that arise during a project’s life cycle. This does not mean, however, that one versed in such techniques will be a successful manager. Experts are needed to collect and interpret data, negotiate contracts, arrange for resources, manage stakeholders, and deal with a wide range of technical and organizational issues that impinge on both the cost and the schedule. The following list contains the major components of a “typical” project. Project initiation, selection, and definition Identification of needs Mapping of stakeholders (who are they, what are their needs and expectations, how much influence and power they have, will they be engaged and by how much and will they be involved in the project and by how much) Figure 1.7 Important skills for the project manager. Figure 1.7 Full Alternative Text Figure 1.8 Major interactions of project stakeholders. Development of (technological and operational) alternatives Evaluation of alternatives based on performances, cost, duration, and risk Selection of the “most promising” alternatives Estimation of the life cycle cost (LCC) of the

promising alternatives Assessment of risk of the promising alternatives Development of a configuration baseline “Selling” the configuration and getting approval Project organization Selection of participating organizations Structuring the work content of the project into smaller work packages using a WBS Allocation of WBS elements to participating organizations and assigning managers to the work packages Development of the project organizational structure and associated communication and reporting facilities Analysis of activities Definition of the project’s major tasks Development of a list of activities required to complete the project’s tasks Development of precedence relations among activities Development of a network model Development of higher level network elements (hammock activities, subnetworks) Selection of milestones Updating the network and its elements Project scheduling Development of a calendar Assigning resources to activities and estimation of activity durations Estimation of activity performance dates Monitoring actual progress and milestones Updating the schedule Resource management Definition of resource requirements Acquisition of resources Allocation of resources among projects/activities Monitoring resource use and cost Technological management Development of a configuration management plan Identification of technological risks Configuration control Risk management and control Total quality management (TQM) Project budgeting Estimation of direct and indirect costs Development of a cash flow forecast Development of a budget Monitoring actual cost Project execution and control Development of data collection systems Development of data analysis systems Execution of activities Data collection and analysis Detection of deviations in cost, configuration, schedule, and quality Development of corrective plans Implementation of corrective plans Forecasting of project cost at completion Project termination Evaluation of project success Recommendation for improvements in project management practices Analysis and storage of information on actual cost, actual duration, actual performance, and configuration Each of these activities is discussed in detail in subsequent chapters. Here, we give an overview with the intention of introducing important concepts and the relationships among them. We also mention some of the tools developed to support the management of each activity. 1. Project initiation, selection, and definition. This process starts with identifying a need for a new service, product, or system. The trigger can come from any number of sources, including a current client, line personnel, or a proposed request from an outside organization. The trigger can come from one or more stakeholders who may have similar or conflicting needs and expectations. If the need is considered important and feasible solutions exist, then the need is translated into technical specifications. Next, a study of alternative solution approaches is initiated. Each alternative is evaluated based on a predetermined set of performance measures, and the most promising compose the “efficient frontier” of possible solutions. An effort is made to estimate the performances, duration, costs, and risks associated with the efficient alternatives. Cost estimates for development, production (or purchasing), maintenance, and operations form the basis of a Life Cycle Cost (LCC) model used for selecting the “optimal” alternative. Because of uncertainty, most of the estimates are likely to be problematic. A risk assessment may be required if high levels of uncertainty are present. The risk associated with an unfavorable outcome is defined as the probability of that outcome multiplied by the cost associated with it. A proactive risk management approach means that major risk drivers should be identified early in the process, and contingency plans should be prepared to handle unfavorable events if and when they occur. Once an alternative is chosen, design details are fleshed out during the concept formulation and definition phase of the project.

Preliminary design efforts end with a configuration baseline. This configuration (the principal alternative) has to satisfy the needs and expectations of the most important stakeholders and be accepted and approved by management. A well-structured selection and evaluation process, in which all relevant parties are involved, increases the probability of management approval. A generic flow diagram for the processes of project initiation selection and definition is presented in Figure 1.9. Figure 1.9 Major activities in the conceptual design phase. Figure 1.9 Full Alternative Text 2. Project organization. Many stakeholders, ranging from private firms and research laboratories to public utilities and government agencies, may participate in a particular project. In the advanced development phase, it is common to define the work content [statement of work (SOW)] as a set of tasks, and to array them hierarchically in a treelike form known as the WBS. The relationship between participating organizations, known as the organizational breakdown structure (OBS) is similarly represented. In the OBS, the lines of communication between and within organizations are defined, and procedures for work authorization and report preparation and distribution are established. Finally, lower-level WBS elements are assigned to lower-level OBS elements to form work packages and a responsibility matrix is constructed, indicating which organizational unit is responsible for which WBS element. At the end of the advanced development phase, a more detailed cost estimate and a long-range budget proposal are prepared and submitted for management approval. A positive response signals the go-ahead for detailed planning and organizational design. This includes the next five functions. 3. Analysis of activities. To assess the need for resources and to prepare a detailed schedule, it is necessary to develop a detailed list of activities that are to be performed. These activities should be aimed at accomplishing the WBS tasks in a logical, economically sound, and technically feasible manner. Each task defined in the initial planning phase may consist of one or more activities. Feasibility is ensured by introducing precedence relations among activities. These relations can be represented graphically in the form of a network model. Completion of an important activity may define a milestone and is represented in the network model. Milestones provide feedback in support of project control and form the basis for budgeting, scheduling, and resource management. As progress is made, the model has to be updated to account for the inclusion of new activities in the WBS, the successful completion of tasks, and any changes in design, organization, and schedule as a result of uncertainty, new needs, or new technological and political developments. 4. Project scheduling. The expected execution dates of activities are important from both a financial (acquisition of the required funds) and an operational (acquisition of the required resources) point of view. Scheduling of project activities starts with the definition of a calendar specifying the working hours per day, working days per week, holidays, and so on. The expected duration of each activity is estimated, and a project schedule is developed based on the calendar, precedence relations among activities, and the expected duration of each activity. The schedule specifies the starting and ending dates of each activity and the accompanying slack or leeway. This information is used in budgeting and resource management. The schedule is used as a basis for work authorization and as a baseline against which actual progress is measured. It is updated throughout the life cycle of the project to reflect actual progress. 5. Resource management. Activities are performed by resources so that before any concrete steps can be taken, requirements have to be identified. This means defining one or more alternatives for meeting the estimated needs

of each activity (the duration of an activity may be a function of the resources assigned to perform it). Based on the results, and in light of the project schedule, total resource requirements are estimated. These requirements are the basis of resource management and resource acquisition planning. When requirements exceed expected availability, schedule delays may occur unless the difference is made up by acquiring additional resources or by subcontracting. Alternatively, it may be possible to reschedule activities (especially those with slack) so as not to exceed expected resource availability. Other considerations, such as minimizing fluctuations in resource usage and maximizing resource utilization, may be applicable as well. During the execution phase, resources are allocated periodically to projects and activities in accordance with a predetermined timetable. However, because actual and planned use may differ, it is important to monitor and compare progress to plans. Low utilization as well as higher-than-planned costs or consumption rates indicate problems and should be brought to the immediate attention of management. Large discrepancies may call for significant alterations in the schedule. 6. Technological management. Once the technological alternatives are evaluated and a consensus forms, the approved configuration is adopted as a baseline. From the baseline, plans for project execution are developed, tests to validate operational and technical requirements are designed, and contingency plans for risky areas are formulated. Changes in needs or in the environment may trigger modifications to the configuration. Technological management deals with execution of the project to achieve the approved baseline. Principal functions include the evaluation of proposed changes, the introduction of approved changes into the configuration baseline, and development of a total quality management (TQM) program. TQM involves the continuous effort to prevent defects, to improve processes, and to guarantee a final result that fits the specifications of the project and the expectations of the client. 7. Project budgeting. Money is the most common resource used in a project. Equipment and labor have to be acquired, and suppliers have to be paid. Overhead costs have to be assigned, and subcontractors have to be put on the payroll. Preparation of a budget is an important management activity that results in a time-phased plan summarizing expected expenditures, income, and milestones. The budget is derived by estimating the cost of activities and resources. Because the schedule of the project relates activities and resource use to the calendar, the budget is also related to the same calendar. With this information, a cash flow analysis can be performed, and the feasibility of the predicted outlays can be tested. If the resulting cash flow or the resulting budget is not acceptable, then the schedule should be modified. This is frequently done by delaying activities that have slack. Once an acceptable budget is developed, it serves as the basic financial tool for the project. Credit lines and loans can be arranged, and the cost of financing the project can be assessed. As work progresses, information on actual cost is accumulated and compared with the budget. This comparison forms the basis for controlling costs. The sequence of activities performed during the detailed design phase is summarized in Figure 1.10. Figure 1.10 Major activities in the detailed design phase. Figure 1.10 Full Alternative Text 8. Project execution and control. The activities described so far compose the necessary steps in initializing and preparing a project for execution. A feasible schedule that integrates task deadlines, budget considerations, resource availability, and technological requirements, while satisfying the precedence relations among activities, provides a good starting point for a project. It is important, however, to remember that successful implementation

of the initial schedule is subject to unexpected or random effects that are difficult (or impossible) to predict. In situations in which all resources are under the direct control of management and activated according to plan, unexpected circumstances or events may sharply divert progress from the original plan. For resources that are not under complete management control, much higher levels of uncertainty may exist, for example, a downturn in the economy, labor unrest, technology breakthroughs or failures, and new environmental regulations. Project control systems are designed with three purposes in mind: (1) to detect current deviations and to forecast future deviations between actual progress and the project plans; (2) to trace the source of these deviations; and (3) to support management decisions aimed at putting the project back on the desired course. Project control is based on the collection and analysis of the most recent performance data. Actual progress, actual cost, resource use, and technological achievements should be monitored continually. The information gleaned from this process is compared with updated plans across all aspects of the project. Deviations in one area (e.g., schedule overrun) may affect the performance and deviations in other areas (e.g., cost overrun). In general, all operational data collected by the control system are analyzed, and, if deviations are detected, a scheme is devised to put the project back on course. The existing plan is modified accordingly, and steps are taken to monitor its implementation. During the life cycle of the project, a continuous effort is made to update original estimates of completion dates and costs. These updates are used by management to evaluate the progress of the project and the efficiency of the participating organizations. These evaluations form the basis of management forecasts regarding the expected success of the project at each stage of its life cycle. Schedule deviations might have implications on a project’s finances or Profit and Loss (P and L), if payments are based on actual progress. If a schedule overrun occurs and payments are delayed, then cash flow difficulties might result. Schedule overruns might also cause excess load on resources as a result of the accumulation of work content. A welldesigned control system in the hands of a well-trained project manager is the best way to counteract the negative effects of uncertainty. 9. Project termination. A project does not necessarily terminate as soon as its technical objectives are met. Management should strive to learn from past experience to improve the handling of future projects. A detailed analysis of the original plan, the modifications made over time, the actual progress, and the relative success of the project should be conducted. The underlying goal is to identify procedures and techniques that were not effective and to recommend ways to improve operations. An effort aimed at identifying missing or redundant managerial tools should also be initiated; new techniques for project management should be adopted when necessary, and obsolete procedures and tools should be discarded. Information on the actual cost and duration of activities and the cost and utilization of resources should be stored in well-organized databases to support the planning effort in future projects. Only by striving for continuous improvement and organizational learning through programs based on past experience is competitiveness likely to persist in an organization. Policies, procedures, and tools must be updated on a regular basis. 1.6 Movement to Project-Based Work Increased reliance on the use of project management techniques, especially for research and development, stems from the changing circumstances in which modern businesses must compete. Pinto (2002) pointed out that among the most important influences promoting a project orientation in recent years have been the following: 1. Shortened product life cycles. Products

become obsolete at an increasingly rapid rate, requiring companies to invest ever-higher amounts in R&D and new product development. 2. Narrow product launch windows. When a delay of months or even weeks can cost a firm its competitive advantage, new products are often scheduled for launch within a narrow time band. 3. Huge influx of global markets. New global opportunities raise new global challenges, such as the increasing difficulty of being first to market with superior products. 4. Increasingly complex and technical problems. As technical advances are diffused into organizations and technical complexity grows, the challenge of R&D becomes increasingly difficult. 5. Low inflation. Corporate profits must now come less from raising prices year after year and more from streamlining internal operations to become ever more efficient. Durney and Donnelly investigated the effects of rapid technological change on complex information technology projects (2013). The impact of these and other economic factors has created conditions under which companies that use project management are flourishing. Their success has encouraged increasingly more organizations to give the discipline a serious look as they contemplate how to become “project savvy.” At the same time, they recognize that, for all the interest in developing a project-based outlook, there is a severe shortage of trained project managers needed to convert market opportunities into profits. Historically, lack of training, poor career ladders, strong political resistance from line managers, unclear reward structures, and almost nonexistent documentation and operating protocols made the decision to become a project manager a risky move at best and downright career suicide at worst. Increasingly, however, management writers such as Tom Peters and insightful corporate executives such as Jack Welch have become strong advocates of the project management role. Between their sponsorship and the business pressures for enhancing the project management function, there is no doubt that we are witnessing a groundswell of support that is likely to continue into the foreseeable future. Recent Trends in Project Management Like any robust field, project management is continuously growing and reorienting itself. Some of the more pronounced shifts and advances can be classified as follows: 1. Risk management. Developing more sophisticated up-front methodologies to better assess risk before significant commitment to the project. 2. Scheduling. New approaches to project scheduling, such as critical chain project management, that offer some visible improvements over traditional techniques. 3. Structure. Two important movements in organizational structure are the rise of the heavyweight project organization and the increasing use of project management offices. 4. Project team coordination. Two powerful advances in the area of project team development are the emphasis on cross-functional cooperation and the model of punctuated equilibrium as it pertains to intra-team dynamics. Punctuated equilibrium proposes that rather than evolution occurring gradually in small steps, real natural change comes about through long periods of status quo interrupted by some seismic event. 5. Control. Important new methods for tracking project costs relative to performance are best exemplified by earned value analysis. Although the technique has been around for some time, its wider diffusion and use are growing. 6. Impact of new technologies. Internet and web technologies have given rise to greater use of distributed and virtual project teams, groups that may never physically interact but must work in close collaboration for project success. 7. Lean project management. The work of teams of experts from academia and industry led to the development of the guide to lean enablers for managing engineering programs (2012). The list of these enablers and the way they should be implemented is an important step in the development and application of lean project management methodologies.

8. Process-based project management. The PMBOK (PMI Standards Committee 2012) views project management as a combination of the ten knowledge areas listed in Section 1.14.1. Each area is composed of a set of processes whose proper execution defines the essence of the field. 1.7 Life Cycle of a Project: Strategic and Tactical Issues Because of the degree to which projects differ in their principal attributes, such as duration, cost, type of technology used, and sources of uncertainty, it is difficult to generalize the operational and technical issues they each face. It is possible, however, to discuss some strategic and tactical issues that are relevant to many types of projects. The framework for the discussion is the project life cycle or the major phases through which a “typical” project progresses. An outline of these phases is depicted in Figure 1.11 and elaborated on by Cleland and Ireland (2006), who identify the long-range (strategic) and medium-range (tactical) issues that management must consider. A synopsis follows. Figure 1.11 Project life cycle. Figure 1.11 Full Alternative Text 1. Conceptual design phase. In this phase, a stakeholder (client, contractor, or subcontractor) initiates the project and evaluates potential alternatives. A client organization may start by identifying a need or a deficiency in existing operations and issuing a request for proposal (RFP). The selection of projects at the conceptual design phase is a strategic decision based on the established goals of the organization, needs, ongoing projects, and long-term commitments and objectives. In this phase, expected benefits from alternative projects, assessment of cost and risks, and estimates of required resources are some of the factors weighed. Important action items include the initial “go/no go” decision for the entire project and “make or buy” decisions for components and equipment, development of contingency plans for high-risk areas, and the preliminary selection of subcontractors and other team members who will participate in the project. In addition, upper management must consider the technological aspects, such as availability and maturity of the required technology, its performance, and expected usage in subsequent projects. Environmental factors related to government regulations, potential markets, and competition also must be analyzed. The selection of projects is based on a variety of goals and performance measures, including expected cost, profitability, risk, and potential for follow-on assignments. Once a project is selected and its conceptual design is approved, work begins on the second phase where many of the details are ironed out. 2. Advanced development phase. In this phase, the organizational structure of the project is formed by weighing the tactical advantages and disadvantages of each possible arrangement mentioned in Section 1.3.4. Once a decision is made, lines of communication and procedures for work authorization and performance reporting are established. This leads to the framework in which the project is executed. 3. Detailed design phase. This is the phase in a project’s life cycle in which comprehensive plans are prepared. These plans consist of: Product and process design Final performance requirements Detailed breakdown of the work structure Scheduling information Blueprints for cost and resource management Detailed contingency plans for high-risk activities Budgets Expected cash flows In addition—and most importantly—procedures and tools for executing, controlling, and correcting the project are developed. When this phase is completed, implementation can begin since the various plans should cover all aspects of the project in sufficient detail to support work authorization and execution. The success of a project is highly correlated with the quality and the depth of the plans prepared during this phase. A detailed design review of each plan and each aspect of the project is, therefore, conducted before approval.

A sensitivity analysis of environmental factors that contribute to uncertainty also may be needed. This analysis is typically performed as part of “what-if” studies using expert opinions and simulation as supporting mechanisms. In most situations, the resources committed to the project are defined during the initial phases of its life cycle. Although these resources are used later, the strategic issues of how much to spend and at what rate are addressed here. 4. Production or execution phase. The fourth life-cycle phase involves the execution of plans and in most projects dominates the others in effort and duration. The critical strategic issue here relates to maintaining top management support, while the critical tactical issues center on the flow of communications within and among the participating organizations. At this level, the focus is on actual performance and changes in the original plans. Modifications can take different forms—in the extreme case, a project may be canceled. More likely, though, the scope of work, schedule, and budget will be adjusted as the situation dictates. Throughout this phase, management’s task is to assign work to the participating parties, to monitor actual progress and compare it with the baseline plans. The establishment and operation of a well-designed communications and control system therefore are necessary. Support of the product or system throughout its entire life (logistic support) requires management attention in most engineering projects for which an operational phase is scheduled to follow implementation. The preparation for logistic support includes documentation, personnel training, maintenance, and initial acquisition of spare parts. Neglecting this activity or giving it only cursory attention can doom an otherwise successful venture. 5. Termination phase. In this phase, management’s goal is to consolidate what it has learned and translate this knowledge into ongoing improvements in the process. Current lessons and experience serve as the basis for improved practice. Although successful projects can provide valuable insights, failures can teach us even more. Databases that store and support the retrieval of project management information related to project cost, schedules, resource utilization, and so on are assets of an organization. Readily available, accurate information is a key factor in the success of future projects. 6. Operational phase. The operational phase is frequently outside the scope of a project and may be carried out by organizations other than those involved in the earlier life-cycle stages. If, for example, the project is to design and build an assembly line for a new model of automobile, then the operation of the line (i.e., the production of the new cars) will not be part of the project because running a mass production system requires a different type of management approach. Alternatively, consider the design and testing of a prototype electric vehicle. Here, the operational phase, which involves operating and testing the prototype, will be part of the project because it is a one-time effort aimed at a ver… CLICK HERE TO GET A PROFESSIONAL WRITER TO WORK ON THIS PAPER AND OTHER SIMILAR PAPERS CLICK THE BUTTON TO MAKE YOUR ORDER

0 notes