Task_TableNameDurationPredecessorsResourcesNotesMobile app plan34 days3/17/16Project set-up7 days2/1/162/9/16Define project processes2 days2/1/162/2/16project manager, product ownerSet up working environment4 days2/3/162/8/163technical administratorDetermine initial sprint velocity1 day2/9/162/9/164lead developerProject setup complete0 days2/9/162/9/165Sprint 1 UI6 days2/10/162/17/162Sprint 1 plan0.5 days2/10/162/10/16Select sprint 1 user stories0.25 days2/10/162/10/16product ownerAssign user stories0.25 days2/10/162/10/169product owner, lead developerSprint 1 plan complete0 days2/10/162/10/1610User Interface5 days2/10/162/16/16Design User Interface2 days2/10/162/11/16UX developerBuild User Interface2 days2/12/162/15/1613UX developerTest User Interface1 day2/16/162/16/1614test engineerUAT of UI1 day2/17/162/17/1612test engineer, product ownerCorrect Issues From UAT UI1 day2/26/162/26/1625UX developerSprint 2 reports15 daysSprint 2 plan0.5 days2/18/162/18/16Select sprint 2 user stories0.25 days2/18/162/18/16lead developerAssign user stories0.25 days2/18/162/18/1619lead developerSprint 1.1 plan complete0 days2/18/162/18/1620Client Specified Reports7 days2/18/162/26/16Design Reports2 days2/18/162/19/16reporting developerBuild Reports2 days2/22/162/23/1623reporting developerTest Reports2 days2/24/162/25/1624test engineerUAT of Reports1 day2/29/162/29/1622test engineer, product ownerCorrect Issues From UAT of Reports1 day3/8/163/8/16reporting developerSprint 3 Platform7 days3/1/163/9/1617Sprint 3 plan0.5 days3/1/163/1/16Select sprint 3 user stories0.25 days3/1/163/1/16lead developerAssign user stories0.25 days3/1/163/1/1630lead developerSprint 3 plan complete0 days3/1/163/1/1631Cross Platform Support6 days3/1/163/8/16Design Cross Platform Support2 days3/1/163/2/16technical administratorBuild Cross Platform Support2 days3/3/163/4/1634technical administratorTest Cross Platform Support1 day3/7/163/7/1635technical administratorUAT of CPS1 day3/9/163/9/1633technical administrator, test engineerProject End2 days3/16/163/17/1644Obtain Final Client Signoff1 day3/16/163/16/16project manager, product ownerProvide Project Report Out0.5 days3/17/163/17/1648project manager, product ownerProject End Celebration0.5 days3/17/163/17/1649project manager, product owner
Project Charter template (contains Scope Section): project name:Executive Summary
Where did this project come from?
Why is it being done?
What impact will the project create (internally, externally)?
What strategic plan does it contribute to?
What does the customer receive/not receive by project end?
What key assumptions are driving this project?
What risks could challenge project success?Goals
What business/organization goal(s) does this project support?
What business need is being satisfied by this project?Objectives
What, specifically, needs to be done to meet project/customer requirements/expectations/goal?
What is the target of the project?
Note: Ensure each objective contributes to the goal. C.
1. Task_TableNameDurationPredecessorsResourcesNotesMobile
app plan34 days3/17/16Project set-up7 days2/1/162/9/16Define
project processes2 days2/1/162/2/16project manager, product
ownerSet up working environment4 days2/3/162/8/163technical
administratorDetermine initial sprint velocity1
day2/9/162/9/164lead developerProject setup complete0
days2/9/162/9/165Sprint 1 UI6 days2/10/162/17/162Sprint 1
plan0.5 days2/10/162/10/16Select sprint 1 user stories0.25
days2/10/162/10/16product ownerAssign user stories0.25
days2/10/162/10/169product owner, lead developerSprint 1 plan
complete0 days2/10/162/10/1610User Interface5
days2/10/162/16/16Design User Interface2
days2/10/162/11/16UX developerBuild User Interface2
days2/12/162/15/1613UX developerTest User Interface1
day2/16/162/16/1614test engineerUAT of UI1
day2/17/162/17/1612test engineer, product ownerCorrect Issues
From UAT UI1 day2/26/162/26/1625UX developerSprint 2
reports15 daysSprint 2 plan0.5 days2/18/162/18/16Select sprint
2 user stories0.25 days2/18/162/18/16lead developerAssign user
stories0.25 days2/18/162/18/1619lead developerSprint 1.1 plan
complete0 days2/18/162/18/1620Client Specified Reports7
days2/18/162/26/16Design Reports2
days2/18/162/19/16reporting developerBuild Reports2
days2/22/162/23/1623reporting developerTest Reports2
days2/24/162/25/1624test engineerUAT of Reports1
day2/29/162/29/1622test engineer, product ownerCorrect Issues
From UAT of Reports1 day3/8/163/8/16reporting
developerSprint 3 Platform7 days3/1/163/9/1617Sprint 3
plan0.5 days3/1/163/1/16Select sprint 3 user stories0.25
days3/1/163/1/16lead developerAssign user stories0.25
days3/1/163/1/1630lead developerSprint 3 plan complete0
days3/1/163/1/1631Cross Platform Support6
days3/1/163/8/16Design Cross Platform Support2
days3/1/163/2/16technical administratorBuild Cross Platform
2. Support2 days3/3/163/4/1634technical administratorTest Cross
Platform Support1 day3/7/163/7/1635technical
administratorUAT of CPS1 day3/9/163/9/1633technical
administrator, test engineerProject End2
days3/16/163/17/1644Obtain Final Client Signoff1
day3/16/163/16/16project manager, product ownerProvide
Project Report Out0.5 days3/17/163/17/1648project manager,
product ownerProject End Celebration0.5
days3/17/163/17/1649project manager, product owner
Project Charter template (contains Scope Section): project
name:Executive Summary
Where did this project come from?
Why is it being done?
What impact will the project create (internally, externally)?
What strategic plan does it contribute to?
What does the customer receive/not receive by project end?
What key assumptions are driving this project?
What risks could challenge project success?Goals
What business/organization goal(s) does this project support?
What business need is being satisfied by this project?Objectives
What, specifically, needs to be done to meet project/customer
requirements/expectations/goal?
What is the target of the project?
Note: Ensure each objective contributes to the goal. Check to
satisfy the "SMART" criteriaScope:
What does the work of the project to meet goal include/not
include?Work IncludesWork does not IncludePhases ⁄
Deliverables:
What are the major components of work to meet the
goals/objectives/scope?
What are the customer, process, and project deliverables within
each phase?
Phase
Description of Phase
Deliverables
3. Internal
External
Assumptions:
What unknowns are being made known in this project?
What uncertainties are considered true, real, or certain for
planning purposes?
What trial balloons are being floated to verify information?
Assumption
Rationale
Probability of Assumption being True
Impact to Project if Assumption is not True
4. Risks:
What events could jeopardize this project's success?
Risk
Supporting Detail (Analysis to be continued in Risk
Management Plan/ Register)
Constraints:
What is restricting this project?
5. What standards, regulations, technologies, resource availability
impact this project?
Constraint
Supporting Detail
Initial Project SizingBudget:
What are the estimated costs to complete this project (document
variability, range, precision at this point)
What is the financial justification for this project?
(i.e. Benefit Cost Analysis, Return on Investment, NPV . . .)
What financial gains are there to doing/not doing this
project?High Level Schedule:
When are the phases/deliverables planned to begin/end?
Phase/Deliverable
Time
6.
7. Milestones:
What major points are important to communicate/measure
against?
When should/will they occur?Resource Requirements:
What specialized resources are necessary to complete this
project?
Team Member
Role
Responsibility
Sponsor
8. Project Manager
Management Approaches:
How will status be taken?
How will project be communicated?
How will change be managed?
How will issues be escalated?
How will the risk be managed?
Communication Type
Stakeholders
Frequency
Agenda/ Content
Responsible
Distribution Media
9. Note: These may be separate plans within the context of the
integrated project planSign-offs/Reviews:
At what points will management/customer/team/peer reviews be
conducted? For what purpose?
Who signs off on the project reviews?
Reviews
Sponsor
10. Customer
Project Manager
Acceptance Criteria:
What measurements will be used to determine customer
acceptance?
What performance criteria define project success (i.e. time,
cost, resource, quality prioritization)?
What check points are in place to ensure the right product is
being delivered in the right way?
Acceptance Criteria
Detail
Priority
Requestor
11. Impacted ⁄ Interdependent Projects
What projects connect to this project via inputs/outputs?
What products are impacted by this project/how?
What other projects are addressing related issues?
Project
Interdependency Relationship
PROJECT CHARTER
TEMPLATE
(CONTAINS SCOPE SEC
12. TION)
:
PROJECT NAME
:
Executive Summary
¨
Where did this project come from?
¨
Why is it being done?
¨
What impact will the project create (internally, externally)?
¨
What strategic plan does it contribute to?
¨
What does the customer receive/not
receive by project end?
¨
What key assumptions are driving this project?
¨
What risks could challenge project success?
13. Goals
¨
What business/organization goal(s) does this project support?
¨
What business need is being satisfied by this project?
Objectives
¨
What, s
pecifically, needs to be done to meet project/customer
requirements/expectations/goal?
¨
What is the target of the project?
Note:
Ensure each objective contributes to the goal. Check to satisfy
the
"SMART" criteria
S
cope:
¨
What does the work of the project t
o meet goal include/not include?
Work Includes
14. Work does not Include
PROJECT CHARTER TEMPLATE (CONTAINS SCOPE
SECTION):
PROJECT NAME:
Executive Summary
tegic plan does it contribute to?
Goals
support?
Objectives
requirements/expectations/goal?
Note: Ensure each objective contributes to the goal. Check to
satisfy the
"SMART" criteria
Scope:
include?
Work Includes Work does not Include
15. PJM Case Study
Case Study Background:
Ms. Deidre Jackson, the CEO of Acme Company, was recently
given a report published by the Project
Management Institute called the Pulse of the Profession.1 In the
report, she learned a startling statistic.
PMI® reported that when projects are poorly managed,
approximately $122 million is wasted for every
$1 billion spent (12.2%). Now, her company’s annual expense
for projects is much smaller
(approximately $3 million expected in the next 12 months), but
if she could experience even a partial
amount of that savings, she could reinvest those savings in
future growth.
In order to accomplish this, she believes that she needs to adopt
a more formal or mature approach to
managing projects, and she needs to professionalize the project
management teams and, specifically, the
project managers. She has a colleague, Xin Xue, from a
previous company who was the internal project
management expert in the company who she believes might be
able to help, so she gives her a call to get
her take.
Ms. Jackson just finished a long conference call with Ms. Xue,
16. and she now has a better idea of what this
might take in terms of effort and resources to move forward. In
short, in Ms. Xue’s opinion, there is a way
to experience the savings that Ms. Jackson hopes for, but it will
take some time and investment, so she
thinks they should move forward with maturing their team and
management approach, but, as noted, it
will take an investment, so Ms. Jackson needs to be certain that
the savings will deliver sufficient
business value. In short, is there a solid, defensible business
case for such a project?
Present Situation:
Ms. Jackson emailed you the Pulse of the Profession report over
the weekend, and you are now sitting in
her office at 9:00 am on Monday morning. She wants you to
develop a business case for implementing a
training program that will lead to maturing the organization’s
project management practices. Based on her
work over the weekend to see where some monies may be
available for the unexpected project and her
conversation with Ms. Xue, she provides you with the following
information:
• The company expects to spend approximately $3,000,000 on
project related work over the next
12 months (year 1) and $3,500,000 over the following 12
months (year 2).
• Based on her conversations with Ms. Xue, she believes the
cost of training and implementing a
more mature model will be approximately $175,000 as an initial
investment
• Conservatively, she believes that the company will experience
17. a savings of 3 percent in the first
year and 4.5 percent in the second year
• Although the company will experience these savings for many
more years in her opinion, she
wants to show that the company will receive a sufficient savings
within the first 2 years to justify
this investment within the business case
• On most investments, the company would expect to see a
return of 11½ - 12 percent (internal rate
of return), and the cost of money (discount rate) is 6 percent.
1 Including in assigned reading for Week 1.
Ms. Jackson has to prepare a business case to share with her
Board of Directors at the next quarterly
board meeting. There are seven board members including the
Chairman, Vice Chair, Secretary, and
members of the Compliance Committee, The Chairman of the
Board, Lou Jackson, is typically resistant
to investing money in these types of initiatives so it is
important that the business case is well defined.
Ms. Jackson is considering having Jaitan Darshana, her internal
PM who has a long tenure with the
organization, assist her with the preparation of the business case
but she is concerned that Jaitan may be
resistant to the idea.
Business Case Assignment Instructions & Considerations
18. You have been tasked by Ms. Jackson with drafting a business
case for this potential initiative, and she
has provided you with a template to use (see template attached
to assignment instructions). She provides
you with the following comments related to each section of the
template, but she tells you that you will
need to sharpen and expand on the ideas that she has provided.
She expects your final draft to be ready to
take to the company’s Board of Directors for review and
approval by week’s end.
• Background and Business Problem
o She believes this has been covered in the contents of your
initial conversation, where she
provided you with background information (see above case
study material)
• Strategic Case
o She states that this is strategically tied to the company’s goal
of becoming more project
oriented, as they believe this will allow for more efficient and
effective work, leading to
the company being able to grow in a more scalable manner.
• Project Overview
o In addition to what she has stated above, if the business case
is approved, then she
believes the basic project would be an 8 – 10 week training
program for all project
managers and team members that would train them in the
adoption of a more mature
project management model, and it would include some
mentorships by the trainer. She
19. believes this would cost a total of $175,000.
• Expected Benefits
o The expected benefits would be increased efficiencies and
effectiveness, as noted above.
• Financial Considerations
o She has provided you with the investment amount to provide
financial support for the
investment
• Risks
o She has asked you to look at primarily risks associated with
the overall initiative, not
necessarily those focused on the training aspect of the project.
The CEO is concerned
about potential disruptions to current projects that are already
in flight.
• Timeline
o Based on her conversations with Ms. Xue, she believes the
project execution could begin
within 60 - 90 days, depending on the path chosen for moving
forward
• Recommendations and Next Steps
o She has asked you to consider all the relevant data you have
collected and put into the
business case, and then provide a succinctly stated and well-
supported recommendation
and concrete next steps if the proposal is accepted
20. General Case Considerations for Business Case:
o It is expected that you will need to make reasonable
assumptions in completing the
business case, so rely on the case study as guide. This is similar
to how projects are
conceived in the real world. We have a basic set of factors, and
then we must make
reasonable assumptions as we progress forward.
Task_TableIDNameDurationStartFinishPredecessorsResourcesN
otesProject Server 2016 upgrade - waterfall1Plan for upgrade to
Project Server 20165 days1/25/16 8:001/29/16
17:00http://go.microsoft.com/fwlink/p/?LinkId=2573572Review
system requirements for upgrade1 day1/25/16 8:001/25/16
17:00Server Administrator, Technical Analyst3Plan for clients1
day1/26/16 8:001/26/16 17:002Technical Analyst, Server
Administrator4Gather information about your Project Server
2010 environment1 day1/27/16 8:001/27/16 17:003Server
Engineer, Server Administrator5Plan to upgrade
customizations1 day1/28/16 8:001/28/16 17:0046Create an
upgrade communications plan1 day1/29/16 8:001/29/16
17:005Project Manager7Prepare your environment for upgrade4
days2/1/16 8:002/4/16 17:001Server
Administratorhttp://go.microsoft.com/fwlink/p/?LinkId=257359
8Deploy your Project Server 2016 destination environment1
day2/1/16 8:002/1/16 17:00Server Engineer9Prepare your
Windows PowerShell environment1 day2/2/16 8:002/2/16
21. 17:008Server Engineer10Disable backward compatibility mode
in your Project Server 2010 environment1 day2/3/16 8:002/3/16
17:009Server Administrator11Check your Project Server 2010
data for issues that can cause the upgrade to fail1 day2/4/16
8:002/4/16 17:0010Server Administrator12Create backup copies
of your Project Server 2010 farm databases1 day2/5/16
8:002/5/16 17:007Server
Administratorhttp://go.microsoft.com/fwlink/p/?LinkId=257360
13Restore your Project Server 2010 farm databases for upgrade1
day2/8/16 8:002/8/16 17:0012Server
Administratorhttp://go.microsoft.com/fwlink/p/?LinkId=257361
14Upgrade your databases and Project Web App site
collections14 days2/9/16 8:002/26/16 17:0013Server
Administratorhttp://go.microsoft.com/fwlink/p/?LinkId=257363
15SharePoint upgrade6 days2/9/16 8:002/16/16 17:0016Check
the SharePoint content database for errors that can cause
upgrade to fail1 day2/9/16 8:002/9/16 17:0017Attach and
upgrade the SharePoint content database1 day2/10/16
8:002/10/16 17:0016Server Administrator18Add your account as
a secondary owner of the Project Web App site collection that
you want to upgrade1 day2/11/16 8:002/11/16 17:0017Server
Administrator19Migrate users who are using Windows Classic
authentication mode to claims based authentication (optional)1
day2/12/16 8:002/12/16 17:0018Server Administrator20Check
your Project Web App site collection for issues that can cause
upgrade of the site to fail1 day2/15/16 8:002/15/16
17:0019Server Administrator21Upgrade the Project Web App
site from SharePoint 2010 mode1 day2/16/16 8:002/16/16
17:0020Server Administrator22Project Server upgrade8
days2/17/16 8:002/26/16 17:001523Consolidate your Project
Server 2010 databases to a Project Services database1
day2/17/16 8:002/17/16 17:0024Attach the Project Services
database to the web application1 day2/18/16 8:002/18/16
17:0023Server Administrator25Check your Project Services
database for errors that can cause upgrade to fail1 day2/19/16
8:002/19/16 17:0024Server Administrator26Upgrade the Project
22. Services database1 day2/22/16 8:002/22/16 17:0025Server
Administrator27Mount the Project Web App instance1
day2/23/16 8:002/23/16 17:0026Server Administrator28Check
the Project Web App instance for issues that can cause upgrade
to fail1 day2/24/16 8:002/24/16 17:0027Server
Administrator29Upgrade the Project Web App instance1
day2/25/16 8:002/25/16 17:0028Server Administrator30Enable
Project Web App features1 day2/26/16 8:002/26/16
17:0029Server Administrator31Testing2 days2/29/16 8:003/1/16
17:002232Test Sharepoint Server1 day2/29/16 8:002/29/16
17:00Server Administrator, Server Engineer33Test Project
Server1 day3/1/16 8:003/1/16 17:0032Server Administrator,
Server Engineer
Resource_TableIDNameInitialsTypeMaterial LabelGroupEmail
AddressUser Logon AccountMax UnitsStandard RateCost Per
UseNotes1Technical AnalystTWork100%$50.00/h02Server
AdministratorSWork100%$65.00/h03Server
EngineerSWork100%$60.00/h0
Assignment_TableTask NameResource Name% Work
CompleteWorkUnitsReview system requirements for
upgradeServer Administrator08h100%Review system
requirements for upgradeTechnical Analyst08h100%Plan for
clientsTechnical Analyst08h100%Gather information about your
Project Server 2010 environmentServer
Administrator08h100%Gather information about your Project
Server 2010 environmentServer Engineer08h100%Plan to
upgrade customizationsServer Administrator08h100%Deploy
your Project Server 2016 destination environmentServer
Engineer08h100%Prepare your Windows PowerShell
environmentServer Engineer08h100%Disable backward
compatibility mode in your Project Server 2010
environmentServer Administrator08h100%Check your Project
Server 2010 data for issues that can cause the upgrade to
failServer Administrator08h100%Create backup copies of your
Project Server 2010 farm databasesServer
Administrator08h100%Restore your Project Server 2010 farm
23. databases for upgradeServer Administrator08h100%Check the
SharePoint content database for errors that can cause upgrade to
failServer Administrator08h100%Attach and upgrade the
SharePoint content databaseServer Administrator08h100%Add
your account as a secondary owner of the Project Web App site
collection that you want to upgradeServer
Administrator08h100%Migrate users who are using Windows
Classic authentication mode to claims based authentication
(optional)Server Administrator08h100%Check your Project Web
App site collection for issues that can cause upgrade of the site
to failServer Administrator08h100%Upgrade the Project Web
App site from SharePoint 2010 modeServer
Administrator08h100%Consolidate your Project Server 2010
databases to a Project Services databaseServer
Administrator08h100%Attach the Project Services database to
the web applicationServer Administrator08h100%Check your
Project Services database for errors that can cause upgrade to
failServer Administrator08h100%Upgrade the Project Services
databaseServer Administrator08h100%Mount the Project Web
App instanceServer Administrator08h100%Check the Project
Web App instance for issues that can cause upgrade to
failServer Administrator08h100%Upgrade the Project Web App
instanceServer Administrator08h100%Enable Project Web App
featuresServer Administrator08h100%Test Sharepoint
ServerServer Administrator08h100%Test Sharepoint
ServerServer Engineer08h100%Test Project ServerServer
Administrator08h100%Test Project ServerServer
Engineer08h100%
Agile project management and the PMBOK® guide
CONFERENCE PAPER19 October 2008
Sliger, Michele
How to cite this article:
Sliger, M. (2008). Agile project management and the PMBOK®
guide. Paper presented at PMI® Global Congress 2008—North
America, Denver, CO. Newtown Square, PA: Project
24. Management Institute.
A common misconception in software project management is
that in order to properly follow the practices outlined in A
Guide to the Project Management Body of Knowledge
(PMBOK® Guide)---Third Edition (Project Management
Institute [PMI], 2004), we must use a nonagile, or waterfall,
approach. This paper attempts to correct that fallacy and show
that agile projects still follow the project life cycle and
processes as outlined by the PMBOK® Guide. First we must
examine the origins of the PMBOK® Guide, the book most
often used as a reference by project managers. Then we’ll see
how its project life cycle and processes correlate to those in an
agile project.
The Project Management Institute and the PMBOK® Guide
The Project Management Institute was founded in 1969 at the
Georgia Institute of Technology by five volunteers: James
Snyder, Gordon Davis, Eric Jenett, A.E. Engman, and Susan C.
Gallagher (PMI, 2005). Its original purpose was to form an
organization in which members could share their experiences in
project management and discuss issues. The purpose has
expanded today to advancing practice knowledge and
application in the profession of project management.
To this end, in 1983 the PMI created a publication entitled
“PMI Special Report on Ethics, Standards, and Accreditation.”
The “Standards” portion of this document was the “Project
Management Body of Knowledge.” In 1996 the first edition of
the PMBOK® Guide, a book that outlined project management
knowledge areas, processes, and practices, was published.
The PMBOK® Guide became a standard for generally
recognized good practices in project management. Now in its
third edition, the PMBOK® Guide has sold more than a million
copies worldwide. For years this has been the de facto archetype
that all project managers follow—not just software project
managers.
Although the PMBOK® Guide does not dictate methodology,
many software project managers nevertheless began to associate
25. the waterfall model with the processes outlined in
the PMBOK® Guide. Perhaps it was because waterfall was the
prevalent methodology at the time, or perhaps it was because
the waterfall model provided a framework that supported all of
the PMBOK® Guide practices. Whatever the reason, it has been
a hard misconception to shake, even though the third edition of
the PMBOK® Guide makes it very clear that it is up to the
reader to determine what processes are most appropriate to use
in their situation.
Indeed, the PMBOK® Guide has paradoxically become broader
in its context even as it becomes more detailed in its processes
and practices. As an important and noted change from the 2000
edition, the third edition states clearly that “there is no single
best way to define an ideal project life cycle” (PMI, 2004, p.
20). It goes on to say that “the project manager, in collaboration
with the project team, is always responsible for determining
what processes are appropriate, and the appropriate degree of
rigor for each process, for any given project” (PMI, 2004, p.
37). Although the 2000 edition may have made it difficult to
make a case showing how agile practices are in keeping with
best practices as outlined in the PMBOK® Guide, the third
edition makes it easy.
It is not only the PMBOK® Guide that is clear in its support of
the validity of the newer agile methodologies. PMI’s
magazine PM Network® started talking specifically about agile
practices in April 2005, when Peter Fretty’s feature article
“Reconciling Differences” shone a spotlight on how agile
practices had improved productivity, quality, and customer
satisfaction at Shine Technologies (Fretty, 2005). That was the
first of several articles that have since appeared in the magazine
touting agility. PMI is also supporting the training of its project
managers in Agile Project Management courses and
presentations in PMI-sponsored programs such as PMI Seminars
World®, PMI Global Congresses®, and chapter symposiums and
conferences.
PMI does not advocate any particular methodology. It only
26. supplies a standard of good project management practices, and
whether individuals choose to follow a waterfall or an agile
approach, the PMBOK® Guide will support them both. You
don’t have to cast aside your PMP designation to be agile. All
you need to do is change how you implement the practices (and
sometimes you may need to rethink where you’ve been placing
your focus).
Project Life Cycle
The PMBOK® Guide defines the project life cycle as “a
collection of generally sequential project phases whose name
and number are determined by the control needs of the
organization or organizations involved in the project” (PMI,
2004, p. 368). These phases are a collection of logical
groupings of related activities that usually culminate in a
deliverable. The PMBOK® Guide describes their sequence as
beginning with an initial phase, followed by a series of
intermediate phases, and ending in a final phase (Exhibit 1).
Processes that aid in the completion of the deliverable are
performed in each phase.
Exhibit 1--Project Life Cycle Phases (PMI, 2004, p. 23)
In traditional approaches to software development, these phases
have typically followed the waterfall methodology (Exhibit 2).
For example, one phase might be Design, and the deliverable for
this phase would be some type of a system design document.
Many times sign-offs are required before proceeding to the next
phase, but this is the result of the methodology and not a
mandate by the PMBOK® Guide.
Exhibit 2--Waterfall Approach to Software
Development (Royce, 1970, pg. 2).
Let’s look at how this translates to an agile project life cycle. In
the definition “a collection of generally sequential project
phases,” the word “sequential” is often the biggest stumbling
block. This is due to the popular misconception that
“sequential” equals “waterfall.” The agile project life cycle has
27. sequential project phases that we call iterations, with the
deliverable in each iteration being working code. However, all
of the processes that are typically done sequentially—analysis,
design, code, test—are done within a single phase in agile
projects to produce an increment of code.
You may even want to consider these iterations as subphases of
a larger phase known as the release, where the major deliverable
is set of those increments of code such that they can be put into
production and/or delivered to the customer.
The second part of the project life cycle definition points out
that the number (and in our agile interpretation, the duration) of
the phases is “determined by the control needs of the
organization.” In agile projects, the number of iterations is
decided on by the customer, based on what they define as the
minimum amount of functionality deemed acceptable for a
release. The length of the iterations—generally between 1 and 4
weeks—is determined by the “control needs” of the customer
(or customer representative)---that is, how often the customer
will want to change what the delivery team is working on. The
volatility of the industry, the amount of risk, and the clarity of
the vision are all factors that affect the length of the iteration
and define the organization’s need for flexibility.
In the initial phase of agile projects, there is a planning process
that is part of the first iteration, and the deliverable is the high-
level plan for the project (and in most cases, the first increment
of working code is delivered as well). Intermediate phases in
agile projects are the releases and/or iterations where additional
features are delivered in the form of working code. The final
phase in an agile project is the hardening or production-
readiness phase, where process activities that prepare the
product for delivery are conducted, along with the final project
retrospective and other closing processes.
The PMBOK® Guide states that the transition from one phase to
another usually involves some type of technical transfer or
hand-off (PMI, 2004, p. 20). This is the type of phrasing that
might lead readers to believe that only a waterfall methodology
28. is appropriate when following PMBOK® Guide practices.
However if we interpret “hand-off” to mean that there is a hand-
off of an increment of code to the customer to use as they see
fit, then agile is still in keeping with the basic tenets of
the PMBOK® Guide. At the end of each iteration, an increment
of code is completed by the team and reviewed by the customer.
Regardless of the outcome, the next iteration begins as planned
(unless the project is cancelled)—only the content of the work
for that iteration is subject to change.
Because of this regular rhythm of incremental delivery, many
have proffered that each iteration of an agile project is itself a
project, having a start and stop date, and delivering a product as
a result. I disagree with this assessment, however, believing it
to be colored by years of waterfall practice. The waterfall
methodology outlines the processes of analysis, design, coding,
testing, and deployment, which were all done as part of a
project. Because these are things that are all done within an
iteration in agile, the logical assumption for many was that an
iteration equaled a project. But an iteration is more properly
referred to as a phase or subphase of the project, if
using PMBOK® Guide terminology. Projects are “undertaken to
create a lasting outcome” (PMI, 2004, p. 5), with the project
team generally remaining the same until the project ends. In
agile projects the delivery team is kept together from iteration
to iteration, with each delivered increment an enhancement
and/or evolution of the previous increment.
The PMBOK® Guide refers to this as “progressive elaboration”
(PMI, 2004, pp. 6, 8), and includes this as a characteristic of
some projects. It defines agile projects perfectly.
The PMBOK® Guide notes that each phase (iteration) should
have a formal initiation outlining what deliverables are
expected in that phase, and a formal review at the end to
conclude the phase with permissions obtained to continue or a
decision made to stop the project. Agile iterations work on this
premise as well. The initiation is done by the customer, whether
informally with a verbal committal that work should begin or
29. approval that work should continue, or formally through the use
of contracts. Agile iterations begin with a planning meeting to
define what will be completed in the iteration and end with a
review to learn from the events and obtain customer acceptance
of the features delivered. During the review, the project can be
cancelled or approved to continue, or a release can be requested
and implemented immediately or implemented in the next
iteration.
Exhibit 3 shows how the project life cycle as depicted in
the PMBOK® Guide can be mapped to the agile project life
cycle. In fact, the agile project life cycle is simply a fractal, as
illustrated by the expanded phases in the figure. An agile
project can be made up of multiple releases or periods of
calendar time (quarters are commonly used), which in turn are
made up of iterations in which teams create the increment of
working code. Each has an initial phase in which planning is a
key process, intermediate phases, and a final phase in which
reviews and retrospectives are key processes.
Exhibit 3--Phases and Subphases in an Agile Project Life Cycle
(Agile Fractal).
One area in which agile projects and
the PMBOK® Guide disagree is in the involvement of the
stakeholders. In agile projects, there is an expectation of the
active involvement of a customer or customer representative
throughout the duration of the project. This individual sets the
direction for the product at the outset of the project, and refines
that vision at the beginning of each iteration, with the same
high level of influence each iteration over the characteristics of
the product until the product is released.
The PMBOK® Guide takes the view that stakeholder influence
occurs up front and then declines throughout the rest of the
project (PMI, 2004, p. 21). In agile projects, however, the
stakeholders’ influence remains strong and does not decrease
until the product is released and the project is over. Agile
welcomes change and provides a framework that manages that
30. change through the use of iterative and incremental
development with regular customer feedback, reviews, and
retrospective analysis.
Project Management Processes
Walter A. Shewhart’s Plan-Do-Check-Act (PDCA) model, also
known as the “Shewhart cycle,” was made popular by the
quality guru, Dr. W. Edwards Deming.
The PMBOK® Guide acknowledges this iterative method of
continuous improvement and mapped its project management
process groups to the PDCA cycle (Exhibit 4). These project
management process groups defined by the PMBOK® Guide are
Initiating, Planning, Executing, Monitoring and Controlling,
and Closing. The graphic on the right in Exhibit 4 is from
the PMBOK® Guide (PMI, 2004, p. 40).
Exhibit 4--Plan-Do-Check-Act and the PMBOK® Guide Process
Groups
The process groups are not phases, but rather they are an
integrated set of processes applied iteratively throughout the
project and revised as needed. Like the project life cycle, we
can map the process groups to the agile fractal—at the overall
project level, at the release level, and at the iteration level (see
Exhibit 5).
Exhibit 5--Process Groups and the Agile Fractal
Conclusion
The PMBOK® Guide is a standard for generally recognized
good practices in project management. Unfortunately,
misconceptions still exist regarding the type of methodologies,
as outlined in the PMBOK® Guide, that can be used to
implement these practices. It is perfectly fine to use an agile
approach—you can do so and still be in keeping with the
recommendations in the PMBOK® Guide.
The PMBOK® Guide outlines project life cycle phases that
correspond to agile releases and/or iterations. An agile project
can be made up of multiple releases or calendar quarters, which
