You are on page 1of 25

1

This slide shows the remaining six knowledge areas in PMBOK that we will discuss individually in
this section. They include:

• Project Quality Management

• Project Human Resource Management

• Project Communications Management

• Project Risk Management

• Project Procurement Management

• Project Stakeholder Management

2
PMBOK defines project quality management to include “the processes and activities of the
performing organization that determine quality policies, objectives, and responsibilities so that the
project will satisfy the needs for which it was undertaken”
As you can see, this is based on a very process-oriented and control-oriented approach to managing
quality that is based heavily using policies and procedures to legislate quality.

3
It is also heavily based on a control and enforcement approach to meeting defined requirements
which doesn’t adequately recognize the possibility that the defined requirements may be wrong.

4
The approach for managing quality is very different in an Agile project. This slide shows a
comparison of the approach between a traditional, plan-driven project and an Agile/adaptive
project. There are major differences between the two approaches:
The sequence of performing testing is different:
• In a traditional, plan-driven project, quality testing is typically done sequentially after
development is completed
• In an Agile project, quality testing is done concurrently with development
The responsibilities for performing testing are also very different:
• In a traditional, plan-driven project, Quality testing is typically the responsibility of an
independent group whose responsibility is to validate the level of quality
• In an Agile project, Quality testing is the responsibility of the entire team who produces the
product – any quality testers should be an integral part of the project team

5
And the way final user acceptance testing is handled is also very different:
• In a traditional, plan-driven project, final acceptance testing typically occurs at the end of the
project
• In an Agile project, acceptance testing is done incrementally at the end of each sprint on the
items produced in that sprint

6
The key point is that in an Agile environment, the team is responsible for the quality of the product
it produces rather than an outside organization. I think you can easily see how that can improve
the quality of the work. And, the Product Owner is responsible for performing acceptance testing
to validate that it provides the appropriate business value as the project progresses rather than
waiting till the final end of the project to perform overall acceptance testing.

7
This slide shows the PMBOK definition of Project Human Resource Management which includes the
processes that organize, manage, and lead the project team”

8
The way resources are allocated and assigned to projects can be very different:

• In a traditional, plan-driven project, Resources are loosely-knit and may be brought in-and-out
of the project as needed at different times to fulfill commitments
• An Agile approach typically is based on a dedicated team of resources who are committed to a
project for the duration of the project

The management of the resources assigned to projects is also very different:

• In a traditional, plan-driven project, functional managers typically provide direction to the


resources that they are responsible for in a project. A project manager usually provides a
coordination function to manage commitments among all the participating groups to meet
overall project goals
• In an Agile project, the team is expected to be cross-functional and self-organizing without a
significant need for functional direction from outside of the team. If a Project Manager is
engaged in the project, he/she should be a strong, cross-functional leader and not just a
coordinator

9
At the team level in an Agile project, the team and the Scrum Master are primarily responsible for
human resource management. This can remove a huge burden from upper management for
managing these issues. The Product Owner may play a role if necessary to approve resource
commitments that impact the project deliverables.

10
This slide shows the PMBOK definition of Project Communications Management which includes all
aspects of managing information related to the project.”

11
The approach for managing communications is also very different in an Agile project.

• In a traditional, plan-driven project, Communications to groups outside of the project team is


typically controlled and funneled through the Project Manager

• In an Agile project, there is an emphasis on openness and transparency information is much


more freely shared without a project manager becoming an intermediary and a bottleneck in
releasing information

12
At the team level in an Agile project, the responsibility for communications management is
distributed:

• Everyone on the team has a responsibility to communicate the status of their assigned work

• The Scrum Master generally has the responsibility for facilitating the review and discussion of
that information in Daily Standups and other forums

• The Product Owner is expected to be the voice of the project to the business sponsor and
stakeholders but he may be assisted in that role by a Scrum Master

13
This slide shows the PMBOK definition of Project Risk Management which includes the processes of
conducting risk management planning, identification, analysis, response planning, and controlling
risk in the project.”

14
The approach for managing risks is also very different in an Agile project.

First, risks are generally related to uncertainties in the project for both a traditional plan-driven
project and an Agile project; however, there are significant differences in how risks are managed:
• Traditional plan-driven projects tend to be very risk-averse and treat risk as something that has
to be controlled and avoided and a traditional plan-driven project many times attempts to
reduce uncertainty to a minimum in order to minimize risks
• An Agile project recognizes that it may be necessary to live with a certain amount of uncertainty
that will be resolved as the project progresses rather than attempting to resolve it all upfront.
As a result, it may be necessary to take a more aggressive approach to managing risks

15
At the team level in an Agile project, the responsibility for managing risk is distributed:

• The Product Owner is expected to be the primary focus for decision-making on risk
management; however,

• The entire team facilitated by the Scrum Master is expected to participate in identifying and
mitigating risks

16
This slide shows the PMBOK definition of Project Procurement Management which includes
processes necessary to purchase or acquire products, services, or results needed from outside the
project team.”

17
The method for managing procurement is very different:
• In a traditional, plan-driven project, procurement is typically based on having very well-defined
requirements and specifications that must be met by the vendor delivering the products or
services
• In an Agile project, there may be more of a spirit of partnership with the vendor who is
delivering the products and services with some level of flexibility to work out details of
requirements and costs and schedules
The relationship with the vendor can also be very different:
• In a traditional, plan-driven project, the relationship between the customer and the vendor is
typically based on a very well-defined contract and it may be competitively bid among multiple
vendors to get the lowest price
• In an Agile project, the contract may be high-level with some latitude provided for working out
details and the vendors selected to participate in the contract may be limited to enable more of
a partnership relationship

18
At the Team Level in an Agile Project, the responsibility for defining and negotiating the
procurement approach will probably belong to the Product Owner who may be assisted in that role
by a Project Manager depending on the size and complexity of the procurement

19
This slide shows the PMBOK definition of Project Stakeholder Management which includes the
processes required to identify the people, groups, or organizations that could impact or be
impacted by the project, to analyze stakeholder expectations and the impact on the project, and to
develop appropriate management strategies for engaging stakeholders in project decisions and
execution.”

20
The responsibilities for stakeholder management are very different in an Agile project:
• In a traditional, plan-driven project, the Project Manager supported by a Business Analyst, if
necessary, is responsible for engaging stakeholders in the project and ensuring that their
interests are adequately represented
• In an Agile project, the Product Owner is responsible for representing the interests of all
stakeholders in the project. He/She may be assisted in that role by a Business Analyst
The way stakeholder requirements are managed and approved is also very different:
• In a traditional, plan-driven project, requirements of the stakeholders are documented and
consolidated and approved by the Business Sponsor as necessary
• In an Agile project, there is a much higher level of reliance on direct face-to-face
communications in the project with less emphasis on documented requirements

21
The responsibilities for stakeholder management are also very different:
• In a traditional, plan-driven project, the Project Manager plays a coordination role in gathering
and consolidating the requirements for approval by the Business Sponsor as necessary
• In an Agile project, the Product Owner is a decision-maker and should be able to approve
stakeholder requirements within the scope of his/her responsibility. (He/She may escalate
decisions to a business sponsor as necessary

22
At the team level in an Agile project, the Product Owner is expected to be the focal point for
managing communications with stakeholders; however, everyone on the team is expected to
communicate directly with stakeholders as needed as the project progresses.

23
I think you can see from this lesson that there are huge differences between PMBOK and Agile in not
only the style and approach of managing knowledge but the content of the knowledge areas is
significantly different as well. This is a key reason why it can be such a big shift in thinking for a
project manager who has been heavily schooled in a PMBOK-style approach to project management
to shift to an Agile approach.

There are a lot of people in the project management community that would argue that the way
PMBOK is written is general enough to apply to any methodology and that might be somewhat true,
but I think you can see from this discussion how difficult and perhaps inappropriate that would be to
do. There is also a fundamental inconsistency in the philosophy behind PMBOK and an Agile
approach:

• PMBOK is over 500 pages long and attempts to take a somewhat prescriptive, checklist approach
to cover almost every conceivable aspect of project management. That approach is more
consistent with what is called an explicit knowledge approach that would be associated with a
defined process model. It assumes that the work is highly repeatable and that project
management is a matter of simply following a fairly well-defined process.

• Agile recognizes that it’s impossible to provide detailed instructions on what to do in almost every
conceivable situation and that it is essential to rely much more heavily on tacit knowledge that
people gain through experience to figure out what to do in the context of a given situation.

Even if the general philosophy and approach behind the two were more consistent, the way the two
approaches are implemented in practice is significantly different so it would be very difficult and
cumbersome to try to create a version of PMBOK that fully embraces both Agile and traditional plan-
driven project management. This is a problem that may have to be solved at some point in time in
the future – for the moment, it’s important to recognize the limitations that are inherent in PMBOK
and know that a very different approach is required for Agile Project Management.

24
In the next section we’re going to begin talking about the specific roles an Agile Project Manager
can play and some case studies to illustrate those roles. In the next lesson, we will discuss the role
of an Agile Project Manager at the team level.

Thanks for taking the time to do this lecture and I’ll look forward to working with you in the rest of
the course.

25

You might also like