Project management theory and practice, second edition by gary l Richardson(PRADYUTVAM2)CPUL

Project Management Theory and Practice Second Edition Gary L Richardson Project Management Theory and Practice Second Edition Project Management Theory and Practice Second Edition Gary L Richardson CRC Press Taylor & Francis Group 6000 Broken Sound Parkway NW, Suite 300 Boca Raton, FL 33487-2742 © 2015 by Taylor & Francis Group, LLC CRC Press is an imprint of Taylor & Francis Group, an Informa business No claim to original U.S Government works Version Date: 20140626 International Standard Book Number-13: 978-1-4822-5497-6 (eBook - PDF) This book contains information obtained from authentic and highly regarded sources Reasonable efforts have been made to publish reliable data and information, but the author and publisher cannot assume responsibility for the validity of all materials or the consequences of their use The authors and publishers have attempted to trace the copyright holders of all material reproduced in this publication and apologize to copyright holders if permission to publish in this form has not been obtained If any copyright material has not been acknowledged please write and let us know so we may rectify in any future reprint Except as permitted under U.S Copyright Law, no part of this book may be reprinted, reproduced, transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying, microfilming, and recording, or in any information storage or retrieval system, without written permission from the publishers For permission to photocopy or use material electronically from this work, please access www.copyright.com (http:// www.copyright.com/) or contact the Copyright Clearance Center, Inc (CCC), 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400 CCC is a not-for-profit organization that provides licenses and registration for a variety of users For organizations that have been granted a photocopy license by the CCC, a separate system of payment has been arranged Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for identification and explanation without intent to infringe Visit the Taylor & Francis Web site at http://www.taylorandfrancis.com and the CRC Press Web site at http://www.crcpress.com CONTENTS Preface xxi Acknowledgments xxiii Author xxv Part Conceptual Overview of the Project Environment Chapter 1 Introduction 1.1 Project Management 1.2 Role of the PM 1.3 PM Skills 1.3.1 Success Management 1.4 Book Content and Organization 1.4.1 Book Structure Appendices 9 References 9 Chapter Evolution of Project Management 11 2.1 Early History of Project Management 12 2.2 Application of Analytical Science 12 2.3 Frederick Taylor and Scientific Management 12 2.4 Frank and Lillian Gilbreth 14 2.5 Henry Gantt 14 2.6 Mary Parker Follett 15 2.7 Elton Mayo 15 2.8 Phases of Project Management Evolution 16 2.9 Project Management Challenges 21 2.10 Project Management Benefits 21 2.10.1 At the Macrolevel 21 2.10.2 At the Microlevel 22 References 22 v vi • Contents Chapter Project Management Body of Knowledge 23 3.1 High-Level Overview 23 3.2 History of PMBOK® Guide Development 24 3.3 Structure of the PMBOK® Guide 24 3.3.1 Project Domains 24 3.3.2 Knowledge Areas (KAs) 28 3.4 Introductory Vocabulary Terms 32 3.5 Ancillary Models 34 3.6 Summary 34 Reference 35 Chapter Industry Trends in Project Management 37 4.1 Standardizing Project Management 37 4.2 Enterprise Project Management 37 4.3 EPM in Operation 39 4.4 Implementation and Advantages of EPM 40 4.5 Other Trends Impacting Project Management 40 4.6 Project Management Perspective 41 Discussion Questions 42 References 42 Chapter Project Types 43 Reference 47 Chapter Project Organization Concepts 49 6.1 PM’s Role 49 6.2 Reporting Relationships 50 6.3 Team Resources 50 6.4 Team Productivity and Size 51 6.5 Team’s Physical Location Issues 51 6.6 Virtual Organizations 53 6.7 Organizational Culture 54 6.8 Summary 55 References 55 Chapter Project Life Cycle Models 7.1 Overview of Project Methodologies 7.2 Life Cycle Management Process 7.2.1 Feasibility Review 7.2.2 Project Plan 7.2.3 Logical versus Physical Design 7.2.4 Quality Control and Quality Assurance 7.2.5 Monitor and Control 7.2.6 Periodic Status Reviews 7.2.7 Milestone or Stage Gate Reviews 7.2.8 Project Close 7.2.9 Project Communication Processes 7.2.10 Life Cycle Models 7.2.11 Templates 57 57 58 59 59 59 60 60 60 60 60 61 61 62 Contents • vii 7.3 Key Project Management Artifacts 62 7.3.1 Initiating 62 7.3.2 Planning 62 7.3.3 Execution 63 7.3.4 Monitoring and Control 63 7.3.5 Baseline 63 7.4 Project Methodology Models 63 7.5 Summary Points 65 References 67 Chapter Quick Start Example 69 8.1 Project Management Work Packages 69 8.2 WP Dictionary 69 8.3 Multiple WPs 71 8.4 Psychology of Estimating 72 8.5 Procrastination 72 8.6 Developing the Whole Project View 73 8.7 Project Scope 74 8.8 Example: Pool Project Mechanics 75 8.9 Quick Start Wrap-Up 79 Discussion Questions 79 Reference 79 Concluding Remarks for Part 80 Part Projects as State Change Vehicles Chapter Role of Projects in the Organization 85 9.1 Project Valuation Models 85 9.2 Project Selection Strategies 88 9.3 Conclusion 90 References 91 Chapter 10 Project Initiation 10.1 Introduction 10.2 Environmental Factors to Consider 10.2.1 User Involvement 10.2.2 Executive Management Support 10.2.3 Experienced PM 10.2.4 Communications 10.2.5 Clear Business Objectives 10.2.6 Minimized Scope 10.3 Other Success Factors 10.3.1 Agile Development Approaches 10.3.2 Existence of a Standard Process Infrastructure 10.3.3 Use of a Standard Methodology 10.3.4 Reliable Time Estimates 10.3.5 Availability of Appropriate Skills 10.3.6 Industry and Organizational Culture 93 93 98 99 99 100 101 101 102 103 103 104 104 105 105 105 viii • Contents 10.4 Project Success Trends 106 10.5 Forecasting the Success of Technology Projects 106 10.6 Conclusion 109 References 109 Part Defining the Triple Constraints Chapter 11 Project Plan Development 115 11.1 Arguments for Planning 116 11.1.1 Project Monitoring and Control 117 11.1.2 Conflicting Expectations 117 11.1.3 Overlooking the Real Solution 117 11.1.4 Competing Solutions 118 11.1.5 Misaligned Goals 118 11.1.6 Quality Solutions 118 11.1.7 Summary 118 11.2 ​Plan Process and Components 118 11.3 ​Initial Planning View 119 11.4 Plan Artifacts 120 11.5 Real-World Planning Process 121 11.6 Conclusion 121 References 122 Chapter 12 Scope Management 123 12.1 Defining Project Work Units 124 12.2 WP Planning Variables 125 12.3 Multiple WPs 126 12.4 Developing the Project View 126 12.5 Developing Project WBS 127 12.6 WBS Mechanics 130 12.6.1 WBS Numbering Scheme 132 12.6.2 WBS Dictionary 133 12.6.3 Other WBS Views 133 12.6.4 Tracking Status of the WP 136 12.7 WBS Construction Mechanics 137 12.8 Requirements “ibilities” 139 12.9 Moving Forward 141 References 142 Chapter 13 Time Management 13.1 Defining Project Work Activities 13.1.1 Define Activities 13.1.2 Activity Sequencing 13.1.3 Estimating Activity Resources 13.1.4 Estimate Activity Duration 13.2 Tips for Accurate Estimating 13.2.1 Types of Estimates 13.3 Estimating Techniques 13.3.1 Expert Judgment 143 144 145 146 146 146 147 148 149 149 612  •  Appendix A: Financial Metrics investment The goal in using this measure would be to favor projects that pay back their investment the quickest NPV is the calculated present value of the benefit stream This measure is sensitive to the time value of money, and the analysis is based on some hurdle rate, that is, it has to be measured positive compared to say 15% This would favor any projects that returned values greater than this amount IRR represents the rate of return calculated for the estimated benefit stream This is analogous to investing money and getting more in return, and then calculating how much return you received on that investment This is the most difficult financial calculation, but the one that has the best comparative value across the project portfolio A.1  CALCULATION MECHANICS PB—time required to pay back the initial investment NPV—this value is calculated by the formula (1 + i)n, where i is the interest rate and n is the number of years in the future In the NPV calculation, each out year value would be translated back to the current time using the formula above, and then all values are added together for the NPV value IRR—this uses the same concept as the NPV, except that the value of i is unknown; therefore it is necessary to repeat the calculation until a value of NPV is zero So, IRR is the value of i where the NPV is zero A.1.1  Timing Issues Related to Estimates In the use of these measures, there is a timing issue to consider, that is, we assume in the estimate that all the cost are incurred at the beginning of the year, middle of the year, or spread equally through the year? For these examples, we will follow the Excel assumptions, but for a particular analysis, the timing question should be reviewed to make sure that the calculated values properly reflect the estimates used A.2  COMMENTS ON EXCEL INTERNAL ASSUMPTIONS In calculating NPV, Excel assumes that the cash flows occur at the end of the indicated period A.3  SAMPLE CALCULATIONS The ABC company is considering investing in three projects The projects are expected to cost the company $500,000 and the future cash inflows for the three projects being considered are as follows: Project X Total $50,000 $150,000 $300,000 $100,000 $50,000 $650,000 Project Y Total $325,000 $175,000 $75,000 $50,000 $25,000 $650,000 Project Z Total $130,000 $130,000 $130,000 $130,000 $130,000 $650,000 Appendix A: Financial Metrics  •  613 Note that all three projects have the same total benefit stream; however, timing of these benefits is different for each We will see the impact this has on the financial measures that each produce One more important thing about the Excel’s NPV function is that if we include the initial project cost or the initial investment into the Excel NPV function, we get incorrect results that are indicated in the worksheet below as NPV (Incorrect) This is an idiosyncrasy of the Excel’s NPV function A.3.1  Other Information The company wants to make 10% or more on any project that they accept Each of these projects is only expected to produce cash inflows for years The worksheets illustrate the calculations both manually as well as using Excel’s functions for the given examples +ve (Returns) NPV = –$5836.66 Convert all future values to present 614  •  Appendix A: Financial Metrics A.4  PROJECT SUMMARY COMPARISON Project X Y Z NPV −5836.66 46,104.96 −7197.72 IRR PB 0.10 0.16 0.10 From the values calculated, we can see that project Y is the best financial option in all three metrics The PB method though very simple often favors short projects with quick returns and penalizes excellent longer-term projects where large benefits not start until years and beyond Also, the PB method completely ignores the time value money concept In this example, all three methods favor the same project This would not be the case if the flows were changed to showing benefits later in the stream Appendix A: Financial Metrics  •  615 Project X Criteria Rating Criteria Strategic fit Availability of resources Probability of success Revenue impact Operation cost impact IRR PB     Weighted Project Y Criteria Rating Weighted 1 = Low, 5 = High Project Z Criteria Rating Weighted Weight (%) 1 = Low, 5 = High 1 = Low, 5 = High 20 10 0.8 0.3 0.6 0.4 0.4 0.2 0.15 0.25 10 10 0.2 0.4 0.4 0.2 0.2 0.4 40 Score Ranking 0.3 0.15 2.65 4 0.8 0.2 3.55 1 0.2 0.1 2.75 There are many different reasons for a company to select a project that has benefits other than financial and therefore would not be reflected in the measurement techniques discussed above For example, the following additional criteria need to be assessed along with the basic financial measures: • • • • • Strategic fit Availability of resources Likelihood of success Increases revenue Process efficiency impact The example below adds some additional assessment criteria to the evaluation and assigns weights to each of these Note that some of the attributes are pure numeric and others are qualitative assessments translated into an integer score Let us see what summary values emerge from this type analysis As we can see from the weighted average shown above, Project Y is still rated the best option based on the highest weighted score of 3.55 The weights assigned for each category are arbitrary, and it is often wise to compare other weightings to see if the answer is sensitive to some particular value DISCUSSION QUESTIONS What other evaluation criteria might be added to the matrix? What might be the value in selecting one of the other projects? Do you see any flaws in the manner in which weights are assigned to the various criteria? Is there a situation where PB might be the best financial metric? APPENDIX B: TEMPLATES One of the irritants of project management is the creation of formalized documents As a result of this many projects shun the documentation process and produce only the bare minimum For those external stakeholders dealing with such projects the lack of professional looking documentation can make the management process appear amateurish, whether that is a valid assessment or not Use of templates can be a great asset in making the overall project look more professional and save a significant amount of time in the process Throughout the book, various project management artifacts have been described as to their role, but not so much in detail as to what they might look like in format If one were to undertake developing a format for all the documents, there would be significant time spent in that activity That is really not a productive use of time and samples of these are readily available through many sources The Internet has opened access to these and there is now a wide array of online sources where tested template formats can be found Some of these have moderate costs and some are free This appendix will summarize a few such sites that are worthy of reviewing A sample listing of template types would include the following: • • • • • • • • • • • • Project plan Change request Scope management plan Scope change register Change tracking Requirements definition Estimating worksheet Standard development network plan Life-cycle development activity list Issue register Project status reporting Project standards The web locations listed below are well-known and respected sources for various project management information, including methodologies, articles, training, and templates 617 618  •  Appendix B: Templates B.1 ​WEB SOURCES • TenStep is a free web site offering technical source material in project management One of the unique aspects of this site is its partnership with Cordin8 The pair offers an inexpensive approach to implementing a tested methodology along with the Cordin8 tool for information sharing and collaboration Both of these options offer good potential for improving project selection, delivery, and collaboration Their URLs are www.­tenstep.­com and www.­cordin8.­com.­ • Method123 is an online web reference for project management They sponsor an excellent methodology and templates for various project management functions Their URL is www.­method123.­com.­ • Gantthead.com is a good online source for various project management articles, training, webinars, and tools related to current project management Their URL is www.­gantthead.­com.­ • The International Association of Project and Program Management (IAPPM), formed in 2003 through volunteers, is established as a global PMP organization and Association providing knowledge and useful content to PMs and program managers IAPPM is the publisher of the CPPMBoK, currently in first draft format It also provides certified project manager (CPM) certification to individuals meeting project experience and eligibility criteria As an independent project organization, IAPPM is dedicated to helping individuals achieving success in the global project community • The Matt H Evans web site contains an extensive listing of spreadsheets that collectively have potential value in various aspects of project management The URL for this list is http:/­/­w ww.­exinfm.­com/­free_­spreadsheets.­html.­ On particularly interesting general purpose, spreadsheet that should be reviewed is The Project Management one which is sponsored by IAPPM (reference # 84 on the list) B.2  GOVERNMENTAL WEB SITES • The State of Texas Department of Information Resources sponsors a large set of templates Further details can be found at www.­dir.­state.­t x.­us.­ • The State of Michigan hosts a very mature web site dedicated to project management (www.­michigan.­gov/­dit).­Use the search option to browse through their library of methodology and templates • The government of Tasmania sponsors a mature project management web site dedicated to various aspects of project management This site includes a knowledge base, various resources including templates, and services Further details can be found at http:/­/­w ww.­egovernment.­tas.­gov.­au/­themes/­project_­management.­ B.3 ​TEXTS Several texts publish project management templates One notable example can be found at Garton, C and E McCulloch, 2007 Fundamentals of Project Management Lewisville, TX: MC Press In addition to the various sources shown here, Internet search engines will uncover many more APPENDIX C: PROJECT REPOSITORY ARCHITECTURE This appendix describes a project document architecture and content designed to be an information repository template for the project team and other stakeholders The value of such a repository comes from having easy access to technical and status documentation regarding the project and its work products These data groups have broad communication value to the various stakeholder groups involved They also have value for management activities related to team collaboration, decision making, and information sharing Organizations that successfully accomplish appropriate levels of information sharing report significant improvements in operational efficiency and improved decision making In addition to this, the cross-communications value produced through the lessons learned process is greatly enhanced by having ready access to previous project’s archival data An appropriate enterprise project documentation repository strategy consists of the following 14 basic component parts: Product artifacts produced by the project (physical design and related artifacts dealing with the technical aspects of the project) Operational metrics (raw performance data collected for the project) Project formal status reports (complete history) KA artifacts (filed by KA) Quality management artifacts (test plans, testing results, etc.) Configuration management libraries (formal documentation repository filed by document type with version control references) Initiation repository (original vision, project Charter, business case, etc.) Operational documentation (user-related documentation) Communication repository (meeting minutes, team communications, and external communications) 10 Lessons learned repository) 11 Reusable standard project management templates 12 Scope management (ICC) 13 Risk management (risk database) 14 Issues log 619 620  •  Appendix C: Project Repository Architecture Note: Items 10 through 14 may be managed separately in centralized enterprise level repositories Each of these repository subsets has value in executing and managing the overall work flow of the project as well as the enterprise project portfolio In addition to the project level items outlined in the first 10 document groups the last four groups have value to external parties as well as the project team For that reason these repositories may be organized as central repositories to contain all projects in the enterprise Finally, there is a top tier of related operational systems that need data from a project If the various project data structures were standardized this could be an automated link For example, data related to enterprise PPM, central accounting, human relations, corporate policies, and others would be managed by their respective custodians but linked to the project as needed Ideally, all the data groupings described above need to be logically interrelated; however, practically speaking, that level of integration is probably not a reasonable tactical goal for most organizations The core discussion here is to describe a subset of those items that are most critical to serve the basic project needs and that are more under the control of the PM In modern terms, this repository should be viewed as automated If that is not practical, a similar manual filing structure should be organized as indicated Migration from manual files to automation should proceed in a priority order based on value to the team Step one of that approach should be to develop an overall repository structure and work toward full automation In operation, value of a structured repository will be achieved through information sharing and improved decision making Additional value will be recognized in supporting audit requirements and other requests for project data One of the common complaints of project team members is the time wasted looking for various project documentation One other aspect often not recognized is using an out-of-date paper document The project repository is intended to be the “one source of the truth” place to retrieve data and one could view this as a “Google” database for all project artifacts In order to achieve these goals, both the storage and the retrieval technical aspects of the repository need to be considered in the design The view shown here is more logical and less technical Access to the data store will require appropriate security access control through a common portal or collaboration tool that simplifies the access process Computer-based storage and retrieval of text and graphics documents has been one of the last frontiers for automation, but relatively recent technology developments in document management software has made this topic one that can be effectively dealt with Basically, large volumes of documents can now be stored cost effectively, and retrieval speed for such documents is impressive Based on this current state of technology the structure described here represents nothing more than an internal project to improve the overall working of projects A manager once described this environment as a project digital workbook Rather than having to pass physical documents around they can be retrieved electronically with more accuracy and timeliness than previous paper approaches A brief comment about each of the document subgroups is included below Product artifacts This segment of the repository contains many of the technical objects needed by team members to execute their daily tasks Items related to the WBS and WBS Dictionary would be cataloged here In addition, any logical Appendix C: Project Repository Architecture  •  621 or physical design notes would be stored under their respective WBS codes Finally, any other related artifacts dealing with the technical aspects of the project are appropriate for this group Operational metrics This subgroup is designed to store all project performance metrics, both planned and actual Data required to report project status externally would be extracted from this source for both internal and external status information; however, other metrics stored in this area would be used for internal analysis of performance Project status reports This subgroup would contain the chronology of all formal project status reports and would be the source used for transmission to appropriate stakeholders In this manner, the person accessing these reports would be sure that they had the latest version KA artifacts (filed by KA) Each of the project KAs produce various documents related to that area Initially, these are the KA subsidiary management plan for the project Later, more detailed documents will be created These groupings would contain operational items for these areas Note: QC and QA could be separated from this group (see below) QC and QA artifacts This section would contain various operational quality artifacts such as test plans, testing results, user acceptance reports, quality audits, and so on Technical design libraries Most projects have some form of technical design definition of the product Physical projects would have CAD drawings and IT projects would have various logical design documents These documents would be filed in some logical structure Project initiation Many historical artifacts are created during the early initiation phase of the project Items such as the original business case, vision statements, preliminary scope statement, and the official Charter authorizing the project should be saved here for future reference and possibly reuse on another project Operational documentation In many cases, the user of the project output will need documentation regarding operational instructions for the device or system Future maintenance support personnel will need this information related to their work All documents in this category should be kept under version control and available to authorized personnel Communications repository This group is intended to include items such as meeting agendas and minutes, internal team communications, and possibly other unstructured documents sent to or received from external sources Portions of this group would be open to all and other portions would have limited access 10 Lessons learned repository The value found in this process has been recognized in recent times and all projects should be tasked with completing their lessons learned for each phase This should be an enterprise level system, but might have to start as a project level effort and then evolve outward 11 Standard project management template library The concept of reuse has been around for quite some time in various industries and project types Over the past few years one of the strategies to make the project management process more time efficient is to reuse templates for various required items (i.e., project plans, status reports, WBSs, etc.) This also should be an enterprise level effort 622  •  Appendix C: Project Repository Architecture and shared by all projects The PMO/EPM organization is typically charged with supporting this effort 12 Scope management (ICC) This process will either be viewed as internal to the project structure or managed at a central level The organizational option for change control will answer how the system data will be stored However, the formal capture, tracking, and management of scope change requests represent the most important formal configuration management and tracking goals for the project and the organization Failure to properly manage this aspect of the process can create severe cost and schedule problems 13 Risk management This management area represents the least mature management process for most organizations Assuming that the process is recognized as being part of formal project management, there is a need to identify and track risk elements in the same basic manner that scope is handled That is, identify risk elements, decide how to handle that element, and then monitor the process A more detailed discussion on risk management processes is included in Chapter 20 and will supply further thoughts on this data group This key data would reside in a formal Risk Register database 14 Issues log Project issues are items that come up in the course of planning, execution, control, and closing They simply mean that someone needs to deal with the “issue.” For instance, an item of hardware needed by the project team is broken and needs to be fixed, or a decision is needed on a particular question The issues log would identify this need, criticality, and person responsible Since many of these events require support from external project team personnel this should be an enterprise system, but the starting point could be to formalize it for the project team Each of repository subgroups outlined above represents important data artifacts for the project Mature organizations seeking to improve their project environment will support the evolution of this concept, but tactically the PM should follow these guidelines in whatever physical form is available—manual files, crude project file systems, enterprise formal systems, and the like C.1  IMPLEMENTATION STRATEGY Data repositories of the breadth and complexity outlined here typically evolve over time through several steps The initial development phase often is triggered by the recognition that a defined data group has value From that initial starting point data are collected and stored, usually in a crude form such as a spreadsheet file, or a manual paper file Similar repository groups often migrate in fragmented fashion horizontally across the organization Finally, at some critical decision point high-level recognition and support will surface for formalizing and centralizing the data store in order to improve the overall operational value of the data Each of the repository groups outlined here often follows such an evolutionary path, but ideally this subject should be looked at in total and a formal solution sponsored by higher organizational levels It is important to recognize the value of these repositories as part of the standard project work processes and to identify an official owner charged with care and feeding of each data group As these groups become operational, there needs to be a mechanism for the cross-connections between these systems to be Appendix C: Project Repository Architecture  •  623 recognized and dealt with Standardization of issues such as master data schema and date element definitions is needed for all subgroups One development hazard is to allow stovepipe, isolated developments, that later not fit together Likewise, data element ownership needs formal recognition (e.g., where does the data come from and who owns it) Philosophically, effort needs to be made to instantiate a single data version of the truth through these data stores by avoiding redundancy and having version control Step two in the evolution is the organizational push to embed the data into the operational culture This is typically accomplished by using these data items for formal status reporting and operational management actions Storage and publication of approved metrics fits into this theme as well The major support facility for this is some type of retrieval strategy that opens up the data store to a wide variety of users with little pretraining requirement—an intuitive usage approach Step three in the evolution involves using the data store for analytical purposes to improve understanding of the project activities—that is, source of errors, productivity variables, resource issues, resource management across the organization, and the like Data mining utilities and search capabilities represent two types of tools to aid in ad hoc exploration through the data These capabilities support efforts to improve performance and understand the processes better than traditional tools or ad hoc judgment provide Step four represents data reusability across projects The management templates will support quick methods of producing high-quality documents efficiently Much of the project management process requires formatting and boilerplate wording All this can be supplied from the template library and other structures defined in the repository Once the entire structure matures, the repository will provide the opportunity to bring significant changes to the traditional documentation and associated development paradigms As with all procedural changes to the organizational culture this process requires high-level management support and an understanding of the value Historically, this has not been the case and project documentation methods have been characterized as being similar to the cobbler’s children with no shoes Process improvement can only come through a strategic focus on the topic Business & Management / Project Management Praise for the Bestselling First Edition: This book expands on PMI’s PMBOK® Guide, providing readers with a balanced knowledge of theory, organizational issues, and the associated human behavior needed to manage real-world projects effectively an ideal choice for graduate management students, as well as those seeking project management certification —C.S Arora, in Computing Reviews, September 2011 Updated to reflect the Project Management Institute’s (PMI’s) Project Management Body of Knowledge (PMBOK® Guide), Fifth Edition, the new edition of this bestselling textbook continues to provide a practical and up-to-date overview of project management theory Project Management Theory and Practice, Second Edition explains project management theory using language that is easy to understand The book integrates the organizational environment that surrounds a project to supply the well-rounded knowledge of theories, organizational issues, and human behavior needed to manage real-world projects effectively This edition includes a new chapter on Stakeholder Management, which is a new knowledge area covered in the new PMBOK® Guide It also provides updated references and a new streamlined organization of chapters There are several project-related model frameworks sponsored by PMI®, and many are covered in this text For many of the major sections, the PMI Global Accreditation curriculum learning objectives have been adapted with permission of PMI and used to guide the content Filled with end-of-chapter questions, scheduling and budgeting problems, and scoping projects, this text is ideal for classroom use and essential reading for anyone seeking project management certification The book also includes sample empirically oriented worksheets that demonstrate various management decision and analysis-oriented tools an informa business www.crcpress.com 6000 Broken Sound Parkway, NW Suite 300, Boca Raton, FL 33487 711 Third Avenue New York, NY 10017 Park Square, Milton Park Abingdon, Oxon OX14 4RN, UK K23990 ISBN: 978-1-4822-5495-2 90000 781482 254952 www.auerbach-publications.com ... Maturity Model 32.4 CMM Structure 32.5 CMM Maturity Levels 32.5.1 Initial Level (Level 1) 32.5.2 Repeatability Level (Level 2) 32.5.3 Defined Level (Level 3) 32.5.4 Managed Level (Level 4) 32.5.5... Taylor and Scientific Management 12 2.4 Frank and Lillian Gilbreth 14 2.5 Henry Gantt 14 2.6 Mary Parker Follett 15 2.7 Elton Mayo 15 2.8 Phases of Project Management Evolution 16 2.9 Project Management. .. Project Management Theory and Practice Second Edition Project Management Theory and Practice Second Edition Gary L Richardson CRC Press Taylor & Francis Group 6000 Broken