3/8/2024
Chapter 3
40
THE ROLE OF THE PROJECT MANAGER
3/8/2024
40
Role of the Project Manager
The 41
project manager plays a critical role in the leadership of a project team in order
to achieve the project’s objectives. This role is clearly visible throughout the project.
Many project managers become involved in a project from its initiation through
closing. However, in some organizations, a project manager may be involved in
evaluation and analysis activities prior to project initiation. These activities may
include consulting with executive and business unit leaders on ideas for advancing
strategic objectives, improving organizational performance, or meeting customer
needs.
In some organizational settings, the project manager may also be called upon to
manage or assist in business analysis, business case development, and aspects of
portfolio management for a project.
A project manager may also be involved in follow-on activities related to realizing
business benefits from the project.
The role of a project manager may vary from organization to organization. Ultimately,
the project management role is tailored to fit the organization in the same way that
the project management processes are tailored to fit the project.
3/8/2024
41
1
3/8/2024
project manager
42
The project manager is
the person assigned by
the performing
organization to
lead the team
that is responsible for
achieving the
project objectives.
Figure 3-1. Example of Project
Manager’s Sphere of Influence
42
3.4 PROJECT MANAGER COMPETENCES
Recent
43 PMI studies applied the Project Manager Competency
Development (PMCD) Framework to the skills needed by project
managers through the use of The PMI Talent Triangle shown in Figure 3-
®
2. The talent triangle focuses on three key skill sets:
Technical project management. The knowledge, skills, and
behaviors related to specific domains of project, program, and portfolio
management. The technical aspects of performing one’s role.
Leadership. The knowledge, skills, and behaviors needed to guide,
motivate, and direct a team, to help an organization achieve its business
goals.
Strategic and business management. The knowledge of and
expertise in the industry and organization that enhanced performance
and better delivers business outcomes.
43
2
3/8/2024
44
(finance, marketing, and operations.)
44
45
45
3
3/8/2024
46 Management & Leadership Skills
Project managers need to employ both
leadership and management in order to
be successful. The skill is in finding the right
balance for each situation. The way in
which management and leadership are
employed often shows up in the project
manager’s leadership style.
46
47
47
4
3/8/2024
48 Predictive project management (Plan Driven)
a precise plan is created and adhered to throughout the
duration of the project. The timetable, budget, and deliverables
are all specified and determined from the beginning of the
project. This method is ideal for projects with well-defined needs
and stable environments.
Predictive project management refers to when the scope of
work and requirements for the project are clear and justify the
detailed upfront planning.
predictive project management also called “traditional”,
“conventional”, or “Waterfall” project management.
48
Adaptive project management (Change based)
49 known as Agile, places emphasis on adaptability and
often
flexibility. On the basis of feedback from stakeholders and changes
in the development environment, requirements and project plans
are continuously revised and reevaluated. This strategy is ideal for
projects with quickly changing requirements and a high level of
uncertainty.
Adaptive is when the scope of work and requirements for the
project are difficult to define, therefore creating a rapidly
changing environment.
Requirements are clarified in short iterations (cycles) and therefore
require an Agile approach.
Adaptive project management can also be referred to as
“responsive” or “iterative”. It is most often simply called Agile
project management, “Agile thinking”, or “an Agile approach”.
49
5
3/8/2024
50
Work is divided into sprints or cycles
50
51
51
6
3/8/2024
52
Accountability Project Manager Entire Team
52
53
53
7
3/8/2024
54 Hybrid Project Management
Degree of Change
54
Agile Life Cycle
Agile projects are broken down into sprints or iterations — short, repeatable
55 typically one to four weeks long. The no. & length of sprints should be
phases,
determined at the beginning of the project, and each sprint should result in a
draft, prototype, or workable version of the final deliverable.
Or Tasks
55
8
3/8/2024
56
56
57 1. Individuals and interactions over
processes and tools
The first value gets straight to the core of Agile
methodology: the focus is on the people. You
can use the best processes and tools available
to support your projects, but they will only work if
your people are doing their best work.
Your team is your most valuable resource.
Communication plays a key role here — when
people interact with each other regularly and
share their ideas, they build better products.
57
9
3/8/2024
2. Working software over
58
comprehensive documentation
Before Agile practices were fully implemented, teams would
spend hours creating exhaustive documents with technical
specifications, requirements, and more. These lists would be
prepared before developers started to write the code, meaning
the whole process was delayed as the documentation took so
long to compile.
The Agile philosophy is to streamline these documents and
condense the information into user stories. These stories equip
the developer with all the details they need to start working on
the software and get it ready for release. The idea is to
accelerate the launch process and make product tweaks in the
early stages, improving the software in future iterations.
58
59
3. Customer collaboration over contract negotiation
The third value of the Agile Manifesto highlights the
importance of customer collaboration.
This is viewed as superior to contract negotiation, which
involves outlining product requirements with the customer
before commencing the project and then renegotiating these
deliverables at a later stage. The issue here is that the customer
is not engaged throughout the development cycle, so teams
lose out on user feedback that could enhance the product.
When you bring your customers into the development process,
you can ask for their opinions regularly and take their
suggestions on board. By delving into their specific needs while
the software is still being built, developers can gain valuable
insights to create the ultimate user experience.
59
10
3/8/2024
60 4. Responding to change over following a plan
Traditional methodologies advocated for as little change as
possible, recognizing that significant alterations could cost
time and money. The aim was to create a comprehensive
plan that followed a structured, linear path and avoided
obstacles where possible.
The Agile mentality turns this rigid method on its head, arguing
that change can benefit the software development process.
When you embrace change, you open yourself up to new
possibilities and ways to improve. Agile teams work in short,
iterative cycles, meaning they can react quickly and
implement changes on a continuous basis. This ultimately
leads to better products.
60
61
61
11
3/8/2024
The 12 Agile Manifesto principles
The
62
Agile Manifesto lists 12 principles to be followed by software
developers:
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
What is the number one rule in software development? Keep your
customer happy. Aim to deliver software to your users at regular
intervals throughout the project life cycle, rather than keep them
waiting for one final deliverable.
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
Software developers should be capable of handling last-minute
changes to a project. They should be flexible enough to turn these
changes into improvements quickly, minimizing delays and ensuring an
uninterrupted flow of work.
62
The 12 Agile Manifesto principles
3. Deliver working software frequently, from a couple of weeks to a couple of
63
months, with a preference to the shorter timescale.
Agile teams break large projects down into short timelines to guarantee regular
delivery. In the Scrum methodology, these timelines are known as sprints, which
often run between one and four weeks long.
4. Business people and developers must work together daily throughout the
project.
As mentioned, collaboration is key to Agile project management. When the
project stakeholders communicate on a daily basis, it minimizes the risk of
confusion and ensures that everyone’s goals remain aligned.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
When you have the right people for the task, the project is more likely to be
successful. Spend time choosing the perfect team, equip them with the
resources they need, and trust them to deliver exceptional results.
63
12
3/8/2024
The 12 Agile Manifesto principles
6. The most efficient and effective method of conveying information to and
64
within a development team is face-to-face conversation.
Barriers are broken easily when teams can converse in person. Co-locate
teams where possible to promote good communication and boost the flow of
information. In a remote working situation, Zoom is a great alternative to
phone or email, enabling people to interact more effectively via camera.
7. Working software is the primary measure of progress.
To keep your customers satisfied, you must deliver high-quality software. That is
your ultimate priority and your metric for success — everything else is a
secondary consideration.
8. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
Agile teams must be consistent throughout their project life cycle, maintaining
their speed throughout. This means they can sustain a constantly evolving
environment without succumbing to delays.
64
The 12 Agile Manifesto principles
9. Continuous attention to technical excellence and good design enhances agility.
65
In Agile, you don’t just deliver one good product and call it a day — your focus should be on
continuous improvement and innovation. Each iteration should bring with it a new update, feature, or
advancement of some kind.
improvements quickly, minimizing delays and ensuring an uninterrupted flow of work.
10. Simplicity — the art of maximizing the amount of work not done — is essential.
The Agile approach is to not overcomplicate things: meet your requirements and do just enough to
complete the task. Don’t waste time with additional steps that don’t add any real value to your
product.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
Why micromanage teams when they are skilled enough to work on their own? By allowing them to work
within their own structures, you create more room for ideas to flourish, ultimately delivering better results.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly.
When you review team performance regularly, you can spot issues before they escalate, as well as
potential areas for improvement. A healthy Agile team is one that self-reflects in order to eliminate
unhelpful practices and advance skills.
65
13
3/8/2024
66
Chapter 4
PROJECT INTEGRATION
MANAGEMENT
66
67
67
14
3/8/2024
Project Integration Management
68
Project Integration Management includes the processes and
activities to identify, define, combine, unify, and coordinate the
various processes and project management activities within the
Project Management Process Groups.
In the project management context, integration includes
characteristics of unification, consolidation, communication, and
interrelationship.
These actions should be applied from the start of the project
through completion. Project Integration Management includes
making choices about:
68
TRENDS AND EMERGING PRACTICES IN PROJECT INTEGRATION MANAGEMENT
The Project Integration Management Knowledge Area requires
69
combining the results from all the other Knowledge Areas. Evolving
trends in integration processes include but are not limited to:
Use of automated tools. The volume of data and information that
project managers need to integrate makes it necessary to use a
project management information system (PMIS) and automated
tools to collect, analyze, and use information to meet project
objectives and realize project benefits.
Use of visual management tools. Some project teams use visual
management tools, rather than written plans and other
documents, to capture and oversee critical project elements.
Making key project elements visible to the entire team provides a
real-time overview of the project status, facilitates knowledge
transfer, and empowers team members and other stakeholders to
help identify and solve issues
69
15
3/8/2024
Project knowledge management. The increasingly mobile and
transitory work force requires a more rigorous process of identifying
knowledge
70
throughout the project life cycle and transferring it to the
target audience so that the knowledge is not lost.
Expanding the project manager’s responsibilities. Project managers are
being called on to initiate and finalize the project, such as project
business case development and benefits management. Historically,
these activities have been the responsibility of management and the
project management office, but project managers are more frequently
collaborating with them to better meet project objectives and deliver
benefits. Project managers are also engaging in more comprehensive
identification and engagement of stakeholders.
Hybrid methodologies. Some project management methodologies are
evolving to incorporate successfully applied new practices.
Examples include the use of agile and other iterative practices; business
analysis techniques for requirements management; tools for identifying
complex elements in projects; and organizational change management
methods to prepare for transitioning the project outputs into the
organization.
70
4.1.2.3 INTERPERSONAL AND TEAM SKILLS
Interpersonal
71 and team skills that can be used for this process include :
Conflict management. Described in Section 9.5.2.1. Conflict management
can be used to help bring stakeholders into alignment on the objectives,
success criteria, high-level requirements, project description, summary
milestones, and other elements of the charter.
Facilitation. Facilitation is the ability to effectively guide a group event to a
successful decision, solution, or conclusion. A facilitator ensures that there is
effective participation, that participants achieve a mutual understanding, that all
contributions are considered, that conclusions or results have full buy-in
according to the decision process established for the project, and that the
actions and agreements achieved are appropriately dealt with afterward.
Meeting management. Described in Section 10.2.2.6. Meeting
management includes preparing the agenda, ensuring that a representative for
each key stakeholder group is invited, and preparing and sending the follow-up
minutes and actions.
71
16
3/8/2024
72
72
73 Processes in Integration Management
3/8/2024
73
17
3/8/2024
74
Resource allocation,
Balancing competing demands,
Examining any alternative approaches,
Tailoring the processes to meet the project
objectives, and
Managing the interdependencies among the
Project Management Knowledge Areas.
74
4.1.3.1 PROJECT CHARTER
75
The project charter is the document issued by the project
initiator or sponsor that formally authorizes the existence of a
project and provides the project manager with the authority
to apply organizational resources to project activities.
It documents the high-level information on the project and
on the product, service, or result the project is intended to
satisfy, such as:
Project purpose;
Measurable project objectives and related success criteria;
High-level requirements;
High-level project description, boundaries, and key
deliverables; 3/8/2024
75
18
3/8/2024
Overall project risk;
76 Summary milestone schedule;
Preapproved financial resources;
Key stakeholder list;
Project approval requirements (i.e., what constitutes project
success, who decides the project is successful, and who signs
off on the project);
Project exit criteria (i.e., what are the conditions to be met in
order to close or to cancel the project or phase);
Assigned project manager, responsibility, and authority level;
and
Name and authority of the sponsor or other person(s)
authorizing the project charter.
76
4.1.3.2 ASSUMPTION LOG
77
High-level strategic and operational assumptions
and constraints are normally identified in the
business case before the project is initiated and will
flow into the project charter.
Lower-level activity and task assumptions are
generated throughout the project such as defining
technical specifications, estimates, the schedule,
risks, etc.
The assumption log is used to record all
assumptions and constraints throughout the project
life cycle.
77
19
3/8/2024
ITTOs – Develop Project Charter
78
78
79
79
20
3/8/2024
Business Case:
80 It is commonly used for decision making by managers or
executives above the project level. Typically, the
business need and the cost benefit analysis are
contained in the business case to justify and establish
boundaries for the project
nuMarket demand (e.g., an automobile manufacturer authorizing
a project to build more fuel-efficient cars in
response to gasoline shortages),
nuOrganizational
need (e.g., due to high overhead costs, a
company may combine staff functions and streamline
processes to reduce costs),
80
nuCustomer request (e.g., an electric utility authorizing a project to
81 build a new substation to serve a new industrial park),
nuTechnological advance (e.g., an airline authorizing a new project
to develop electronic tickets instead of paper tickets based on
technological advances),
nuLegal requirement (e.g., a paint manufacturer authorizing a
project to establish guidelines for handling toxic materials),
nuEcological impacts (e.g., a company authorizing a project to
lessen its environmental impact), or
nuSocial need (e.g., a nongovernmental organization in a
developing country authorizing a project to provide potable water
systems, latrines, and sanitation education to communities
suffering from high rates of cholera).
81
21
3/8/2024
82 4.1.1.2 AGREEMENTS
Described in Section 12.2.3.2. Agreements are
used to define initial intentions for a project.
Agreements may take the form of contracts,
memorandums of understanding (MoUs), service
level agreements (SLA), letters of agreement,
letters of intent, verbal agreements, email, or
other written agreements.
Typically, a contract is used when a project is
being performed for an external customer.
82
4.1.2.1 EXPERT JUDGMENT
Expert
83 judgment is defined as judgment provided based upon expertise
in an application area, Knowledge Area, discipline, industry, etc., as
appropriate for the activity being performed. Such expertise may be
provided by any group or person with specialized education, knowledge,
skill, experience, or training.
For this process, expertise should be considered from individuals or
groups with specialized knowledge of or training in the following topics:
Organizational strategy,
Benefits management,
Technical knowledge of the industry and focus area of the project,
Duration and budget estimation, and
Risk identification.
83
22
3/8/2024
Data Gathering techniques
Data-gathering
84 techniques include but are not limited to:
Brainstorming. This technique is used to identify a list of ideas in a short
period of time. It is conducted in a group environment and is led by a facilitator.
Brainstorming comprises two parts: idea generation and analysis.
Brainstorming can be used to gather data and solutions or ideas from
stakeholders, subject matter experts, and team members when developing the
project charter.
Focus groups. Described in Section 5.2.2.2. Focus groups bring together
stakeholders and subject matter experts to learn about the perceived project
risk, success criteria, and other topics in a more conversational way than a
one-on-one interview.
Interviews. Described in Section 5.2.2.2. Interviews are used to obtain
information on high-level requirements, assumptions or constraints, approval
criteria, and other information from stakeholders by talking directly to them.
84
4.1.3.1 PROJECT CHARTER
Project purpose;
85
Measurable project objectives and related success criteria;
High-level requirements;
High-level project description, boundaries, and key deliverables;
Overall project risk;
Summary milestone schedule;
Preapproved financial resources;
Key stakeholder list;
Project approval requirements (i.e., what constitutes project success, who
decides the project is successful, and who signs off on the project);
Project exit criteria (i.e., what are the conditions to be met in order to close
or to cancel the project or phase);
Name and authority of the sponsor or other person(s) authorizing the
project charter.
85
23
3/8/2024
86 4.1.3.2 ASSUMPTION LOG
High-level strategic and operational assumptions and
constraints are normally identified in the business case
before the project is initiated and will flow into the
project charter.
Lower-level activity and task assumptions are
generated throughout the project such as defining
technical specifications, estimates, the schedule, risks,
etc.
The assumption log is used to record all assumptions
and constraints throughout the project life cycle.
86
87 4.2 DEVELOP PROJECT MANAGEMENT PLAN
Develop Project Management Plan is the process of
defining, preparing, and coordinating all plan components
and consolidating them into an integrated project
management plan.
The key benefit of this process is the production of a
comprehensive document that defines the basis of all project
work and how the work will be performed.
This process is performed once or at predefined points in the
project. The inputs, tools and techniques, and outputs of the
process are depicted in Figure 4-4. Figure 4-5 depicts the
data flow diagram for the process.
87
24
3/8/2024
88
88
89 4.2.3 DEVELOP PROJECT MANAGEMENT
PLAN: OUTPUTS
4.2.3.1 PROJECT MANAGEMENT PLAN
The project management plan is the document
that describes how the project will be executed,
monitored and controlled, and closed.
It integrates and consolidates all of the subsidiary
management plans and baselines, and other
information necessary to manage the project.
The needs of the project determine which
components of the project management plan
are needed.
89
25
3/8/2024
Subsidiary management plans:
Scope management plan. Described in Section 5.1.3.1. Establishes
nu90
how the scope will be defined, developed, monitored, controlled, and
validated.
Requirements management plan. Described in Section 5.1.3.2.
nu
Establishes how the requirements will be analyzed, documented, and
managed.
nuSchedule management plan. Described in Section 6.1.3.1. Establishes
the criteria and the activities for developing, monitoring, and controlling
the schedule.
nuCost management plan. Described in Section 7.1.3.1. Establishes how
the costs will be planned, structured, and controlled.
nuQuality management plan. Described in Section 8.1.3.1. Establishes
how an organization´s quality policies, methodologies, and standards
will be implemented in the project.
90
nuResource management plan. Described in Section 9.1.3.1
Provides guidance on how project resources should be
91
categorized, allocated, managed, and released.
nuCommunications management plan. Described in Section
10.1.3.1. Establishes how, when, and by whom information about
the project will be administered and disseminated.
nuRisk management plan. Described in Section 11.1.3.1.
Establishes how the risk management activities will be structured
and performed.
nuProcurement management plan. Described in Section 12.1.3.1.
Establishes how the project team will acquire goods and services
from outside of the performing organization.
nuStakeholder engagement plan. Described in Section 13.2.3.1.
Establishes how stakeholders will be engaged in project decisions
and execution, according to their needs, interests, and impact.
91
26
3/8/2024
92 Baselines:
nuScope baseline. Described in Section 5.4.3.1. The
approved version of a scope statement, work breakdown
structure (WBS), and its associated WBS dictionary, which is
used as a basis for comparison.
nuSchedule baseline. Described in Section 6.5.3.1. The
approved version of the schedule model that is used as a
basis for comparison to the actual results.
nuCost baseline. Described in Section 7.3.3.1. The approved
version of the time-phased project budget that is used as a
basis for comparison to the actual results.
92
Change management plan. Describes how the change requests
throughout the project will be formally authorized and incorporated
93
Configuration management plan. Describes how the information about
the items of the project (and which items) will be recorded and
updated so that the product, service, or result of the project remains
consistent and/or operative.
Performance measurement baseline. An integrated scope-schedule-
cost plan for the project work against which project execution is
compared to measure and manage performance.
Project life cycle. Describes the series of phases that a project passes
through from its initiation to its closure.
Development approach. Describes the product, service, or result
development approach, such as predictive, agile, or a hybrid model.
Management reviews. Identifies the points in the project when the
project manager and relevant stakeholders will review the project
progress to determine if performance is as expected, or if preventive or
corrective actions are necessary
93
27
3/8/2024
94
3/8/2024
94
95 4.3 DIRECT AND MANAGE PROJECT WORK
Direct and Manage Project Work is the process of leading
and performing the work defined in the project
management plan and implementing approved changes
to achieve the project’s objectives. The key benefit of this
process is that it provides overall management of the
project work and deliverables, thus improving the probability
of project success.
This process is performed throughout the project. The inputs,
tools and techniques, and outputs of the process are
depicted in Figure 4-6. Figure 4-7 depicts the data flow
diagram for the process 3/8/2024
95
28
3/8/2024
96
96
4.3.3 DIRECT AND MANAGE PROJECT WORK:
97
OUTPUTS
4.3.3.1 DELIVERABLES
A deliverable is any unique and verifiable product, result, or
capability to perform a service that is required to be produced to
complete a process, phase, or project.
Deliverables are typically the outcomes of the project and can
include components of the project management plan.
Change control should be applied once the first version of a
deliverable has been completed.
The control of the multiple versions or editions of a deliverable
(e.g., documents, software, and building blocks) is supported by
configuration management tools and procedures
97
29
3/8/2024
4.6.1.2 PROJECT DOCUMENTS
98 documents that can be considered as inputs for this process
Project
include but are not limited to:
Basis of estimates. Described in Section 6.4.3.2. Basis of estimates
indicate how the duration, cost, and resources estimates were
derived and can be used to calculate the impact of the change
in time, budget, and resources.
Requirements traceability matrix. Described in Section 5.2.3.2. The
requirements traceability matrix helps assess the impact of the
change on the project scope.
Risk report. Described in Section 11.2.3.2. The risk report presents
information on sources of overall and individual project risks
involved by the change requested.
98
4.3.1.3 APPROVED CHANGE REQUESTS
99 Described in Section 4.6.3.1. Approved change requests
are an output of the Perform Integrated Change Control
process, and include those requests reviewed and
approved for implementation by the project manager or
by the change control board (CCB) when applicable.
The approved change request may be a corrective
action, a preventive action, or a defect repair.
Approved change requests are scheduled and
implemented by the project team and can impact any
area of the project or project management plan.
The approved change requests can also modify the
formally controlled project management plan
components or project documents.
99
30
3/8/2024
100 4.3.1.4 ENTERPRISE ENVIRONMENTAL FACTORS
The enterprise environmental factors that can influence the
Direct and Manage Project Work process include but are not
limited to:
Organizational structure, culture, management practices, and
sustainability;
Infrastructure (e.g., existing facilities and capital equipment);
and
Stakeholder risk thresholds (e.g., allowable cost overrun
percentage)
100
4.3.1.5 ORGANIZATIONAL PROCESS ASSETS
The organizational process assets that can influence the Direct and
101
Manage Project Work process include but are not limited to:
Organizational standard policies, processes, and procedures;
Issue and defect management procedures defining issue and defect
controls, issue and defect identification and resolution, and action item
tracking;
Issue and defect management database(s) containing historical issue
and defect status, issue and defect resolution, and action item results;
Performance measurement database used to collect and make
available measurement data on processes and products;
Change control and risk control procedures; and
Project information from previous projects (e.g., scope, cost, schedule,
performance measurement baselines,
project calendars, project schedule network diagrams, risk registers, risk
reports, and lessons learned repository)
101
31
3/8/2024
4.3.3.3 ISSUE LOG
102 Throughout the life cycle of a project, the project manager
will normally face problems, gaps, inconsistencies, or conflicts
that occur unexpectedly and that require some action, so
they do not impact the project performance.
The issue log is a project document where all the issues are
recorded and tracked. Data on issues may include:
Issue type,
Who raised the issue and when,
Description,
Priority,
Who is assigned to the issue,
Target resolution date,
Status, and
Final solution
102
103 4.3.3.3 ISSUE LOG
The issue log will help the project manager
effectively track and manage issues, ensuring that
they are investigated and resolved.
The issue log is created for the first time as an
output of this process, although issues may
happen at any time during the project.
The issue log is updated as a result of the
monitoring and control activities throughout the
project’s life cycle.
103
32
3/8/2024
104 4.3.3.4 CHANGE REQUESTS
A change request is a formal proposal to modify any document,
deliverable, or baseline. When issues are found while project work is
being performed, change requests can be submitted, which may
modify project policies or procedures, project or product scope,
project cost or budget, project schedule, or quality of the project or
product results.
Other change requests cover the needed preventive or corrective
actions to forestall negative impact later in the project.
Any project stakeholder may request a change.
Change requests are processed for review and disposition through the
Perform Integrated Change Control process (Section 4.6).
Change requests can be initiated from inside or outside the project
and they can be optional or legally/contractually mandated. Change
requests may include
104
105 4.3.3.4 CHANGE REQUESTS
Corrective action. An intentional activity that realigns the performance of
the project work with the project management plan.
Preventive action. An intentional activity that ensures the future
performance of the project work is aligned with the project management
plan.
Defect repair. An intentional activity to modify a nonconforming product
or product component.
Updates. Changes to formally controlled project documents, plans, etc.,
to reflect modified or additional ideas or content
105
33
3/8/2024
106 4.3.3.5 PROJECT MANAGEMENT PLAN
UPDATES
Any change to the project management
plan goes through the organization’s
change control process via a change
request.
Any component of the project
management plan may require a change
request as a result of this process
106
4.3.3.6 PROJECT DOCUMENTS UPDATES
107 Project documents that may be updated as a result of
carrying out this process include but are not limited to:
Activity list. Described in Section 6.2.3.1. The activity list
may be updated with additional or modified activities to
be performed to complete project work.
Assumption log. Described in Section 4.1.3.2. New
assumptions and constraints may be added, and the
status of existing assumptions and constraints may be
updated or closed out.
Lessons learned register. Described in Section 4.4.3.1. Any
lessons learned that will improve performance for current
or future projects is recorded as it is learned
107
34
3/8/2024
108 4.3.3.6 PROJECT DOCUMENTS UPDATES
Requirements documentation. Described in Section 5.2.3.1.
New requirements may be identified during this process.
Progress on meeting requirements can also be updated.
Risk register. Described in Section 11.2.3.1. New risks may be
identified, and existing risks may be updated during this
process. Risks are recorded in the risk register via risk
management processes.
Stakeholder register. Described in Section 13.1.3.1. Where
additional information on existing or new stakeholders is
gathered as a result of this process, it is recorded in the
stakeholder register
108
109 4.4 MANAGE PROJECT KNOWLEDGE
Manage Project Knowledge is the process of using existing
knowledge and creating new knowledge to achieve the
project’s objectives and contribute to organizational
learning.
The key benefits of this process are that prior organizational
knowledge is leveraged to produce or improve the project
outcomes, and knowledge created by the project is
available to support organizational operations and future
projects or phases.
This process is performed throughout the project.
The inputs, tools and techniques, and outputs of the
process are depicted in Figure 4-8. Figure 4-9 depicts the
data flow diagram for the process
109
35
3/8/2024
110
110
4.4.1 MANAGE PROJECT KNOWLEDGE: INPUTS
4.4.1.1
111 PROJECT MANAGEMENT PLAN
All components of the project management plan are inputs. E.g.
Lessons learned register. Described in Section 4.4.3.1. The lessons
learned register provides information on effective practices in
knowledge management.
Project team assignments. Described in Section 9.3.3.1. Project team
assignments provide information on the type of competencies and
experience available in the project and the knowledge that may be
missing.
Resource breakdown structure. Described in Section 9.2.3.3. The
resource breakdown structure includes information on the composition
of the team and may help to understand what knowledge is available
as a group and what knowledge is missing.
Stakeholder register. Described in Section 13.1.3.1. The stakeholder
register contains details about the identified stakeholders to help
understand the knowledge they may have
111
36
3/8/2024
112 4.4.1.3 DELIVERABLES
A deliverable is any unique and verifiable
product, result, or capability to perform a
service that is required to be produced to
complete a process, phase, or project.
Deliverables are typically tangible components
completed to meet the project objectives and
can include components of the project
management plan.
112
113 4.4.1.4 ENTERPRISE ENVIRONMENTAL FACTORS
The enterprise environmental factors that can influence the Manage
Project Knowledge process include but are not limited to:
Organizational, stakeholder, and customer culture. The existence
of trusting working relationships and a no-blame culture is
particularly important in managing knowledge. Other factors
include the value placed on learning and social behavioral norms.
Geographic distribution of facilities and resources. The location of
team members helps determine methods for gaining and sharing
knowledge.
Organizational knowledge experts. Some organizations have a
team or individual that specializes in knowledge management.
Legal and regulatory requirements and/or constraints. These
include confidentiality of project information
113
37
3/8/2024
114 4.4.1.5 ORGANIZATIONAL PROCESS ASSETS
Knowledge about project management is often embedded in
processes and routines. The organizational process assets that can
influence the Manage Project Knowledge process include but are
not limited to:
Organizational standard policies, processes, and procedures.
These may include: confidentiality and access to information;
security and data protection; record retention policies; use of
copyrighted information; destruction of classified information;
format and maximum size of files; registry data and metadata;
authorized technology and social media; etc.
Personnel administration. These include, for example, employee
development and training records, and competency frameworks
that refer to knowledge-sharing behaviors
114
115 4.4.1.5 ORGANIZATIONAL PROCESS ASSETS
Organizational communication requirements. Formal, rigid
communication requirements are good for sharing information.
Informal communication is more effective for creating new
knowledge and integrating knowledge across diverse stakeholder
groups.
Formal knowledge-sharing and information-sharing procedures.
These include learning reviews before, during, and after projects
and project phases; for example, identifying, capturing, and
sharing lessons learned from the current project and other projects
115
38
3/8/2024
4.4.2 MANAGE PROJECT KNOWLEDGE:
116 TOOLS AND TECHNIQUES
4.4.2.1 EXPERT JUDGMENT
Described in Section 4.1.2.1. Expertise should be
considered from individuals or groups with specialized
knowledge or training in the following topics:
Knowledge management,
Information management,
Organizational learning,
Knowledge and information management tools, and
Relevant information from other projects
116
117 4.4.2.2 KNOWLEDGE MANAGEMENT
Knowledge management tools and techniques connect
people so they can work together to create new
knowledge, share knowledge, and integrate the
knowledge of diverse team members.
The tools and techniques appropriate in a project depend
on the nature of the project, especially the degree of
innovation involved, the project complexity, and the level
of diversity (including diversity of disciplines) among team
members
117
39
3/8/2024
Tools and techniques include but are not limited to:
118
Networking, including informal social interaction and
online social networking. Online forums where people
can ask open questions (“What does anyone know
about…?”) are useful for starting knowledge-sharing
conversations with specialists;
Communities of practice (sometimes called
communities of interest or just communities) and special
interest groups;
Meetings, including virtual meetings where participants
can interact using communications technology;
Work shadowing and reverse shadowing;
Discussion forums such as focus groups;
118
119
Knowledge-sharing events such as seminars and
conferences;
Workshops, including problem-solving sessions and
learning reviews designed to identify lessons
learned;
Storytelling;
Creativity and ideas management techniques;
Knowledge fairs and cafés; and
Training that involves interaction between learners
119
40
3/8/2024
4.4.2.3 INFORMATION MANAGEMENT
Information
120 management tools and techniques are used to
create and connect people to information. They are effective
for sharing simple, unambiguous, codified explicit knowledge.
They include but are not limited to:
Methods for codifying knowledge; for example, for producing
lessons to be learned entries for the lessons learned register;
Lessons learned register;
Library services;
Information gathering, for example, web searches and reading
published articles; and
Project management information system (PMIS). Described in
Section 4.3.2.2. Project management information systems often
include document management systems.
120
4.4.2.4 INTERPERSONAL AND TEAM SKILLS
The interpersonal and team skills used include but are not limited to:
121
Active listening. Described in Section 10.2.2.6. Active listening helps
reduce misunderstandings and improves communication and knowledge
sharing.
Facilitation. Described in Section 4.1.2.3. Facilitation helps effectively
guide a group to a successful decision, solution, or conclusion.
Leadership. Described in Section 3.4.4. Leadership is used to
communicate the vision and inspire the project team to focus on the
appropriate knowledge and knowledge objectives.
Networking. Described in Section 10.2.2.6. Networking allows informal
connections and relations among project stakeholders to be established
and creates the conditions to share tacit and explicit knowledge.
Political awareness. Described in Section 10.1.2.6. Political awareness
helps the project manager to plan communications based on the project
environment as well as the organization’s political environment
121
41