Global Standard
Project Management Institute
GUIDE TO MANAGEMENT KNOWLEDGE
PROJECTS
(PMBOK® Guide) - Fifth Edition
ISBN 978-1-62825-008-4
Publisher:
Project Management Institute, Inc.
14 Campus Boulevard
Newtown Square, Pennsylvania 19073-3299 USA
Phone: + 610-356-4600
Fax: + 610-356-4647
E-mail address: [email protected]
Internet: www.PMI.org
© 2013 Project Management Institute, Inc. All rights reserved.
PMI, the PMI logo, PMP, the PMP logo, PMBOK, PgMP, Project Management Journal, PM Network and the PMI Today logo are registered trademarks of Project Management Institute, Inc. "Quarter Globe Design" is a trademark of Project
Management Institute, Inc. A complete list of PMI trademarks is available from the PMI Legal Department.
Any corrections and comments related to PMI publications are gratefully accepted by the PMI Publications Department. Please send your reports of any typing errors, formatting errors or any other errors. To do this, just make a copy of the page you want, mark the error you noticed on it and send this copy to the address:
Book Editor, PMI Publications, 14 Campus Boulevard, Newtown Square, PA 19073-3299 USA.
For information on discounts on resale or educational use, please contact the PMI Book Service Center.
PMI Book Service Center
P.O. Box 932683, Atlanta, GA 31193-2683 USA
Phone: 1-866-276-4764 (in the US and Canada) or + 1-770-280-4129 (elsewhere)
Fax: + 1-770-280-4113
E-mail address: [email protected]
Printed in the United States of America. No part of this work may be reproduced or transmitted in any form or by any means, whether electronically, in handwritten form, by photography or audio recording, or using any information storage and reproduction system, without the prior written permission of the publisher.
This one complies with the US Permanent Paper Standard published by the National Information Standards Organization, # Z39.48-1984.
10 9 8 7 6 5 4 3 2 1
Bibliographic record of the Library of Congress
Guide to the Project Management Body of Knowledge (PMBOK® Guide). - Fifth edition.
pages cm
Includes bibliographic references and alphabetical index.
ISBN 978-1-62825-008-4 (paperback)
1. Project management. I. Project Management Institute. II. Title: The PMBOK Guide.
HD69.P75G845 2013 658.4'04 - dc23 2012046112
FSC LABEL.pdf 1 12/18/12 1:16 PM
NOTIFICATION
The standards and guidelines published by the Project Management Institute, Inc. (PMI), which include this document, are developed through a standards development process based on voluntary participation and general consensus. This process brings together volunteers and / or brings together the comments and opinions of those interested in the subject matter of this publication. While the PMI administers this process and lays down rules to ensure impartiality in reaching consensus, PMI does not write the document or independently test, evaluate, and verify the accuracy or completeness of the material contained in the standards and guidelines published by PMI. Likewise, PMI does not check the validity of the opinions expressed in these documents.
PMI is not responsible for any personal injury, property damage, or any other damages, whether real, consequential or compensatory, arising directly or indirectly from the publication, use or use of this document. PMI accepts no responsibility or warranty, either express or implied, regarding the accuracy or completeness of any material contained in this document, nor is it responsible or warranted that the information contained in this document will meet any of your purposes or needs. ... PMI makes no warranty as to the quality of any individual manufacturer's or vendor's products or services arising from the use of this standard or guideline.
By publishing and distributing this document, PMI does not provide professional or other services to any person or organization or on behalf of any person or organization; likewise, PMI does not fulfill the obligations of any person or organization towards any third party. When using this document, the person using it should independently determine the actions necessary in the specific circumstances, relying solely on his own judgment or, if necessary, on the advice of a competent professional. Information regarding the topic covered by this document, or related standards, may be obtained from other sources, to which, in order to obtain additional information not contained in this document.
PMI has no authority or responsibility to monitor the conformity of existing practices with the content of this document or to bring those practices in line with this document. PMI does not certify, test or inspect products, designs or designs for safe use or health for consumers. Any certification or other statement of conformity with any safety or health information contained in this document cannot be attributed to PMI; in such a case, responsibility rests solely with the person who issued the certificate or made such a statement.
TABLE OF CONTENTS
I
TABLE OF CONTENTS
1. INTRODUCTION............................................... .................................................. ..................................one
1.1 Purpose of the PMBOK® Guide
................................................................................................... 2
1.2 What is a project? .................................................. .................................................. .......... 3
1.2.1. Links between portfolios, programs and projects ....................................... 4
1.3 What is project management? .................................................. ....................................5
1.4 Links between portfolio management, program management, management
project and organizational project management ............................................. ..... 7
1.4.1 Program Management ............................................. .........................................9
1.4.2 Portfolio Management ............................................. ............................................9
1.4.3 Projects and Strategic Planning ........................................... ................ 10
1.4.4 Project Management Office ............................................ .................................. eleven
1.5 Relationship Between Project Management, Operations Management
and organizational strategy ............................................... ......................................... 12
1.5.1 Operations management
and project management ............................................... ...................................... 12
1.5.2 Organization and project management ........................................... .................... 14
1.6 Business value .............................................. .................................................. ............. 15
1.7 Role of the project manager .............................................. .............................................. sixteen
1.7.1 Areas of responsibility and competence of the project leader .......................... 17
1.7.2 Interpersonal Skills of the Project Leader ................................. 17
1.8 Body of knowledge on project management ............................................ .............................. eighteen
2. THE INFLUENCE OF THE ORGANIZATION AND THE LIFE CYCLE OF THE PROJECT .......................................... .................. nineteen
2.1 Influence of the organization on project management ............................................ ................ twenty
2.1.1 Organizational cultures and styles ........................................... ........................ twenty
2.1.2 Organizational communications ............................................. ......................... 21
2.1.3 Organizational structures ............................................. ................................. 21
2.1.4 Organizational process assets ............................................ .............................. 27
2.1.5 Enterprise environmental factors ............................................ ................................. 29
2.2 Stakeholders and Project Leadership ............................................ ......... thirty
2.2.1 Project stakeholders ............................................ ...................... thirty
TABLE OF CONTENTS
II
© 2013 Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) - Fifth Edition
2.2.2 Project management ............................................. ........................................... 34
2.2.3 Success of the project ............................................. .................................................. ....... 35
2.3 Project team ............................................... .................................................. ............ 35
2.3.1 Composition of project teams ............................................ ......................................... 37
2.4 Project life cycle .............................................. ................................................. 38
2.4.1 Characteristics of the project life cycle ........................................... ............ 38
2.4.2 Project phases ............................................. .................................................. ...... 41
3. PROJECT MANAGEMENT PROCESSES ............................................. .............................................. 47
3.1 General interactions of project management processes ............................................ .. 50
3.2 Project management process groups ............................................. ........................... 52
3.3 Initiation process group .............................................. ............................................ 54
3.4 Group of planning processes .............................................. ....................................... 55
3.5 Execution process group .............................................. ........................................... 56
3.6 Monitoring and control process group ............................................ ......................... 57
3.7 Group of closing processes .............................................. ............................................... 57
3.8 Project information ............................................... .................................................. ..... 58
3.9 Role of Knowledge Areas .............................................. .................................................. ...... 60
4. PROJECT INTEGRATION MANAGEMENT ............................................. ............................................ 63
4.1 Development of the project charter .............................................. ................................................ 66
4.1.1 Develop Project Charter: Inputs ... ........................... 68
4.1.2 Develop Project Charter: Tools and Techniques ... ... 71
4.1.3 Develop Project Charter: Outputs .......................................... ......................... 71
4.2 Developing a project management plan ............................................. ........................... 72
4.2.1 Develop a Project Management Plan: Inputs ... ....... 74
4.2.2 Develop a Project Management Plan: Tools and Techniques ..................... 76
4.2.3 Develop a Project Management Plan: Outputs ......................................... .... 76
4.3 Leadership and management of project work ............................................ ..................... 79
4.3.1 Lead and Control Project Work: Inputs ... 82
4.3.2 Leading and Managing Project Work: Tools and Techniques ... 83
4.3.3 Lead and Manage Project Work: Outputs ...................................... 84
4.4 Monitoring and control of project work ............................................ ................................ 86
TABLE OF CONTENTS
III
© 2013 Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) - Fifth Edition
4.4.1 Monitor and Control Project Work: Inputs ... ............ 88
4.4.2 Monitoring and Controlling Project Work: Tools and Techniques ......................... 91
4.4.3 Monitoring and Controlling Project Work: Outputs ........................................ ......... 92
4.5 Integrated change control .............................................. ........................... 94
4.5.1 Integrated Change Control: Inputs ... ....... 97
4.5.2 Integrated Change Control: Tools and Techniques ....................... 98
4.5.3 Integrated Change Control: Outputs ... ..... 99
4.6 Closing a project or phase ............................................. ............................................. one hundred
4.6.1 Close Project or Phase: Inputs ... ........................ 102
4.6.2 Closing a Project or Phase: Tools and Techniques ... 102
4.6.3 Close Project or Phase: Outputs ... ...................... 103
5. PROJECT CONTENT MANAGEMENT ............................................. ........................................ 105
5.1 Scope Management Planning .............................................. ....................... 107
5.1.1 Plan Scope Management: Inputs ... ... 108
5.1.2 Plan Scope Management: Tools and Techniques .................. 109
5.1.3 Plan Scope Management: Outputs ... 109
5.2 Collecting Requirements ............................................... .................................................. .......... 110
5.2.1 Collect Requirements: Inputs ... ........................................ 113
5.2.2 Gathering Requirements: Tools and Techniques ... ............... 114
5.2.3 Collect Requirements: Outputs ... ..................................... 117
5.3 Definition of content ............................................... .............................................. 120
5.3.1 Scope Definition: Inputs ... .......................... 121
5.3.2 Scope Definition: Tools and Techniques ... .122
5.3.3 Scope Definition: Outputs ... ....................... 123
5.4 Creation of WBS ............................................... .................................................. ................ 125
5.4.1 Create WBS: Inputs ... .............................................. 127
5.4.2 Creating a WBS: Tools and Techniques ......................................... ..................... 128
5.4.3 Create WBS: Outputs ... ........................................... 131
5.5 Confirmation of content ............................................... .......................................... 133
5.5.1 Confirmation of Content: Inputs ... ...................... 134
5.5.2 Validating Content: Tools and Techniques ... 135
TABLE OF CONTENTS
IV
© 2013 Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) - Fifth Edition
5.5.3 Validate Content: Outputs ... ................... 135
5.6 Content Control ............................................... .................................................. .. 136
5.6.1 Content Control: Inputs ... ................................ 138
5.6.2 Scope Control: Tools and Techniques ... ....... 139
On December 31, 2012, PMI released the revised PMBOK® Guide - 5th Edition.
PMI specialists for the release of the PMBoK translation into Russian promise that this work will be done by the end of the year, and the Russian professional community will be able to fully learn all the news and subtleties of the new edition of PMBoK. Remembering the complaints about the translation of PMBoK v.4, it is better to let the Russian version be published later, but they will its quality.
Judging by the experts, the long term of work is justified: there are many new terms to be explained, new processes to be described, the translation of old terms and processes to be clarified, the translations to be harmonized with other standards issued by PMI.
What's new in the new PMBOK 5?
Section X1 "Changes in the fifth edition" just tells us about this. Among all the information of a general nature (such as, “all text and graphics in the document have been revised to make the information more accurate, clear, complete and up-to-date” or “the chapter of the Process Group has been moved to Appendix A1”) there is also useful information:
1. Terminology and harmonization
The authors proudly state that all terminology has been aligned with the PMI Lexicon of Project Management Terms. At the same time, it is the terminology from PMI Lexicon that is taken as priority. If, in addition, the translation of PMBOK 5 into Russian begins with the creation of the correct terminology, then there is hope to get a correctly translated body of knowledge.
PMBOK 5 was also brought in line with ISO 21500: 2012 "Guidance on project management" and ensured the alignment of names, processes, inputs, outputs, tools and methods with other PMI standards (such as "The Standard for Portfolio Management", etc.) ...
Finally, they stopped putting people in a stupor with their "positive risk". After all, what is risk? This is the possibility of danger or failure! The term comes from the Greek risikon, i.e. "Cliff" or "rock". At the time of the greatness and power of Ancient Greece, "to take risks" meant "to maneuver on a ship between the rocks", i.e. potential danger of failure.
PMBOK 5 changed the description of project risk management and shifted the emphasis from the term “positive risk” to the term “opportunity”. The text also added concepts such as risk attitude, risk appetite, risk tolerance and risk thresholds.
2. Project success
Since projects are temporary in nature, project success must be measured in terms of project completion within the constraints of content, time, cost, quality, resources and risks.
But the dynamics of changing requirements in modern projects is so high that by its final stage, the project crawls out beyond all conceivable and inconceivable limitations. Therefore, managing changing requirements, fixing them in project documents and renegotiation basic plans is an increasingly sought-after skill for a project manager. This was reflected in PMBOK 5 in the proposal “The success of the project should be attributed to the implementation of the latest baselines approved by the designated stakeholders”. In my opinion, it couldn't be better. If I managed to agree with the customer to increase the project timeline and budget two days before the end of the project, then the project is successful, in spite of the 2-fold excess of the deadline and 3-fold increase in the budget.
3. Planning management approaches
In PMBOK 4, some of the subsidiary plans appeared out of thin air. For example, the Scope Management Plan was described directly in the Project Scope Management Knowledge Zone, but it was not specified in which process it was created. Four new planning processes have now been added: Content Management Planning, Schedule Management Planning, Cost Management Planning, and Stakeholder Management Planning. This ensures clear leadership of the project team to actively think over and plan approaches to the management of all areas of knowledge.
Although not without flaws here. So two plans remained "unattended" - the Change Management Plan and the Configuration Management Plan. Logically, it is clear that the Configuration Management Plan should appear along with the Scope of Management Plan, and the Change Management Plan - during the development of the overall Project Management Plan, but this is only implied in PMBOK 5.
4. Requirements
The Requirements Gathering process has been expanded to focus on getting all the requirements necessary for the success of the project.
The Verify Scope process has been completely redesigned. First, it has been renamed Validate Scope. Second, emphasis was added that the process is not only about accepting the results, but also that the results will be of value to the business and will serve the purpose of the project.
Funny, but in PMBOK 4 there was not a very correct translation of "Verify Scope" as "Content confirmation". Now this will lead to the fact that in Russian PMBOK 5 this process will not change its name. Just wondering how the translators will get out by translating the section on the changes?
5. Gutta-percha
In all past PMBOKs taken together, the word "agile" has never been not used. In the current PMBOK, it occurs as many as 10 times.
It has never been hidden by PMI that the main purpose of the PMBOK Guide is to highlight the part of the Project Management Body of Knowledge that is generally considered good practice. Those. The knowledge and practices described are applicable to most projects in most cases, and the correct application of these skills, tools and techniques can increase the likelihood of success for a wide range of different projects.
Therefore, the concept of agile project management was included in the process of developing a project schedule.
That's right, you need to keep your nose to the wind! It is also modern, both fashionable and commercially in demand.
6. Project communications
It has long been ripe for the ordering of information and knowledge generated during the implementation of the project. One of the most revolutionary changes in PMBOK 5 is the use of the DIKW (data, information, knowledge, wisdom) model - an information hierarchy, where each level adds certain properties to the previous level:
At the bottom is the data.
Information adds context.
Knowledge adds the answer to the question "how?" (mechanism of use).
Wisdom adds an answer to the question "when?" (Terms of Use).
This was reflected in a clear sequence of collection, aggregation and processing of data from the fields in the form of the following documents:
1. Work performance data. "Raw" observations and measurements identified in the course of the design work.
2. Information about the performance of work. Work performance data is analyzed and integrated based on the relationships between different areas / stages of the project.
3. Reports on the performance of work. Physical or electronic presentation of information about the performance of work, designed to make decisions, highlight issues and problems, develop actions or understand the situation.
If we also attach Lessons of experience here, then the cycle closes, and all the knowledge generated in the processes of project implementation will be collected, processed and be used in the processes of management of all projects in the organization.
Well, the processes that confused many with their blurred boundaries and an incomprehensible sequence: "Dissemination of information" and "Preparation of performance reports", were renamed, respectively, into "Communications Management" and "Communications Control" with logical inputs and outputs.
7. Management of "share owners"
PMBOK 5 places a lot of emphasis on stakeholder management. Almost all sections have been covered to better highlight who the project stakeholders are and their impact on the project. Added a new (10th) Knowledge Area, Project Stakeholder Management, which includes two processes from Project Communications Management, and added two new processes.
The main reasons for this development of the field of knowledge in communications are as follows:
1. A clearer focus of project communications management was required on planning the project's communication needs, on collecting, storing and dissemination information in the project, as well as on monitoring the overall relationships of the project in order to ensure their effectiveness.
2. Real stakeholder management includes not only an analysis of their expectations, their impact on the project and the development of appropriate strategies for their management, but also an ongoing dialogue with interested parties to meet their needs and expectations, addressing issues as their occurrence, and the involvement of stakeholders in decision-making and project activities.
3. Planning and managing the communication needs of the project on the one hand and the needs of the stakeholders on the other are two different keys to the success of a project.
Distinguishing Project Stakeholder Management from Project Communications Management, in addition to solving the 3 problems described above, ensures that PMBOK 5 is in line with new and growing trends in project management and a strong interest of researchers and practicing project managers. to interaction with stakeholders, as one of the keys to the overall success of the project. These trends are already reflected in The Standard for Program Management and ISO 21500: 2012 Guidance on project management. So PMBOK has made up for lost time.
So, the new area of knowledge includes processes:
Identification of stakeholders.
Development of a Stakeholder Management Plan.
Stakeholder Engagement Management.
Monitoring stakeholder engagement.
8. "Soft skills"
Added Trust Building, Conflict Management to Interpersonal Skills and Mentoring. Moreover, a new section has been added to Chapter 1, Introduction, highlighting the importance of interpersonal skills in the project manager and referring the reader to Appendix X3 for a detailed description of these skills.
9. Documentation
Well, and the most important thing for documenting the project - the general ordering of documents, started in PMBOK 4, continued in the 5th. Now the inputs of processes are only documents that play a key role in the execution of the process. The documents and their composition have become clearer and more specific. Although the names of the documents themselves in the text are written everywhere with a small letter, which is why it is difficult to visually find documents in the text and, to work with documents, you need to know PMBOK terminology well or use a package of templates.
In general, PMBOK 5 has become better structured, consistent, with normal interconnections between processes, verified terminology
________________________________________________________________________________________________
1. INTRODUCTION
2. THE INFLUENCE OF THE ORGANIZATION AND THE LIFE CYCLE OF THE PROJECT
3. PROJECT MANAGEMENT PROCESSES
4. PROJECT INTEGRATION MANAGEMENT
5. PROJECT CONTENT MANAGEMENT
6. PROJECT TIME MANAGEMENT
7. PROJECT COST MANAGEMENT
8. PROJECT QUALITY MANAGEMENT
9. PROJECT HUMAN RESOURCES MANAGEMENT
10. PROJECT COMMUNICATION MANAGEMENT
11. PROJECT RISK MANAGEMENT
12. MANAGEMENT OF PROJECT PURCHASES
13. STAKEHOLDER MANAGEMENT
1. INTRODUCTION
Project is a temporary enterprise aimed at creating a unique product, service or result.
The project can create:
· product that is a component of another product, an improvement to a product, or an end product;
· service or the ability to provide a service (for example, a business function that supports manufacturing or distribution);
· improvement an existing line of products or services (for example, a Six Sigma project undertaken to reduce defects);
· result, such as an end result or document (for example, a research project brings new knowledge that can be used to determine if there is a trend or the benefits of a new process for society).
Project management is the application of knowledge, skills, tools and methods to the work of a project to meet the requirements of a project. Project management is accomplished through the proper application and integration of 47 logically grouped project management processes grouped into 5 process groups.
These 5 process groups are as follows:
Initiation,
Planning,
Execution,
Monitoring and control,
· Closing.
Project constraints:
· quality,
· timetable,
Budget,
Resources,
Due to a possible change, the development of a project management plan is iterative and goes through sequential refinement at various stages of the project life cycle. Sequential refinement allows the project management team to define the scope of work and manage it at a more granular level as the project progresses.
Program- a set of related projects, subprograms and program activities, the management of which is coordinated to obtain benefits that would not be available if they were managed separately. Programs may contain elements of work related to them, but outside the scope of individual projects of the program. The project may or may not be part of the program, but the program always contains projects.
Program management- the application of knowledge, skills, tools and techniques to the program to meet the requirements of the program and to obtain benefits and control that would not be available when managing projects in isolation.
Projects within the program are linked through a common end result or shared opportunity. If the link between projects is only a common client, vendor, technology, or resource, the effort should be managed as a portfolio of projects, not a program.
Program management focuses on project interdependencies and helps determine the best approach to managing them.
As an example of a program, we can cite a new satellite communication system with projects for the design of a satellite and satellite ground stations, for the construction of each of them, for the integration of the system and for the launch of the satellite.
Briefcase is a set of projects, programs, sub-portfolios and elements of operations, managed as a group in order to achieve strategic goals. Programs are grouped within a portfolio and consist of subroutines, projects, and other activities managed in a coordinated manner to support the portfolio. Individual projects that are either inside or outside the program are equally considered part of the portfolio. While projects or portfolio programs are not necessarily interdependent or directly related, they are linked to the organization's strategic plan through the organization's portfolio.
Portfolio management- centralized management of one or several portfolios to achieve strategic goals. Portfolio management focuses on providing analysis of projects and programs in order to prioritize resource allocation and align and align portfolio management with organizational strategies.
Project Management Office (PMO)- an organizational structure that standardizes project management processes and facilitates the exchange of resources, methodologies, tools and techniques. The PMO's responsibilities can range from providing project management support to direct management of one or more projects.
There are several types of PMO structures in organizations, each of which differs in the degree of control and influence exerted on projects within the organization, namely:
· Supportive... Supportive PMOs play an advisory role by providing templates, best practices, training, access to information and lessons learned from other projects. This type of PMO serves as a repository for the project. The degree of control from the PMO is low.
· Supervising... Controlling PMOs provide support and require compliance through a variety of means. Compliance may involve the adaptation of project management structures or methodologies, the use of specific templates, forms and tools, or compliance with management requirements. The degree of control from the PMO is medium.
· Governing... Management PMOs control projects by direct management of these projects. The degree of control from the PMO is high.
The main function of the PMO is to support project managers in a variety of ways, which may include, but are not limited to:
· Management of the common resources of all projects administered by the PMO;
· Definition and development of methodology, best practices and standards for project management;
· Coaching, mentoring, training and supervision;
· Monitoring compliance with project management standards, policies, procedures and templates through project audits;
· Development and management of policies, procedures, project templates and other general documentation (assets of the organization's processes);
· Coordination of communications between projects.
Project managers and PMOs have different goals and are thus driven by different requirements. All of their actions are aligned with the strategic interests of the organization. The difference between the role of a project manager and a PMO can be as follows:
· The project manager focuses on the specific objectives of the project, while the PMO manages major changes to the program content and can see these as potential opportunities for better achievement of the business objectives.
· The project manager monitors the resources allocated to the project in order to more accurately meet the project goals, and the PMO optimizes the use of the organization's total resources in all projects.
· The project manager manages the constraints (scope, schedule, cost and quality, etc.) of individual projects, and the PMO manages the methodologies, standards, overall risks / opportunities, metrics and interdependencies of projects at the enterprise level.
Operating activities is an ongoing activity that produces repeatable results, with resources allocated to perform nearly the same set of tasks in accordance with the standards embedded in the product lifecycle. Unlike operating activities, which are of an ongoing nature, projects are temporary undertakings.
Operations management is the supervision, direction and control of business operations. Operations are used to support day-to-day operations and are necessary to achieve the strategic and tactical objectives of the organization. Examples include manufacturing operations, manufacturing operations, accounting operations, software support, and maintenance.
Business value- a concept that is unique to each organization. Business value is defined as the total value of an organization, the sum of all tangible and intangible elements. Examples of tangible elements are monetary assets, fixed assets, equity and communications. Examples of intangibles include reputation, brand awareness, public good, and trade marks. Depending on the organization, the content of business value can be short-, medium- and long-term. Value can be created by effectively managing day-to-day operations. However, through the effective application of the disciplines of project, program, and portfolio management, organizations gain the ability to apply robust, established processes to achieve strategic objectives and derive more business value from their project investments.
Project Manager- a person designated by the executing organization to lead the team and who is responsible for achieving the objectives of the project.
The role of a project manager is different from that of a functional or operational leader. Typically, the functional leader is focused on providing oversight of the functional or business unit, while operations leaders are responsible for ensuring the effectiveness of business operations.
RP competencies:
· Knowledge Competencies- what the manager knows about project management.
· Execution competencies- what the project manager is able to do or achieve by applying his knowledge of project management.
· Personal competencies- how the project manager behaves during the execution of the project or related activities. Personal performance encompasses attitudes, core personality traits, and leadership qualities — the ability to lead a project team in achieving project goals and balancing project constraints.
RP skills:
Leadership,
Strengthening by the team,
Motivation,
Communication,
· influence,
· making decisions,
Political and cultural awareness,
· negotiation,
Building trusting relationships,
Settlement of conflicts,
· Coaching.
2. THE INFLUENCE OF THE ORGANIZATION AND THE LIFE CYCLE OF THE PROJECT
Organizational process assets are plans, processes, policies, procedures and knowledge bases specific to and used by the performing organization. They include any artifacts, techniques, and knowledge of some or all of the organizations involved in the project that can be used to execute or guide the project. In addition, process assets include the organization's knowledge bases such as lessons learned and historical information. Organizational process assets can include completed schedules, risk data, and earned value data. Organizational process assets are inputs to most planning processes. Throughout the project, team members can update and supplement the organization's process assets as needed. Organizational process assets can be broken down into two categories:
Processes and procedures
Corporate knowledge base
Enterprise environmental factors vary widely in type or nature. Enterprise environmental factors include, but are not limited to:
· Organizational culture, structure and leadership;
· Geographical distribution of equipment and resources;
· Government and industry standards (for example, regulations of regulatory authorities, codes of conduct, product standards, quality standards, manufacturing standards);
· Infrastructure (eg existing facilities and major equipment);
Human resources available (eg skills, knowledge, specializations such as design, development, legal, contracting and procurement);
HR management (for example, hiring and firing guidelines, performance and performance reviews and personnel training records, remuneration and overtime policies, and time tracking);
· Market situation;
· Risk tolerance of stakeholders;
· Political climate;
· Channels of communication adopted in the organization;
· Commercial databases (eg standardized estimates, industrial risk studies and risk databases);
· A project management information system (for example, automated systems such as schedule management software, configuration management systems, information collection and distribution systems, or web interfaces to other online automated systems).
Project team members fulfill the following roles:
· Personnel in charge of project management. Team members performing project management activities such as scheduling, budgeting, reporting and control, communications, risk management, and administrative support. This function can be performed or supported by a project management office (PMO).
· Project staff. The team members who do the work to create the deliverables for the project.
· Supporting experts... Supporting experts take the steps necessary to develop or execute a project management plan. This can include contracting, financial management, logistics, legal support, security, development, testing, or quality control. Depending on the size of the project and the level of support needed, supporting experts may work full-time or simply participate in a team when their specific skills are required.
· User or customer representatives... The members of the organization who will accept the deliverables or products of the project may act as representatives or intermediaries to ensure proper coordination, advice on requirements, or to confirm the acceptability of the project's outputs.
· Sellers... Vendors, also called agents, suppliers, or contractors, are third-party companies that are contracted to provide components or services required for a project. The project team is often responsible for overseeing the implementation and acceptance of deliverables or vendor services. If vendors carry a significant amount of risk in delivering project deliverables, they can play an important role in the project team.
· Members of business partner organizations. Members of business partner organizations can be assigned to the project team to ensure proper coordination.
· Business partners. Business partners are also third-party companies, but they have a special relationship with the enterprise, sometimes acquired through a certification process. Business partners provide specialized expert assistance or play a designated role, such as installation, customization, training, or support.
Project life cycle- a set of phases through which the project passes from the moment of its initiation to the moment of closure.
All projects can have the following life cycle structure:
· Start of the project;
· Organization and preparation;
· Execution of project works;
· Completion of the project.
Project phase- a set of logically related project operations, ending with the achievement of one or a number of deliverables.
Predictive life cycles(also known as fully plan-driven) - A type of project life cycle in which the scope of the project, as well as the time and cost required to complete the content, are determined at the earliest possible stage of the life cycle.
Iterative and incremental lifecycles are lifecycles in which project phases (also called iterations) intentionally repeat one or more project activities as the project team gains a better understanding of the product. Iterativeness defines product development by performing a series of repetitive cycles, while incrementality defines the sequential build-up of product functionality. During these life cycles, the product is developed both iteratively and incrementally.
Responsive lifecycles(also known as change-driven or agile methods) are designed to respond to high levels of change and require a high level of ongoing stakeholder engagement. Adaptive methods are also iterative and incremental, but they differ in that iterations are very fast (typically 2–4 weeks in duration) and are fixed in terms of time and cost. In responsive projects, multiple processes typically run during each iteration, although early iterations may focus more on scheduling operations. The overall content of a project is broken down into a set of requirements, and the work that needs to be done is sometimes referred to as a backlog (requirements log). At the beginning of an iteration, the command determines how many high-priority items from the backlog can be retrieved during the next iteration. At the end of each iteration, the product must be ready for customer analysis.
3. PROJECT MANAGEMENT PROCESSES
Project management is the application of knowledge, skills, tools and methods to the work of a project to meet the requirements of a project. This knowledge application requires effective management of project management processes.
Process is a set of interrelated actions and operations carried out to create a predetermined product, service or result. Each process is characterized by its inputs, the tools and methods that can be applied, and the resulting outputs.
Project processes can be divided into two main categories:
· Project management processes... These processes ensure the effective execution of a project throughout its life cycle. These processes encompass tools and techniques related to the application of the skills and capabilities described in the areas of expertise.
· Product-oriented processes. These processes define and create a project product. Product-oriented processes are usually determined by the project life cycle and differ depending on the application area as well as the phase of the product life cycle. The content of a project cannot be defined without some basic understanding of how to create a given product. For example, when determining the total complexity of a building to be constructed, a variety of building technologies and tools should be considered.
Project management processes fall into five categories, known as project management process groups (or process groups):
· Initiation process group. Processes performed to define a new project or a new phase of an existing project by obtaining authorization to start a project or phase.
· Group of planning processes. The processes required to establish the scope of work, clarify objectives, and determine the course of action required to achieve the objectives of the project.
· Execution process group... The processes used to carry out the activities specified in the project management plan to meet project specifications.
· Monitoring and control process group... Processes required to track, analyze, and regulate project execution; identifying areas requiring changes to the plan; and initiating appropriate changes.
· Closing process group... Processes performed to complete all activities across all process groups in order to formally close a project or phase.
Process groups are not phases of the project life cycle!
As part of the project life cycle, a significant amount of data and information is collected, analyzed, transformed and disseminated in various formats to project team members and other stakeholders. Project data is collected as a result of various execution processes and is then shared with the project team members.
The following guidelines minimize confusion and help the project team use proper terminology:
· Work performance data. Raw observations and measurements identified during operations undertaken to complete project work. Examples include percentages of physically completed work, quality and performance metrics, start and finish dates for schedule activities, number of change requests, number of defects, actual cost, actual duration, and so on.
· Information about the performance of work. Performance data collected through various control processes, analyzed in context and summarized based on links in different areas. Examples of performance information include the status of deliverables, the implementation status of change requests, and the assessment of projections to completion.
· Work performance reports. A physical or electronic representation of performance information, collected in project documents, designed to make decisions or formulate problems, take action, or generate awareness. Examples include status reports, service memos, justifications, newsletters, electronic dashboards, recommendations, and updates.
The 47 project management processes described in the PMBOK Guide are broken down into 10 distinct knowledge areas. An area of expertise is a comprehensive system of concepts, terms, and activities that make up a professional area, project management area, or area of activity. These 10 Knowledge Areas are used almost consistently in most projects. Project teams should use these 10 Knowledge Zones and other Knowledge Zones as needed for their specific project. Areas of expertise include:
Project integration management,
Project content management,
Project time management,
Project cost management,
Project quality management,
Project human resource management,
Project communications management,
Project risk management,
Project procurement management,
· Management of project stakeholders.
4. PROJECT INTEGRATION MANAGEMENT
Project Integration Management includes the processes and activities required to define, refine, combine, combine, and coordinate various project management processes and activities within project management process groups.
The project charter contains:
· Designation or justification of the project;
· Measurable project objectives and associated success criteria;
· High-level requirements;
· Assumptions and limitations;
· High-level description and boundaries of the project;
· High-level risks;
· Enlarged schedule of control events;
· Consolidated budget;
· List of interested parties;
· Requirements for project approval (ie what constitutes the success of the project, who decides that the project was successful, and who signs the project);
· Designated project leader, area of responsibility and level of authority;
· FULL NAME. and the powers of the sponsor or other person (s) authorizing (s) the project charter.
Description of work The (statement of work, SOW) of a project is a verbal description of the products, services or results that the project must produce.
SOW reflects:
· Business need. An organization's business need may be based on market demand, technological progress, legal requirements, government regulations, or environmental considerations. Typically the business need and cost-benefit comparison are included in the business case to justify the project.
· Description of the content of the product. The product content description includes the characteristics of the product, service, or deliverable for which the project is undertaken. The description should also reflect the relationship between the product, service, or output being created and the business need that the project must satisfy.
· Strategic plan. The strategic plan includes the strategic vision, goals and objectives of the organization, and a high-level mission statement. All projects must be consistent with the strategic plan of the organization. Consistency with the strategic plan allows each project to contribute to the overall goals of the organization.
Business case
A business case or similar document provides the necessary information from a business perspective to determine if a project is worth the investment required. It is usually used by project managers to make decisions. Typically, a business case contains a business need and a cost-benefit comparison to justify the project and define its boundaries, and usually the business analyst performs this analysis using a variety of information from stakeholders. The sponsor must agree on the content and limitations of the business case. A business case is created as a result of one or more of the following factors:
· Market demand (for example, an auto maker will authorize a project to make more fuel efficient vehicles in response to a shortage of gasoline);
The need of the organization (for example, due to high overhead costs, the company can combine personnel functions and optimize processes to reduce costs);
· The customer's requirement (for example, the electric company authorizes the project for the construction of a new substation to supply power to a new industrial area);
· Technological progress (for example, an airline will authorize a new project to develop electronic tickets to replace paper tickets based on technological advances);
· A legal requirement (for example, a paint manufacturer will authorize a project to develop guidelines for the handling of toxic materials);
· Environmental impacts (for example, a company will authorize a project to reduce its environmental impact);
· Social need (for example, a nongovernmental organization in a developing country will authorize a project to provide drinking water supplies, toilets and health education to communities suffering from high incidence of cholera).
Agreements
Agreements are used to define the initial intent for a project. Agreements can take the form of a contract, memorandum of understanding, service level agreement, letter of agreement, letter of intent, oral agreement, email, or other written agreement. Typically, a contract is used if the project is carried out for an external customer.
Enterprise environmental factors
Enterprise environmental factors that can influence the process of developing a project charter include, but are not limited to:
· Government and industry standards or regulations (for example, codes of conduct, quality standards or standards for the protection of workers);
· Organizational culture and structure;
· Market situation.
Organizational process assets
Organizational process assets that can influence the process for developing a project charter include, but are not limited to:
· Standard organizational processes, policies and process descriptions;
· Templates (for example, a project charter template);
· Historical information and knowledge base (for example, projects, records and documents, all information and documentation on project closure, information on the results of decisions on the selection of previous projects along with information on the performance of previous projects, as well as information on risk management operations).
Project management plan is a document describing how the project will be executed, how it will be monitored and controlled. It integrates and consolidates all sub-plans and baselines resulting from planning processes.
Project baselines include, among others:
· Basic plan for the content;
· Basic schedule;
· Cost baseline.
Ancillary plans include, but are not limited to:
· Content management plan;
· Requirements management plan;
· A schedule management plan;
· Cost management plan;
· Quality management plan;
· Process improvement plan;
· Plan of human resource management;
· Communications management plan;
· Risk management plan;
· Procurement management plan;
· A stakeholder management plan.
Among other things, a project management plan may also include the following:
· The life cycle chosen for the project and the processes that will be applied in each phase;
Details of onboarding decisions made by the project management team, namely:
o project management processes selected by the project management team;
o level of implementation of each selected process;
o descriptions of tools and methods that will be used to carry out these processes;
o a description of how the selected processes are used to manage a specific project, including the dependencies and interactions between these processes, as well as the necessary inputs and outputs.
· The procedure for performing work to achieve the goals of the project;
· A change management plan documenting how changes are monitored and controlled;
· A configuration management plan documenting how configuration management is performed;
· A description of how to maintain the integrity of baselines;
· Requirements and methods of communication between interested parties;
· Key management review activities in terms of content, boundaries and timelines to address existing issues and pending solutions.
Schedule Predictions
Schedule forecasts are based on progress against the baseline schedule and the estimated forecast time to completion (PRT). They are usually expressed in the form of a variance in terms of time (OCP) and an index of the fulfillment of time (TDI). For projects that do not use earned value management, deviations from planned and projected finish dates are reported.
You can use the forecast to determine if a project is within the acceptable range and to identify required change requests.
Cost projections
Cost projections are based on progress against the cost baseline and the estimated projection to completion (PDP). They are usually expressed in terms of cost variance (OST) and value performance index (VCI). The forecast on completion (PF) can be compared with the budget on completion (BOP) to determine if the project is within the range or if a change request is required. For projects that do not use earned value management, deviations from planned and actual costs are shown, as well as projected final costs.
The following are some of the configuration management activities involved in the integrated change control process:
· Configuration definition. Define and select configuration items to provide a framework from which product configuration is defined and validated, products and documents are tagged, change management is performed, and accounting is maintained.
· Configuration status reporting. If it is necessary to provide the appropriate data about the configuration item, the information is documented and reported. Such information includes a list of approved identified configuration items, the status of the proposed configuration changes, and the implementation status of the approved changes.
· Confirmation and audit of configuration. Confirmation and configuration audits ensure that the structure of the configuration items for a project is correct and that appropriate changes are recorded, evaluated, approved, tracked, and properly implemented. This ensures that the functional requirements defined in the configuration documentation are met.
5. PROJECT CONTENT MANAGEMENT
Project Scope Management includes the processes required to ensure that the project contains all and only the work required to successfully complete the project. Project Scope Management is directly related to defining and controlling what is included and what is not included in the project.
In the context of a project, the term “content” can mean:
Classes of requirements:
· Business requirements that describe the high-level needs of the organization as a whole, such as problems or opportunities for the organization, and the reasons why the project was undertaken.
· Stakeholder requirements that describe the needs of a stakeholder or stakeholder group.
· Solution requirements that describe the properties, functions and characteristics of a product, service, or outcome that will satisfy the business and stakeholder requirements. Solution requirements, in turn, are grouped into functional and non-functional requirements:
o Functional requirements describe the behavior of a product. Examples include processes, data, and product interactions.
o Non-functional requirements complement functional requirements and describe the environmental conditions or qualities required to ensure the effectiveness of the product. Examples include: reliability, security, performance, security, service level, maintainability, retention / destruction requirements, etc.
· Transition requirements describe the temporal capabilities, such as data transformation and training requirements, required to transition from the current state as is to the state as it should be in the future.
· Requirements for a project describe the activities, processes, or other conditions that the project must meet.
· Quality requirements, which include any condition or criterion necessary to demonstrate the successful delivery of the deliverable project deliverable or other project requirements.
6. PROJECT TIME MANAGEMENT
Project time management includes the processes required to ensure that a project is completed on time.
Operation dependency types:
· Finish start(finish-start, FS). A logical relationship in which the start of a subsequent operation depends on the finish of the previous operation. Example: The awards ceremony (follow-up operation) cannot start until the race is over (the preceding operation).
· Finish-finish(finish-finish, FF). A logical relationship in which the finish of a subsequent operation depends on the finish of the previous operation. Example: the creation of a document (previous operation) must be completed before the completion of its editing (subsequent operation).
· Start-start(start-start, SS). A logical connection in which the start of the subsequent operation depends on the start of the previous operation. Example: The leveling of a concrete surface (subsequent operation) cannot start before the foundation is poured (prior operation).
· Start-finish(start-finish, SF). A logical connection in which the finish of the subsequent operation depends on the start of the previous operation. Example: the first change of guard (subsequent operation) cannot be completed until the second change of guard (previous operation) starts.
Three-point estimate
The accuracy of single point duration estimates can be improved by considering estimation uncertainties and risks. This concept derives from the program evaluation and review technique (PERT). PERT uses three estimates to determine an approximate range of duration for an operation:
· Most likely(tM). The duration of an operation is determined taking into account the preliminary allocation of resources, their performance, a realistic assessment of their availability to perform this operation, dependencies on other participants, and also taking into account interruptions in work.
· Optimistic(tO). The duration of the operation is based on the analysis of the most favorable scenario for the operation.
· Pessimistic(tP). The duration of the operation is based on an analysis of the worst-case scenario for the operation.
Depending on the expected distribution of values in a range of three estimates, the expected duration, tE, is calculated using the formula. The two most common formulas are triangular distribution and beta distribution.
· Triangular distribution. tE = (tO + tM + tP) / 3
· Beta distribution (from the traditional PERT method). tE = (tO + 4tM + tP) / 6
Critical path method
Critical path method- the method used to estimate the minimum project duration and determine the degree of scheduling flexibility on logical paths in the network within the scheduling model. The scheduling network analysis method allows calculating the early start and finish dates, as well as the late start and finish dates for all operations without taking into account resource constraints by analyzing the forward and backward pass through the project network, as shown in Fig. 6-18. In this example, the longest path includes steps A, C, and D, and therefore the sequence A-C-D is the critical path. A critical path is a sequence of activities that is the longest path in the project schedule and defines the shortest possible project duration. The resulting early start and finish dates are not necessarily the project schedule; rather, they indicate the periods of time within which an operation can be performed using parameters entered into the schedule model associated with the duration of operations, logical relationships, leads, lags, and other known constraints. Method of critical
path is used to calculate the degree of scheduling flexibility on logical paths in the network within the scheduling model.
Critical chain method
Critical chain method(CCM) is a scheduling technique that allows the project team to place buffers along any path in the schedule to accommodate resource constraints and project uncertainties. It is developed from the critical path method and takes into account the impacts of allocation, optimization, resource leveling, and
uncertainty about the duration of the operation on the critical path determined by the critical path method. The critical chain method includes the concepts of buffers and buffer management. The critical chain method uses operations whose duration does not include safety margins, logical connections, and resource availability with
statistically defined buffers, including the cumulative safety margins of operations at specific points in the project along the project schedule to account for resource constraints and project uncertainties. A resource-constrained critical path is known as a critical chain.
7. PROJECT COST MANAGEMENT
Project cost management includes the processes required for planning, evaluating, budgeting, fundraising, financing, managing and controlling costs to ensure that the project is delivered within the approved budget.
Earned value management
Earned value management(EVM) is a methodology that combines content, schedule, and resource assessments to measure project progress and achieved performance. It is a widely used method of measuring project performance. It combines the Scope Baseline with the Cost Baseline as well as the Project Baseline to form an Execution Baseline that enables the project management team to assess and measure project performance and progress. It is a project management method that requires an integrated baseline against which performance can be measured throughout the project. EVM principles can be applied to
all projects in any industry. The EVM is used to develop and monitor the following three KPIs for each work package and master account:
· Planned volume. Planned Scope (PA) - the authorized budget allocated for the planned work. This is an authorized budget allocated for work to be performed within an activity or work breakdown component, excluding the management reserve. This budget is spread over phases in the life cycle of the project, but at some point the planned amount determines the physical work that had to be done. The cumulative software is sometimes called the performance measurement baseline (PMB). The total planned scope of the project is also known as the budget on completion (BOB).
· Developed volume... The earned value (GA) is the amount of work performed, expressed in terms of the authorized budget allocated for the work. This is the budget associated with the authorized work that has been completed. The measured TOE must be associated with the PMB and the measured TOE cannot exceed the authorized software budget for that component. OO is often used to calculate the percentage of completion of a project. For each component of the WBS, criteria should be established to measure the progress of the work performed. Project managers monitor the TOE, both incrementally to determine the current status and cumulatively to determine long-term performance trends.
· Actual cost. Actual cost (FS) - actually incurred costs of performing work within the operation for a certain period of time. These are the total costs incurred in performing the work as measured by the TOE. By definition, the FS should correspond to what was laid down in the software and measured by the TOE (for example, only direct costs of working time, only direct costs, or all costs, including indirect ones). FS has no upper bound; everything that is expended to achieve OO is measured.
Deviations from the approved baseline are also monitored:
· Timing deviation... Timing Deviation (OCP) is an indicator of schedule fulfillment expressed as the difference between earned value and planned volume. The amount of time that the project is behind or ahead of the planned delivery date at a given point in time. It is a measurement of project schedule execution. Its value is equal to the earned volume (OO) minus the planned volume (PO). Timing Deviation in EVM is a useful metric in that it demonstrates when a project is behind or ahead of its baseline. The timing variance in the EVM will ultimately be zero at the end of the project, as all targets must be met by then. Timing variance is best used in conjunction with critical path method (CPM) scheduling and risk management. Formula: OCP = OO - PO
· Cost variance... Value Variance (VVC) - The sum of the budget deficit or surplus at a given point in time, expressed as the difference between the earned value and the actual value. It is a measure of the cost effectiveness of a project. It is equal to the earned value (GA) minus the actual cost (FC). The variance in cost at the end of the project will be equal to the difference between the budget on completion (BOP) and the amount actually spent. OST is extremely important as it demonstrates the relationship between physical performance and funds expended. A negative OST is often not recoverable for the project. Formula: OST = OO - FS.
The OCP and OST values can be converted to performance indicators to reflect the cost and timeframe of any project versus all other projects or within a portfolio of projects. Deviations are useful for determining the status of a project.
· Deadline Fulfillment Index... Deadline Fulfillment Index (TDI) is an indicator of the effectiveness of the schedule, expressed as the ratio of earned value to planned volume. It measures how effectively the project team uses its time. It is sometimes used in conjunction with the Cost Performance Index (CWI) to predict the final estimates of project completion. A PWM value of less than 1.0 indicates that less work has been completed than planned. A PWM value greater than 1.0 indicates that more work has been completed than planned. Since the IVSR measures all the work of a project, it is also necessary to analyze the performance on the critical path to determine if the project will be completed before or after its planned finish date. IVSR is equal to the ratio of OO to PO. Formula: IVSR = OO / PO
· Cost fulfillment index. Value fulfillment index (IVST) is an indicator of the efficiency of resources included in the budget, in terms of cost, expressed as the ratio of earned value to actual cost. It is considered the most important EVM metric and measures the cost effectiveness of the work performed. A TRI value less than 1.0 indicates cost overruns for the work performed. A TRI value greater than 1.0 indicates that funds are underpaid when executed on a specific date. IVSR is equal to the ratio of the OO to the FS. Indexes are useful for determining the status of a project and also provide a basis for assessing the final time frame and cost of a project. Formula: IVST = OO / FS
The three indicators of target volume, earned value and actual value can be monitored and reported periodically (usually weekly or monthly) or cumulatively.
Forecasting
As the project progresses, the project team may develop a forecast at completion (BPF), which may differ from the budget at completion (BPF), based on project performance. If it becomes clear that the BPZ is no longer realistic, the project manager should consider the BPZ. The development of the PPP includes forecasting conditions and events that will arise in the future of the project, based on information about the current performance and other knowledge available at the time of forecasting. Forecasts are generated, updated and reissued based on
data on the performance of work, received as the project progresses. Work performance information covers the past performance of the project and any information that may have an impact on the project in the future.
The LOI is usually calculated as the actual cost accounted for for the work completed, plus the forecast to completion (TOR) of the remaining work. The project team is charged with the responsibility to predict what it may face during the implementation of the PDS, based on the current experience. The EVM method works well in conjunction with manually generated predictions of required LFR. The most widely used approach to forecasting LTP is manual bottom-up summation by the project manager and project team.
The bottom-up PPR method used by the project manager is based on actual cost and experience gained from the work performed, and requires a new forecast to be generated before completion for the remaining project work. Formula: PPZ = FS + PDZ “from bottom to top”.
The PPR, manually developed by the project manager, is quickly matched against a number of calculated PPRs representing a variety of risk scenarios. When calculating PPZ values, as a rule, cumulative values of IVST and IVSR are used. Although EVM data can provide a variety of statistical PPVs quickly, only the three most common methods are described below:
· PPZ for PDZ works performed at the rates set in the budget. This LAR method uses the actual performance of the project on a specific date (favorable or unfavorable), represented by the actual cost, and predicts that all future LAR work will be completed at the budgeted rates. Where actual performance is unfavorable, an assumption that future performance will improve should only be made if supported by a project risk analysis. Formula: PPZ = FS + (BPZ - OO)
· PPZ for PDZ works performed with the current IVST. This method assumes that the project will continue in the future just as it has proceeded up to this point. It is assumed that the PDZ work will be performed at the same level of the cumulative index of cost performance (CWI), which has been achieved in the project at this point. Formula: PPZ = BPZ / IVST
· PPZ for PDZ works, taking into account both factors IVSR and IVST. In this forecast, the work of the PDZ will be carried out with efficiency, which takes into account the indices of the implementation of both cost and timing. This method is most useful when the project schedule is one of the factors influencing the LRP. Variations of this method consider IVST and IVSR in different proportions (for example, 80/20, 50/50 or other proportions), in accordance with the opinion of the project manager. Formula: PPZ = FS + [(BPZ - OO) / (IVST x IVSR)]
Each of these approaches can be applied to any specific project and provide an “early warning” signal to the project management team if the PPR goes beyond the accepted acceptable variation.
Productivity to Completion Index (CPI)
Performance index to completion(IPDI) - a calculated indicator of the efficiency of the project in terms of cost, which must be achieved with the remaining resources in order to achieve the established management indicator, expressed as the ratio of the cost of performing the remaining part of the work to the remaining budget. The CPI is a computed index of value fulfillment that must be provided for the remaining jobs to achieve a specific management goal, such as a BPI or a PPI. If it becomes clear that the BPZ is no longer realistic, the project manager should consider the BPZ. Once approved, the LPR can replace the BPR in the calculation of the LPR. Formula for BPZ-based SPDI: (BPZ - RO) / (BPZ - FS). The HITS is conceptually presented in the figure below. The formula for the SPR is shown in the lower left corner - work remaining (defined as BPZ minus OO) divided by the remaining funds (which can be calculated as either BPZ minus FS, or as LPR minus FS).
If the cumulative TRI is below the baseline (as shown in the figure below), all future project work must immediately be carried out in accordance with the IPR (BPZ) (as reflected in the top line of the figure below) in order to remain within the authorized BPR. Whether a given level of performance is attainable is judged based on a number of considerations, including risk, schedule, and technical performance. This level of performance is depicted as an EIT line (LRP). Formula for PPI based on PPV: (PPV - RO) / (PPV - FS). The EVM formulas are presented in the table below.
Execution analysis
Performance analysis compares cost performance over time, schedule activities or work packages that have budget overruns or undershoots, and estimates of the money required to complete the work in progress. If EVM is used, the following information is determined:
· Analysis of variances. Deviation analysis when used in EVM is an explanation (cause, impact and corrective actions) of deviations for cost (OST = OO - FS), schedule (OCP = OO - OO) and variance on completion (OOF = OO - OO). The most frequently analyzed deviations in terms of cost and timing. For projects that do not use earned value management, a similar variance analysis can be performed by comparing the planned cost of the transaction with the actual cost of the transaction to determine the cost deviation of the actual project from the baseline. Further analysis can be performed to determine the cause and extent of the deviation from the baseline schedule and necessary corrective actions or preventive actions. Measurements of cost fulfillment are used to estimate the amount of deviation from the original baseline in terms of cost. Important aspects of project cost management include determining the cause and extent of deviation from the cost baseline and deciding whether corrective action or preventive action is needed. As more work is done, the percentage tolerance range will tend to decrease.
· Analysis of trends. Trend analysis involves examining project performance data over time to determine whether project performance is improving or deteriorating. Graphical analysis techniques are valuable for understanding performance as of a specific date and for comparing with future performance targets in the form of BIP versus LF and in the form of completion dates.
· Earned value execution... Earned value execution involves comparing the baseline execution plan with actual time and cost delivery. If no EVM is used, a cost baseline analysis is used to compare cost performance against the actual cost of work performed.
8. PROJECT QUALITY MANAGEMENT
Project quality management includes the processes and activities of the performing organization that define the quality policies, objectives and responsibilities so that the project meets the needs for which it was undertaken. Project quality management uses policies and procedures to implement the organization's quality management system in the context of the project and, where necessary, supports actions to continually improve the processes being undertaken by the performing organization. Project quality management seeks to ensure that project requirements, including product requirements, are met and verified.
Quality and grade are conceptually different concepts. Quality, as a delivered output or result, is “the degree to which a set of inherent characteristics meet the requirements” (ISO 9000). A grade as a design intent is a category assigned to deliverables that have the same functionality but different technical characteristics. The project manager and the project management team are responsible for reaching the tradeoffs for achieving the required levels of both quality and grade. A quality level that does not meet quality requirements is always a problem, and a low grade may not be a problem.
In the context of achieving ISO compliance, modern approaches to quality management strive to minimize variances and achieve results that meet specific requirements. These approaches recognize the importance of the following points:
· Customer satisfaction. Understanding, evaluating, defining and managing customer requirements to meet customer expectations. This requires a combination of compliance (the project must produce what it was undertaken for) and usability (the product or service must meet real needs).
· Prevention is more important than inspections... Quality should be planned, designed and built in, and not inspected when managing a project or delivering deliverable project deliverables. The cost of preventing errors is generally significantly lower than the cost of correcting them once discovered through inspection or in use.
· Continuous improvement. The plan-do-check-act (PDCA) cycle — the model described by Shewhart and refined by Deming — is the basis for quality improvement. In addition, quality improvement initiatives such as Total Quality Management (TQM), Six Sigma, and the combined application of Six Sigma and Lean Six Sigma can improve project management and also the quality of the product of the project. Process improvement models include the Malcolm Baldridge Quality Model, the Organizational Project Management Maturity Model (OPM3®), and the Capability Maturity Model Integrated (CMMI®) model.
· Management responsibility. Success requires the involvement of all members of the project team. However, management retains, under its responsibility for quality, an appropriate responsibility for providing the right resources in the right amount.
· Quality cost(cost of quality, COQ). The quality cost is the total cost of compliance work and non-compliance work that must be done as a compensatory effort, since the first time that work is attempted, there is the potential for some of the work to be done or was not done correctly. ... Quality assurance costs can be incurred throughout the life cycle of the deliverable. For example, decisions made by the project team can affect the operational costs associated with using the delivered deliverable. Post-project quality assurance costs may arise from product returns, warranty claims, and product recall campaigns. Thus, due to the time nature of the project and the potential benefit that can be derived from lower post-project quality costs, sponsoring organizations may decide to invest in product quality improvements. These investments are typically made in the area of compliance work with the aim of preventing defects or reducing the cost of defects by inspecting non-conforming items. Moreover, issues related to post-project COQ should be addressed in the program management and portfolio management process, for example, project, program and portfolio management offices should apply appropriate analysis methods, templates and ways of allocating funds for this purpose.
Seven Essential Quality Tools
The seven core quality tools, also known in the industry as 7QC tools, are used in the context of the PDCA cycle to address quality problems. Rice. below is a conceptual illustration of seven basic quality tools, which include:
· Causal Diagrams, also called fish skeleton diagrams or Ishikawa diagrams. The description of the problem, located in the head of the fishbone, is used as a starting point for tracing the source of the problem to the root cause that requires action. A problem description is usually a statement of the problem as a deficiency that needs to be addressed or a goal that needs to be achieved. The search for causes is carried out by examining the description of the problem and looking for answers to the question "why" until the root cause is identified that requires action, or until all reasonable possibilities on each part of the fish skeleton have been exhausted. Fishbone diagrams are often useful when looking for the relationship of unwanted effects seen as a specific variation with an established reason for which project teams should take corrective actions to eliminate that specific variation found on a control chart.
· Block diagrams, also called process maps, as they represent the sequence of steps and branching possibilities of a process that transforms one or more inputs into one or more outputs. Flowcharts represent operations, decision points, loops, parallel paths, and process flow by mapping the operational details of procedures that exist within the horizontal value chain of the SIPOC model. Flowcharts can be helpful in understanding and evaluating the cost of quality within a process. This is accomplished by using workflow fanout logic and associated relative frequencies to estimate the expected monetary value of the compliance and noncompliance work required to provide a compliant output.
· Data collection sheets, also known as tally sheets, can be used as checklists when collecting data. Data collection sheets are used to organize facts in a way that will efficiently collect useful data about a potential quality issue. They are especially useful for collecting performance data during inspections to identify defects. For example, data on the incidence or impact of defects collected using data collection worksheets is often displayed using Pareto charts.
· Pareto charts are specially shaped vertical bar charts and are used to identify a few of the most important sources causing most of the effects of a problem. The categories shown on the horizontal axis represent the existing probability distribution, accounting for 100% of possible observations. The corresponding frequency of occurrence of each designated cause shown on the horizontal axis is reduced until it reaches a default source called "other", which is responsible for unidentified causes. Typically, a Pareto chart is organized into categories that measure either frequency of occurrence or impact.
· Histograms is a special type of bar chart used to describe the center of distribution, variance and shape of a statistical distribution. Unlike a control chart, a histogram does not account for the effect of time on the variation that exists within a distribution.
· Control charts are used to determine whether a process is stable or not and whether it exhibits predictable performance. The lower and upper bounds specified by the specification are based on the requirements set out in the agreement. They reflect the maximum and minimum values allowed. Penalties may apply due to values outside the specification limits. The upper and lower control limits differ from the limits specified by the specification. Control limits are established using standard statistical calculations and principles to ultimately determine the natural ability of the process to stabilize. The project manager and relevant stakeholders can use statistically calculated control boundaries to determine the points at which corrective actions will be taken to prevent unnatural performance. The aim of corrective action, as a rule, is to maintain the natural stability of a stable and efficient process. For repetitive processes, control limits are typically ± 3 sigma of the process mean, which was set to 0. A process is considered out of control if: (1) the data point is outside the control limits; (2) seven consecutive points are above the centerline; or (3) seven consecutive points are below the centerline. Control charts can be used to control various types of output variables. While checklists are most commonly used to track the repetitive steps required to produce industrial products, they can also be used to track cost and scheduling variances, volume and frequency of content changes, or other management results, which helps determine if project management processes are under control. ...
· Scatter plots are plotted ordered pairs (X, Y), sometimes called correlation plots because they are used to explain the change in the dependent variable, Y, relative to the change observed in the independent variable, X. The direction of the correlation can be proportional (positive correlation). the opposite (negative correlation), or the correlation model may not exist (zero correlation). If a correlation can be established, a regression line can be determined and used to estimate how a change in the independent variable will change the value of the dependent variable.
Management and quality control tools
The quality assurance process uses the tools and methods of the quality management planning and quality control processes. In addition to this, other available tools include:
· Similarity diagrams... The affinity diagram is similar to the mind mapping technique in that it is used to generate ideas that can be combined to form an orderly way of thinking about a problem. During project management, the creation of a WBS can be improved by using affinity diagrams to provide structure for content decomposition.
· Program flow diagrams(process decision program charts, PDPC). Used to understand the goal in relation to the actions taken to achieve the goal. PDPC is a useful method for planning for potential losses as it helps teams anticipate intermediate steps that might hinder the achievement of a goal.
· Oriented relationship graphs. Adaptation of relationship diagrams. Oriented relationship graphs represent the process of creative problem solving in moderately complex scenarios characterized by intertwined logical connections of up to 50 related elements. A directed relationship graph can be built from data obtained from other tools, such as a similarity diagram, tree diagram, or fishbone diagram.
· Tree diagrams. Also known as systematic diagrams, which can be used to depict the decomposition of hierarchies such as the WBS, the risk breakdown structure (RBS), and the organizational breakdown structure (OBS). In project management, tree diagrams are useful for visualizing parent-child relationships in any decomposition hierarchy that uses a systematic set of rules to define subordination relationships. Tree diagrams can be horizontal (for example, a hierarchical risk structure) or vertical (for example, a team hierarchy or OBS). Because tree diagrams make it possible to create nested branches that end at a single decision point, they are useful as decision trees for determining the expected value of a limited number of relationships that are systematically plotted as a diagram.
· Priority matrices... Used to identify key issues and suitable alternatives to prioritize as a set of solutions for implementation. Criteria are prioritized and weighted before being applied to all available alternatives in order to obtain a mathematical score for ranking all options.
· Operations network diagrams. Formerly known as arrow charts. These include network diagram formats such as activity on arrow (AOA) and the most commonly used activity on node (AON) format. Activity network diagrams are used with project scheduling techniques such as Program Evaluation and Analysis (PERT), Critical Path Method (CPM), and Precedence Diagram (PDM).
· Matrix charts. A quality management and control tool used to analyze data within an organizational structure created in a matrix. A matrix chart seeks to show the strength of the relationships between factors, causes and goals, displayed in a matrix in the form of rows and columns.
9. PROJECT HUMAN RESOURCES MANAGEMENT
Project Human Resource Management includes the processes of organizing, managing, and leading the project team. The project team consists of people who are assigned roles and responsibilities for the implementation of the project. Project team members can have a variety of skill sets, can be full-time or part-time, and can be added or removed from the team as the project progresses. Project team members can also be called project personnel. Although project team members are assigned specific roles and responsibilities, the participation of all team members in project planning and decision making is valuable to the project. Involvement of team members allows them to use their experience in project planning and strengthens the team's focus on achieving project results.
Organization charts and job descriptions
There are various formats for documenting the roles and responsibilities of team members. Most formats are one of three types: hierarchical, matrix, and text. In addition, some project assignments are identified in supporting plans, such as risk, quality, or communications plans. Regardless of which method is used, the goal is always the same - to ensure that for each work package there is a unique person responsible for its implementation and that each team member clearly understands his role and area of responsibility. For example, a hierarchical format can be used to represent high-level roles; a text format is better suited for documenting areas of responsibility in detail.
The human resource management plan includes, among others:
· Roles and responsibilities. When listing the roles and responsibilities required to complete the project, consider the following:
o Role. A feature accepted by or assigned to a project employee. Examples of roles in a project are Civil Engineer, Business Analyst, and Test Coordinator. A clear description of the role in terms of authority, responsibilities and boundaries should be documented.
o Credentials. The right to engage project resources, make decisions, sign approvals, accept deliverables, and influence other team members to complete project work. Examples of decisions that require clear and precise authority include choosing how to proceed, quality acceptance, and how to respond to project deviations. Team members perform best when their level of authority is consistent with their individual area of responsibility.
o Responsibility. The assigned responsibilities and work that a project team member must perform to complete project activities.
o Qualification. The skills and abilities required to carry out assigned activities within the constraints of the project. If the members of the project team do not have the necessary qualifications, then the project can be at risk. When such inconsistencies are identified, preventive action should be taken, such as training, hiring qualified personnel, or adjusting the schedule or project scope accordingly.
· Organization charts of the project. A project organization chart is a graphical representation of the composition of a project team and the accountability relationships among its members. Depending on the requirements of the project, it can be formal or informal, detailed or generalized. For example, a project organization chart for a 3,000-person emergency response team would be significantly more detailed than an internal project organization chart with a 20-person team.
· Staffing plan. The staffing plan is a component of the human resource management plan that describes when and how project team members will be involved and for how long they will be needed. It describes a way to fulfill human resource requirements. Depending on the requirements of the project, the staffing plan can be formal or informal, detailed or generalized. To reflect the ongoing recruiting and development of the project team, this plan is constantly updated during the course of the project. The information contained in the staffing plan differs depending on the application area and the size of the project, but in any case should include the following elements:
o Recruitment of personnel. When planning to recruit members for a project team, a number of questions arise. For example, whether the existing human resources of the organization will be involved or they will be recruited from the outside on a contractual basis; whether team members will work in one place or can they work remotely; what is the cost corresponding to each skill level required for the project; and what level of support the project team can provide for the organization's HR department and functional leaders.
o Resource calendars. Calendars that determine the availability of a specific resource on certain working days and shifts. The staffing plan specifies the timing of the engagement of project team members, both individually and collectively, and the timing of when staffing activities such as recruiting should begin. One tool for graphically displaying human resources is a resource histogram used by a project management team as a means of visually representing or allocating resources to all stakeholders. This chart displays the number of hours an individual, department, or entire project team needs each week or month throughout the project. The chart may include a horizontal line representing the maximum number of hours calculated for a specific resource. If the bars on the chart exceed the maximum available hours, then a resource optimization strategy must be applied, such as allocating additional resources or changing the schedule.
o Personnel release plan. Determining the method and timing of release of team members from project responsibilities is beneficial to both the project and the team members. When team members are released from a project, it eliminates payments to employees who have already completed their share of the project, and thus reduces the cost of the project. The overall morale improves when the smooth transition to new projects is already planned in advance. A staff release plan can also reduce the human resource risks that may arise during implementation or at the end of a project.
o Training needs. If there is concern that the qualifications of the team members assigned to the project may not be sufficient, a training plan should be developed as part of the project plan. The plan may also include training programs for team members that will lead to them obtaining certifications that contribute to the successful completion of the project.
o Recognition and rewards. Clear criteria and a planned reward system help to stimulate and maintain the desired behavior of the people involved in the project. For recognition and rewards to be effective, they must be based on actions and performance and effectiveness under the individual's control. For example, a team member can only be rewarded for meeting a certain cost rate if he or she has sufficient authority to oversee decisions that affect cost. Creating a timed reward plan ensures that the reward is not forgotten. Recognition and reward is part of the development process for the project team.
o Compliance with regulations. The staffing management plan may include strategies to ensure that the project complies with existing government regulations, union contracts, and other established human resource policies.
o Security. The staffing plan as well as the risk register may include policies and procedures to protect team members from accidents.
One model used to describe team development is the Tuckman ladder (Tuckman, 1965; Tuckman & Jensen, 1977), which includes five stages of development that teams must go through. Usually, these stages occur in order, but it is not uncommon for a team to get stuck at a certain stage or return to an earlier stage. In projects where team members have previously worked together, certain stages may be skipped.
· Formation... At this stage, the team gets together and learns about the project and their formal roles and responsibilities in it. Team members in this phase are usually independent from each other and not particularly open.
· Storm. During this stage, the team begins to study the work on the project, technical solutions and approach to project management. If team members are not cooperative and open to different ideas and perspectives, the environment can become unproductive.
· Settlement... During the settlement stage, team members begin to work together and adjust their work habits and behaviors to facilitate teamwork. Team members learn to trust each other.
· Effectiveness... Teams that have reached the performance stage function as a well-organized unit. They are independent and calmly and effectively solve problems.
· Completion... At this stage, the team completes its work and moves on to the next project. This typically occurs when personnel are released from a project after delivery of deliverables or as part of a project or phase closure process.
The duration of each specific stage depends on the dynamics, size and leadership of the team. Project managers need to be well aware of the dynamics of the team's development in order to facilitate the effective passage of team members through all stages.
There are five main methods used to resolve conflicts.
Since each of them has its own purpose and application, the methods are listed in no particular order:
· Evasion / Avoidance. Retreat from an actual or potential conflict situation, postponing the solution to a problem at a later date in order to better prepare for its resolution or transfer its resolution to others.
· Antialiasing / adjusting. Emphasizing points of contact instead of areas of contradiction, abandoning one's position in favor of the needs of others in order to maintain harmony and relationships.
· Compromise / settlement. Search for solutions that will be satisfactory to a certain extent for all parties in order to temporarily or partially resolve the conflict.
· Coercion / Direction. Lobbying someone's point of view at the expense of others, offering only one-win-all-lose solutions, usually from a position of power, to resolve a critical situation.
· Collaboration / problem solving. The unification of multiple points of view and views from different perspectives, the need for a willingness to cooperate and open dialogue, which usually leads to reaching a consensus and maintaining a solution by all parties.
Examples of interpersonal skills The most commonly used by a project manager include:
· Leadership... Strong leadership skills are required for the success of the project. Leadership is essential in all phases of a project's life cycle. There are many leadership theories that define leadership styles that each team should use when appropriate in a given situation. It is especially important to convey to the team members a common vision of the project and inspire them to achieve high efficiency and effectiveness in their work.
· Influence... Because project managers often have little or no direct authority over their team members in a matrix setting, their ability to influence project stakeholders in a timely manner is critical to project success. Key influencing skills include:
o the ability to convincingly and clearly state the point of view and position;
o high level of active and effective listening skills;
o understanding and considering different perspectives in any situation;
o Gathering essential and critical information to solve important problems and reach agreements while maintaining mutual trust.
· Effective decision making. This includes the ability to negotiate and influence the organization and the project management team. Below are some of the recommendations for decision making:
o need to focus on the goals to be achieved;
o it is necessary to adhere to the decision-making procedure;
o it is necessary to study environmental factors;
o it is necessary to analyze the available information;
o it is necessary to develop the personal qualities of team members;
o it is necessary to stimulate the creative approach of the team to work;
o need to manage risks.
10. PROJECT COMMUNICATION MANAGEMENT
Project communications management includes the processes necessary to ensure that project information is planned, collected, generated, distributed, stored, received, managed, controlled, monitored, and ultimately archived / disposed of in a timely and appropriate manner. Project managers spend most of their time communicating with team members and with other project stakeholders, whether they are internal (at all levels of the organization) or external to the organization. Effective communication creates a bridge between different stakeholders, who may have different cultural and organizational backgrounds, different levels of knowledge, and different views and interests that impacts or may have an impact on project performance or outcomes.
Factors that can influence the choice of communication technologies include:
· The urgency of obtaining information. It is necessary to take into account the urgency, frequency and format of the information transmitted, as they may differ in different projects, as well as at different stages of the same project.
· Technology availability... Ensure that the technology required to communicate is compatible and accessible to all stakeholders throughout the project lifecycle.
· Ease of use. It is necessary to ensure that the selected communication technologies are suitable for the project participants and that appropriate training events are planned, if necessary.
· Project environment... It is necessary to determine whether the team will meet and act in person or virtually; whether team members will be in one or more time zones; whether they will use multiple languages for communication; and, ultimately, whether there are any other factors in the project environment, such as culture, that may affect communication.
· Secrecy and confidentiality of information. It is necessary to determine whether the transmitted information is classified or confidential and whether additional measures are required to protect it. It is also necessary to consider the most appropriate way of transmitting such information.
The basic communication model has the following sequence of steps:
· Coding... Converting (encoding) thoughts or ideas into a code language by the sender.
· Message transmission. Sending information by a sender using an information channel (information transmission medium). Various factors (eg distance, unfamiliar technology, inadequate infrastructure, cultural differences and lack of additional information) may interfere with the transmission of this message. These factors are collectively referred to as noise.
· Decoding... The message is translated by the recipient back into meaningful thoughts and ideas.
· Confirmation... After receiving a message, the recipient can send a signal (acknowledgment) to receive the message, but this does not necessarily mean agreeing with the message or understanding the message.
· Feedback / Answer... When the received message is decoded and understood, the recipient converts (encodes) thoughts and ideas into a message and transmits the given message to the original sender.
Several communication methods are used to disseminate information between project stakeholders.
These methods can be divided into the following large groups:
· Interactive communications... Between two or more parties in a multilateral exchange of information. This method is most effective for ensuring a common understanding of certain issues by all participants; it includes meetings, phone calls, instant messaging, video conferencing, etc.
· Communication by informing method without request. The information is sent to specific recipients who need to receive it. This method disseminates information, but does not guarantee that it will actually be received or understood by its intended audience. Unsolicited communications include letters, notes, reports, emails, faxes, voicemail messages, blogs, press releases, etc.
· Communication by the method of informing on demand... They are used for very large amounts of information or for very large audiences and require recipients to access the transmitted content of their own accord. Such methods include intranets, e-learning, lessons learned databases, knowledge repositories, etc.
Methods and aspects of effective communication management include, but are not limited to:
· Models "sender-recipient". Implement feedback loops to create favorable opportunities for interaction / participation and remove communication barriers.
· Choice of means of communication. Situational choices of when is best to communicate verbally, when in writing, when is it best to prepare informal notes and when is a formal report, as well as when is it best to speak in person and when to email.
· Style of writing. The use of a real or passive voice, sentence structure, word selection.
· Methods of managing meetings. Preparing the agenda and dealing with conflicts.
· Presentation techniques. Awareness of the impact of body language and the development of visual aids.
· Methods of organizing group work. Building consensus and overcoming obstacles.
· Methods of listening. Active listening (reaffirming, refining and testing understanding) and removing barriers that can distort understanding.
11. PROJECT RISK MANAGEMENT
Project risk management includes the processes involved in implementing risk management planning, identification, analysis, response planning, and risk control in a project. The objectives of project risk management are to increase the likelihood and increase the impact of favorable events and reduce the likelihood of occurrence and mitigate the impact of adverse events during project implementation.
Project risk is an undefined event or condition, the occurrence of which negatively or positively affects the goals of the project, such as content, schedule, cost and quality. A risk can be due to one or more reasons and, if it does, can affect one or more aspects.
Risk management plan is a component of a project management plan that describes how risk management activities will be structured and executed. The risk management plan includes the following elements:
· Methodology... Determination of approaches, tools and data sources that will be used for risk management in this project.
· Roles and areas of responsibility. Identify leading team members, supportive team members, and team members responsible for risk management for each activity included in the risk management plan and clarifying their areas of responsibility.
· Development of a budget. Assessment of the necessary funds, taking into account the allocated resources for inclusion in the base plan at cost and development of procedures for the use of the reserve for possible losses and management reserves.
· Determination of terms. Determining the timing and frequency of risk management processes throughout the project life cycle, developing procedures for using the schedule reserves for possible losses, as well as determining the risk management activities that will be included in the project schedule.
· Risk categories. Provides a means to categorize potential sources of risk into groups. Several approaches can be used, for example, a structure based on project objectives by category. The Risk Breakdown Structure (RBS) helps the project team consider the many sources from which project risks may arise during the risk identification process. Different RBS structures correspond to different types of projects. An organization can use a pre-designed risk categorization scheme, which can take the form of a simple list of categories or take the form of an RBS. RBS is a hierarchical presentation of risks according to risk categories.
· Determination of the likelihood and impact of risks. A good and reliable risk analysis involves the identification of different levels of likelihood and impact of risks in the context of the project. General definitions of likelihood and exposure levels are adapted to the specific project during the risk management planning process and then used in subsequent processes. The table below provides an example of definitions of negative impacts that can be used in assessing the impact of risks associated with the four project objectives (similar tables can be created for positive impacts). The table below demonstrates both relative and numerical (in this case, non-linear) approaches.
· Probability and Impact Matrix... The Probability and Impact Matrix is a table that displays the likelihood of each risk occurring and its impact on the project objectives should it occur. Risks are prioritized according to their likely consequences, which may have an impact on project objectives. A typical prioritization approach is to use a look-up table or probability-impact matrix. Typically, the organization itself establishes the combinations of probability and impact, on the basis of which the level of risk is determined as “high”, “medium” or “low”.
· Clarified stakeholder tolerance. During the risk management planning process, stakeholder tolerance can be adjusted for a specific project.
· Reporting formats. Reporting formats define how the results of the risk management process will be documented, analyzed and communicated. The reporting formats describe the content and format of the risk register and any other required risk reports.
· Tracking... Tracking documents how all risk-related activities are recorded for the purposes of this project, and when and how the risk management processes will be audited.
Chart methods
Risk diagramming techniques include:
· Cause-and-effect diagrams. These diagrams, also known as Ishikawa diagrams or fishbone diagrams, are used to determine the causes of risks.
· Flowcharts of a process or system. This type of graphical display demonstrates the order of interaction of various elements of the system with each other and their cause-and-effect relationships.
· Influence charts. A graphical representation of situations showing causal relationships, sequences of events over time, and other relationships between variables and outcomes.
SWOT analysis
This method allows you to analyze the project from the point of view of each of the aspects: strengths, weaknesses, opportunities and threats (strengths, weaknesses, opportunities, and threats, SWOT), which makes the identification of risks more complete, taking into account the risks within the project. This method begins by identifying the strengths and weaknesses of the organization, focusing on either the project, the organization, or the area of the business as a whole. The SWOT analysis then identifies any opportunity for the project based on the organisation's strengths, as well as any threats posed by its weaknesses. This analysis also examines how the organization's strengths compensate for threats and identifies opportunities that can be used to overcome weaknesses.
Risk register
The main output of the risk identification process is the initial entry in the risk register. A risk register is a document containing the results of risk analysis and risk response planning. The risk register records the results of other risk management processes as they occur, resulting in an increase in the level and variety of types of information contained in the risk register over time. The preparation of the risk register begins with the risk identification process, during which the register is filled with the information below. This information is then made available to other processes related to project management and risk management.
· List of identified risks. The identified risks are described in sufficient detail. This list can use a specific structure to describe risks, for example: an EVENT can occur that will have an IMPACT, or if there is a CAUSE, an EVENT can occur that will have a CONSEQUENCE. In addition, as the list of identified risks is constructed, the root causes of these risks may become more apparent. These are fundamental conditions or events that are capable of causing one or more of the identified risks to occur. They should be recorded and used to support future risk identification for this and other projects.
· List of possible responses. Sometimes in the process of identifying risks, possible responses to them can be determined. Such responses, if identified during this process, should serve as inputs to the risk response planning process.
Qualitative risk analysis- the process of prioritizing risks for further analysis or actions, carried out by assessing and comparing their impact and likelihood of occurrence. The key benefit of this process is that it allows project managers to reduce the level of uncertainty and focus on high priority risks.
Quantitative risk analysis- the process of numerical analysis of the impact of the identified risks on the goals of the project as a whole. A key benefit of this process is that it provides quantitative information about risks to support decision-making in order to reduce project uncertainty.
Methods of collecting and presenting information
· Interviewing... Interviewing techniques provide experience and historical data to quantify the likelihood and impact of risks on project objectives. The information required depends on the type of probability distribution used. For example, for some of the most widely used distribution models, it is necessary to collect information about the optimistic (low probability), pessimistic (high probability), and most probable scenarios. Documenting the rationale for risk ranges and associated assumptions is an important element of the risk interview, as these documents allow conclusions to be drawn about the reliability and validity of the analysis.
· Probability distribution. Continuous probability distributions, widely used in modeling and simulation, represent uncertainties in values such as the duration of schedule activities and the cost of project components. Discrete distributions can be used to represent undefined events, such as test results or possible scenarios in a decision tree. In fig. below are two examples of commonly used continuous distributions. These distributions describe patterns that fit with data typically obtained from quantitative risk analysis. Uniform distributions can be used in cases where there is no obvious value that is more likely than others between the specified upper and lower bounds, for example, at an early stage of design.
Methods for quantitative analysis and risk modeling
The widely used methods use both event-driven and project-oriented approaches to analysis, including:
· Sensitivity analysis... Sensitivity analysis helps to identify the risks with the greatest possible impact on the project. It helps you understand how variation in the design goals correlates with variation in various uncertainties. On the other hand, it establishes to what extent the uncertainty of each element of the project affects the studied goal, while all other undefined elements are at their base values. One typical display of sensitivity analysis is a tornado diagram (Figure below), which is useful for comparing the relative importance and impact of variables with a high degree of uncertainty with other, more stable variables. The tornado chart is also useful in analyzing risk taking scenarios applied to specific risks, the quantitative analysis of which indicates that the potential benefits are greater than the corresponding negative impacts identified. A tornado chart is a special kind of bar chart used in sensitivity analysis to compare the relative importance of variables. In a tornado chart, the y-axis represents each type of uncertainty in baseline values, and the x-axis represents the variance or correlation of uncertainty in the yield of interest. In this figure, each uncertainty contains a horizontal bar (line), and the vertical shows uncertainties with decreasing spread from the baseline.
· Analysis of the expected monetary value. Expected monetary value (EMV) analysis is a statistical technique that calculates the average outcome when there are future scenarios that may or may not happen (that is, an analysis under conditions of uncertainty). EMVs of opportunity are generally positive and threats are negative. EMV requires a risk-neutral assumption - neither prone to excessive risk, nor, conversely, completely rejecting it. To calculate the EMV for a project, you multiply the value of each possible outcome by the probability that it will occur, and then add the resulting values together. Typically this type of analysis is used as a decision tree analysis.
· Modeling and imitation. A project simulation uses a model to determine the possible impacts of detailed uncertainties on the project objectives. Simulations are usually performed using the Monte Carlo method. During simulation, the project model is calculated many times (iteratively), and for each iteration, the input values (for example, estimates of the cost or duration of operations) are selected arbitrarily from the probability distributions of these variables. During the iterations, a histogram is calculated (for example, total cost or completion date). In the analysis of value risks by the simulation method, value estimates are used. The scheduling risk analysis uses the scheduling network diagram and duration estimates. The way out of the simulation of value risks using a three-element model and risk ranges is shown in Fig. below. The figure shows the relative likelihood of achieving certain cost targets. Similar curves can be designed for other design purposes.
Strategies for responding to negative risks (threats)
· Evasion... Risk Avoidance is a risk response strategy in which the project team acts to eliminate a threat or protect the project from its impact. As a rule, it involves changing the project management plan in such a way as to completely eliminate the threat. The project manager can also insulate the project objectives from exposure to risk, or change a goal that is at risk (for example, expand the scope of the schedule, change the strategy, or reduce the content). The most radical evasion strategy is to end the project altogether. Some of the risks that arise early in a project can be avoided by clarifying requirements, obtaining information, improving communications, or acquiring expertise.
· Broadcast... Risk transfer is a risk response strategy whereby the project team shifts the consequences of a threat, along with responsibility for the response, to a third party. When a risk is transferred, responsibility for managing it is shifted to the other party; the risk is not eliminated. Transfer of risk does not mean refusal of responsibility for it by transferring it to a future project or another person, without notifying the latter or entering into an agreement with him. Risk transfer almost always involves the payment of a risk premium to the party assuming the risk. Risk transfer is most effective in dealing with financial risks. Transfer instruments can be very diverse and include, but are not limited to: the use of insurance, performance guarantees, warranties, etc. Contracts or agreements can be used to transfer responsibility for certain risks to another party. For example, when a buyer has options that the seller does not have, it may be prudent to contract through a contract to transfer some of the work and its associated risks back to the buyer. In many cases, in a cost-reimbursement contract, the value risk can be transferred to the buyer, and in a fixed price contract, the risk can be transferred to the seller.
· Decrease... Risk Mitigation is a risk response strategy in which the project team acts to reduce the likelihood or impact of risk. It involves reducing the likelihood and / or impact of an adverse risk to acceptable threshold levels. Early action taken to reduce the likelihood of a risk and / or its impact during a project is often more effective than post-risk redress efforts. Examples of actions to mitigate risk include implementing less complex processes, running more tests, or choosing a more reliable supplier. Also, the reduction may require prototyping to reduce the risk of process or product scaling up compared to a bench model. If it is not possible to reduce the likelihood, risk mitigation actions should focus on the impact of the risk, namely those relationships that determine the severity of the impact. For example, designing a redundant system can reduce the severity of the consequences of failure of the original element.
· Adoption... Risk Acceptance is a risk response strategy in which the project team decides to acknowledge the risk and not take any action until the risk occurs. This strategy is used if any other way of responding to a particular risk is impossible or economically ineffective. She indicates that the project team has decided not to modify the project management plan to deal with the risk, or is unable to identify any other appropriate response strategy. This strategy can be passive or active. Passive acceptance requires no action other than documenting the strategy — the project team will have to deal with risks as they occur and periodically review the threat to ensure that it has not changed significantly. The most common strategy for proactive acceptance is to establish a reserve for potential losses, including the amount of time, money, or resources required to manage risk.
Strategies for responding to positive risks (opportunities)
· Usage... A leverage strategy can be chosen to respond to risks with positive impacts if the organization wants the opportunity to be guaranteed to be realized. This strategy is designed to address the uncertainty associated with a defined positive risk through measures that ensure the opportunity is realized. Directly leveraged responses include recruiting the most talented staff in the organization to reduce the time required to complete the project, or using new or upgraded technologies to reduce the cost and time required to achieve project objectives.
· Increase... An augmentation strategy is used to increase the likelihood and / or positive impact of an opportunity. Identifying and maximizing the key factors driving the emergence of these positive-impacting risks can increase the likelihood of their occurrence. Examples of increasing opportunities include allocating additional resources to an operation to complete early.
· Separation... Sharing a positive risk involves transferring some or all of the responsibility for an opportunity to a third party who is best placed to take advantage of the opportunity to the benefit of the project. Unbundling activities include the formation of risk-sharing partnerships, teams, specialized companies or joint ventures that may be formed with the specific purpose of ensuring that all parties benefit from an opportunity.
· Adoption... Opportunity acceptance is the desire to take advantage of the opportunity when it occurs without actively pursuing it.
12. MANAGEMENT OF PROJECT PURCHASES
Project procurement management includes the processes of purchasing or purchasing products, services or outputs necessary for the implementation of a project outside the project team. An organization can act as both a buyer and a seller of products, services, or project deliverables.
Project Procurement Management includes the contract management and change control processes required for drafting and administering contracts or purchase orders prepared by authorized members of the project team.
Types of contracts
· Fixed price contracts. This type of contract provides for the total fixed cost of the delivered product, service or result. Fixed-price contracts may also provide financial incentives for achieving or improving specific project objectives, such as planned delivery dates, technical completion and cost performance, or other quantifiable and measurable metrics. In accordance with fixed price contracts, sellers are legally obliged to fulfill such contracts or incur potential financial losses if they are not fulfilled. Buyers, in accordance with the provisions of such contracts, are obliged to accurately determine the purchased product or service. Changes to the content may occur, but this usually results in an increase in the contract price.
o Firm Fixed Price Contracts (FFP). The most widely used type of contract is FFP. Most buying organizations prefer this type of contract, since the price of goods is set at the very beginning and is not subject to changes if the content of the work does not change. Any increase in value caused by negative performance is the seller's responsibility to complete the job. The FFP requires the buyer to accurately identify the product or service to be purchased, and any changes to the purchasing specification could increase the buyer's costs.
o Contracts with a fixed price and incentive remuneration (Fixed Price Incentive Fee Contracts, FPIF). This lump-sum agreement gives the buyer and seller some flexibility as it allows for variance and provides financial incentives for meeting agreed metrics. Typically, these financial incentives are related to cost, schedule or technical performance by the seller. Target values of performance indicators are set at the beginning, and the final price of the contract is determined after the completion of all work, depending on their performance by the seller. Under FPIF, a price cap is set and all costs above the price cap are held by the seller to complete the job.
o Fixed Price with Economics Price Adjustment Contracts (FP-EPA). This type of contract is used in the event that the performance of the contract by the seller stretches over a significant period of time, which is usually the goal in long-term relationships. A contract with a fixed price, but with a special provision that allows predetermined final adjustments to the contract value due to changed conditions, such as inflation or increases (decreases) in the prices of certain goods. The price adjustment clause must be linked to a valid financial index used to accurately adjust the final price. FP-EPA is designed to protect both buyer and seller from external conditions that they cannot control.
· Cost-recovery contracts. This type of contract implies payment (reimbursement) to the seller of all lawful actual costs incurred as a result of the performance of the work, plus remuneration that constitutes his profit. Cost-reimbursement contracts often include clauses that provide incentives for exceeding or improving project targets (for example, cost, schedule, or technical performance). The three most common types of cost reimbursement contracts are: Cost Plus Fixed Fee Contract (CPFF), Cost Plus Incentive Fee Contract (CPIF), Cost Plus Fixed Fee Contract (CPIF), and Cost Plus Fixed Fee Contract (CPIF) reward (Cost Plus Award Fee Contract, CPAF). A cost-reimbursement agreement provides project flexibility by allowing changes to instructions for the seller in the event that the content of the work cannot be accurately described in the beginning and needs to be adjusted or there are high risks during the execution of the work.
o Cost Reimbursement Plus Fixed Fee Contracts (CPFF). The seller is reimbursed for all agreed costs of performing the work under the contract, and is paid a fixed fee that is a percentage of the original assessed cost of the project. The remuneration is paid only for the completed work and does not change depending on the performance of the seller. The amount of remuneration does not change if the content of the project does not change.
o Cost-recovery plus incentive contracts (CPIF). The seller receives reimbursement of all agreed costs of performing work under the contract, as well as a predetermined incentive remuneration for achieving specific performance indicators specified in the contract. The CPIF contracts stipulate that if the final costs are more or less than the original estimated cost, then the saved / overspending funds are distributed between the seller and the buyer in a predetermined ratio, for example, in the 80/20 ratio of the difference between the planned costs and the actual performance of the seller.
o Cost-reimbursement plus premium contracts (CPAF). The seller is reimbursed for all reasonable costs, but the majority of the remuneration is paid only on the basis of meeting a set of broadly interpreted subjective performance criteria as defined in the contract. The determination of remuneration is based solely on the buyer's subjective assessment of the seller's performance of the contract and, as a rule, is not subject to appeal.
· Time and material contracts(Time and Material Contracts, T&M). Time and material contracts are a mixed type of contract, containing both cost-recovery and fixed price contracts. They are often used for staff augmentation, experts, and any third-party support in cases where it is impossible to quickly create an accurate job description. These types of contracts are similar to cost-recovery contracts in that they allow for amendments and increases in value for the purchaser. At the time of the conclusion of the contract, the buyer may not indicate the total value of the contract and the exact number of items to be delivered. Thus, the value of T&M contracts can increase, as in cost-recovery contracts. To prevent unlimited growth in value, many organizations require price and time limits to be included in all T&M contracts. On the other hand, T&M contracts can also resemble fixed price agreements when certain parameters are specified in the contract. The rates for labor hours or the cost of materials, including the seller's profit, can be predetermined by the buyer and seller if both parties agree on the cost of certain categories of resources, such as a certain hourly rate for chief engineers or a certain price per unit of material.
13. STAKEHOLDER MANAGEMENT
Project stakeholder management includes the processes needed to identify the people, groups and organizations that may or may be influenced by the project, to analyze the expectations of stakeholders and their impact on the project, and to develop appropriate management strategies for effective engagement. stakeholders in decision-making and project execution. Stakeholder management also focuses on ongoing communication with stakeholders to understand their needs and expectations, on responding to problems as they arise, on managing conflicting interests, and on fostering appropriate stakeholder involvement in decision making and project operations. Stakeholder satisfaction should be managed as one of the key project objectives.
Various classification models are used in the stakeholder analysis, such as:
· power / interests matrix, grouping stakeholders based on their level of authority ("power") and level of interest ("interest") in relation to project results;
· power / influence matrix grouping stakeholders based on their level of authority ("power") and active involvement ("influence") in the project;
· influence / impact matrix, grouping stakeholders on the basis of their active involvement ("influence") in the project and their ability to lead to changes in the planning or execution of the project ("impact");
· feature model describing the classes of stakeholders according to their level of power (ability to impose their will), urgency (need for immediate action) and legitimacy (their involvement is appropriate).
Stakeholder engagement levels can be classified as follows:
· Uninformed... The stakeholder is not aware of the project and potential impacts.
· Resisting... The stakeholder is aware of the project and potential impacts and resists change.
· Neutral... The stakeholder is aware of the project, but does not support or oppose the change.
· Supportive... The stakeholder is aware of the project, potential impacts and supports the change.
· Leading... The stakeholder is aware of the project, potential impacts, and is actively involved in ensuring the success of the project.
The main output of the stakeholder identification process is the stakeholder register. It contains all the details related to stakeholders that have been identified, including but not limited to:
· Identification information: name, position in the organization, location, role in the project, contact information.
· Assessment information: basic requirements and expectations, potential impact in the project, the most interesting phase in the project life cycle.
Stakeholder classification: internal / external, support / neutral / resist, etc.
In addition to data from the stakeholder register, the stakeholder management plan often also contains:
· The desired and current level of involvement of key stakeholders;
· The scope and impact of the change on stakeholders;
· Identified relationships and potential intersections of stakeholders;
· Requirements of stakeholders for communications in the current phase of the project;
· Information about the information disseminated to interested parties, including language, format, content and level of detail;
· The reason for the dissemination of this information and the expected impact on the level of stakeholder engagement;
· The time and frequency of dissemination of the required information to interested parties;
· A method for updating and refining the stakeholder management plan as the project progresses and develops.
Guide to the Project Management Body of Knowledge (PMBOK Guide)
Bibliographic record of the Library of Congress
Titles: Project Management Institute (PMI), publisher.
Title: A guide to the project management body of knowledge (PMBOK guide) / Project Management Institute.
Other titles: PMBOK Guide
Description: Sixth Edition | Newtown Square, PA: Project Management Institute, 2017. | Series: PMBOK Manual |
Identifiers: LCCN 2017032505 (print) | LCCN 2017035597 (ebook) | ISBN 9781628253900 (ePUP) |
ISBN 9781628253917 (kindle) | ISBN 9781628253924 (Web PDF) | ISBN 9781628251845 (paperback)
Topic: LCSH: Project management. | BISAC: BUSINESS & ECONOMICS / Project Management (BUSINESS & ECONOMICS / Project Management).
Classification: LCC HD69.P75 (ebook) | LCC HD69.P75 G845 2017 (print) | DDC 658.4 / 04-dc23
The LC record is available at https://lccn.loc.gov/2017032505
Project Management Institute, Inc.
14 Campus Boulevard
Newtown Square, Pennsylvania 19073-3299 USA
Phone: +1 610-356-4600
Fax: +1 610-356-4647
Email mail: [email protected]
Website: https://www.PMI.org
Materials of the Project Management Institute, Inc. are copyrighted under US Intellectual Property Law, which is recognized in most countries. You must obtain our permission to reprint or reproduce PMI material. For more information visit http://www.pmi.org/permissions_for_details.
To place a trade order or obtain a quote, contact the Independent Publishers Group:
Independent Publishers Group
Order Department
814 North Franklin Street
Chicago, IL 60610 USA
Phone: +1 800-888-4741
Fax: +1 312-337-5985
Email mail: [email protected](only for orders)
For all other questions, please contact the PMI Book Service Center.
PMI Book Service Center
P.O. Box 932683, Atlanta, GA 31193-2683 USA
Phone: 1-866-276-4764 (US or Canada) or + 1-770-280-4129 (worldwide)
Fax: + 1-770-280-4113
Email mail: [email protected]
Printed in the United States of America Reproduction or transmission in any form or by any means, electronic, manual, photocopying, recording, or by any storage or retrieval system, of any part of this publication, without prior permission from the publisher, is prohibited.
PMI, PMI logo, PMBOK, OPM3, PMP, CAPM, PgMP, PfMP, PMI-RMP, PMI-SP, PMI-ACP, PMI-PBA, PROJECT MANAGEMENT JOURNAL, PM NETWORK, PMI TODAY, PULSE OF THE PROFESSION and MAKING slogan PROJECT MANAGEMENT INDISPENSABLE FOR BUSINESS RESULTS.
are trademarks of Project Management Institute, Inc. For a complete list of PMI trademarks, contact the PMI Legal Department. All other trademarks, service marks, trade names, trade dress, product names, and logos appearing in this document are the property of their respective owners. Any rights not expressly assigned in this document belong to the copyright holder.
All rights reserved. Reproduction of the entire book or part of it in any form is prohibited without the written permission of the publisher.
© Copyright 2017 Project Management Institute, Inc. All rights reserved.
© Translation into Russian, edition, design by "Olymp - Business" publishing house, 2018
Notification
The standards and guidelines published by the Project Management Institute, Inc. (PMI), which include this document, are developed through a standards development process based on voluntary participation and general consensus. This process brings together volunteers and / or brings together the comments and opinions of those interested in the subject matter of this publication. While the PMI administers this process and lays down rules to ensure impartiality in reaching consensus, PMI does not write the document or independently test, evaluate, and verify the accuracy or completeness of the material contained in the standards and guidelines published by PMI. Likewise, PMI does not check the validity of the opinions expressed in these documents.
PMI is not responsible for any personal injury, property damage, or any other loss, whether real, consequential or compensatory, arising directly or indirectly from the publication, use or use of this document. PMI accepts no responsibility or warranty, either express or implied, regarding the accuracy or completeness of any material contained in this document, nor is it responsible or warranted that the information contained in this document will meet any of your purposes or needs. ... PMI makes no warranty as to the quality of any individual manufacturer's or vendor's products or services arising from the use of this standard or guideline.
By publishing and distributing this document, PMI does not provide professional or other services to any person or organization or on behalf of any person or organization; likewise, PMI does not fulfill the obligations of any person or organization towards any third party. When using this document, the person using it should independently determine the actions necessary in the specific circumstances, relying solely on his own judgment or, if necessary, on the advice of a competent professional. Information regarding the topic covered by this document, or related standards, may be obtained from other sources, which the user can refer to, if necessary, for additional information not contained in this document.
PMI has no authority or responsibility to monitor the conformity of existing practices with the content of this document or to bring those practices in line with this document. PMI does not certify, test or inspect products, designs or designs for safe use or health for consumers. Any certification or other statement of conformity with any safety or health information contained in this document cannot be attributed to PMI; in such a case, responsibility rests solely with the person who issued the certificate or made such a statement.
Part 1: A Guide to the Project Management Body of Knowledge (PMBOK® Guide)
1. Introduction
1.1 Overview and purpose of this manual
Project management is nothing new. People have been using it for centuries. Examples of completed projects include:
Pyramids at Giza
Olympic Games,
The great wall of china
Taj Mahal,
Publication of a book for children,
Panama Canal,
Creation of commercial jet aircraft,
Polio vaccine,
Landing a man on the moon
Commercial computer applications,
Portable devices for using the Global Positioning System (GPS),
Launching the International Space Station into Earth Orbit.
The practical achievements of these projects are the result of the application of project management practices, principles, processes, tools and methods by managers and managers in their work. The leaders of these projects used a number of key skills and applied the knowledge necessary to satisfy their clients and others involved in the implementation or affected by the project. By the middle of the 20th century, project managers began to work with the goal of gaining recognition as a profession of project management. One aspect of this work was reaching agreement on the content of a body of knowledge (BOK) called project management. The EQA becomes known as the Project Management Body of Knowledge (PMBOK). The Project Management Institute (PMI) has created baselines and glossaries for the PMBOK. Project managers soon came to realize that PMBOK cannot be fully contained in one book. Therefore PMI developed and published "Guide to the Body of Knowledge on Project Management" (PMBOK® Guide).
PMI's definition of a Project Management Body of Knowledge (PMBOK) is a term that describes knowledge of the project management profession. The Project Management Body of Knowledge includes established and widely used traditional practices as well as newly emerging innovative practices.
Body of Knowledge (CQA) includes both published and unpublished material. This body of knowledge is constantly evolving. The present PMBOK® Guide highlights that part of the Project Management Body of Knowledge that is generally recognized as good practice.
? Universally recognized means that the described knowledge and practices are applicable to most projects in most cases, and there is a consensus on their value and benefits.
? Good practice means there is broad agreement that the correct application of this knowledge, skills, tools and techniques to project management processes can increase the likelihood of success across a wide range of different projects to deliver the expected business value and results.
The project manager works with the project team and other stakeholders to identify and apply good, recognized practices for each project. Determining the appropriate combination of processes, inputs, tools, methods, outputs, and life cycle phases for project management is called “tailoring” the knowledge described in this Guide.
The present PMBOK® Guide is not a methodology. A methodology is a system of practices, methods, procedures and rules used in a particular field of activity. The present PMBOK® Guide is the basis on which an organization can develop its methodologies, policies, procedures, rules, tools and techniques, as well as the life cycle phases required in project management practice.
This Guide is based on Project Management Standard... A standard is a document established by a notified body, custom or by common agreement as a model or pattern. Project Management Standard was developed as an American National Standards Institute (ANSI) standard using a process based on the principles of consensus, openness, due process and balance. Project Management Standard is the foundational reference for PMI's professional development programs and project management practice. Since there is a need to adapt project management to meet the needs of a specific project, both the Standard and the Guidelines are based on descriptive, but not prescriptive practice. As such, this Standard defines processes that are good practice for most projects in most cases. This Standard also defines the inputs and outputs that are commonly associated with these processes. The standard does not contain requirements for the mandatory implementation of certain specific processes or practices. Project Management Standard part of Part II Guidelines for the Project Management Body of Knowledge (PMBOK® Guidelines).
V PMBOK® Guide outlines key concepts, emerging trends, considerations for adapting project management processes, and information on how to apply tools and techniques to projects. Project managers may use one or more methodologies when implementing the project management processes described in this Standard.
? Portfolio Management Standard, and
? Program control standard .
A common vocabulary is an essential element of any professional discipline. PMI Lexicon of Project Management Terms is a basic vocabulary of professional terminology that can be used consistently by organizations, project, program and portfolio managers, and other project stakeholders. Lexicon will develop over time. The glossary of this manual includes a glossary of the included Lexicon terms, as well as additional definitions. Projects may use other industry-specific terms that are defined in the industry literature.
PMI publishes in order to build confidence in the project management profession and help the person make smart decisions, especially in difficult situations where he or she may be asked to do dishonest behavior or compromise their values. The values that the global project management community has identified as the most important are responsibility, respect, fairness and honesty. These four values are at the heart of the Code of Professional Ethics and Conduct.
Code of Professional Ethics and Conduct includes both incentive and mandatory standards. Incentive standards describe the behavior that practitioners who are also PMI members, certificate holders or volunteers should strive for because of their inner conviction. While it is not easy to assess compliance with incentive standards, behavior in accordance with them is expected for those professionals who consider themselves professionals, that is, these standards should not be considered optional. Mandatory standards are mandatory requirements and in some cases restrict or prohibit certain behavior of practitioners. Practitioners who are simultaneously PMI members, certificate holders, or volunteers who violate these standards in their activities are subject to the disciplinary procedures of the PMI Ethics Committee.
1.2 Founding elements
This section describes the foundational elements required to work in the field and understand the discipline of project management.
A project is a temporary venture aimed at creating a unique product, service or result.
? Unique product, service or result... Projects are implemented to achieve goals by creating deliverables. The goal is the end result towards which the work should be directed; the strategic position to be taken; the task to be solved; the result to be obtained; product to be produced; or a service to be provided. A Delivered Outcome is any unique and verifiable product, outcome, or service capability that is required to complete a process, phase, or project. Deliverables can be tangible or intangible.
Achievement of project objectives can produce one or more of the following deliverables:
A unique product that can be either a component of another product, or an improvement or fix for a product, or itself as a new final product (for example, the elimination of a defect in the final product);
A unique service or ability to provide a service (for example, a business unit supporting manufacturing or distribution);
A unique result, such as an end result or document (for example, a research project brings new knowledge that can be used to determine if there is a trend or the benefits of a new process for society);
A unique combination of one or more products, services, or deliverables (for example, a software application, associated documentation, and technical support services).
Some elements may be repeated in some deliverables and project activities. This repetition does not change the fundamental and unique characteristics of the project's work. For example, office buildings can be built from the same materials or by the same construction team. However, each construction project remains unique in its key characteristics (eg location, design, environment, setting, people involved).
Projects are undertaken at all levels of the organization. One or more people can participate in the project. One structural division of an organization or several structural divisions of different organizations can participate in the project.
Examples of projects include, among others:
Development of new pharmaceuticals for the market;
Expansion of excursion tourism services;
Merger of two organizations;
Improving the business process in the organization;
Purchase and installation of new computer hardware for use in the organization;
Exploration of oil fields in the region;
Modification of a computer program used in an organization;
Research to develop a new production process;
Building construction.
? Temporary venture... The temporary nature of projects indicates a definite start and end. The definition of "temporary" does not necessarily mean that the project is designed for a short time. The end of a project occurs when one or more of the following statements are true:
The objectives of the project have been achieved;
The goals will not or cannot be achieved;
Funding for the implementation of the project has been exhausted or can no longer be allocated;
The need for the project has disappeared (for example, the customer no longer wants to complete the project, a change in strategy or priorities requires the termination of the project, the management of the organization gives an order to terminate the project);
Human or material resources have been exhausted;
The project is being terminated for legal or expediency reasons.
Projects are temporary, but deliverables may continue after the end of the project. Projects can deliver deliverables of a social, economic, material or environmental nature. For example, a national monument project produces a deliverable that is expected to last for centuries.
? Projects drive change... Projects are the driving force behind change in organizations. From a business perspective, the goal of a project is to transition an organization from one state to another to achieve a specific goal (see Figure 1-1). It is generally assumed that the organization is in its original state before the start of the project. And the desired result of the change in the course of the project is described as a future state.
Some projects may involve the creation of a transitional state when several consequential steps are taken to achieve a future state. The result of the successful completion of the project is the transition of the organization to the future state and the achievement of a specific goal. For more information on project and change management, see the document Governance of Portfolios, Programs, and Projects: A Practice Guide.
Rice. 1-1. Transitioning an organization to a new state using a project
? Projects create business value... PMI defines business value as the net, quantifiable benefit derived from a business venture. Benefits can be tangible, intangible, or both. In business analysis, business value is considered to be the benefit gained in forms such as time, money, goods, or intangible assets in exchange for an investment. Cm. Business Analysis for Practitioners: A Practice Guide, p. 185.
The business value of projects is understood as the benefit that stakeholders receive as a result of the implementation of a specific project. Benefits from project implementation can be tangible, intangible, or both.
Examples of material elements include:
Cash,
Share capital,
Network engineering,
Fixed assets,
PMBOK-5 ® Guide represents generally recognized good practice in the profession of project management.
How to download PMBOK?
The new PMBOK Guide 5th Edition has been published on December 31st 2008. It is now available to all PMI Members at the following page:
You will find a link with title A Guide to the Project Management Body of Knowledge (PMBOK. Guide), Fifth Edition which will be used to buy this version of PMBOK. So just click this link which will give you an option to add a copy of the standard in your shopping cart. At the moment its price is $ 65.95 for non-members and $ 49.50 for PMI members. Finally do a checkout and download its PDF version. The following procedure needs to be adopted while downloading your copy of PMBOK 5.
Windows Users:
When you click the english version to download PMBOK ® Guide 5th edition this message will prompt like "The FileOpen system associates your member permissions to the publication" and prompts you to download and install the FileOpen Adobe Reader plug-in.
This step is required for first-time use only. Click Yes to begin installation of the Adobe Reader plug-in. "Then after successfull installing Fileopen plugin, close the window and go back and download but you need to be a PMI member to access.
Mac Users:
Mac uses Safari, which opens PDFs in the browser. That cannot work if security and other advanced functions are imbedded in the PDF. That requires a full version of PDF Reader or Adobe Acrobat installed.
Here is the APPLE support comment on reading PDFs with Safari. Adobe PDFViewer for Mac OS X will not run correctly on a system that doesn "t meet the following requirements.
