________________________________________________________________________________________________
1. INTRODUCTION
2. ORGANIZATION IMPACT AND PROJECT LIFE CYCLE
3. PROJECT MANAGEMENT PROCESSES
4. PROJECT INTEGRATION MANAGEMENT
5. PROJECT SCOPE MANAGEMENT
6. PROJECT TIME MANAGEMENT
7. PROJECT COST MANAGEMENT
8. PROJECT QUALITY MANAGEMENT
9. PROJECT HUMAN RESOURCE MANAGEMENT
10. PROJECT COMMUNICATION MANAGEMENT
11. PROJECT RISK MANAGEMENT
12. PROJECT PURCHASING MANAGEMENT
13. STAKEHOLDER MANAGEMENT
1. INTRODUCTION
Project is a temporary venture aimed at creating a unique product, service or result.
The project can create:
· product, which is a component of another product, an improvement of a product, or a final 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 benefit of a new process for society).
Project management is the application of knowledge, skills, tools, and methods to project work to meet project requirements. The project is managed through the proper application and integration of 47 project management processes logically grouped into 5 process groups.
These 5 process groups are as follows:
initiation,
planning,
the execution,
Monitoring and control
closure.
Project restrictions:
· quality,
· timetable,
the budget
the resources
Because of the potential for change, the development of a project management plan is iterative and goes through successive refinements at various stages of the project life cycle. Progressive refinement allows the project management team to define the work scope and manage it at a more granular level as the project evolves.
Program- a set of related projects, sub-programs and activities of a program that are managed in a coordinated manner to obtain benefits that would not be available if they were managed separately. Programs may contain elements of work related to them, but lying outside the scope of individual projects of the program. A project may or may not be part of a program, but a program always contains projects.
Program management- the application of knowledge, skills, tools and methods to the program to meet the requirements of the program and to obtain benefits and control that would not be available when managing projects separately.
Projects within a program are linked through a common end result or shared opportunity. If the link between projects is only a common customer, 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.
An example of a program would be a new satellite communications system with projects to design the satellite and satellite earth stations, build each of them, integrate the system, and launch 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 the portfolio and consist of sub-programs, projects and other activities managed in a coordinated manner in support of the portfolio. Individual projects that are either inside or outside the program are equally considered part of the portfolio. Although not necessarily interdependent or directly related, projects or programs in a portfolio are linked to an organization's strategic plan through the organization's portfolio.
Portfolio management- centralized management of one or more portfolios to achieve strategic goals. Portfolio management is focused on providing project and program analysis to prioritize resource allocation and to align and align portfolio management with the organization's strategies.
Project Management Office (PMO)- an organizational structure that standardizes project management processes and facilitates the exchange of resources, methodologies, tools and methods. 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. Supporting 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 project repository. The degree of control by the PMO is low.
· controlling. 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 by the PMO is medium.
· guiding. Leading PMOs control projects by directly managing those projects. The degree of control by the PMO is high.
The primary function of the PMO is to support project managers in a variety of ways, which may include but are not limited to:
· managing 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 common documentation (organizational process assets);
Coordinating communications between projects.
Project managers and PMOs have different goals and thus have different requirements. All their actions are aligned with the strategic interests of the organization. The difference between the role of the project manager and the PMO can be as follows:
· The project manager focuses on specific project objectives, while the PMO manages major changes in program content and may view them as potential opportunities to better achieve business objectives.
· The project manager controls the resources allocated to the project in order to more accurately meet the project objectives, 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, while the PMO manages methodologies, standards, shared risks/opportunities, metrics, and project interdependencies at the enterprise level.
Operating activities is a continuous activity that produces repetitive results, with resources allocated to perform a nearly identical set of tasks in accordance with standards embedded in the product life cycle. Unlike operations, which are permanent, projects are temporary businesses.
Operations management is the supervision, direction and control of business operations. Operations are used to support day-to-day activities and are necessary to achieve the organization's strategic and tactical objectives. Examples include: manufacturing operations, manufacturing operations, accounting operations, software support and maintenance.
Business value- a concept unique to each organization. Business value is defined as the total value of an organization, the sum total of all tangible and intangible elements. Examples of tangible items are monetary assets, fixed assets, equity, and communications. Examples of intangible elements include reputation, brand awareness, public good, and trademarks. 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 project, program and portfolio management disciplines, organizations gain the ability to apply sound, recognized processes to achieve strategic goals and derive greater business value from their project investments.
Project Manager- a person appointed by the performing organization to lead the team and responsible for achieving the objectives of the project.
The role of a project manager is different from that of a functional manager or a manager of operations. Typically, the functional manager is focused on providing oversight of the functional or business unit, while the operations managers are responsible for ensuring the effectiveness of business operations.
Competences of the RP:
· Knowledge competencies- what the manager knows about project management.
· Competencies in execution- 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 characteristics, and leadership qualities - the ability to lead the project team in achieving project goals and balancing project constraints.
RP skills:
leadership,
strengthening the team
motivation,
communication,
· influence,
· making decisions,
political and cultural awareness,
· negotiation,
Building trusting relationships
conflict resolution,
coaching.
2. ORGANIZATION IMPACT AND PROJECT LIFE CYCLE
Organization Process Assets are the plans, processes, policies, procedures and knowledge bases specific to and used by the performing organization. They include any artifacts, methods, and knowledge of some or all of the organizations involved in the project that can be used to execute or direct the project. In addition, process assets include the organization's knowledge bases, such as lessons learned and historical information. An organization's 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 add to 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 (eg regulations, codes of conduct, product standards, quality standards, manufacturing standards);
infrastructure (eg existing facilities and major equipment);
• available human resources (eg skills, knowledge, specializations such as design, development, legal, contracting and procurement);
· personnel management (for example, hiring and firing guidelines, performance analysis and staff training records, remuneration and overtime policies, and time tracking);
the situation on the market;
risk tolerance of stakeholders;
the political climate;
communication channels adopted in the organization;
· commercial databases (eg standardized cost estimates, industrial risk studies and risk databases);
· project management information system (for example, automated systems such as schedule management software, configuration management system, information collection and distribution system, or web interfaces to other online automated systems).
Project team members perform the following roles:
· Personnel responsible for project management. Team members who perform project management activities such as scheduling, budgeting, reporting and control, communications, risk management, and administrative support. This function may be performed or supported by a Project Management Office (PMO).
· Project staff. Team members who perform the work of creating project deliverables.
· Supporting Experts. Supporting experts perform the activities necessary to develop or execute the project management plan. This may 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 required, supporting experts may work full-time or simply be part of the team when their specific skills are required.
· Representatives of users or customers. Members of the organization who will accept project deliverables or products may act as spokespersons or intermediaries to ensure proper coordination, advice on requirements, or validation of project outcomes.
· Sellers. Vendors, also referred to as agents, suppliers, or contractors, are third-party companies that have contracted to provide components or services required for a project. The project team is often responsible for overseeing the execution and acceptance of vendor deliverables or services. If vendors bear 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 may 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 expertise or play a role assigned to them, 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 closing.
All projects can have the following life cycle structure:
start of the project;
organization and preparation;
Execution of project work;
completion of the project.
Project phase- a set of logically related project activities, culminating in the achievement of one or a number of delivered results.
Predictive life cycles(also known as fully plan-driven) is a type of project life cycle in which the scope of the project, and the time and cost required to complete that scope, are determined as early in the life cycle as possible.
Iterative and incremental life cycles are life cycles 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. Iterative defines the development of a product through a series of iterative cycles, while incrementality defines the incremental growth of a product's functionality. During these life cycles, the product is developed both iteratively and incrementally.
Adaptive life cycles(also known as change-driven or agile practices) aim to respond to high levels of change and require a high degree of stakeholder engagement at all times. Adaptive methods are also iterative and incremental, but differ in that the iterations are very fast (duration is typically 2–4 weeks) and are fixed in time and cost. Agile projects typically run multiple processes during each iteration, although early iterations may focus more on scheduling operations. The overall scope of the project is broken down into a set of requirements, and the work to be done is sometimes called the backlog (requirements log). At the beginning of an iteration, the team determines how many high-priority backlog items can be obtained during the next iteration. At the end of each iteration, the product should be ready for customer review.
3. PROJECT MANAGEMENT PROCESSES
Project management is the application of knowledge, skills, tools, and methods to project work to meet project requirements. This application of knowledge requires the 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, tools and methods that can be applied, as well as the resulting outputs.
Project processes can be divided into two main categories:
· Project Management Processes. These processes ensure the effective execution of the project during its life cycle. These processes cover the tools and techniques associated with applying the skills and capabilities described in the knowledge areas.
· Product oriented processes. These processes define and create the product of the project. Product-oriented processes are usually defined by the project life cycle and vary by application area as well as by phase of the product life cycle. The scope of a project cannot be determined without some basic understanding of how to create a given product. For example, when determining the total complexity of a building to be built, 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 the project or phase.
· Planning process group. The processes required to establish the scope of work, clarify the 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 work specified in the project management plan to meet project specifications.
· Group of monitoring and control processes. Processes required to track, analyze, and regulate project performance; identifying areas that require changes to the plan; and initiating appropriate changes.
· Closing process group. Processes performed to complete all activities within all process groups in order to formally close a project or phase.
Process groups are not project lifecycle phases!
As part of the project life cycle, a significant amount of data and information in various formats is collected, analyzed, transformed and disseminated to project team members and other stakeholders. Project data is collected as a result of various execution processes, after which it is provided to project team members.
The following guidelines minimize misunderstandings and help the project team use proper terminology:
· Work performance data. Raw observations and measurements identified during operations undertaken to carry out project activities. Examples include percentages of physically completed work, quality and technical performance measures, 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 evaluation of forecasts to completion.
· Work performance reports. A physical or electronic representation of work performance information collected in project documents, intended to make decisions or formulate problems, take actions, or create awareness. Examples include status reports, 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. A knowledge area is a comprehensive system of concepts, terms and activities that make up a professional area, a project management area, or a field of activity. These 10 areas of knowledge are almost always used in most projects. Project teams should use these 10 knowledge areas and other knowledge areas 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 communication management
Project risk management
Project procurement management
management of project stakeholders.
4. PROJECT INTEGRATION MANAGEMENT
Project integration management includes the processes and activities needed to define, refine, combine, combine, and coordinate the various project management processes and activities within the project management process groups.
The project charter contains:
Purpose or justification of the project;
measurable project objectives and related success criteria;
High-level requirements
· Assumptions and restrictions;
High-level description and boundaries of the project;
High-level risks
enlarged schedule of control events;
The enlarged budget
a list of interested parties;
· requirements for project approval (i.e. what exactly constitutes the success of the project, who decides that the project was successful, and who signs the project);
Appointed project manager, area of responsibility and level of authority;
· FULL NAME. and the authority of the sponsor or other person(s) authorizing(s) the project charter.
Description of works(statement of work, SOW) of a project is a verbal description of the products, services, or results that the project is to produce.
SOW reflects:
· Business need. An organization's business need may be based on market demand, technological advances, legal requirements, government regulations, or environmental considerations. Typically, a business need and a cost-benefit comparison are included in the business case to justify the project.
· Description of the content of the product. The product scope description includes the characteristics of the product, service, or outcome that the project is attempting to create. The description should also reflect the relationship between the products, services, or results being created and the business need that the project is intended to 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 aligned with the organization's strategic plan. Alignment 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 business information to determine whether a project is worth the required investment. It is commonly used by superiors in relation to the project to make decisions. Typically, a business case contains a business need and a comparative cost-benefit analysis to justify the project and define its boundaries, and usually a business analyst performs this analysis using various information received 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:
a market demand (for example, an automaker authorizes a project to make more fuel-efficient cars in response to a shortage of gasoline);
the need of the organization (for example, due to high overhead costs, the company can combine the functions of personnel and optimize processes to reduce costs);
· customer requirement (for example, an electric company authorizes a project to build a new substation to supply electricity to a new industrial area);
· technological progress (for example, an airline authorizes a new project to develop e-tickets to replace paper-based tickets based on technological advances);
· a legal requirement (for example, a paint manufacturer authorizes a project to develop guidelines for the handling of toxic materials);
· environmental impacts (for example, a company authorizes a project to reduce its environmental impact);
· a social need (for example, an NGO in a developing country authorizes a project to provide drinking water, toilets, and health education to communities suffering from high levels of cholera cases).
Agreements
Agreements are used to define the initial intentions for a project. Agreements may 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, the contract is used if the project is carried out for an external customer.
Enterprise environmental factors
Enterprise environmental factors that may influence the project charter development process include, but are not limited to:
· government and industry standards or regulations (eg codes of conduct, quality standards or worker protection standards);
organizational culture and structure;
the market situation.
Organization Process Assets
Organizational process assets that can influence the project charter development process include, but are not limited to:
standard organization processes, policies and process descriptions;
Templates (for example, a project charter template)
historical information and knowledge base (for example, projects, records and documents, all project closure information and documentation, information on the results of previous project selection decisions along with information on the performance of previous projects, and 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 subplans and baselines resulting from planning processes.
The basic plans for the project include, among others:
Basic content plan
basic schedule;
basic cost plan.
Ancillary plans include but are not limited to:
content management plan
Requirements management plan
schedule management plan
Cost management plan
a quality management plan;
Process improvement plan
· human resource management plan;
a communications management plan;
· risk management plan;
Procurement management plan
· Stakeholder management plan.
Among other things, the project management plan may also include the following:
· the life cycle selected for the project and the processes that will be applied in each phase;
Details of tailoring decisions made by the project management team, namely:
o Project management processes selected by the project management team;
o the level of implementation of each selected process;
o descriptions of the tools and methods that will be used to carry out these processes;
o A description of how the selected processes will be used to manage a specific project, including the dependencies and interactions between these processes, as well as the required inputs and outputs.
the procedure for performing work to achieve the goals of the project;
a change management plan that documents how changes are monitored and controlled;
a configuration management plan that documents how configuration is managed;
description of the procedure for maintaining the integrity of base plans;
· requirements and methods of communication between interested parties;
· key management review activities with regard to content, boundaries and timeframes to address existing issues and pending solutions.
Schedule Forecasts
Schedule forecasts are based on progress against the baseline schedule and estimated forecast time to completion (ETC). They are usually expressed as a timing deviation (RTD) and a timing performance index (TDI). For projects that do not use earned value management, deviations from planned and predicted finish dates are indicated.
The forecast can be used to determine if a project is within the tolerance range and identify necessary change requests.
Cost Predictions
Cost projections are based on progress against the baseline cost plan and the estimated forecast to completion (CPC). They are usually expressed as a cost variance (CVA) and a cost performance index (CFI). The Forecast-on-Completion (PCF) can be compared with the Budget-on-Completion (BPC) to determine if a project is within tolerance or if change requests need to be made. For projects that do not use earned value management, variances from planned and actual costs, as well as the projected final cost, are provided.
The following are some of the configuration management activities included in the integrated change control process:
· Configuration definition. Define and select configuration items to provide a basis from which product configuration is defined and validated, products and documents are tagged, change is managed, and accounted for.
· Reporting on configuration status. Where relevant information about a configuration item needs to be provided, the information is documented and reported on. Such information includes a list of approved configuration items identified, the status of proposed configuration changes, and the implementation status of approved changes.
· Validate and audit the configuration. Configuration Validation and Audits ensure that the design of the project's configuration items is correct and that the corresponding changes are logged, evaluated, approved, tracked, and properly implemented. This ensures that the functional requirements defined in the configuration documentation are met.
5. PROJECT SCOPE MANAGEMENT
Project Scope Management includes the processes required to ensure that a project contains all and only the work required to complete the project successfully. 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 refer to:
Requirements classes:
· Business requirements that describe the high-level needs of the organization as a whole, such as the organization's problems or opportunities, and the reasons why the project was undertaken.
· Stakeholder requirements, which describe the needs of a stakeholder or stakeholder group.
· Solution requirements that describe the features, functions, and characteristics of a product, service, or result that will satisfy 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 the functional requirements and describe the conditions or qualities of the environment necessary to ensure the effectiveness of the product. Examples include: reliability, security, performance, security, service level, supportability, retention/destruction requirements, etc.
· Transition requirements describe temporal capabilities, such as data transformation and training requirements, required to transition from the current "as is" state to the "as it should be" state in the future.
· Project requirements describe the activities, processes, or other conditions that the project must meet.
· Quality requirements, which include any condition or criteria necessary to confirm successful delivery of a project deliverable or other project requirements.
6. PROJECT TIME MANAGEMENT
Project time management includes the processes necessary to ensure that the project is completed on time.
Operation Dependency Types:
· Finish start(finish-start, FS). A logical relationship in which the start of the next activity depends on the finish of the previous activity. Example: the awards ceremony (subsequent operation) cannot be started until the race of the preceding operation has ended).
· finish-finish(finish-finish, FF). A logical relationship in which the finish of the subsequent operation depends on the finish of the predecessor operation. Example: the creation of a document (prior operation) must be completed before its editing is completed (subsequent operation).
· Start-start(start-start, SS). A logical relationship in which the start of the subsequent operation depends on the start of the predecessor operation. Example: Leveling a concrete surface (subsequent operation) cannot start before pouring the foundation (preceding operation).
· start-finish(start-finish, SF). A logical relationship in which the finish of the subsequent operation depends on the start of the previous operation. Example: The first guard shift (subsequent operation) cannot end until the second guard shift (preceding operation) begins.
Three-Point Assessment
The accuracy of one-point activity duration estimates can be improved by considering estimation uncertainties and risks. This concept comes from the program evaluation and review technique (PERT). PERT uses three estimates to determine the approximate range of operation duration:
· Most likely(tM). The duration of an operation is determined by taking into account the pre-allocation of resources, their performance, a realistic assessment of their availability to perform this operation, dependencies on other participants, as well as taking into account interruptions in work.
· optimistic(to). The duration of the operation is based on the analysis of the best-case scenario for the operation.
· Pessimistic(tP). The duration of the operation is based on a worst case scenario analysis for the operation.
Being dependent on the expected distribution of values in the range of three estimates, the expected duration, tE, is calculated by the formula. The two most common formulas are the triangular distribution and the 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 is a method used to estimate the minimum duration of a project and determine the degree of scheduling flexibility on logical paths in a network within a scheduling model. The schedule network analysis method calculates the early start and finish dates, as well as the late start and finish dates for all activities without regard to resource constraints, by performing a forward and backward pass analysis through the project network, as shown in Fig. 6-18. In this example, the longest path includes activities A, C, and D, and so the sequence A-C-D is the critical path. The critical path is a sequence of activities that is the longest path in the project schedule and that defines the shortest possible project duration. The early start and finish dates obtained are not necessarily the project schedule; rather, they indicate the time periods within which an operation can be performed, using parameters entered into the schedule model related to operation durations, logical links, leads, delays, and other known limitations. Critical method
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 schedule development technique that allows the project team to place buffers on any path in the schedule to account for resource constraints and uncertainties associated with the project. 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 an activity on the critical path as 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 limits, logical connections, and resource availability with
Statistically defined buffers that include the overall safety margins for operations at specific points in the project along the project schedule path to account for limited resources and uncertainty associated with the project. A critical path with resource constraints is known as a "critical chain".
7. PROJECT COST MANAGEMENT
Project cost management includes the processes required for planning, estimating, budgeting, raising funds, 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 scope, schedule and resource assessments to measure project progress and performance. This is a widely used method for measuring project performance. It combines a scope baseline with a cost baseline and a project schedule baseline to form a performance baseline that allows the project management team to evaluate and measure project performance and progress. It is a project management method that requires the formation of 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 develops and monitors the following three key metrics for each work package and control account:
· Planned volume. Planned volume (PV) - the authorized budget allocated for planned activities. This is the authorized budget allocated for the work to be completed in an activity or work breakdown structure component, excluding management allowance. This budget is allocated to the phases in the life cycle of the project, but at some point the planned scope determines the physical work that needs to be done. The cumulative software is sometimes referred to as a performance measurement baseline (PMB). The total project budget is also known as the budget at completion (BFC).
· Earned value. Earned Value (EV) - the amount of work performed, expressed in terms of the authorized budget allocated for this 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 percent complete of a project. For each component of the WBS, criteria for measuring the progress of work performed should be established. Project managers monitor the TOE both incrementally to determine current status and cumulatively to determine long-term performance trends.
· actual cost. Actual cost (FC) - the actual costs incurred to perform work within an operation for a certain period of time. These are the total costs incurred in performing the work measured by the TOE. FS, by definition, should correspond to what was included in the software and measured by the TOE (for example, only direct costs of working hours, only direct costs, or all costs, including indirect ones). The FS has no upper bound; everything that is expended to achieve the TOE is measured.
Deviations from the approved baseline are also monitored:
· Timing deviation. Timing variance (RTV) is a schedule performance indicator expressed as the difference between earned value and planned value. The amount of time the project is behind or ahead of the planned delivery date at a particular point in time. It is a measure of project schedule execution. Its value is equal to the earned value (OO) minus the planned value (PV). Timing variance in EVM is a useful metric in that it shows when a project is behind or ahead of its baseline. The timing variance in the EVM will eventually be zero at the end of the project, since all the planned volumes should have been mastered by that time. Timing variance is best used in conjunction with Critical Path Method (CPM) scheduling and risk management. Formula: OSR \u003d OO - PO
· Cost deviation. Cost variance (CV) is the amount of budget deficit or surplus at a given point in time, expressed as the difference between earned value and actual cost. It is a measure of the cost effectiveness of a project. It is equal to earned value (EV) minus actual cost (FC). The cost variance at the end of the project will be equal to the difference between the budget at completion (BPC) and the amount actually spent. The OST is extremely important as it demonstrates the relationship between physical performance and funds spent. Negative OST is often not recoverable for the project. Formula: OST \u003d OO - FS.
The OSR and TSR values can be converted to performance measures to reflect the cost and timing performance of any project compared to all other projects or within a portfolio of projects. Deviations are useful for determining the status of a project.
· Deadline performance index. Timing Completion Index (TII) is an indicator of schedule performance, expressed as the ratio of earned value to planned value. It measures how efficiently the project team uses its time. It is sometimes used in conjunction with the Cost Fulfillment Index (CFI) to predict final project completion estimates. A WRI value less than 1.0 indicates that less work has been completed than planned. A WPI value greater than 1.0 indicates that more work has been completed than planned. Since the RIMS measures all project work, it is also necessary to analyze the performance on the critical path to determine whether the project will be completed before or after its planned finish date. RIVR is equal to the ratio of OO to software. Formula: IVSR \u003d OO / PO
· Cost execution index. Cost Performance Index (CFI) is a cost performance measure of budgeted resources expressed as a 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 PVCT value less than 1.0 indicates an overrun for the work performed. A PICT value greater than 1.0 indicates an underutilization of funds when executed on a specific date. RIVR is equal to the ratio of the TOE to the FS. Indices are useful for determining the status of a project, and also provide a basis for estimating the overall timing and cost of a project. Formula: IVST = OO / FS
The three indicators of planned value, earned value and actual cost can be monitored and reported periodically (usually weekly or monthly) or cumulatively.
Forecasting
As the project progresses, the project team may develop a budget-at-completion (CPC) that may differ from the budget-at-completion (BPC) based on project performance. If it becomes apparent that the BPP is no longer realistic, the project manager should review the PPP. The development of a PPP involves forecasting the conditions and events that will occur in the future of the project, based on information about current performance and other knowledge available at the time of forecasting. Forecasts are generated, updated and re-issued on the basis of
performance data obtained as the project progresses. Work performance information covers the past performance of the project and any information that may affect the project in the future.
The PPP is usually calculated as the actual cost accounted for for the completed work plus the forecast to completion (EPC) of the remaining work. The project team is charged with the responsibility of predicting what it may encounter during the implementation of the EAP, based on current experience. The EVM method works well together with manually developed forecasts of the required LTF. The most widely used KPP forecasting approach is manual bottom-up summation by the project manager and project team.
The bottom-up PPP method used by the project manager is based on actual cost accounting and experience gained from work performed and requires a new forecast to be made before completion for the remaining work of the project. Formula: PPP \u003d FS + PDZ "bottom up".
The PPV, manually developed by the project manager, is quickly compared to a set of calculated PPVs representing a variety of risk scenarios. When calculating the values of PPV, as a rule, the cumulative values of TIWT and TIVR are used. Although EVM data provide many statistical PPVs quickly, only the three most common methods are described below:
· PPP for PPP works performed at budgeted rates. This PPP method uses the actual project performance on a specific date (good or bad), represented by actual cost, and predicts that all future PPP work will be completed at budgeted rates. Where actual performance is unfavorable, the assumption that future performance will improve should only be accepted if this is supported by the risk analysis of the project. Formula: PPZ = FS + (BPZ - OO)
· PPP for PPP works performed with the current IVST. This method assumes that the project will continue in the future in the same way that it has proceeded up to this point. It is assumed that the EP activities will be performed at the same Cumulative Cost Performance Index (CPI) level as the project has achieved to date. Formula: PPZ = BPZ / IVST
· PPZ for PDZ works, taking into account both factors PVSR and CVST. In this forecast, the work of the PD will be performed with an efficiency that takes into account the performance indices of both cost and timing. This method is most useful when one of the factors influencing the EAP is the project schedule. Variations of this method consider the RVSI and RVSR in various ratios (eg 80/20, 50/50 or other proportions), according to the opinion of the project manager. Formula: PPZ = FS + [(BPZ - OO) / (IVST x EVSR)]
Each of these approaches can be applied to any given project and provide the project management team with an "early warning" signal if the PPPs are outside the accepted tolerances.
Performance to Completion Index (PPI)
Performance index to completion(IBPI) is the estimated cost performance of the project that must be achieved with the remaining resources in order to achieve the established management target, expressed as the ratio of the cost of completing the remaining part of the work to the remaining budget. The BPI is a calculated cost performance index that must be achieved on the remaining jobs to achieve a specific management goal, such as a BPP or a BPP. If it becomes apparent that the BPP is no longer realistic, the project manager should review the PPP. Once approved, the PPP may replace the BPI in the calculation of the EITI. The formula for the BPHI based on the BPZ is (BPZ - GS)/(BPZ - FS). The EITI is conceptually represented in the figure below. The formula for the EITI is shown in the lower left corner as the work remaining (defined as BPV minus QA) divided by the funds remaining (which can be calculated as either BPV minus FS or RP minus FS).
If the cumulative TFI is below the baseline (as shown in the figure below), all future work on the project must immediately be carried out in accordance with the EITI (BOI) (as reflected in the top line of the figure below) in order to remain within the authorized BPO. Whether a given level of performance is achievable is judged based on a number of considerations, including risk, schedule and technical performance. This level of performance is depicted as a line of IPDZ (PPZ). The formula for a PPP-based PPP is (BPP - GS)/(PPP - FS). The EVM formulas are presented in the table below.
Performance analysis
Performance analysis compares cost performance over time, schedule activities or work packages that are over or under budgeted, and estimates of the cash needed to complete the work being performed. If an EVM is used, then the following information is defined:
· Analysis of deviations. Variance Analysis, when used in EVM, is the clarification (cause, impact, and corrective actions) of variances for cost (CTS = TS - FS), schedule (SSR = TS - TS) and variances at completion (CPV = BPV - CPV). The most frequently analyzed deviations are cost and timing. For projects that do not apply earned value management, a similar variance analysis can be performed by comparing the planned cost of an operation with the actual cost of the operation to determine the variances between the actual project execution and the cost baseline. Further analysis can be performed to determine the cause and extent of the deviation from the baseline and the necessary corrective or preventive actions. Cost fulfillment measurements are used to estimate the amount of deviation from the original cost baseline. 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 and more work is done, the percentage tolerance range will tend to decrease.
· Trend analysis. 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 on a specific date and for comparison with future performance targets in the BPO versus PPP and completion date formats.
· Earned value execution. Earned value execution involves comparing a baseline performance plan against actual time and cost performance. If EVM is not used, then cost baseline analysis against actual cost of work performed is used to compare cost execution.
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 continual improvement activities of the processes undertaken by the performing organization. Project quality management aims to ensure that project requirements, including product requirements, are met and verified.
Quality and grade are conceptually different concepts. Quality as a deliverable output or result is “the degree to which a set of inherent characteristics conforms to requirements” (ISO 9000). A grade as a design intent is a category assigned to deliverables that have the same functionality but different specifications. The project manager and the project management team are responsible for reaching trade-offs to ensure 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 seek to minimize deviations and achieve results that meet certain requirements. These approaches recognize the importance of the following:
· Customer satisfaction. Understanding, evaluating, identifying and managing customer requirements to meet customer expectations. This requires a combination of suitability (the project must produce what it was undertaken for) and usability (the product or service must meet real needs).
· Prevention is more important than inspection. Quality should be planned, developed and built in, not inspected in project management or delivery of project deliverables. The cost of preventing errors is generally much lower than the cost of correcting them once discovered through inspection or in use.
· Continuous improvement. The plan-do-check-act (PDCA) cycle, a model described by Shewhart and improved by Deming, is the basis for quality improvement. In addition, quality improvement initiatives such as Total Quality Management (TQM), Six Sigma, and Lean Six Sigma combined can improve the quality of 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®).
· Management responsibility. Success requires the participation of all members of the project team. However, management retains, under the responsibility for quality, the appropriate responsibility for providing the right resources in the right amount.
· The cost of quality(cost of quality, COQ). The cost of quality is the total cost of compliance work and non-compliance work that must be done as a compensatory effort because the first time that work is attempted, there is the potential that some of the required amount of work may or may not have been done incorrectly. . The cost of performing quality assurance activities can occur throughout the life cycle of a deliverable. For example, decisions made by the project team can affect the operational costs associated with using a completed deliverable. Post-closing quality costs can arise from product returns, warranty claims, and product recall campaigns. Thus, due to the temporary nature of the project and the potential benefit that can be gained from reducing the post-project cost of quality, sponsoring organizations may decide to invest in improving product quality. These investments are typically made in the area of compliance work to prevent defects or reduce the cost of defects by inspecting non-conforming units. 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 methods of allocation of 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 related issues. Rice. below is a conceptual illustration of the seven main quality tools, which include:
· Cause-and-effect diagrams, also called fishbone 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 requiring action. A problem description is usually a statement of the problem as a gap to be fixed or a goal to be achieved. Cause searching is done 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 helpful when trying to correlate undesirable effects seen as a particular variation with an identified cause for which project teams need to take corrective actions to eliminate that particular variation found on the control chart.
· Flowcharts, also called process maps, because they show the sequence of steps and branching possibilities of a process that transforms one or more inputs into one or more outputs. Flowcharts reflect the operations, decision points, cycles, parallel paths, and order of execution of processes by representing, as a map, the operational details of the procedures that exist within the horizontal value chain of the SIPOC model. Flowcharts can be helpful in understanding and estimating the cost of quality within a process. This is achieved by using the workflow branching logic and its associated relative frequencies to estimate the expected monetary value of compliance work and non-compliance work required to provide a conforming output.
· data collection sheets, also known as counting sheets, can be used as checklists when collecting data. Data Collection Sheets are used to organize facts in a way that will effectively capture useful data about a potential quality issue. They are especially useful for capturing parameter data during inspections to identify defects. For example, data on the incidence or consequences of defects collected using data collection sheets is often displayed using Pareto charts.
· Pareto charts are specially shaped vertical bar charts and are used to identify the few most important sources that cause most of the effects of a problem. The categories shown on the horizontal axis represent the existing probability distribution considering 100% of the possible observations. The value of the corresponding frequency of occurrence of each labeled cause, shown on the horizontal axis, decreases until reaching the default source called "other", which is responsible for unspecified causes. Typically, a Pareto chart is organized into categories that measure either the frequency of occurrence or the consequences.
· Histograms is a special kind of bar chart used to describe the center of distribution, variance, and the shape of a statistical distribution. Unlike a control chart, a histogram does not take into account the effect of time on the variation that exists within a distribution.
· Control cards are used to determine whether a process is stable or not and whether it performs predictably. The lower and upper limits given by the specification are based on the requirements set out in the agreement. They reflect the maximum and minimum allowable values. Penalties associated with the output of values beyond the boundaries set by the specification may be imposed. The upper and lower control limits differ from the limits given by the specification. Control limits are established using standard statistical calculations and principles in order to finally determine the natural possibility of stabilizing the process. The project manager and relevant stakeholders can use statistically calculated control limits to determine points at which corrective actions will be taken to prevent unnatural performance. The purpose of corrective action is usually 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 has been set to 0. A process is considered out of control if: (1) the data point is outside the control limits; (2) seven consecutive dots are above the midline; or (3) seven consecutive dots are below the midline. Control charts can be used to control various types of output variables. While most commonly used to track the repetitive activities required to manufacture industrial products, they can also be used to control cost and schedule variances, volume and frequency of scope changes, or other management outputs to help determine if project management processes are under control. .
· Scatterplots 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), reverse (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.
Quality management and 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 tools available include:
· Affinity Diagrams. An affinity diagram is similar to mind mapping in that it is used to generate ideas that can be combined to form an ordered way of thinking about a problem. In the project management process, the creation of a WBS can be improved by using an affinity diagram to structure the content decomposition.
· Diagrams of the program implementation process(process decision program charts, PDPC). Used to understand the goal in relation to the actions taken to achieve the goal. PDPC is a useful technique for loss planning, as it helps teams anticipate intermediate steps that may be holding them back from reaching their goal.
· Oriented Relationship Graphs. Adaptation of relationship diagrams. Oriented Relationship Graphs are a process of creative problem solving in moderately complex scenarios characterized by intertwined logical relationships of up to 50 related items. A directed relationship graph can be built from data obtained from other tools such as an affinity diagram, a tree diagram, or a fishbone diagram.
· Tree diagrams. Also known as systematic diagrams, they can be used to show the decomposition of hierarchies such as WBS, risk breakdown structure (RBS), and 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 reporting relationships. Tree diagrams can be horizontal (eg risk hierarchy) or vertical (eg team hierarchy or OBS). Because tree diagrams allow for 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.
· Priority matrices. Used to identify key issues and suitable alternatives to prioritize as a set of solutions for implementation. The criteria are prioritized and weighted before being applied to all available alternatives in order to obtain a mathematical score to rank all alternatives.
· Operations network diagrams. Formerly known as arrow charts. They include such network diagram formats as operations on arcs (activity on arrow, AOA) and the most commonly used operation format on nodes (activity on node, AON). Activity network diagrams are used with project scheduling methods such as Program Evaluation and Review Method (PERT), Critical Path Method (CPM), and Precedence Diagram Method (PDM).
· Matrix charts. A management and quality control tool used to analyze data within the organizational structure created in the matrix. With the help of a matrix diagram, they seek to show the strength of dependencies between factors, causes, and goals, displayed in a matrix in the form of rows and columns.
9. PROJECT HUMAN RESOURCE MANAGEMENT
Project Human Resource Management includes the processes of organizing, managing and leading the project team. The project team consists of people who have defined roles and responsibilities for the implementation of the project. Project team members may have different skill sets, may be full-time or part-time, and may be added to or removed from the team as the project progresses. Project team members can also be referred to as 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. Involving team members allows them to use their existing experience in project planning and strengthens the team's focus on achieving project results.
Organizational charts and job descriptions
There are various formats for documenting the distribution of roles and responsibilities of team members. Most formats fall into one of three types: hierarchical, matrix, and text. In addition, some project assignments appear 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 each work package has an unambiguous responsibility for its execution and that each team member clearly understands their role and responsibilities. For example, a hierarchical format can be used to represent high-level roles, a text format is better for documenting areas of responsibility in detail.
The Human Resource Management Plan includes, among other things:
· Roles and responsibilities. When listing the roles and responsibilities required to carry out a project, consider the following:
o Role. A feature accepted by an employee 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 Authority. The right to commit project resources, make decisions, sign approvals, accept deliverables, and influence other team members to carry out project work. Examples of decisions that require clear and concise authority include choosing how to perform an operation, accepting quality, and how to respond to design deviations. Team members perform better when the level of authority of each of them corresponds to their individual area of responsibility.
o Responsibility. The assigned duties and work that a project team member must perform to complete project activities.
o Qualification. The skills and abilities required to perform assigned activities within project constraints. If the members of the project team do not have the necessary qualifications, then the project may be in jeopardy. If such discrepancies are identified, preventive actions should be taken, such as training, hiring qualified specialists, or making appropriate changes to the schedule or scope of the project.
Project organization charts. A project org chart is a graphical representation of the composition of a project team and the reporting relationships between its members. Depending on the requirements of the project, it can be formal or informal, detailed or generalized. For example, a project org chart for an emergency response team of 3,000 people will be significantly more detailed than an internal project org chart with a team of 20 people.
· Staffing plan. The staffing plan is a component of the human resource management plan that describes when and how project team members will be recruited and for how long they will be needed. It describes how to meet human resource requirements. Depending on the requirements of the project, the staffing plan can be formal or informal, detailed or generalized. This plan is constantly updated during the course of the project to reflect ongoing activities to replenish and develop the project team. The information contained in the staffing plan varies depending on the application area and the size of the project, but in any case should include the following elements:
o Recruitment. When planning the recruitment of project team members, a number of questions arise. For example, will the existing human resources of the organization be used or will they be recruited from outside on a contractual basis; whether team members will be working in the same location or they can work remotely; what is the cost corresponding to each skill level required for the project; and what is the level of project team support that the organization's human resources department and functional leaders can provide.
o Resource calendars. Calendars that determine the availability of a particular resource on certain working days and shifts. The staffing plan specifies the timing of the engagement of project team members, both individually and collectively, as well as the timing of when recruitment activities, such as hiring staff, should begin. One tool for graphing human resources is the resource bar chart, used by the project management team as a means of visualizing or allocating resources to all stakeholders. This chart displays the number of hours a person, department, or entire project team needs each week or month for the duration of the project. The chart may include a horizontal line representing the maximum number of hours calculated for a particular resource. If the bars in the chart are outside the maximum available hours, then a resource optimization strategy needs to be applied, such as allocating additional resources or rescheduling.
o Staff release plan. Determining how and when to release team members from project responsibilities is beneficial to both the project and team members. When team members are exempted from participating in a project, this eliminates payments to employees who have already completed their share of the work in the project, and thus reduces the cost of the project. The overall moral climate improves if a smooth transition to new projects is already planned in advance. A staff release plan can also reduce human resource risks that may arise during the implementation or at the end of the project.
o Training needs. If there are concerns that the qualifications of the team members assigned to the project may not be sufficient, then a staff 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 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 support the desired behavior of the people involved in the project. For recognition and rewards to be effective, they must be based on the actions, performance, and performance under the individual's control. For example, a team member can only be rewarded for meeting a certain cost rate if they have sufficient authority to control the decisions that affect the cost. Creating a plan with reward timing ensures that the reward is not forgotten. Recognition and rewards are part of the project team development process.
o Compliance. The staffing management plan may include strategies to ensure that the project complies with existing government regulations, labor contract terms, and other established human resource policies.
o Safety. 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 come in order, but it is not uncommon for a team to get stuck at a particular stage or fall back to an earlier one. In projects where team members have previously worked together, certain stages may be skipped.
· Formation. At this stage, the team comes together and learns about the project and their formal roles and responsibilities in it. Team members in this phase tend to be independent of 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 collaborative and open to different ideas and perspectives, the environment can become unproductive.
· Settlement. During the adjustment stage, team members begin to work together and adjust their work habits and behaviors to facilitate teamwork. Team members learn to trust each other.
· Efficiency. Teams that have reached the performance stage function as a well-organized unit. They are independent and solve problems calmly and effectively.
· Completion. At this stage, the team completes the work and moves on to the next project. This usually happens when people are released from the project after deliverables have been completed, or as part of the project closure process or phase.
The duration of each specific stage depends on the dynamics, strength and leadership of the team. Project managers must have a good understanding of the dynamics of the development of the team in order to facilitate the effective passage of team members through all stages.
There are five main methods used to resolve conflicts.
Since each has its own purpose and application, the methods are listed in no particular order:
· Evasion/avoidance. Departure from an actual or potential conflict situation, postponing the solution of the problem to a later date in order to better prepare for its resolution or transfer its resolution to others.
· Smoothing/fitting. 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. The search for solutions that will be to a certain extent satisfactory for all parties in order to temporarily or partially resolve the conflict.
· Coercion / instructions. Lobbying for 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 resolution. Combining many points of view and views from different perspectives, the need for cooperation and open dialogue, which usually leads to consensus and support for the decision by all parties.
Examples of Interpersonal Skills that are most commonly used by the project manager include:
· Leadership. Developed leadership skills are required for the success of a project. Leadership is important in all phases of the project life cycle. There are many theories of leadership that define leadership styles, which, if necessary, each team should use in the appropriate situation. It is especially important to communicate the overall vision of the project to team members 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 matrix terms, their ability to influence project stakeholders in a timely manner is critical to project success. Key influencer skills include:
o the ability to convincingly and clearly state the point of view and position;
o a high level of active and effective listening skills;
o understanding and considering different perspectives in any situation;
o collecting 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. The following are some of the recommendations for decision making:
o need to focus on the goals to be achieved;
o Decision-making procedures must be followed;
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 risk needs to be managed.
10. PROJECT COMMUNICATION MANAGEMENT
Project communications management includes the processes necessary to ensure the timely and proper planning, collection, creation, distribution, storage, receipt, management, control, monitoring and ultimately archiving/disposal of project information. Project managers spend most of their time communicating with team members and other project stakeholders, whether they are internal (at all levels of the organization) or external to the organization. Effective communications create a bridge between different stakeholders who may have different cultural and organizational backgrounds, different levels of knowledge, and different views and interests that affect or may have an impact on project execution or outcomes.
Factors that may influence the choice of communications technology include:
· The urgency of obtaining information. The urgency, frequency and format of the information to be communicated must be taken into account, as these may vary from project to project and also at different stages of the same project.
· Availability of technology. It must be ensured that the technology required to enable communication is compatible and available to all stakeholders throughout the life of the project.
· Ease of use. It must be ensured that the communication technologies chosen are suitable for the project participants and that appropriate training activities 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 communications.
· Secrecy and confidentiality of information. It is necessary to determine whether the information being transferred is classified or confidential and whether additional measures are required to protect it. Consideration should also be given to the most appropriate means of conveying such information.
The basic communication model has the following sequence of steps:
· Coding. Transformation (coding) of thoughts or ideas into a code language by the sender.
· Sending a message. Sending information by the sender using the information channel (information transmission medium). Various factors (such as distance, unfamiliar technology, insufficient infrastructure, cultural differences, and lack of additional information) can prevent this message from being transmitted. These factors are collectively referred to as noise.
· Decoding. The message is translated back into meaningful thoughts and ideas by the recipient.
· Confirmation. After receiving the message, the recipient may send a signal (acknowledgment) that the message has been received, but this does not necessarily mean that the message is accepted or understood.
· Feedback/Answer. When the received message is decoded and understood, the receiver converts (encodes) the thoughts and ideas into a message and relays the message to the original sender.
Several methods of communication are used to disseminate information among project stakeholders.
These methods can be divided into the following large groups:
· Interactive communications. Between two or more parties engaged 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, calls, instant messages, video conferences, etc.
· Communication by informing without request. Information is sent to specific recipients who need to receive it. This method ensures the dissemination of information, but does not guarantee that it will actually be received or understood by the intended audience. Unsolicited communications include letters, notes, reports, e-mails, faxes, voicemail messages, blogs, press releases, etc.
· On-demand communication. Used for very large volumes of information or for very large audiences, and require recipients to access the transmitted content at their own will. Such methods include intranet sites, e-learning, lessons learned databases, knowledge repositories, etc.
Methods and aspects of effective communications management include, but are not limited to:
The sender-receiver model. Implement feedback loops to provide favorable opportunities for engagement/participation and remove communication barriers.
· Choice of means of communication. Situational choices about when to communicate verbally and when in writing, when to prepare informal notes and when to make a formal report, and when to talk in person versus email.
· Style of writing. The use of active or passive voice, sentence structure, choice of words.
· Meeting management methods. Preparing the agenda and dealing with conflicts.
Presentation methods. Awareness of the impact of body language and development of visual aids.
· Methods of organizing group work. Reaching consensus and overcoming obstacles.
· Listening methods. Active listening (confirmation, clarification and verification of understanding) and removal of barriers that can distort understanding.
11. PROJECT RISK MANAGEMENT
Project risk management includes the processes associated with risk management planning, identification, analysis, response planning, and project risk control. The objectives of project risk management are to increase the likelihood and impact of favorable events and to reduce the likelihood and impact of adverse events during project implementation.
Project risk is an uncertain event or condition whose occurrence negatively or positively affects the objectives of the project, such as scope, schedule, cost, and quality. A risk may be due to one or more causes and, if it occurs, may affect one or more aspects.
Risk Management Plan is a component of the project management plan that describes how risk management activities will be structured and performed. The risk management plan includes the following elements:
· Methodology. Determination of approaches, tools and data sources that will be used to manage risks in this project.
· Roles and responsibilities. Identifying the leading team members, supporting team members, and risk management team members for each activity included in the risk management plan, and clarifying their responsibilities.
· Budget development. Estimation of the necessary funds, taking into account the allocated resources, to be included in the base plan at cost and development of procedures for the use of the reserve for possible losses and the management reserve.
· Definition of terms. Determining the timing and frequency of risk management processes throughout the life cycle of the project, developing procedures for the use of schedule reserves for possible losses, as well as determining the risk management activities that will be included in the project schedule.
· Categories of risks. Provides a means to classify potential sources of risk into groups. Several approaches can be used, such as a structure based on project objectives by category. The Risk Hierarchy Structure (RBS) helps the project team to consider the many sources from which project risks may arise during the risk identification process. Different types of projects correspond to different RBS structures. The organization may use a pre-designed risk categorization scheme, which may take the form of a simple list of categories or in the form of an RBS. RBS is a hierarchical representation of risks according to risk categories.
· Determining the likelihood and impact of risks. A good and credible risk analysis involves identifying different levels of likelihood and impact of risks in the context of a project. Generic definitions of probability levels and impact levels are tailored to a specific project during the risk management planning process and then used in subsequent processes. The table below provides an example of the 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 shows both relative and numerical (in this case, non-linear) approaches.
· Probability and Impact Matrix. The Probability and Impact Matrix is a table showing the likelihood of each risk occurring and its impact on the project objectives if it occurs. Risks are prioritized according to their likely consequences, which may affect the objectives of the project. A typical way to prioritize is to use a lookup table or probability and impact matrix. Typically, the organization itself determines the combinations of probability and impact, on the basis of which the risk level is determined as “high”, “medium” or “low”.
· Refined stakeholder tolerance. During the risk management planning process, stakeholder tolerance can be adjusted to suit a specific project.
· Reporting formats. The reporting formats determine how the results of the risk management process will be documented, analyzed and shared. The reporting formats describe the content and format of the risk register, as well as any other required risk reports.
· Tracking. Tracking documents how all risk-related activities are recorded for the purposes of a given project, and when and how risk management processes will be audited.
Chart Methods
Risk diagram methods include:
· Diagrams of cause-and-effect relationships. These diagrams, also known as Ishikawa diagrams or fishbone diagrams, are used to identify the causes of risks.
· Flowcharts of a process or system. This type of graphic display demonstrates the order of interaction of various elements of the system with each other and their cause-and-effect relationships.
· Influence diagrams. Graphical representation of situations showing cause and effect 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 (SWOT), which makes the identification of risks more complete, taking into account the risks within the project. When using this method, one begins by identifying the strengths and weaknesses of the organization, focusing on either the project, or the organization, or the business area as a whole. The SWOT analysis then identifies any project opportunities that come from the organization's strengths, as well as any threats that come from its weaknesses. This analysis also examines how the organization's strengths offset 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. The risk register is a document containing the results of risk analysis and risk response planning. The risk register captures the results of other risk management processes as they are implemented, 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 during the risk identification process, during which the register is populated with the following information. 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 may use a specific structure to describe the risks, for example: an EVENT may occur that will have an IMPACT, or if there is a CAUSE, an EVENT may occur that will have an CONSEQUENCE. In addition, when building a list of identified risks, the root causes of these risks may become more apparent. These are fundamental conditions or events that are capable of triggering one or more of the identified risks. They should be recorded and used to support future risk identification in this and other projects.
· List of possible responses. Sometimes the process of identifying risks can identify possible responses to them. Such response measures, 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 action by evaluating and comparing their impact and likelihood of occurrence. A key benefit of this process is that it allows project managers to reduce uncertainty and focus on high-priority risks.
Quantitative risk analysis- the process of numerical analysis of the impact of identified risks on the objectives of the project as a whole. A key benefit of this process is that it provides quantitative risk information to support decision making in order to reduce project uncertainty.
Methods for collecting and presenting information
· Conducting an interview. Interview techniques provide experience and historical data to quantify the likelihood and impact of risks on project objectives. The required information depends on the type of probability distribution used. For example, for some of the most widely used distribution models, you need to collect information about the optimistic (low probability), pessimistic (high probability), and most likely scenario. Documenting the justifications for risk ranges and their associated assumptions is an important element of the risk interview as these documents allow inferences to be made 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 uncertain events, such as test results or possible decision tree scenarios. On fig. Below are two examples of commonly used continuous distributions. Such distributions describe patterns that are consistent 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, such as at an early design stage.
Methods for quantitative analysis and risk modeling
Widely used methods use both event-driven and project-driven approaches to analysis, including:
· Sensitivity analysis. Sensitivity analysis helps to identify the risks with the greatest possible impact on the project. It helps to understand how variations in project objectives correlate with variations in various uncertainties. On the other hand, it establishes the extent to which the uncertainty of each element of the project affects the goal under study, while all other uncertain elements are in their baseline values. One typical way of displaying sensitivity analysis is the tornado chart (Figure below), which is useful in comparing the relative importance and impact of variables that have a high degree of uncertainty with other, more stable variables. The tornado chart is also useful in the analysis of risk-taking scenarios applied to certain risks, the quantitative analysis of which indicates that the possible benefits are greater than the corresponding identified negative impacts. 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 is each type of uncertainty in baseline values, and the x-axis is the spread or correlation of the uncertainty about the output under study. In this figure, each uncertainty contains a horizontal bar (line), and the vertical shows the uncertainties with decreasing spread from the baseline values.
· Analysis of the expected monetary value. Expected monetary value (EMV) analysis is a statistical technique that calculates the average outcome when there are scenarios in the future that may or may not occur (i.e., analysis under uncertainty). The EMV of favorable opportunities is usually expressed in positive terms, while the EMV of threats is expressed in negative terms. EMV requires a risk-neutral assumption—neither prone to excessive risk, nor, on the contrary, completely rejecting it. To calculate the EMV for a project, you need to multiply the value of each possible outcome by the probability of its occurrence, and then add the resulting values together. Typically, this type of analysis is used in the form of a decision tree analysis.
· Modeling and imitation. Project simulation uses a model to determine the possible impacts of detailed uncertainties on project objectives. Simulations are usually carried out using the Monte Carlo method. In simulation, the project model is calculated many times (iteratively), and for each iteration, input values (for example, cost estimates or activity durations) are chosen randomly from the probability distributions of these variables. During iterations, a histogram is calculated (for example, total cost or completion date). Cost risk analysis uses cost estimates. Schedule risk analysis uses a schedule network diagram and duration estimates. The output from cost risk simulation using a tri-element model and risk ranges is shown in Figure 1. below. The figure shows the corresponding probability of meeting certain value targets. Similar curves may be developed for other project purposes.
Strategies for responding to negative risks (threats)
· Evasion. Risk avoidance is a risk response strategy in which the project team acts to eliminate the 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 the target that is at risk (for example, expand the scope of the schedule, change the strategy, or reduce the scope). The most radical avoidance strategy is to terminate the project entirely. Some risks that arise early in a project can be avoided by clarifying requirements, obtaining information, improving communications, or acquiring expertise.
· Broadcast. Risk Transfer - A risk response strategy whereby the project team transfers the consequences of a threat, along with responsibility for responding, to a third party. When a risk is transferred, the responsibility for managing it is shifted to another party; the risk is not eliminated. The transfer of risk does not mean a waiver of responsibility for it by transferring it to a future project or another person, without notifying the latter or concluding an agreement with him. The transfer of risk almost always involves the payment of a risk premium to the party taking the risk. The transfer of responsibility for risk is most effective in relation to financial risks. Transfer instruments can be very diverse and include but are not limited to: the use of insurance, performance bonds, warranties, etc. Contracts or agreements may be used to transfer responsibility for certain risks to another party. For example, when the buyer has options that the seller does not, it may be reasonable to transfer some of the work and its associated risks back to the buyer through a contract. In many cases, cost risk may be transferred to the buyer in a cost-reimbursable contract, while risk may be transferred to the seller in a fixed-price contract.
· decline. Risk mitigation is a risk response strategy in which the project team acts to reduce the likelihood or impact of a 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 occurring and/or its impact during the course of a project is often more effective than remediation attempts made after the risk has occurred. Examples of risk mitigation actions include implementing less complex processes, running more tests, or choosing a more reliable supplier. Also, reduction may require the development of a prototype to reduce the risk of process or product scaling compared to a bench model. If it is not possible to reduce the likelihood, mitigation actions should focus on the impact of the risk, namely those links that determine the severity of the impact. For example, system redundancy design can reduce the severity of the 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 to respond to a particular risk is not possible or not cost effective. It indicates that the project team has decided not to change the project management plan to deal with the risk, or is unable to determine any other suitable 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 make sure it hasn't changed significantly. The most common active acceptance strategy is to reserve for possible losses, including certain amounts of time, money or resources needed to manage the risks.
Strategies for responding to positive risks (opportunities)
· Usage. An exploitation strategy may be chosen to respond to risks with a positive impact if it is necessary from the organization's point of view that the opportunity is guaranteed to be realised. This strategy is designed to eliminate the uncertainty associated with a particular positive risk through measures that ensure that the opportunity is realised. Direct-to-use responses include bringing the best talent in the organization to the project to reduce the time it takes to complete the project, or using new or improved technology to reduce the cost and time needed to achieve the project's goals.
· Increase. An increase strategy is used to increase the likelihood and/or positive impact of an opportunity. Identifying and maximizing the key factors behind these positive impact risks can increase the likelihood of them occurring. Examples of increasing opportunities include allocating additional resources to an operation to complete it early.
· Separation. Positive risk sharing involves transferring some or all of the responsibility for an opportunity to a third party that is best placed to take advantage of the opportunity for the benefit of the project. Sharing activities include the formation of risk-sharing partnerships, teams, spin-off companies or joint ventures, which may be established with the express purpose of reaping the benefits of an opportunity for all parties.
· Adoption. Opportunity acceptance is the desire to take advantage of an opportunity if it comes, without actively pursuing it.
12. PROJECT PURCHASING MANAGEMENT
Project Procurement Management includes the processes of purchasing or acquiring products, services, or deliverables needed to carry out a project outside the project team. An organization can act as both a buyer and a seller of products, services, or project results.
Project Procurement Management includes the contract management processes and change control processes required to create and administer contracts or purchase orders prepared by authorized members of the project team.
Contract types
· 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 certain specified project objectives, such as planned delivery dates, technical and cost performance, or other quantifiable and measurable indicators. Under fixed price contracts, sellers are legally required to honor such contracts or incur possible financial losses if they are not. Buyers, in accordance with the provisions of such contracts, are required to accurately identify the product or service being purchased. Changes to the content may take place, but as a rule, this leads to an increase in the contract price.
o Firm Fixed Price Contracts (FFP). The most widely used type of contract is the FFP. Most purchasing organizations prefer this type of contract, since the price of goods is set at the very beginning and is not subject to change if the content of the work does not change. Any increase in value caused by negative performance is the responsibility of the seller, who is obligated to complete the work. Under the FFP, the purchaser is required to accurately identify the product or service being purchased, and any change to the purchase specification may increase the purchaser's costs.
o Fixed Price Incentive Fee Contracts (FPIF). This fixed price agreement provides the buyer and seller with some flexibility, as it allows for deviation from performance and provides financial incentives for meeting agreed metrics. As a rule, such financial incentives are associated with cost, schedule or technical performance on the part of 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, there is a price ceiling, and all costs above the price ceiling are the responsibility of the seller, who is obligated to complete the work.
o Fixed Price with Economics Price Adjustment Contracts (FP-EPA). This type of contract is used if the performance of the contract by the seller extends over a significant period of time, which is usually sought in long-term relationships. A contract with a fixed price, but with a special provision allowing for predetermined final adjustments to the value of the contract due to changing conditions, such as inflation or increases (decreases) in the prices of certain goods. The price adjustment clause must be linked to a reliable 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-reimbursement contracts. This type of contract involves payment (reimbursement) to the seller of all legitimate actual costs incurred as a result of the performance of the work, plus remuneration constituting his profit. Cost-reimbursable contracts often include clauses providing 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 remuneration (Cost Plus Award Fee Contract, CPAF). A cost-reimbursable contract provides flexibility to the project by allowing changes to the instructions for the seller in case the scope of work cannot be accurately described at the beginning and needs to be adjusted, or there are high risks during the execution of the work.
o Cost-reimbursement plus fixed fee (CPFF) contracts. The seller is reimbursed for all agreed costs of performing the work under the contract, and is also paid a fixed fee, which is a certain percentage of the original estimated cost of the project. The remuneration is paid only for completed work and does not change depending on the performance of the seller. The remuneration amounts do not change if the content of the project does not change.
o Cost Reimbursement Plus Incentive (CPIF) contracts. The seller receives reimbursement of all agreed costs for the performance of work under the contract, as well as a predetermined incentive fee for achieving specific performance indicators stipulated in the contract. CPIF contracts stipulate that if the final cost is greater or less than the original estimated cost, then the savings/overspent are distributed between the seller and the buyer in a predetermined ratio, for example, in the ratio of 80/20 of the difference between the planned costs and the actual performance of the seller.
o Cost-reimbursement-plus-award (CPAF) contracts. The seller is reimbursed for all reasonable costs, but most of the consideration is paid only on the basis of meeting a set of broadly construed subjective performance criteria 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 is generally not subject to appeal.
· Contracts "time and materials"(Time and Material Contracts, T&M). Time and materials contracts are a mixed type of contractual agreement, containing provisions for both cost-reimbursement and fixed-price contracts. They are often used for staff augmentation, bringing in experts, and for any third-party support in cases where it is not possible to quickly create an accurate job description. These types of contracts are similar to cost-reimbursement contracts in that they allow for amendments and increases in value for the buyer. At the time of 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 cost of T&M contracts can increase, as in cost-reimbursable contracts. To prevent unlimited growth in value, many organizations require price and time caps to be included in all T&M contracts. On the other hand, T&M contracts can also resemble fixed price agreements where certain parameters are specified in the contract. Labor hourly rates or material costs, including the seller's profit, may 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 necessary to identify the people, groups and organizations that may or may be affected by the project, to analyze stakeholder expectations 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, responding to problems as they arise, managing conflicting interests, and facilitating appropriate stakeholder involvement in decision making and project operations. Stakeholder satisfaction should be managed as one of the key objectives of the project.
Various classification models are used in stakeholder analysis, such as:
· power/interest matrix, grouping stakeholders based on their level of authority (“authority”) and level of interest (“interest”) in relation to the results of the project;
· power/influence matrix grouping stakeholders based on their level of authority (“power”) and active involvement (“influence”) in the project;
· influence/impact matrix, grouping stakeholders based on their active involvement (“influence”) in the project and their ability to lead to changes in the planning or execution of the project (“impact”);
· features model, which describes the classes of stakeholders depending on their level of power (the ability to impose their will), urgency (the need for immediate action) and legitimacy (their involvement is appropriate).
The levels of stakeholder involvement 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 resist the change.
· supportive. The stakeholder is aware of the project, the potential impacts, and is supportive of the changes.
· Leading. The stakeholder is aware of the project, the potential impacts and is actively involved in ensuring the success of the project.
The main output of the stakeholder identification process is the register of stakeholders. It contains all the details related to the stakeholders that have been identified, including but not limited to:
· Identification information: full name, position in the organization, location, role in the project, contact information.
· Evaluation information: basic requirements and expectations, potential impact on the project, the most interesting phase in the project life cycle.
Stakeholder classification: internal/external, supportive/neutral/resisting, etc.
In addition to data from the stakeholder register, a 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 intersection of stakeholders;
· requirements of interested parties to communications at 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 involvement;
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 evolves.
On December 31, 2012, PMI released a new edition of the Project Management Body of Knowledge Guide (PMBOK® Guide - 5th Edition).
PMI specialists in the release of the translation of PMBoK 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. Bearing in mind the complaints about the translation of PMBoK v.4, it is better to let the Russian version be published later, but then they will its quality.
Judging by the opinion of experts, the long term of work is justified: it is necessary to explain a lot of new terms, describe new processes, clarify the translation of old terms and processes, and harmonize translations with other standards released by PMI.
What's new in the new PMBOK 5?
Section X1 "Changes in the Fifth Edition" tells us just that. 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:
1. Terminology and harmonization
The authors proudly claim that all terminology has been aligned with the PMI Lexicon of Project Management Terms. At the same time, the terminology from the PMI Lexicon is taken as a priority. If the translation of PMBOK 5 into Russian also begins with the creation of the correct terminology, then there is a hope of obtaining a competently translated body of knowledge.
Also, PMBOK 5 has been brought into line with the ISO 21500:2012 “Guidance on project management” standard and harmonization 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". In the days of the greatness and power of Ancient Greece, “taking risks” meant “tackling a ship between rocks”, i.e. potential risk of failure.
In PMBOK 5, changes were made to the description of project risk management and the emphasis was shifted from the term “positive risk” to the term “opportunity”. Concepts such as risk attitude, risk appetite, risk tolerance and risk thresholds have also been added to the text.
2. Project success
Because projects are temporary, project success must be measured in terms of completing the project within the constraints of scope, time, cost, quality, resources, and risk.
But the dynamics of changes in requirements in modern projects is so high that by the end, the project gets out of all conceivable and unimaginable restrictions. Therefore, managing changing requirements, fixing them in project documents and renegotiation Baselines are an increasingly in-demand skill for project managers. This was reflected in PMBOK 5 in the sentence “Success of the project should be attributed to the implementation of the latest baselines approved by authorized stakeholders”. I don't think it's better to say. If you managed to agree with the customer on the increase in the terms and budget of the project two days before the end of the project, then the project is successful, despite the 2-fold overtime and 3-fold increase in the budget.
3. Planning approaches to management
In PMBOK 4, part of the supporting plans appeared out of thin air. For example, the description of the Scope Management Plan was given directly in the description of the “Project Scope Management” knowledge area, and in what process it is created is not indicated. Four new planning processes have now been added: Scope Management Planning, Schedule Management Planning, Cost Management Planning, and Stakeholder Management Planning. This provides clear guidance to the project team to actively think through and plan approaches to managing all areas of knowledge.
Although not without its shortcomings. So two plans remained "without supervision" - the Change Management Plan and the Configuration Management Plan. It is logical that the Configuration Management Plan should appear along with the Content Management Plan and the Change Management Plan should appear during the development of the overall Project Management Plan, but in PMBOK 5 this is only implied.
4. Requirements
The requirements gathering process has been expanded to focus on obtaining all the requirements necessary for the success of the project.
The Verify Scope process has been completely redesigned. First, it has been renamed to Validate Scope. Second, emphasis was added that this process is not only about accepting the results, but that the results will be of value to the business and will satisfy the project's goals.
It's funny, but in PMBOK 4 there was a not 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 changes?
5. Gutta-percha
In all past PMBOKs combined, the word "agile" never was not used. In the current PMBOK, it occurs as many as 10 times.
PMI has never made a secret of the fact that the primary purpose of the PMBOK Guidelines is to highlight that 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 methods 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 the project schedule.
That's right, you need to keep your nose to the wind! This is modern both fashionable and commercially in demand.
6. Project communications
The ordering of information and knowledge generated during the implementation of the project has long been brewing. One of the most revolutionary changes in PMBOK 5 is the application 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 the answer to the question "when?" (Terms of Use).
This was expressed in a clear sequence of collecting, aggregating and processing data from the fields in the form of the following documents:
1. Data on the performance of work. "Raw" observations and measurements identified in the course of design work.
2. Information about the performance of work. Work performance data is analyzed and integrated based on the relationships between different areas/phases of the project.
3. Reports on the performance of work. Physical or electronic representation of information about the performance of work, intended for decision making, highlighting issues and problems, generating actions or understanding the situation.
If we also add Lessons of Experience here, then the cycle closes, and all the knowledge generated in the process of project implementation will be collected and processed and be used in the management of all projects in the organization.
Well, and the processes that confused many with the blurring of their boundaries and incomprehensible sequence: “Dissemination of information” and “Preparation of performance reports”, have been renamed, respectively, into “Communications Management” and “Communications Control” with logical inputs and outputs.
7. Management of "shareholders"
Stakeholder management is of great importance in PMBOK 5. Almost all sections have been touched to better highlight who the project stakeholders are and their impact on the project. A new (10th) knowledge area, Project Stakeholder Management, has been added, which includes two processes from Project Communications Management, and two new processes have been added.
The main reasons for such a budding 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 collection, storage and distribution information in the project, as well as monitoring the overall project relationships to ensure their effectiveness.
2. Real stakeholder management includes not only the analysis of their expectations, their impact on the project and the development of appropriate strategies for managing them, but also an ongoing dialogue with interested parties to meet their needs and expectations, resolving issues as their occurrence, and 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 the project.
The separation of Project Stakeholder Management from Project Communications Management, in addition to solving the 3 problems described above, ensures that PMBOK 5 is in line with the new growing trends in project management and of great interest to 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 made up for lost time.
So, the new area of knowledge includes the processes:
Stakeholder identification.
Development of a Stakeholder Management Plan.
Stakeholder engagement management.
Stakeholder engagement control.
8. "Soft skills"
Added Confidence Building, Conflict Management to Interpersonal Skills and Mentoring. Furthermore, a new section has been added to Chapter 1, Introduction, pointing out the importance of the project manager's interpersonal skills 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, which began in PMBOK 4, continued in the 5th. Now the only inputs to processes are documents that play a key role in the execution of the process. Documents and their composition have become clearer and more specific. Although the names of the documents themselves in the text were 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 template package.
In general, PMBOK 5 has become better structured, consistent, with normal relationships between processes, verified terminology
Publisher: PMI-2010
PMBOK (Project Management Body of Knowledge) - The PMBOK Guide 4th Edition (Project Management Body of Knowledge) defines the scope of knowledge required for effective project management. The document includes processes covering all stages of the project life cycle (initiation, planning, execution, control and completion). The results or outputs of one process may be inputs to another process. PMBOK includes the following parts of the project management processes:
Integration Management (Project Integration Management)
Human Resource Management (Project Human Resource Management)
Cost management (Project Cost Management)
Content Management (Project Scope Management)
Time management (Project Time Management)
Quality Management (Project Quality Management)
Communication management (Project Communication Management)
Risk Management (Project Risk Management)
Supply and contract management (Project Procurement And Contracts Management)
PMBOK is the most widespread in the world. The creators of the standard are the American Project Management Institute (PMI - Project Management Institute). Founded in 1969, the Project Management Institute (PMI) has grown into the leading professional association for project management with over 150,000 members.
It is worth remembering that PMBOK was created as a universal set of rules for managing any project in any industry. Evaluate for yourself whether it was possible to abstract from a specific area and take into account all the processes of project management. It seems to me that one should not treat this set of rules as an axiom, but choose the best.
The main differences between the third and fourth editions are:
1. All process names are presented in the form of verbal nouns.
2. A standard approach has been taken to consider enterprise environmental factors and assets
organization processes.
3. A standard approach has been taken to review the requested changes to prevent
actions, corrective actions and defect corrections.
4. Number of processes reduced from 44 to
42. Two processes have been removed, two processes have been added, and 6 processes have been reformulated into 4 processes in the Project Procurement Management Knowledge Area.
5. For the sake of clarity, a distinction has been made between the project management plan and the project documents used to manage the project.
6. The difference between the information contained in the Project Charter and the Project Scope Description was clarified.
7. The flowcharts at the beginning of chapters 4 to 12 have been removed.
8. For each process, a corresponding flowchart was created to show the processes associated with inputs and outputs.
9. A new appendix has been added that describes the key interpersonal skills used by the project manager during project management.
Overview of the sixth edition of the Guide to the Project Management Body of Knowledge
The Project Management Institute (PMI) released the sixth edition of the Guide to the Project Management Body of Knowledge (PMBOK Guide) on September 6, 2017. In addition to traditional stylistic and technical fixes, the new PMBOK incorporates ideas from PRINCE2, systems theory, Agile project management agile approaches.
Three part structure
In the sixth edition of PMBOK, the content is divided into 3 parts:
- The PMBOK Guide itself
- Project Management Standard - formerly located in the Applications. Some of the content that used to be part of the Guide is now reflected only in the Standard. Due to this, information is less duplicated.
- Applications, glossary, indexes.
Emphasis on adaptation
There is an old Russian fun - to arrange "holy wars" on the topic of the correct use of terminology. Whether PMBOK is a methodology is one of the favorite questions, the discussion of which often turns into a holy war.
This time the colleagues from PMI wrote unequivocally - "...this Guide is not a methodology". And for greater understanding, they described in detail how to use the Guide (the terms Guide, PMBOK are used in the text of this article as synonyms - author's note).
The developers recommend using PMBOK to create a project management methodology for an organization. The methodology can be created by the organization's own internal experts or with the help of external professional consultants. This is the first level of customization - the processes and tools from PMBOK are customized for a specific organization.
The second level of adaptation is when the organization's project methodology takes into account the characteristics of each individual project and allows the project manager to change management processes within certain limits.
To make it easier to adapt, PMBOK has a section “Considerations for Adaptation” in each knowledge area, which, through leading questions, makes you wonder which of the tools listed in the Guide are really needed on the project. For convenience, considerations for adaptation are also collected in a separate appendix at the end of the edition.
Thus, although many professionals associate PMBOK with hard classical project management, the Project Management Institute makes each subsequent edition of the Guide more flexible and adaptive.
Attention to business problems
The sixth edition of the Guide focuses more on the business aspects of project implementation. In this, PMBOK has come to resemble the competing management method PRINCE2, in which the control of project feasibility and benefits from its implementation is given increased attention at each phase of the project.
Business case. The Business Case document was also mentioned in the fifth edition of the Guide, but the new edition describes its purpose and content in more detail. The developers pursued the goal of harmonizing the PMBOK and another PMI guide on business analysis (Business analysis for Practitioners: A Practice Guide).
Project Benefit Management Plan. The document solves a pressing problem: often after the completion of the project, its results are not used or are not used as originally planned. The organization does not receive the benefits for which the project was initiated. At the same time, top management does not know about this, because. after the completion of the project and the distribution of the bonus fund, everyone forgets about the project, including the Customer. PBMOK now recommends the creation of a Project Benefit Management Plan that establishes a link between the project and the program in which it is included; between the project and the portfolio in which it is included; between the project and the goals of the organization; and appoints a beneficiary and determines the time frame for achieving benefits, which may extend far beyond the project.
Additional competencies of the project manager. The logical consequence of introducing business documents into the project was the expansion of the required competencies of the project manager. A new group of competencies "Strategic management and business management" has been introduced. The meaning of competence is that the project manager understands the connection of the project with the business results of the organization and tries to bring maximum business value, and not just perform the task.
Emphasis on knowledge management
A new process, Project Knowledge Management, has been added to the Integration Management knowledge area. It is likely that the inclusion of the new PMI process was prompted by a strong focus on learning in agile project management approaches, where experience evaluation and critical review of the methods used are performed regularly throughout the project.
In describing the process, two methods “Knowledge Management” and “Information Management” deserve attention.
For example, knowledge management methods include groups in social networks, conferences, and even “knowledge cafes”, by which the authors probably mean the format of “business breakfasts” or informal meetings in a cafe with a project team to exchange experiences.
Attention to the project implementation environment
The environment in which a project is run has a strong impact on success, so the sixth edition of the Guide has given even more attention to the description of the environment.
Enterprise environmental factors- divided into external and internal. Examples are given for each group. Now it's easier to understand what it is.
Process assets- divided into 2 groups:
- processes, policies, procedures,
- organization's knowledge repository.
Organizational Systems. In the new edition, organizations are considered as complex systems, which are characterized by elements of management, leadership models, types of organizational structures. The use of systems theory made it possible to more clearly understand the environment in which projects are carried out and what factors affect the success of projects. Organizational models are briefly presented in PMBOK and the reader is referred to the specialist literature on systems theory for more information.
Types of organizational structures. The 5th edition described 5 types of organizational structures. Five more were added in the 6th edition:
- organic or simple
- Multidivisional
- Virtual
- hybrid
- Portfolio/program/project management office
The inclusion of the project management office in the general register of organizational structures is also not clear - as a rule, this is a division within the organization, and not a separate organization with its own structure.
Recognition of agile approaches
In each area of knowledge, PMBOK provides considerations on how best to apply the described approaches in an Agile environment. Flexibilities were also mentioned in the previous edition, but in the sixth edition we can talk about the full recognition of flexibilities and their integration into the Guide.
Life cycle. In the project life cycle, PMBOK developers highlight the product development life cycle, which can be of different types: predictive, adaptive, iterative, incremental, or hybrid. There is no clear boundary between the types of life cycles, we are talking about a continuum of options.
For adaptive projects, there are two options for separating project phases:
Sequential phases based on iterations. The Scrum framework can be traced here, although the developers clearly do not write about it.
A Guide to the Project Management Body of Knowledge (PMBOK®) is a national American standard that contains professional knowledge of the project management process. The standard is issued by the Project Management Institute (PMI), located in Pennsylvania, USA. Official translation into Russian is carried out by the PMI office in Russia.
Purpose
PMBOK® provides guidelines for individual project management based on the best practices and best practices of project management professionals. The manual defines the key aspects of project management and describes the project management life cycle and related processes.
PMBOK® is a universal standard and can be used as the primary project management reference for professional development and certification programs. Also, the standard can be taken as a basis and adapted to the needs of project activities in any organization implementing projects.
Structure
The fifth edition of the PMBOK® standard highlights several key building blocks.
First, the main object of standardization is designated - the project, as well as the relationship between projects, programs, portfolios and operational activities.
Secondly, a typical project life cycle is described (Fig. 2) and the impact of organizational policies on project activities.
Rice. 2. Life cycle according to the fifth edition of the PMBOK® standard
Thirdly, the fifth edition of the PMBOK® standard describes the project management technology through the designation of management process groups (five groups are indicated) and functional areas (ten areas are highlighted).
And finally, in the appendix to the standard, interpersonal quality skills are disclosed, which are important for the activities of the project manager. These skills include:
leadership;
team building;
motivation;
communication;
impact;
making decisions;
political and cultural awareness;
Negotiation;
building trusting relationships;
Conflict Management;
mentoring;
All of these qualities can help the manager to effectively implement the project management process.
Short description
According to PMBOK®, the project is carried out through the integration of several key management processes. The standard has five groups of processes that define the management essence:
initiation;
planning (planning);
execution (executing);
control (controlling);
completion (closing).
The five process groups cover a number of areas of knowledge. The fifth edition of PMBOK® highlights ten key areas:
project integration management (Project Integration Management) - includes the processes and activities necessary to define, refine, combine, combine and coordinate various project management processes;
project scope management (Project Scope Management) - includes processes that ensure the inclusion in the project of key (those and only those) works that are necessary for the successful completion of the project;
project time management (Project Time Management) - includes the processes through which the timely completion of the project is ensured;
project cost management (Project Cost Management) - combines the processes of cost management and ensuring the completion of the project within the approved budget;
project quality management (Project Quality Management) - includes the processes and activities of the performing organization, the quality policy and is carried out through a quality management system that provides for certain rules and procedures, as well as actions for continuous improvement of processes carried out, if necessary, throughout the project ;
project human resource management (Project Human Resource Management) - includes the processes of organizing, managing and leading the project team;
project communications management (Project Communications Management) - includes the processes necessary for the timely creation, collection, distribution, storage, receipt and use of project information;
project risk management (Project Risk Management) - includes the processes necessary to increase the likelihood of occurrence and impact of favorable events and reduce the likelihood of occurrence and impact of adverse events for the project during its implementation;
project supply management (Project Procurement Management) - includes the processes of purchasing or acquiring those necessary products, services or results that are produced outside the organization executing the project;
project stakeholder management (Project Stakeholder Management) - includes the processes necessary to identify individuals (or organizations) that can affect the project or are influenced by it; and also includes those processes that are necessary to develop acceptable management strategies for involving these individuals (or organizations) in the project.
Each area of knowledge includes those and only those processes, the implementation of which allows the implementation of the agreed content within the specified time frame and within the allocated budget. As a result, the intersection of five groups of processes and ten areas of knowledge formed 47 processes that can be implemented by the management team during the implementation of the project. The description of each process contains four key elements: inputs, outputs, tools and methods, steps of the procedure (methods, instructions) for the implementation of the process. All processes contain the listed elements, which allows not only to understand the management methodology, but also to apply specific project management methods that have earned trust among project management professionals.
