See

discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/221231619

Comparing PMBOK and Agile Project

Management Software Development Processes

Conference Paper January 2007

DOI: 10.1007/978-1-4020-8741-7_68 Source: DBLP

CITATIONS READS

11 1,478

1 author:

Panos Fitsilis
Technological Educational Institute of Thessaly
75 PUBLICATIONS 431 CITATIONS

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Enterprise Architecture for Digital Cities (EADIC) View project

SPRINT SMES Project http://sprint.teilar.gr/ View project

All content following this page was uploaded by Panos Fitsilis on 21 September 2014.

The user has requested enhancement of the downloaded file.

 Comparing PMBOK and Agile Project Management
software development processes
P. Fitsilis
TEI Larissa
41335 Larissa, Greece
fitsilis@teilar.gr

Abstract- The objective of this article is to compare a generic
set of project management processes as defined in Project
Management Body of Knowledge (PMBOK) with a number of
agile project management processes. PMBOK is developed by
Project Management Institute and it is structured around five
process groups (initiating, planning, execution, controlling and
closure) and nine knowledge areas (integration management,
scope management, time management, cost management, quality
management, human resource management, communication
management, risk management, procurement management). On
the other hand, agile software project management is based on the
following principles: embrace change, focus on customer value,
deliver part of functionality incrementally, collaborate, reflect
and learn continuously. The purpose of this comparison is to
identify gaps, differences, discrepancies etc. The result is that,
agile project management methodologies cannot be considered
complete, from the traditional project management point of view,
since a number of processes either are missing or not described
explicitly.
I. INTRODUCTION
Traditional software development methodologies grew out
of a need to control large development projects, and from the
difficulties of estimating and managing these efforts to reliably
deliver results. These difficulties are inherited in the nature of
software and they were identified from the early years of
software system development and unfortunately most of them
still remain. Most of the skepticism expressed in the legendary
book of Frederic Brooks, The mythical man-month thirty
years ago is still valid [1].
Further, todays information technology professionals are
under tremendous pressure to deliver quality IT products and
services, in order to respond to an always dynamic and fast
changing market.
As a result, the list of large software projects that have failed
is still growing. Robert Charette [2] compiled a list of the most
notable fiascoes in the IT industry. Further, he states that most
IT experts agree that such failures occur far more often than
they should and that the failures are universally
unprejudiced.
Literature suggests that project organization, stakeholders
expectation management, scope creep etc., are always
important factors leading to project success, when managed
properly [3, 4, 5].
Agile methodologies attempt to overcome these obstacles by
changing the approach used to develop software and manage
projects. Agile software development attempts to put the
software being developed first. Further, agile methods
acknowledge that the user requirements change, that we have
to respond quickly to the users needs, that there is a need to
produce frequent and regular, software releases, etc.
The Manifesto for Agile Software Development was
released in February 2001 by a group of 17 software process
methodologists, who attended a summit meeting to promote a
better way of developing software and then formed the Agile
Alliance. The Manifesto for Agile Software Development can
be found on the Agile Alliance website
(http://www.agilemanifesto.org).
Since then, a number of software development methods
subscribed to this approach.
The list varies depending on different viewpoints and
interpretations, but in general the list includes Extreme
Programming (XP), Scrum, Feature-Driven Development
(FDD), Adaptive Software Development (ASD), Crystal Clear
Methodology, etc.
Most agile development methods were created within
corporations by software process experts as an attempt to
improve existing processes. For example, XP was created by
Kent Beck during his work on the Chrysler Comprehensive
Compensation System payroll project. Kent Beck refined the
development method used and the result was published in his
book Extreme Programming Explained [6]. Similarly, FDD
was initially introduced by Jeff De Luca, in order to meet the
specific needs of a 15 month, 50 person software development
project at a large Singapore bank in 1997. FDD was influenced
by ideas of Peter Coad on object modeling. The description of
FDD was first introduced in the book Java Modeling in Color
with UML by Peter Coad, Eric Lefebvre and Jeff De Luca in
1999 [7]. A more generic description of FDD decoupled from
Java can be found in the book A Practical Guide to Feature-
Driven Development [8].
On the other end more traditional project management
methodologies rely heavier on processes, linear development
cycles and waterfall like software development life cycles.
Along with predictability, they inherited a deterministic,
reductionist approach that relied on task breakdown, and was
predicated on stability stable requirements, analysis and
stable design. This rigidity was also marked by a tendency c. Develop Project Management Plan,
towards slavish process compliance as a means of project d. Direct and Manage Project Execution,
control [9]. e. Monitor and Control Project Work,
Project Management Body of Knowledge (PMBOK) f. Integrated Change Control, and
developed by Project Management Institute is the best g. Project Closure.
representative of this approach [10]. PMBOK formally defines 2. Project Scope Management. It encapsulates processes
a total of 44 project processes that describe activities that are responsible for controlling project scope. It
throughout a project's life cycle. These 44 project processes are consists of:
organized into two axis: into five process groups and into nine a. Scope Planning,
knowledge areas that will be described briefly in the following b. Scope Definition,
section. Within PMBOK each process is described in terms of c. Create Work Breakdown Structure (WBS),
inputs (documents, plans, design, other data, etc.), outputs d. Scope Verification, and
(documents, products) and tools and techniques (mechanisms e. Scope Control.
that are applied to inputs for producing outputs) and without 3. Project Time Management, which describes the
being too specific, it provides guidance to someone that wishes processes concerning the timely completion of the
to apply the processes [11]. project. It consists of
Similar approaches, process oriented, have been introduced a. Activity Definition,
by other international bodies or associations. Among them, b. Activity Sequencing,
worths mentioning International Project Management c. Activity Resource Estimating,
Association, Competence Baseline (ICB), which describes the d. Activity Duration Estimating,
necessary competences (technical, behavioral, contextual) for e. Schedule Development, and
project management [12] and project management body of f. Schedule Control.
knowledge as defined by Association for Project Management 4. Project Cost Management that includes processes
in UK (APM) (http://www.apm.org.uk) which again describes concerning the cost. The processes that are part of this
40 necessary for project management competencies. knowledge area are:
These approaches study project management in a multi facet a. Cost Estimating,
way and therefore somebody can argue about the definition of b. Cost Budgeting, and
a process or if a competence is needed but not about their c. Cost Control.
completeness. Further, most of them are widely known and 5. Project Quality Management describes the processes
accepted by professionals and organizations. involved in assuring that the project will satisfy the
However, even if agile methods look attractive and their use objectives for which it was undertaken. It consists of:
is achieving promising results there is criticism if they are a. Quality Planning,
complete project management methodologies or extended, with b. Perform Quality Assurance, and
some management elements, software lifecycles. Similar c. Perform Quality Control.
studies and discussion can be found to [13, 14] 6. Project Human Resource Management includes all
In the next sections, we will briefly present PMBOK along necessary processes for organizing and managing the
with some of the most known agile methods. Then we will to project team. It consists of:
compare them having as basis for comparison the processes as a. Human Resource Planning,
defined, per knowledge area, in PMBOK. b. Acquire Project Team,
II. PROJECT MANAGEMENT INSTITUTE BODY OF c. Develop Project Team, and
KNOWLEDGE d. Manage Project Team.
7. Project Communications Management describes the
As it was mentioned before, Project Management Body of processes concerning communication mechanisms of
Knowledge (PMBOK) [10] is defined in terms of process a project, and relate to the timely and appropriate
groups and knowledge areas. In this study, we will focus on the generation, collection, dissemination, storage and
knowledge areas, since these areas are offering a more precise ultimate disposition of project information. It consists
idea of what is project management about and at the same time of the following processes:
they give the overall picture. The knowledge areas are the a. Communications Planning,
following: b. Information Distribution,
1. Project Integration Management describes the c. Performance Reporting, and
processes and activities that integrate different aspects d. Manage Stakeholders
of project management. It consists of the following 8. Project Risk Management describes the processes
processes: concerned with project-related risk management. It
a. Develop Project Charter, consists of:
b. Develop Preliminary Project Scope Statement, a. Risk Management Planning,
 b. Risk Identification,
c. Qualitative Risk Analysis,
d. Quantitative Risk Analysis,
e. Risk Response Planning, and
f. Risk Monitoring and Control.
9. Project Procurement Management includes all
processes that deal with acquiring products and
services needed to complete a project. It consists of:
a. Plan Purchases and Acquisitions,
b. Plan Contracting,
c. Request Seller Responses,
d. Select Sellers,
e. Contract Administration, and
f. Contract Closure.
III. AGILE PROJECT MANAGEMENT
Agile Software Development manifesto objective was to
uncover better ways of developing software by doing it and
helping others do it ((http://www.agilemanifesto.org). The
principles that it is based are the following:
Individuals and interactions over processes and tools.
Working software over comprehensive
documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
Obviously, the agile manifesto is not a process oriented
approach.
As, it was presented in the introduction, there are many
software development methods that can be called "agile".
However, in this work we have selected to include only a few
of them as the most representative. The software development
methods that were included are: Extreme Programming (XP),
Scrum and Feature-Driven Development (FDD).
A. eXtreme Programming (XP)
Extreme Programming, or XP, is an agile method that
emerged from a project at Chrysler Corporation in the late
1990s. It was devised by Ward Cunningham, Kent Beck, and
Ron Jeffries. The method is well documented in a number of
books, articles and web sites
(http://www.extremeprogramming.org/) [6, 15, 16, 17]. XP
method is based on four values:
Communication, which is based on practices such as
unit testing, pair programming, task estimation.
Simplicity, by always seeking the simplest solution.
Feedback, by having concrete knowledge about the
current state of system
Courage, to admit flaws in the system and take
immediate corrective actions
Further, XP is based on a number of practices. Some of them
are:
Planning. The scope of the next release should be
defined as soon as possible, by combining business
priorities and technical estimates.
Small releases. The system has to be up and running
by having very short cycles and quick releases.
Metaphor. All development is driven by a simple
story of how the whole system works.
Simple design. Simple solutions are the preferred.
Complexity should be removed wherever possible.
Testing. Testing is a continuous activity.
Pair programming. All programmers are working in
pairs.
Collective ownership. Anyone can change any code
anywhere in the system at any time.
Continuous integration. The system is built many
times a day, as soon as a task is finished.
On-site customer. A representative of the customer
organization should be available full-time to the
project team to answer questions.
B. SCRUM
Scrum approach for new product development was first
presented by Takeuchi and Nonaka [18] after observing small
high performance teams, at various companies. Similar,
observations were made as well by other researchers [19, 20].
Scrum is an agile software development process where
projects progress via a series of month-long iterations called
sprints [21, 22, 23]. Furthermore, a series of scrum sprints, on
average 6 to 9, can produce a product release.
At the beginning of the project, the project requirements are
captured into a list known as the product backlog.
Then, at the start of each sprint a sprint planning meeting is
held during which the product owner prioritizes over the
product backlog and the members of the scrum team define the
tasks that they can complete during the coming sprint.
For each day of the sprint, there is daily stand-up meeting for
discussing project issues, called the daily scrum. Daily scrums
help significantly team development and team communication.
Further, the members of the daily scrum can quickly decide on
any issue requiring further attention. Issues are not debated in
the meeting itself, since the meeting should not last more than
15 minutes. At the end of the sprint the team presents the
developed functionality at a Sprint Review Meeting.
Scrum processes are grouped in three phases [23], the
pregame, the game and the post game. Pregame phase includes
the following processes:
Planning, which includes the definition of a new
release based on currently known product backlog,
along with an estimate of its schedule and cost. If the
system under development is new, planning includes
both conceptualization and analysis.
Architecture development. Includes the architecture
development and the high level design.
The game consists of development sprints that produce a
new product release.
Postgame is the closure of the project, which includes
preparation of the releases, producing the final documentation,
executing the site acceptance testing and the final product
release.
C. Feature Driven Development (FDD)
Feature Driven Development (FDD) is an iterative and
incremental software development process [7, 8]. FDD
methodology consists of five steps that are the following:
Develop the Overall Model,
Build the Feature List,
Plan by Subject Area,
Design by Feature Set, and
Build by Feature.
In the first step, of developing the overall model, a high level
walkthrough of the scope of the system and of its environment
is done. The main purpose is to capture requirements and to
develop the initial UML class diagram which describes the
entities of the problem domain. The whole work is split and
assigned to small teams, consisting of developers and users.
These teams are responsible for parts of the whole model and
for presenting their models for review and approval. Finally,
the proposed models are merged in order to form the domain
model.
The second step of FDD is to build the feature list. The
development team will identify the set of features needed, by
decomposing the system functionality into subject areas. Each
subject area is composed of business activities that comprise
business activity steps (features). Features are granular
functions expressed in customer terms. Usually, each feature
requires up to two weeks of development. In case, the feature
requires more time then this step is decomposed into smaller
steps.
The third step is to produce the project development plan.
Planning by subject area involves planning the project by
grouping features to feature sets and subject areas. The
grouping is done according to the functionality and the existing
dependencies between features. Other factors to take into
consideration are: the load across the development team and
the complexity of the features to be implemented.
As soon as features are grouped and the features to be included
in the release are agreed, we have to determine the
development sequence, to assign business activities to chief
programmers and in doing so, consider which of the key
classes are assigned to which developers. When this planning
is complete the team would then agree on a schedule of
delivery for the subject area and the feature sets together with
the project sponsor.
The forth step is the Design by Feature Set. The objective
in this step us to produce the design of each feature set. The
design model includes UML sequence diagrams, refinement of
the overall UML class diagram developed in the first step, etc.
Finally, the fifth step, Build by feature, involves
packaging a smaller batch of features from the feature set
decided in step 4 and developing the code for those features
and unit testing them. The batch of features is known as a
Chief Programmer Work Package (CPWP) and should be
selected such that it can be completed by a single feature team
in less than 2 weeks.
IV. COMPARISON OF PMBOK AND AGILE METHODS
In order to compare the presented project management
methods we took as basis the PMBOK processes as they are
organized per knowledge area. The reasons that contributed to
this decision were two:
PMBOK is an exhaustive list of good practices, in the
form of processes that can be tailored and customized
to specific needs.
PMBOK is well known and formally documented
compared with the presented in this work agile
methods.
The result of this comparison is presented Table I.

PMBOK
Project Integration Management
Develop Project Charter
Develop Preliminary Project
Scope Statement
Develop Project Management
Plan
Direct and Manage Project
Execution
Monitor and Control Project
Work
Integrated Change Control
Close Project
TABLE I
COMPARISON OF PMBOK AND AGILE METHODS PROCESSES
XP
Integration of software as
soon as possible and as often
as possible (mostly related
with software code).
Collective code ownership
Project velocity measurement
Agile methods
Scrum FDD
Verification of management Development of the overall
approval and funding during system model.
planning phase.
Validation of development
tools and infrastructure
during planning phase.
Strong change management
procedure with product and
sprint backlog.
Refinement of system
architecture to support
changes.
Postgame phase.
 PMBOK
Project Scope Management
Scope Planning,
Scope Definition,
Create Work Breakdown
Structure (WBS),
Scope Verification, and
Scope Control
Project Time Management
Activity Definition,
Activity Sequencing,
Activity Resource
Estimating,
Activity Duration Estimating,
Schedule Development, and
Schedule Control
Project Cost Management
Cost Estimating,
Cost Budgeting, and
Cost Control project
Project Quality Management
Quality Planning,
Perform Quality Assurance,
and
Perform Quality Control.
Project Human Resource Management
Human Resource Planning,
Acquire Project Team,
Develop Project Team, and
Manage Project Team.
Project Communications Management
Communications Planning,
Information Distribution,
Performance Reporting, and
Manage Stakeholders
Agile methods
XP Scrum FDD
User Stories Perform domain analysis for Perform domain analysis for
Release Planning, Small building domain model. building domain model (step
Releases Development of a comprehensive 1).
product backlog list. Build Features List, subject
Development of a comprehensive areas (step 2).
product sprint backlog.
Definition of the functionality
that will be included in each
release.
Selection of the release most
appropriate for immediate
development.
Review of progress for assigned
backlog items.
Release Planning, Definition of the delivery date Determine development
Iterations planning and functionality for each release. sequence (step 3).
Monthly iterations Assign Business Activities to
Chief Programmers (step 3).
Assign Classes to Developers
(step 3).
Chief programmer work
package.
Not available Estimation of release cost, during Not available
planning phase.
Emphasize on testing Distribution, review and Review meetings (all steps)
(unit, acceptance) adjustment of the standards with Code inspection and unit test
Based on simplicity which the product will conform. (step 5)
Use of project standards Design review meeting
Sprint planning meeting
Sprint review meeting.
Daily scrum.
Personnel rotation to Appointment of project team(s) Appoint modeling team (step
various positions per release. 1)
Pair programming Team participation in sprint Appoint feature list team
Good working conditions meetings. (step 2)
(no overtime) Team participation in daily Appoint Planning Team
scrums. (step 3)
Appoint Feature Team (step
3)
Use of system metaphor Design review meeting Review meetings (all steps)
Customer always Scrum meeting
available Sprint planning meeting
Daily meetings Sprint review meeting
Use of project standards Communication of standards to
the project team
 PMBOK Agile methods
XP Scrum FDD
Project Risk Management
Risk Management Planning, Create prototype to limit Initial assessment of risks during Not available
Risk Identification, risk pregame.
Qualitative Risk Analysis, Risk review during review
Quantitative Risk Analysis, meetings
Risk Response Planning, and
Risk Monitoring and Control.
Project Procurement Management
Plan Purchases and Not available Not available Not available
Acquisitions,
Plan Contracting,
Request Seller Responses,
Select Sellers,
Contract Administration, and
Contract Closure.

[4] T. Chow, and D-B. Cao, A Survey Study of Critical Success Factors in
V. CONCLUSION Agile Software Projects, The Journal of Systems and Software, doi:
10.1016/j.jss.2007.08.020, in press.
Table I proves that agile methods do not define all facets [5] A. Carmichael, and D. Haywood, Better Software Faster, Prentice-Hall
needed in order to cover all aspects of project management, in NJ, 2002.
the traditional sense. This was partially expected since [6] K. Beck, Extreme Programming Explained: Embrace Change, Addison-
Wesley Professional, 1999.
traditional project management processes are fully defined [7] P. Coad, E. Lefebvre, and J. De Luca, Java Modeling in Color with
compared with agile methods that are considered empirical. UML: Enterprise Components and Process, Prentice Hall, 1999.
However, from this study we could conclude the following. [8] A. Carmichael, and D. Haywood, Better Software Faster, Prentice-Hall
NJ, 2002.
Agile methods are giving emphasis in the following [9] S. Augustine and S. Woodcock, Agile Project Management, CC Pace,
knowledge areas: Available at www.ccpace.com.
Scope Management, since emphasis is given in [10] PMI Institute, A Guide to the Project Management Body of Knowledge,
PMI Standard Committee, 2004.
managing requirements. [11] U.S. Department of Defense, Extension to: A Guide to the Project
Human resource management, since emphasis is given Management Body of Knowledge, First Edition, Version 1.0, 2003.
in team work. [12] International Project Management Association, IPMA Competence
Baseline, Version 3.0. Van Haren Publishing, 2006.
Quality management, even though not formally [13] M. Sliger, Relating PMBOK Practices to Agile Practices, Available at
defined, use of standards, testing and frequent reviews http://www.stickyminds.com
are promoted. [14] G. Alleman, PMBOK and agile article, Available at
http://herdingcats.typepad.com/my_weblog/2007/08/pmbok-and-
On the other hand, agile methods do not fully address the agile.html
following knowledge areas: [15] K. Auer, and R. Miller, Extreme Programming Applied: Playing to Win
Risk is not managed explicitly, (The XP Series), Addison Wesley - New York, 2002.
[16] S. W. Ambler, Agile Modeling: Effective Practices for Extreme
Cost management is not part of the agile Programming and the Unified Process, Wiley and Son, Inc., 2002.
methodologies [17] K. Beck and M. Fowler, Planning Extreme Programming, Addison-
Procurement management is not addressed at all. Wesley, 200.
[18] H. Takeuchi and I. Nonaka, The New New Product Development Game,
Harvard Business Review, January-February 1986.
This implies that connecting agile methods with PMBOK [19] J. Coplien, Borland Software Craftsmanship: A New Look at Process,
will benefit the software project management community. The Quality and Productivity, Proceedings of the 5th Annual Borland
International Conference, June 1994, Orlando, Florida.
next step of this work is the detailed mapping between [20] K. Schwaber, Controlled Chaos: Living on the Edge, American
PMBOK processes and the agile methodologies. Programmer, April 1996.
[21] K. Schwaber, Agile Project Management with Scrum, Microsoft Press,
2004.
REFERENCES [22] L. Rising, and N.S. Janoff, The Scrum Software Development Process
for Small Teams, IEEE Software, July-August 2000.
[1] F. Brooks Jr., The mythical man-month: essays on software engineering [23] K. Schwaber, Advanced Development Methods. SCRUM Development.
Anniversary ed., Addison Wesley Longman, 1995. Available at http://jeffsutherland.com/oopsla/schwapub.pdf
[2] R. Charette, Why software fails, IEEE Spectrum, September 2005.
[3] J.S. Reel, Critical success factors in software projects, IEEE Software,
16(3), 19-23.

View publication stats