Page 1
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
1/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
1 Software Extension to the PMBOK® Guide – Fifth Edition
2 Public Exposure Draft Review – December 2012 to January 2013
3 Preface
4 A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition is the
5 recognized standard for the project management profession. The knowledge contained in the
6 PMBOK® Guide has evolved from the recognized good practices of the project management
7 practitioners who contributed to the development of the standard. In a similar manner, the
8 knowledge contained in this extension to the PMBOK® Guide represents good practices of the
9 software project management of the software project management practitioners who
10 contributed to the development of this extension; they include the standards committee,
11 the subject matter expert reviewers, and the public reviewers all of whom provided
12 insightful comments. On the other hand, it must be recognized that good practices in
13 managing software projects, as in managing other kinds of projects, must be tailored and
14 adapted to fit the needs of each project.15
16 It is widely acknowledged that the software medium has distinct characteristics, as
17 compared to physical artifacts, and that those characteristics exert strong influence on
18 the processes, methods, tools, and techniques used to manage software projects. This
19 document, the Software Extension to the PMBOK® Guide – Fifth Edition thus describes the
20 situations in which the various tools and techniques documented in the PMBOK® Guide are
21 applicable for managing software projects and provides alternative approaches that are
22 important for efficiently and effectively managing the various aspects of software
23 projects.24
25 This software extension is a companion document to the PMBOK® Guide – Fifth Edition. It is
26 written in the style of, and follows the structure of the PMBOK® Guide. For consistency
27 and ease of reference, the paragraph numbering is largely the same as in the PMBOK® Guide
28 – Fifth Edition. Software project managers and other interested professionals should use
29 the two documents concurrently.30
31 This software extension is based on commonly accepted practices for managing software
32 projects and on the relevant ISO/IEC and IEEE standards. These standards are cited, as
33 appropriate, throughout this extension.34
35 {ED NOTE: A complete list of references will be compiled prior to publication of this
36 standard. Professionally drawn graphics will be incorporated at the time of publication.}
37 1 INTRODUCTION
38 This Software Extension to the PMBOK® Guide – Fifth Edition describes the generally
39 accepted practices for managing software projects that are not common to all kinds of
40 projects; it addresses those practices applicable for managing projects to develop new
41 software and modify existing software. The objective of this software extension is to
42 expand and elaborate on the general project management concepts, tools and techniques, and
43 vocabulary found in A Guide to the Project Management Body of Knowledge (PMBOK® Guide) –
44 Fifth Edition [1],1 and to provide more specific and precise terms, concepts, and methods
45 for managing software projects.46
47 Many project managers, including those certified by PMI, can improve their ability to
48 manage projects that involve development or modification of software by increasing their
49 understanding of the processes, methods, tools, and techniques used to manage and
Page 2
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
2/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
50 successfully complete software projects as covered in this extension to the PMBOK® Guide.
51 Conversely, software project managers can improve their ability to manage software
52 projects by understanding the good practices that are documented in the PMBOK® Guide.53
54 Software project managers and their project teams develop and modify software applications
55 and the software elements of software-intensive systems. Applications programs are based
56 on standardized hardware platforms, operating systems, and communication protocols as well
57 as infrastructure software, such as operating system components, communication protocols,
58 hardware drivers, and software development tools.59
60 A software-intensive system is a collection of hardware, software, and, in some cases,
61 operational personnel, in which software is the primary component that integrates and
62 coordinates the operation of the system and provides a set of capabilities to a community
63 of users. Applications programs and software-intensive systems support all aspects of
64 modern society, ranging from information technology support for organizations, to network
65 protocols for communications networks, to operating systems, to embedded software devices
66 in home appliances, automobiles, mobile phones, spacecraft, consumer products, and
67 aviation; as well as software for fields such as defense, medicine, transportation,
68 simulation and training, banking and insurance, and recreational games.69
70 Managers of applications and software-intensive projects face increasing challenges as
71 software projects grow ever larger and more complex, with increasing interplay between
72 hardware development, firmware development, software development, and the considerations
73 related to the ergonomics of human elements within these systems.74
75 1.1 Purpose of the Software Extension to the PMBOK® Guide
76 The primary purpose of the PMBOK® Guide is to identify and document that subset of the
77 Project Management Body of Knowledge generally recognized as good practice. The purpose of
78 this Software Extension to the PMBOK® Guide – Fifth Edition is to supplement the good
79 practices in the PMBOK® Guide with knowledge and practices that can improve the efficiency
80 and effectiveness of software project managers, their management teams, and their project
81 members.82
83 As stated in Section 1.1 of the PMBOK® Guide “good practice” does not mean the knowledge
84 described should always be applied uniformly to all projects; the organization and/or
85 project management team is responsible for determining what is appropriate for any given
86 project. A similar statement applies to this software extension.87
88 While this extension focuses on management of software projects, it will also be useful to
89 IT organizations in many ways. First, IT organizations need to manage solution development
90 projects. These projects may require in-house development of applications software and
91 software-intensive systems; this extension applies directly to those projects. Second, IT
92 organizations may outsource software development to external organizations. In these
93 cases, this extension provides helpful information to those responsible for monitoring the
94 external effort. The information can be used to review a third-party’s project plans,
95 analyze their progress reports and understand issues that may arise during the course of
96 the contract. Third, most, if not all, of the organizational and team considerations
97 explained in this document apply equally to IT technology development.98
99 The PMBOK® Guide also provides and promotes a common vocabulary within the project
100 management profession for discussing, writing, and applying project management concepts.
101 Like all professional disciplines, software technology has a specialized vocabulary.
102 ISO/IEC/IEEE Standard 24765 (SEVOCAB) [2] provides terminology for software and systems
103 engineering. This SWX extension also provides and promotes a common vocabulary for
104 discussing, writing, and applying software project management concepts. In cases of
105 conflicting terminology for project management, the Glossary in the PMBOK® Guide and the
106 PMI Lexicon [3] shall prevail. Departures from the PMBOK® Guide Glossary and SEVOCAB are
107 documented in the glossary to this software extension.
Page 3
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
3/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
108
109 The PMBOK® Guide also references and explains the purpose of the Project Management
110 Institute Code of Ethics and Professional Conduct [4] (see www.PMI.org). For additional
111 information on software engineering ethics, consult the IEEE Code of Ethics. In addition,
112 the Software Engineering Code of Ethics and Professional Practice [5] was developed as the
113 resource for teaching and practicing software engineering. Also, the Association of
114 Information Technology Professionals (AITP) has developed a code of ethics [6]. See also
115 the American Society for Information Science and Technology (AIS&T) Guidelines [7].116
117 1.1.1 Audience for the Software Extension to the PMBOK® Guide
118 The audience for this software extension includes, but is not limited to:119
120 • 0Managers of traditional projects;
121 • 0Software project managers;
122 • 0Software team leaders;
123 • 0Software systems engineers;
124 • 0Software developers;
125 • 0Software V&V personnel;
126 • 0Software project support personnel;
127 • 0Software infrastructure professionals;
128 • 0Business analysts, business continuity planners, quality engineers, and those in
129 related disciplines;
130 • 0IT CIOs, strategists, project managers, analysts, architects, solution providers,
131 and service personnel;
132 • 0Program managers;
133 • 0Product managers;
134 • 0Customers;
135 • 0Acquirers; and
136 • 0Other stakeholders who affect, or are affected by, a software project.137
138 1.2 What is a Software Project?
139 According to Section 1.2 of the PMBOK® Guide, a project is a temporary endeavor undertaken
140 to create a unique product, service, or result. Attributes of projects, including software
141 projects, are described in Section 1.2 of the PMBOK® Guide. In addition to creating new
142 products, software projects are often undertaken to modify an existing software product,
143 to integrate a set of existing software components, or to modify the software
144 infrastructure of an organization. Software projects may also be undertaken to satisfy
145 service requests, maintenance needs, and to provide operations support; however these
146 activities may occur as low-level continuous activities; they are considered projects only
147 when they are specified as: temporary endeavors that occur within predetermined timeframes
148 to provide deliverables and outcomes.149
150 1.2.1 The Relationships Among Software Portfolios, Programs, and Projects
151 Section 1.2.1 of the PMBOK® Guide describes the relationships that exist among portfolios,
152 programs, and projects; see also Figure 1-1 of the PMBOK® Guide. Specifics that apply to
153 management of software portfolios, programs, and projects are illustrated in Figure 1-1
154 and discussed in Section 1.4 of this software extension.155
156 1.2.2 Why Are Software Projects Challenging?
157 Every discipline has unique aspects that differentiate it from other disciplines. Within
158 those disciplines, the general principles of project management are adapted to account for
159 the special aspects of the projects in those disciplines. Software projects are
160 challenging for the following reasons:
Page 4
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
4/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
161
162 • 0Software has no physical properties.
163 • 0Productivity of software developers is widely variable.
164 • 0Estimation for software projects is particularly difficult and imprecise.
165 • 0Risk management for software projects is predominantly process-oriented.
166 • 0Software is always part of a larger system. Software cannot function alone; it is
167 executed on hardware and is often part of a larger system of diverse hardware and
168 different users and support personnel.
169 • 0Software is often the most easily changed element in systems that incorporate software.170
171 While not unique to software projects, it is certainly true that software is the product
172 of closely coordinated intellectual teamwork, to a greater degree than occurs in many
173 other kinds of projects. It is also true that planning of software projects is usually
174 characterized by a high degree of uncertainty, which results from a lack of
175 information—some people characterize software development as a learning process in which
176 information of various kinds is gained during the project.177
178 The primary reason why management of software projects is challenging is because software,
179 unlike other artifacts of engineering and technology, has no physical properties that are
180 observable by humans. Computer programs are textual representations of control signals and
181 data flows within digital devices; the written programs are representations of and not the
182 actual software.183
184 Although software has no physical properties, it is a direct product of the thought
185 processes of individuals engaged in intellect-intensive, innovative teamwork. While it is
186 true that all engineers engage in intellect-intensive teamwork, the fact that software is
187 developed and modified without the intervening constraints of physical media or
188 manufacturing processes makes software teamwork different from teamwork in other
189 engineering disciplines. As a result, many of the procedures and techniques used in
190 software project management are designed to facilitate communication and coordination
191 among team members engaged in closely coordinated, intellect-intensive teamwork.
192
193 Lack of physical properties has both positive and negative connotations for managing
194 software projects. On the positive side, the intangibility of software makes it possible
195 to rapidly respond to changing user needs and other environmental factors in comparison to
196 changing computer hardware or other physical artifacts. On the negative side, changes need
197 to be carefully managed; otherwise customer expectations and other stakeholder
198 considerations overwhelm the schedule and budget constraints. “Software requirements
199 always change” is a well-known maxim of software projects. Requirements also change for
200 other kinds of projects but, as noted previously, software is usually easier to change
201 than is changing the physical elements of a system undergoing development or modification;
202 this results in frequent stakeholders’ requests for changes to software requirements.
203 Modern life cycle processes for software projects are designed to gracefully cope with
204 this issue.205
206 It should be noted that stakeholder requests are not the only reason software requirements
207 change; changes in technology, software infrastructure, business priorities, resources,
208 and policies and regulations may necessitate changes to the software requirements.209
210 Due to the relative ease of changing software, corrective actions that should be taken to
211 maintain a balance among requirements (including both feature and quality and
212 requirements), because schedule, budget, resources, and technology are sometimes lacking
213 in software projects. This results in the perception that software projects are always
214 behind schedule and over budget. The resulting pressure on the schedule leads to the
215 delivery of software that has poor quality and fewer features than specified. Project
216 management techniques for controlling software requirements are essential, as is
217 performing impact analysis to determine and account for the effect of requirements changes
218 on schedule, budget, resources, and technology. Changes made without careful analysis may
219 cause unforeseeable consequences because of the interwoven aspects of software logic.220
221
Page 5
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
5/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
The interwoven logic of software, combined with the enormous number of computational
222 states in even a small computer program makes exhaustive testing of software impossible
223 for other than trivial programs. It is thus necessary for a software project manager to
224 manage quality assurance, quality control, as well as work product verification and
225 validation throughout the software development life cycle. As with other engineering
226 artifacts, it is particularly important to build quality into software products rather
227 than attempting to test it in after the fact.228
229 Also, the lack of physical properties in software creates challenges in observing the
230 current state of the product, which in turn complicates tracking of a software project.
231 Traditional approaches, such as work breakdown structures, schedule networks, and earned
232 value reporting, are tailored to fit the needs of software projects and are augmented with
233 techniques, such as iterative development and frequent demonstrations of partially
234 completed software.235
236 Accurate estimation of cost and schedule is difficult for all kinds of projects, but it is
237 particularly difficult for software projects because: (1) software is developed and
238 modified by the intellectual work activities of the developers, (2) productivity among
239 individual software developers varies widely (in both quantity and quality of work), (3)
240 the requirements on which estimates are based are often poorly defined, and (4) continuing
241 evolution of technology may make historical data inaccurate for new projects. For these
242 reasons, modern software development life cycle methods tend to focus on developing an
243 expanding set of product increments so that tradeoffs among schedule, budget,
244 functionality, and quality can be continually adjusted. Controlling “scope creep” is
245 another reason for developing and demonstrating product increments as a project evolves.246
247 Yet another factor that creates difficulty for software projects is the degree of
248 uncertainty in software projects. Every software project is a unique endeavor because
249 replication (i.e., copying) of existing software is a trivial process—unlike replication
250 of the physical artifacts of manufacturing and construction projects. Every software
251 project is an undertaking that produces a unique product. It is said that the goal of
252 manufacturing is to repeatedly produce artifacts that are as nearly identical as possible,
253 given the constraints of material science and practicalities such as manufacturing
254 technology and market acceptability; whereas the goal of a software project is to produce
255 one perfect copy of a software product, within the constraints of schedule, budget,
256 resources, and software technology. Management of risk and uncertainty in creating a new
257 and different software product creates difficult challenges for software project managers.258
259 The development of new software, or the modification of existing software may incorporate
260 (or reuse) existing software components, but these components will likely be modified and
261 configured in a different way to produce new or modified capabilities for users of the
262 software. (“Users” of software to be developed or modified may include hardware, humans,
263 and/or other software.) When existing components are reused, additional software is
264 typically written to integrate and combine the features and quality attributes of those
265 components; this may require significant effort because the reuse of existing software is
266 typically not free.267
268 Software projects are also difficult because software is always part of a larger system.
269 Software as a stand-alone entity is useless; to be of use, software is executed on a
270 digital hardware device. In some cases, a software project is one element of a development
271 program that involves accompanying development of hardware components, development of
272 related software by other projects, and development of variants of the user interface
273 software for diverse classes of users.274
275 In other cases, development of a software-intensive system may be limited to developing
276 new software for a pre-specified computer, operating system, and programming language, so
277 that the resulting system will provide capabilities for a population of users. In all
278 cases, a software project manager is required to be aware of, and account for, the context
279 and constraints of the larger system in which the software will be developed, deployed,
Page 6
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
6/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
280 and used.281
282 1.3 What is Software Project Management?
283 According to Section 1.3 of the PMBOK® Guide, project management is the application of
284 knowledge, skills, tools, and techniques for project activities to meet the project
285 requirements. Project management is accomplished through the appropriate application and
286 integration of the 47 logically grouped project management processes comprising five
287 Process Groups. These five Process Groups are:
288 • 0Initiating,
289 • 0Planning,
290 • 0Executing,
291 • 0Monitoring and Controlling, and
292 • 0Closing.293
294 The unique nature of software, as described in Section 1.2.1, allows the elements of the
295 47 processes within the 5 process groups to be beneficially overlapped, interleaved, and
296 iterated in various ways, which results in modifications of and extension to the methods,
297 tools, and techniques in the PMBOK® Guide that are used to manage software projects.298
299 According to Section 1.3 of the PMBOK® Guide, project management involves balancing
300 competing constraints, which include but are not limited to:301
302 • 0Scope,
303 • 0Quality,
304 • 0Schedule,
305 • 0Budget,
306 • 0Resources, and
307 • 0Risk.308
309 Technological factors that can place constraints on software projects include:310
311 • 0State of the art in hardware and software technology,
312 • 0Hardware platforms, operating systems, and communication protocols.
313 • 0Reuse of software components from a library,
314 • 0Use of open source (freely obtained) software components,
315 • 0Use of customer-supplied software components,
316 • 0Interfaces to existing software, and
317 • 0Hardware interfaces.318
319 Other factors that can place constraints on software projects include but are not limited
320 to requirements for system safety, security, reliability, availability, and information
321 assurance, and creation of and reuse of intellectual property.322
323 1.4 Relationship with Program and Portfolio Management
324 1.4.1 Software Portfolio Management
325 As stated in the PMBOK® Guide, a portfolio refers to a collection of
326 projects or programs and other work that are grouped together to facilitate effective
327 management of that work to meet strategic business objectives.
328
329 Organizations for which the primary mission is the development and modification of
330 software typically treat software projects as elements of a portfolio in order to increase
331 efficiency and effectiveness of their work activities and to engage in process improvement
332 initiatives that will be of benefit to all projects within the organization’s portfolio.
333 Within a portfolio, software projects are prioritized for execution based on parameters
334 such as: complexity, degree of uncertainty, business value, returns on investment, and so
Page 7
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
7/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
335 forth. Standardized life cycle frameworks that can be tailored for each project are
336 important elements of portfolio management for software organizations. The relationship
337 among portfolios, programs, and projects are illustrated in Figure 1-1.338
339
340
341 Figure 1-1. Relationships Among Portfolios, Programs, and Projects342
343 Not all software organizations undertake programs and not all organizations manage
344 software projects on a portfolio basis. In these cases, each software project exists as an
345 independent entity.346
347 Software product lines are a related concept. A product line consists of a base component
348 that supports additions and extensions that result in specific products within the product
349 line. For example, a product line might consist of a base component for financial
350 accounting to which different user interfaces are added to accommodate different languages
351 and cultures.352
353 While software has a strong impact on organizations and their missions (both
354 infrastructure software and applications software), there are different ways in which
355 software can generate value, for example, financial value, social value, public welfare,
356 and impact on work places and recreational environments. Therefore, establishing
357 prioritization criteria for programs and projects within a portfolio may be a difficult
358 balancing act among different value criteria.359
360 1.4.2 Software Program Management
Page 8
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
8/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
361 In some programs, software is regarded as a secondary system component; as a result, there
362 may be no explicitly identified software project or designated software project manager.
363 Given the central role of software in modern systems and the impact software has on system
364 characteristics, as well as software being a primary component that can impact completion
365 of a system on a predetermined schedule, it is essential that a designated software
366 project manager be a member of the program management team when software is an element of
367 a system development program.368
369 1.4.3 Software Projects and Strategic Planning
370 In addition to the strategic considerations for authorizing projects, as mentioned in the
371 PMBOK® Guide, software projects are sometimes undertaken to explore the feasibility of
372 using a new development process within a specific context (such as an adaptive project
373life cycle model), to explore a new technology (such as cloud computing), to develop a
374 prototype of a new style of user interface (such as a holographic or 3-dimensional
375 display), or to exploit a software-provided innovation within itself (such as a tablet).
376 In these cases, the business value of the software project is not the output product but
377 the institutional learning that results from the project.378
379 1.4.4 Software Project Management Office
380 In addition to the functions and objectives cited in the PMBOK® Guide, a project
381 management office (PMO) for a collection of software projects may also:382
383 • 0Provide a common repository for data relating to effort, cost, schedule, defects,
384 and risk factors collected from software projects within an organization (i.e., within a
385 portfolio);
386 • 0Use the data repository to develop one or more cost models;
387 • 0Use the data repository to analyze strengths and weaknesses among software
388 projects as a basis for process improvement initiatives and for analyzing the results of
389 process improvement activities;
390 • 0Assist project managers in making cost estimates and preparing project plans;
391 • 0Provide standard templates and forms;
392 • 0Acquire new software development tools and platforms for use throughout an organization;
393 • 0Maintain a library of reusable code modules; and
394 • 0Provide training for project managers and project teams.395
396 In some organizations, the software PMO may also be involved in project management process
397 compliance audits, project management maturity assessment, and process improvement
398 initiatives. Project management offices, like software projects, may be subject to
399 organizational constraints.
400
401 1.5 Relationship with Operations Mgmt and Organizational Strategy
402 As stated in the PMBOK® Guide, operations are an organizational function performing the
403 ongoing execution of activities that produce the same product or provide a repetitive
404 service. Operations evolve to support the day-to-day business, and are necessary to
405 achieve strategic and tactical goals of the business. An example of operations is software
406 production support and maintenance.407
408 In contrast to production support in manufacturing, software production support may
409 include supporting processes for elements such as software component integration, software
410 configuration management, software quality assurance, software execution, and software
411 system testing. Some or all of these supporting processes may be under the control of the
412 software project manager, however, separate organizational units may provide a few or
413 perhaps all of them.
Page 9
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
9/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
414
415 1.5.1 Operational Issues and Software Project Management
416 Software project managers are sometimes responsible for sustaining the operation of one or
417 more software systems while simultaneously developing a new system or a new version of an
418 existing system. Operations personnel may report defects to be fixed in an existing system
419 or request enhancements to an existing system. Updates in vendor-supplied software may
420 have to be installed. Fixing defects, providing enhancements, and installing updates may
421 divert resources from the project at hand and thus disrupt schedules and budgets.422
423 1.5.1.1 Operations Management
424 As stated in the PMBOK® Guide, operations management is a subject area that is outside the
425 scope of formal project management as described in the PMBOK® Guide.426
427 1.5.1.2 Operational Stakeholders in Software Project Management
428 The PMBOK® Guide distinguishes between operational personnel and product users. While
429 operations management is different from project management (see Section 1.5.1.1 of the
430 PMBOK® Guide), the needs of the stakeholders who perform and conduct business operations
431 are important considerations in managing software projects. The software supported by and
432 used by operational personnel exerts a strong influence on the efficiency and
433 effectiveness of their work processes and procedures; therefore the inputs of operational
434 stakeholders are important sources of requirements that software projects strive to
435 satisfy. It is important to address requirements that will improve the efficiency of
436 sustainment; software projects should also consider issues related to deployment,
437 sustainment, replacement, retirement, and disposal of the software product.438
439 1.5.2 Organizational Issues and Software Project Management
440 As stated in the PMBOK® Guide, governance usually sets high-level strategic direction and
441 performance parameters. The strategy provides the purpose, expectations, goals, and
442 actions necessary to guide business pursuit, and is aligned with business objectives.443
444 ISO/IEC/IEEE Standards 15528 [8] and 12207 [9], as well as the Capability Maturity Model
445 Integrated for Development (CMMI-DEV) [10] and the Capability Maturity Model Integrated
446for Services (CMMI-SVC) [11] are used by many software organizations as frameworks for
447 specifying strategic directions and performance parameters. They also serve as models for
448 process and product improvement initiatives.449
450 1.5.2.1 Software Project-Based Organizations
451 Many software organizations are project-based. As stated in the PMBOK® Guide,
452 project-based organizations weaken the hierarchy and bureaucracy inside the organizations
453 as the success of the work is measured by the final result rather than position or
454 politics. A project-based organization is particularly desirable for software projects,
455 which are often comprised of self-enabling teams of creative individuals.456
457 1.5.2.2 Link Between Software Project Management and Organizational Governance
458 As stated in the PMBOK® Guide, projects (and programs) are undertaken to achieve strategic
459 business outcomes, for which many organizations now adopt formal organizational governance
460 processes and procedures.461
Page 10
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
10/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
462 In addition to internally imposed governance policies, many software projects are
463 conducted for external customers who may require that certain processes and procedures be
464 followed when developing software that may place at risk the health, safety, or welfare of
465 the public. There may also be compliance requirements, such as Sarbanes-Oxley in the
466 United States or the policies governing development of medical devices that contain
467 software. The type of contract with an external customer may also affect the way in which
468 a software project is governed.469
470 1.5.2.3 The Relationship Between Software Project Management and Organizational Strategy
471 The statements in this section of the PMBOK® Guide apply equally to software projects,
472 which should support the strategies and goals of the organization. Software organizations
473 sometimes undertake contracted projects that are not aligned with the mission and goals of
474 the organization in order to provide jobs and income. Although these projects can provide
475 job security and, in some cases, allow survival of the organization, they often
476 unnecessarily divert organizational assets in cases where survival is not at stake. On the
477 positive side, a software project may be undertaken to support an organizational strategy
478 of, for example, developing an inventory application to accommodate a new product line
479 that supports the business goal of growing the revenue stream for that product line.480
481 1.6 Software Business Value
482 According to this section of PMBOK® Guide, business value is defined as the entire value
483 of the business; the total sum of all tangible and intangible elements. A software product
484 may be a proprietary product of the business and provide a major revenue stream for that
485 business or business unit. In some cases, infrastructure and customer support software may
486 be capitalized and depreciated over time.487
488 Because software is the product of closely coordinated teamwork that is often innovative,
489 the intellectual capital of a software organization (the software developers, maintainers,
490 and other software personnel) is a particularly important element of business value.
491 Another important element of business value for software organizations is the set of
492 processes and procedures that enable software project management and product development
493 in an efficient and effective manner by enhancing communication and coordination among
494 individuals, teams, projects, programs, customers, and other external stakeholders.495
496 1.7 The Role of a Software Project Manager
497 As stated in the PMBOK® Guide, the role of a project manager is distinct from that of a
498 functional manager or an operations manager. However, software project work may be
499 internally organized functionally by product component (i.e., user interface, database,
500 computation, and communication software) or functionally by process component (i.e.,
501 analysis, design, construction, testing, and installation/training processes). The project
502 team may be organized in a functional manner and the software project manager may, as a
503 result, be the manager of the project’s functional units during planning and execution of
504 that project.505
506 In addition to the characteristics of project managers listed in the PMBOK® Guide
507 (knowledge, performance, and personal), software project managers provide leadership in:508
509 • 0Planning and estimating: both initially and on an ongoing basis as conditions change;
510 • 0Monitoring and controlling of schedule milestones, budget expenditures,
511 requirements stability, staff performance, resource utilization, and identified risk
512 factors, using a systematic version control process;
513 • 0Leading and directing: by defining the project vision and maintaining it as
514 requirements and other constraints change and by providing hands on, day-to-day leadership
515 of team leaders, software developers, and supporting personnel who are engaged in
Page 11
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
11/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
516 innovative teamwork;
517 • 0Managing risk by identifying, analyzing, prioritizing, and responding to risk
518 factors on an ongoing, continuous manner; and
519 • 0Coaching, monitoring, inspiring, and working with the software engineering
520 knowledge workers to obtain desired results. [19]521
522 On a small project (i.e., less than 10 people), the software project manager may also be
523 the team leader, the software designer, and assume other contributing roles.524
525 1.7.1 Interpersonal Skills of a Software Project Manager
526 Because of the intangible nature of software and the intellectual effort required to
527 produce software, an important factor for project success is the communication and
528 coordination mechanisms instituted and reinforced by the project manager, as conveyed by
529 the interpersonal skills of the project manager. The project manager must ensure that
530 effective communication and coordination occurs within the project team and with entities
531 external to the project.532
533 Interpersonal skills that are particularly important for software project managers
534 include:535
536 • 0Leadership,
537 • 0Team building,
538 • 0Motivation,
539 • 0Communication,
540 • 0Influencing,
541 • 0Decision making,
542 • 0Political and cultural awareness, and
543 • 0Negotiation.544
545 1.8 This Software Extension
546 As stated in Section 1.8 of the PMBOK® Guide, project management standards do not address
547 all details of every topic. This standard is limited to single projects and the project
548 management processes that are generally recognized as good practice. Other standards may
549 be consulted for additional information on the broader context in which projects are
550 accomplished.”551
552 This Software Extension to the PMBOK® Guide – Fifth Edition is similarly limited to
553 management of single software projects and the software project management processes that
554 are generally recognized as good practice. Good practices outlined in this extension are
555 generally applicable to most software projects, most of the time. In addition, this
556 extension provides information about IEEE Computer Society standards for software and
557 systems development that reflects standard practice in the software industry. These
558 standards are cited throughout this software extension.559
560 The following observations summarize some of the key points made previously and provide
561 pointers to the following sections of this software extension.562
563 • 0Because software is not subject to physical constraints, there are many
564 possibilities for software project life cycles and many different approaches to applying
565 the techniques of software project management to those life cycles. Section 2.4.2 of this
566 software extension describes the continuum of software project life cycles that vary from
567 predictive to iterative to highly adaptive. “Most software projects, most of the time,”
568 uses some variation within the continuum of iterative cycles for developing software
569 between iterative-incremental and highly adaptive; software project managers adapt the
570 methods and techniques of project management to those project life cycles.
571 • 0Software project managers should have a basic understanding of software
572 engineering development processes and various approaches to managing software projects
Page 12
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
12/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
573 within the continuum of software project life cycles.
574 • 0Software project managers may have technical backgrounds, but not always in
575 software. Those with strong technical backgrounds may need to focus on developing their
576 business, project management and interpersonal skills. Conversely, some software project
577 managers may not have strong software skills and may need to work closely with a technical
578 leader on each of their software projects.
579 • 0Two especially important aspects for software project managers are interpersonal
580 skills and an understanding of software quality attributes. Section 1.7.1 lists
581 interpersonal skills that are particularly important for software project managers.582
583 Management of software quality is particularly important because the safety, security, and
584 welfare of the general public are increasingly dependent on software. The deliverable work
585 products of software projects may include artifacts such as requirements; design
586 description; source code; object code; test results; test suites; configuration library;
587 the complete tool chain, including the version control tool used during software
588 development, installation, and delivery; maintenance instructions; and operator and user
589 instructions and training manuals and materials. Each of the deliverable work products
590 should have acceptable quality, as determined by the needs of the users and other
591 stakeholders. As mentioned previously, management of quality assurance, quality control,
592 verification, and validations are especially important aspects of managing software
593 projects.594
595 Software quality attributes that are important to users and other stakeholders include,
596 but are not limited to attributes such as:597
598 • 0Safety,
599 • 0Security,
600 • 0Reliability,
601 • 0Performance,
602 • 0Ease of learning,
603 • 0Ease of using,
604 • 0Interpretation of error messages
605 • 0Availability,
606 • 0Accessibility,
607 • 0Efficiency,
608 • 0Flexibility,
609 • 0Interoperability, and
610 • 0Robustness.611
612 Software quality attributes that are important to software developers include, but are not
613 limited to:614
615 • 0Testability,
616 • 0Maintainability,
617 • 0Portability,
618 • 0Extensibility, and
619 • 0Reusability.620
621 While these quality attributes are not unique to software, it is important that a software
622 project manager understand the priorities among necessary and desired quality attributes
623 of the software work products and the influence that quality attributes exert on the
624 methods, tools, and techniques used to manage and conduct software projects. These topics
625 are addressed in Section 8 of this software extension.626
627 2 Software Project Life Cycle and Organization
628 This section of the Software Extension to the PMBOK® Guide – Fifth Edition describes
629 software project life cycles; how software projects interact with ongoing operational work
Page 13
630 and other elements of the organization; the influence of stakeholders beyond the software
631 development team; and how organizational structure affects the way a project is initiated,
632 planned, executed, monitored and controlled, and closed. Emphasis is placed on tools and
633 techniques that have been developed to accommodate the special and unique aspects of
634 software projects and management of software projects.635
636 2.1 Organizational Influences on Software Project Management
637 As stated in Section 2.1 of the PMBOK® Guide, the organizational culture, style, and
638 structure influence how projects are performed. Organizational culture and style have a
639strong influence on how software projects are performed because software engineers are
640 knowledge workers who develop software by engaging in closely coordinated teamwork.641
642 2.1.1 Organizational Cultures and Styles for Software Projects
643 There are two extremes of organizational culture and style for software projects, with
644 many variations in between. Organizations that engage in large, complex software projects
645 tend to have more rigorously controlled processes and procedures than do organizations
646 engaged in smaller, simpler efforts. In the former case, a software organization may have
647 separate functional units to accomplish requirements analysis and architectural design,
648 software construction, and verification and validation; with iterations within and among
649 these activities, as necessary. Techniques such as work breakdown structures and earned
650 value reporting are typically utilized on large software projects.651
652 At the other extreme, the organizational culture and style may minimize formality in
653 documenting requirements and design and focus on iterative development cycles in which the
654 requirements and design emerge through frequent demonstrations of increasing software
655 capabilities for continually engaged customers and users who provide feedback and
656 direction.657
658 Many variations within this continuum of software project life cycles are found within
659 software development organizations. Also, there are other dimensions that may influence
660 the organizational culture and style. For example, an organization that develops software
661 for medical devices might not place undue emphasis on project planning but, because of
662 government regulations, may have rigorous documentation requirements.663
664 In addition, because of the unique nature of software projects (intangible product and
665 intellect-intensive teamwork), the organizational factors that influence the morale and
666 motivation of software workers are somewhat different than for others who work in
667 organizations.668
669 Organizational factors that tend to increase motivation, engagement, and productivity of
670 software personnel include issues such as:671
672 • 0Workplace free of disruptions and external interruptions
673 • 0Challenging technical problems,
674 • 0Autonomy to solve problems,
675 • 0Ability to control one’s work schedule,
676 • 0Learning new things,
677 • 0Competent technical leaders,
678 • 0Compelling vision or end-state, and
679 • 0Adequate software tools and computing technology.680
681 Software development—whether in adaptive projects or predictive projects—tends to be a
682 learning experience. Organizational factors that tend to increase learning among project
683 team members and therefore increase product quality and project performance include:684
685 • 0Collaborative culture,
686 • 0Easy access to cross-functional team members,
Page 14
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
14/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
687 • 0Opportunities to discuss issues in a timely fashion,
688 • 0Access to needed information,
689 • 0Colocation or electronic connectivity that results in easy communication among
690 the team members, and
691 • 0High level of trust among the team members and between the project team and the
692 project manager, other managers, and the customer (whether internal or external to the
693 organization) allowing for open discussion of challenges and options to increase the
694 probability of project success.695
696 Conversely, the absence of these factors can result in decreased motivation and morale, at
697 both the individual and team levels. These factors are especially important for software
698 workers.699
700 2.1.2 Organizational Communications
701 Software organizations, like other modern organizations, utilize the communication
702 mechanism noted in Section 2.1.2 of the PMBOK® Guide. In particular, the nature of
703 software (no physical properties) and the growth of the Internet and Web infrastructure,
704 as noted in the PMBOK® Guide, have made possible the globalization of software
705 development. Software project managers increasingly manage virtual projects.706
707 2.1.3 Organizational Structures for Software Projects
708 From the organizational point of view, organizations that conduct software projects may
709 organize projects as individual entities, project-by-project (projectized organization);
710 by coordination among functional units (functional organization); or as a matrix
711 organization that combines projectized and functional structures.712
713 Internally, the structure of a software project is typically organized into one or more
714 small teams (i.e., ten or fewer members per team) where the number of teams depends on the
715 scope of the project. Small, coordinated teams are used to minimize the problems of
716 communication within teams because the number of communication paths within a team
717 increases exponentially with the number of team members. Several small teams have fewer
718 overall communication paths than one large team (see Section 5). Other functional elements
719 of a software organization may provide supporting services such as configuration
720 management, infrastructure tools and support, and separate verification and validation
721 units.722
723 When organizing a software project, it is important to align the project structure with
724 the desired structure of the software product. As observed by Conway (in a statement that
725 became known as Conway’s Law):726
727 “Any organization that designs a system (defined more broadly here than just information
728 systems) will inevitably produce a design whose structure is a copy of the organization's
729 communication structure.“ [12]730
731 A project that is organized using three software development teams (or a single team of 3
732 members) will develop a software product having three components; if a project of four
733 teams (or a single team of 4 team members) develops the same product it will likely have
734 four components, because software is a product of the closely coordinated intellectual
735 effort of teams and team members who divide among them the features and interfaces to be
736 implemented.737
738 Section 2.1.3 of the PMBOK® Guide provides additional information about organizational
739 structures applicable to software projects.740
741 2.1.4 Organizational Project Assets
742 According to Section 2.1.4 of the PMBOK® Guide, organizational process assets include any
Page 15
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
15/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
743 and all process-related assets that can be used to influence the project’s success, from
744 any or all of the organizations involved in the project. In the PMBOK® Guide
745 organizational project assets are grouped as processes and procedures and the corporate
746 knowledge base. The PMBOK® Guide provides examples of project assets; they are applicable
747 to software projects. Additional considerations for software projects include:748
749 2.1.4.1 Software Processes and Procedures
750 The processes and procedures of many software development and service organizations are
751 based on ISO/IEC and/or IEEE standards for software engineering and on the Capability
752 Maturity Models and the process asset library of the Software Engineering Institute2.753
754 Some ISO/IEC and IEEE standards have been harmonized and issued as joint standards
755 (ISO/IEC/IEEE); they include:756
757 • 0ISO/IEC/IEEE 15288: Systems and software engineering—System life cycle processes
758 • 0ISO/IEC/IEEE 12207: Systems and software engineering—Software project life cycle processes
759 • 0ISO/IEC/IEEE 16326: Systems and software engineering—Life cycle processes—Project
760 management [13]
761 • 0The Capability Maturity Models Integrated (CMMI), developed and maintained by the
762 Software Engineering Institute include:
763 • 0CMMI for Development (CMMI-DEV) [10],
764 • 0CMMI for Services (CMMI-SVC) [11], and
765 • 0CMMI for Acquisition (CMMI-ACQ) [14].766
767 CMMI for Development is a collection of best practices for system and software
768 engineering. CMMI-DEV, V1.3 contains 22 process areas. The process areas are grouped into
769 four categories; one of the categories is project management, which has 7 process areas as
770 follows:771
772 • 0Project Planning,
773 • 0Project Monitoring and Control,
774 • 0Supplier Agreement Management,
775 • 0Integrated Project Management
776 • 0Requirements Management
777 • 0Risk Management, and
778 • 0Quantitative Project Management.779
780 2.1.4.2 Corporate Knowledge Base for Software Development
781 Section 2.1.4.2 of the PMBOK® Guide provides examples of information that is typically
782 contained in a corporate knowledge base. Many software organizations maintain corporate
783 knowledge bases that contain information similar to that in Section 2.1.4.2 of the PMBOK®
784 Guide.785
786 CMMI-DEV includes the process area, Organizational Process Definition, the purpose of
787 which is to establish and maintain a usable set of organizational process assets and work
788 environment standards. Also, generic practice GP3.2 in CMMI-DEV (Collect Improvement
789 Information) states information and artifacts are stored in the organization’s measurement
790 repository and the organization’s process asset library.”791
792 Although many software organizations maintain a corporate knowledge base for software
793 engineering and software project management, it is not a universal practice.794
795 2.1.5 Enterprise Environmental Factors
796 The factors cited in Section of 2.1.5 of the PMBOK® Guide apply equally to software
797 projects. They include, but are not limited to:
Page 16
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
16/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
798
799 • 0Organizational culture, structure, and processes;
800 • 0Government or industry standards;
801 • 0Infrastructure (e.g., facilities and capital equipment);
802 • 0Human resources;
803 • 0Personnel administration;
804 • 0Political climate; and
805 • 0Project management information systems.806
807 2.2 Software Project Stakeholders and Governance
808 2.2.1 Software Project Stakeholders
809 A software project stakeholder is any individual or organizational entity that affects or
810 is affected by a software project or the resulting software product. Stakeholders include
811 both internal and external stakeholders. Internal stakeholders include the project team
812 and other organizational entities such as a marketing or contract administration
813 department. External stakeholders include acquirers, integrators, customers, and users and
814 may include policy makers and regulatory agencies.815
816 Because of software’s abstract nature, software project deliverables are subject to
817 broader and more variable interpretations by project stakeholders than are physical
818 entities. It is important to engage the appropriate stakeholders in issues of relevance to
819 them as often as is appropriate in order to gauge expectations on the project deliverables
820 and project governance. This topic is explored in depth in Section 13 of this software
821 extension (Stakeholder Management). Stakeholder management is a project deliverable.822
823 2.2.2 Software Project Governance
824 According to the PMBOK® Guide, project governance is the alignment of project objectives
825 with the strategy of the larger organization by the project sponsor and project team.”
826 Governance is concerned with issues such as decision making, prioritization, and alignment
827 of vision and strategy with an organization’s work. Organizational governance for software
828 projects may include elements such as a software project management office (SPMO), a
829 software project portfolio management, or an IT strategy group. The intangible nature of
830 software may result in a high level of formality in the governance model, in an attempt to
831 bring visibility to an inherently invisible product. Software projects typically involve
832 discovery of requirements and constraints within a learning environment as the projects
833 evolve. Formal governance models that treat software development as a linear, predictive
834 process may exert a detrimental impact on the software projects conducted by the
835 organization. While different types of projects call for different levels of rigor and
836 formality of governance, it is important that the governance models are suited to the
837 nonlinear, adaptive learning environment of software development.838
839 2.3 The Project Team
840 2.3.1 Composition of Software Project Teams
841 The composition of a software project team is often a balance between ideal considerations
842 and practical constraints. Ideal considerations for software development teams include:843
844 • 0Dedicated vs. non-dedicated staff members. In the world of knowledge work,
845 switching context between multiple assignments incurs intellectual overhead. Therefore,
846 software projects benefit from dedicated resources. Assigning team members to one project
847 at a time can limit switching of contexts among multiple, part-time tasks and improve the
848 productivity of software teams. However, some projects simply do not have enough work for
Page 17
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
17/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
849 the various specialized skill sets required nor the budget to support dedicated resources
850 for those specialized skills. As a result, many software project managers strike a balance
851 between dedicated and non-dedicated resources.852
853 • 0Collaborative team vs. functional division. In some organizations, dedicated team
854 members work together with all the skills required to deliver tested working software
855 represented within the team rather than allocating functionality to be developed among
856 separate functional units. The latter approach may involve assigning development of user
857 interface components to the user interface group, database components to the database
858 group, etc. In contrast, a collaborative team may include expertise in user interfaces,
859 databases, and other needed specialties. Aligning teams in a collaborative manner
860 increases feedback among team members and reduces feedback time. It also allows learning
861 to occur throughout the course of the project, which is reflected in the work products and
862 interactions among the team members. Some software organizations maintain functional
863 groups in the interest of maximizing utilization of specialty resources. As indicated
864 previously, striking a balance between dedicated and non-dedicated resources, which may be
865 reflected as a collaborative team versus functional divisions is a challenging economic
866 dilemma in software development.867
868 • 0Virtual vs. colocated. The complex and abstract nature of software makes it
869 difficult for software engineers to communicate detailed technical issues in written form.
870 In order to convey abstract ideas and achieve the collaboration needed for innovation,
871 many teams benefit from the high fidelity of face-to-face conversations using white
872 boards. An additional benefit is the tacit knowledge that is gained and used when project
873 team discussions are held in common meeting areas. However, some organizations need to
874 control costs by outsourcing project staff using low-cost providers and limiting travel.
875 As a result, a project manager may choose to strike a balance between face-to-face
876 communication for activities such as project orientation, training, and key meetings
877 (e.g., kickoff and coordination meetings), with day-to-day work performed in a virtual
878 environment.879
880 • 0Specialists vs. generalists. Software projects often require specialized skills
881 that incur high labor costs. As a result, many project managers staff their software
882 projects with project members who have generalist skills and rely on them to perform the
883 majority of the work. Then, periodically an expert will be called upon to mentor the
884 generalists in specialized areas. Another benefit of this approach is that generalists may
885 offer broader perspectives than experts and develop more solution options.886
887 • 0Stable vs. interim. Many organizations create a new project team for each
888 software project and disband the team when the product is delivered. For ongoing
889 maintenance, enhancement, and support of software products, it is beneficial to keep
890 cross-functional teams together over time so that knowledge is retained about the product,
891 team interactions and learning are maintained and improved, and teams maintain high levels
892 of performance. Another benefit of stable teams is that project performance throughout the
893 organization typically becomes more predictable.894
895 In practice, organizations may have to make trade-offs among these considerations. A
896 detailed exploration of software project teams is included in Section 9 on Human Resources
897 Management.
898
899 2.4 The Software Project Life Cycle – Overview
900 According to Section 2.4 of the PMBOK® Guide, project life cycles can be described as
901 falling somewhere in a continuum from predictive or plan-driven approaches at one end to
902 adaptive or change-driven approaches at the other.903
904 Software has no physical properties and lends itself to a wide variety of software project
905 models. These models occupy positions within the predictive to adaptive continuum that
906 span from a linear sequence of project phases in which an individual phase may last for a
Page 18
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
18/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
907 few weeks to a few months (highly predictive), to project models that have daily iterative
908 cycles and include frequent demonstrations of partially completed, working software
909 (highly adaptive). The continuum of software project life cycles is illustrated in Figure
910 2-1.911
912
913 Figure 2-1. The Continuum of Software Project Life Cycles914
915 It must be emphasized that the continuum in Figure 2-1 is not a thin straight line.
916 Software project life cycles are complex and multidimensional and include processes, such
917 as configuration management, process and product quality assurance, independent testing,
918 and other processes as appropriate and needed. In addition, software projects may include
919 interfaces to programs of which they are an element, to other parts of the software
920 development organization, affiliated projects, or to subcontracted groups or projects.921
922 There is a subtle distinction between a software project life cycle (as the term life
923 cycle is used in the PMBOK® Guide), and the life cycle model that is used for a particular
924 software project. The malleability of software permits intermixing of elements from the
925 life cycle continuum. For example, a software project life cycle model may rigorously
926 control requirements (predictive) but use frequent iteration cycles during software
927 construction (adaptive). Each software project has a tailored software project life cycle
928 model based on elements of the project life cycle continuum needed to conduct the project
929 efficiently and effectively.930
931 Another distinction is between software project life cycle model and software product life
932 cycle model. A product life cycle model includes an initial project life cycle model but
933 also includes the processes for deployment, support, maintenance, evolution, replacement,
934 and retirement of a software product. Additionally, enhancement and adaption of the
935 initially delivered software may involve several project life cycles beyond the initial
936 one.937
938 A highly predictive project life cycle model, as partially illustrated in Figure 2-2 (also
939 known as a waterfall life cycle) is characterized by a linear sequencing of development
940 phases and longer phase durations, as compared to an adaptive life cycle. Predictive life
941 cycles may be appropriate for software projects that have well-defined requirements, a
942 familiar problem domain, stable technology, a known customer (either internal or
943 external), and a short duration (i.e., 3 months or less). However, most software projects
944 require adaptive approaches to accommodate changing requirements, a new problem domain,
945 new or updated technology, a new customer, or an extended duration plus the learning that
Page 19
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
19/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
946 typically takes place during the project, In those cases, an adaptive life cycle model is
947 appropriate.948
949 As noted in the PMBOK® Guide, iterative and incremental life cycles are those in which the
950 project scope is generally determined early in the project life cycle. A project life
951 cycle can be either iterative or incremental or iterative-incremental (as illustrated in
952 Figure 2-1). An incremental model might develop software using a sequence of development
953 phases where each phase produces working software and where each phase might be adaptive
954 or predictive. Iterative life cycle models for software projects typically produce working
955 software but it is not unusual for the requirements and design phases of a predictive
956 model to proceed iteratively before moving to the next phase of software development. See
957 Section 2.4.2.3 for a discussion of iterative and incremental software project life cycle
958 models.
959
960 As noted in the PMBOK® Guide, most software project life cycles develop the product both
961 iteratively and incrementally. In Figure 2-1 the iterative-incremental life cycle (It-In)
962 occupies the middle range of the life cycle continuum. An It-In life cycle model for a
963 software project may be more on the predictive side or more on the adaptive side. For
964 example, a life cycle model for a software project could be based on the It-In life cycle
965 and instantiated as a project life cycle model having three iterative cycles with the
966 requirements to be revised at the end of the first two iterations based on demonstrations
967 of working software. In this case, the project life cycle model would lie on the adaptive
968 side of the continuum. On the other hand, adherence to rigorously specified and rigorously
969 controlled requirements would place the It-In project life cycle model on the predictive
970 side of the continuum.971
972 Adaptive life cycles for software projects are depicted in Figure 2-1. According to the
973 PMBOK® Guide adaptive life cycles (also stated as change-driven or agile methods in PMBOK)
974 are intended to facilitate change and require a high degree of ongoing stakeholder
975 involvement. There are several adaptive software project life cycle models that
976 incorporate various elements of agility. See Section 2.4.2.4 for a discussion of adaptive
977life cycle models for software projects.
978
979 Highly adaptive software project life cycles are exploratory and experimental in nature.
980 In exploratory development, a hypothesis concerning a possible solution is postulated and
981 software is constructed to test the hypothesis. The solution is tested in use to gain
982 rapid feedback on the hypothesis. Based on the feedback, the solution may be discarded,
983 further developed in a highly adaptive fashion, or further developed using a different
984 software project life cycle model. A sequence of increments may be constructed while
985 testing the hypothesis; development of increments may all be based on the same life cycle
986 model throughout or different increments may be developed using different software project
987 life cycle models.988
989 Software prototyping is a related concept and often used to present alternative user
990 interface designs to user representatives or to explore a technical option. Software
991 prototypes differ from prototypes of physical products, which are often fully functional
992 units. In contrast, a software prototype is typically a rapidly developed mockup of one or
993 a few software features. Software prototyping is a valuable technique that can be used at
994 any time during software development but software prototypes are not constructed to be
995 deliverable software products and software prototyping is not a software project life
996 cycle model suitable for developing a software product. Software project managers should
997 take care to ensure that prototype software that has not been productized (i.e., well
998 structured, documented, and thoroughly tested) is not incorporated into a software
999 product. Software prototypes are often designated as “throwaway prototypes” to maintain
1000 this distinction.1001
10022.4.1 Characteristics of the Software Project Life Cycle
Page 20
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
20/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
1003The creation of software deliverables typically requires a variety of project life cycle
1004processes. According to ISO/IEC/IEEE Standard 12207 development of software includes the
1005 following processes:1006
1007 • 0Analyze: Software Requirements Analysis Process (refer to Section 7.1.2 of
1008 ISO/IEC/IEEE Standard 12207)
1009 • 0Architect: Software Architectural Design Process (refer to Section 7.1.3 of
1010 ISO/IEC/IEEE Standard 12207)
1011 • 0Design: Software Detailed Design Process (refer to Section 7.1.4 of ISO/IEC/IEEE
1012Standard 12207)
1013 • 0Construct: Software Construction Process (refer to Section 7.1.5 of ISO/IEC/IEEE
1014Standard 12207)
1015 • 0Integrate: Software Integration Process (refer to Section 7.1.6 of ISO/IEC/IEEE
1016Standard 12207)
1017 • 0Test: Software Qualification Testing (refer to Section 7.1.7 of ISO/IEC/IEEE
1018Standard 12207)
1019
1020For purposes of exposition, this extension will refer to these software implementation
1021processes to describe the variations in software project life cycles found in the software
1022 industry.1023
1024Figure 2-9 in the PMBOK® Guide, illustrates typical cost and staffing levels across the
1025project life cycle. The build-up and build-down of cost and staffing level for the
1026 “carrying out the work” and “closing” segments of Figure 2-9 are typical for predictive
1027 software project life cycles but these segments of the figure are typically flat for
1028 adaptive software project life cycles.1029
10302.4.2 Software Project Phases
10312.4.2.1 Phase-to-Phase Relationships
1032According to the PMBOK® Guide, there are two basic types of phase-to-phase relationships:
1033 sequential and overlapped. The volatile nature of software allows for significant
1034 flexibility in overlapping, interleaving, and iterating software development phases.
1035 ISO/IEC/IEEE Standards 15288 and 12207 use the term stages rather than phases to indicate
1036 that these stages are to be used throughout a project whenever they are needed to achieve
1037project objectives. Highly adaptive software project life cycle models, for example,
1038 execute many of the processes during each iterative cycle, as explained in Section
10392.4.2.4.1040
10412.4.2.2 Predictive Software Project Life Cycles
1042The PMBOK® Guide defines predictive life cycles as those for which the project scope, and
1043 the time and cost required to deliver that scope, are determined as early as practically
1044possible in the project life cycle.1045
1046When using a predictive life cycle, each project phase is organized around a specific
1047 activity within the project life cycle. Namely, the first phase is dedicated to defining
1048 the product concept and collecting requirements, which in turn leads to a dedicated phase
1049of defining the requirements to be included in the product. The requirements phase is
1050 followed by a dedicated phase to specify the design of the entire software deliverable.
1051The subsequent phases (construction, integration, testing, etc.) follow in sequence. A
1052highly predictive life cycle does not allow any work activities in subsequent phases until
1053 the current phase is completed.1054
1055Variations on a highly predictive project life cycle allow some work to proceed on one or
1056more well defined subsystems while earlier work continues on other subsystems, or to
Page 21
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
21/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
1057 continue into the next phase while some documented problems are corrected. Figure 2-2
1058 illustrates the sequential phases of the highly predictive life cycle for software
1059projects; the feedback that may occur between the phases is not illustrated.1060
1061The graphic above each project phase is similar to Figure 2-11 of the PMBOK® Guide, which
1062 illustrates the application of the five Process Groups within each project phase
1063 (Initiating, Planning, Executing, Monitoring and Controlling, and Closing).1064
1065
1066
1067 Figure 2-2. Sequential Phases of a Predictive Software Project Life Cycle1068
1069As stated in Section 2.4 of this extension, a predictive software project life cycle may
1070be appropriate for software projects that have well-defined requirements, a familiar
1071problem domain, stable technology, a known customer (either internal or external), and a
1072 short duration (i.e., 3 months or less). Also, a predictive software project life cycle
1073model may be used when specialized resources required for a project phase are only
1074 available for a limited time. It may also be appropriate when trying to achieve short-term
1075 efficiencies in specific software activities. Additionally, this approach may be used on
1076 routine projects, where the requirements, technology, and customer are familiar and when
1077 there is less need to gain new understanding or accommodate ongoing changes.1078
1079However, due to the typically volatile nature of software requirements, many software
1080development organizations and software projects use iterative, incremental, and adaptive
1081 approaches. When working with complex software projects, the need to change some element
1082of a previously completed activity phase occurs frequently because: (1) the requirements
1083 are emergent in nature, (2) new understandings arise around stakeholder expectations
1084 regarding scope, (3) new insights into the technology are discovered, or (4) errors in
1085previous work need to be fixed. As a result, the intended isolation of a specific activity
1086 to a specific project phase becomes increasingly impractical as product size and
1087 complexity increase.1088
10892.4.2.3 Iterative and Incremental Software Project Life Cycles
1090According to Section 2.4.2.3 of the PMBOK® Guide, iterative and incremental life cycles
1091 are ones in which the project scope is generally determined early in the project life
1092 cycle, but time and cost estimates are routinely modified as the project team
1093understanding of the product increases. Iterations develop the product through a series of
1094 repeated cycles, while increments successively add to the functionality of the product.
Page 22
1095Most life cycles develop the product both iteratively and incrementally.1096
1097For software projects, it is not uncommon that some or all of the time, cost, or
1098 requirements are modified as the project team’s understanding of the software product
1099 increases, thus providing a three-way trade-off space. In some cases one or more of the
1100 three may be fixed, which restricts the tradeoff space. Typically, attempting to fix all
1101 three (time, cost, and requirements) without any flexibility results in software project
1102 failure. The information in Section 2.4.2.3 of the PMBOK® Guide concerning iterative and
1103 incremental life cycles is generally applicable to software projects.1104
1105 • 0Iterative project life cycle phases. Iterative software project life cycle phases
1106 systematically repeat one or more of the software development stages, thus iteratively
1107 converging on a product that satisfies the defined scope. The software product is
1108progressively elaborated, and incorporates feedback as new information or understanding
1109 emerges during the project. This approach is often beneficial when complexity is high,
1110when the project incurs frequent changes, or when the scope is subject to various
1111 stakeholders’ views of the final software product. Iterative life cycles may include
1112varying degrees of iteration within the spectrum of software development activities. Some
1113of the iterations may include phases that involve only one development stage, whereas
1114others may involve multiple stages, as shown in Figure 2-3.1115
1116
1117
1118 Figure 2-3. An Iterative Project Life Cycle with a Phase having Multiple Stages1119
1120 • 0Incremental project life cycle phases. Incremental project life cycle phases add
1121new increments of functionality that increase the product scope. This approach provides
1122project managers and stakeholders the opportunity to view intermediate demonstrations of
1123working software as meaningful checkpoints. A strictly incremental life cycle produces the
1124 increments sequentially. The scope of increments may vary, provided new functionality is
Page 23
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
23/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
1125delivered at the end of each incremental phase. The duration of incremental project phases
1126varies widely. Some projects define fewer phases to be completed over a longer time frame,
1127while others define more phases, each having a shorter duration.1128
1129 • 0Iterative-incremental project life cycles. As stated in the Section 2.4.2.3 of
1130 the PMBOK® Guide, most life cycles develop the product both iteratively and incrementally.
1131This is true of software projects that use incremental life cycle models.
1132 Iterative-incremental life cycles occupy a middle position between predictive and adaptive
1133 software project life cycles, as illustrated in Figure 2-1.1134
1135 In addition, the PMBOK® Guide states the project scope is generally determined early in
1136 the project life cycle, but time and cost estimates are routinely modified as the project
1137 team understanding of the product increases. For software projects, requirements may be
1138modified in addition to modifications of time and cost estimates, thus making possible
1139 tradeoffs among requirements, time, and cost. As stated in Section 2.4.2.3, one or more of
1140 these three factors may be highly constrained, thus limiting the tradeoff options.1141
1142An iterative-incremental software project life cycle model is illustrated in Figure 2-4.
1143The prioritized feature set has been partitioned into three iterative-incremental feature
1144 sets to be built, where the prioritization of features is based on predetermined
1145prioritization criteria. Prioritizing of the feature sets was preceded by analysis and
1146design phases.1147
1148
1149
1150 Figure 2-4. Illustrating an Iterative-Incremental Software Project Life Cycle Model1151
1152As illustrated in Figure 2-4, increments 2, 3, and 4 produce additional features that
1153build on previously implemented features in accordance with prioritization of the feature
1154 sets. The feedback arrows on the left side of the figure indicate that implemented
1155 features may have to be reworked based on evolving requirements, issues encountered during
1156 implementation, defects discovered when implementing subsequent features, or
1157demonstrations of the working product. Each increment of product capability is verified
1158with respect to the requirements for that feature set and validated by demonstrating
1159 incremental capabilities for the appropriate stakeholders.1160
1161The time boxes for iterations may vary but iterative-incremental life cycle models for
1162 software projects typically uses durations of 1 week to 1 month as the time box for most
1163 iterations; some time boxes may be extended to address specific issues. The feedback
Page 24
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
24/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
1164 arrows from time boxes to the previous ones in Figure 2-4 indicate that adding additional
1165 features may expose defects in previous work and that refactoring may be needed to better
1166 accommodate the features being added.1167
1168 Iterative-incremental life cycles for software projects may be on the predictive side of
1169 the life cycle continuum or on the adaptive end of the life cycle continuum, depending on
1170 the manner in which the prioritized feature sets. A predictive model establishes the
1171 feature sets and the priorities among them prior to starting the iterative-incremental
1172development cycles, perhaps to satisfy schedule and resource constraints when the
1173 requirements are known and are stable.1174
1175An adaptive approach allows feature sets designated for future iterations of the software
1176project life cycle to be reprioritized and modified prior to start of the iterative cycle
1177 in which they will be implemented. The number of iterations may be extended as needed or
1178desired.1179
11802.4.2.4 Adaptive Software Project Life Cycles
1181The considerations presented in Section 2.3.2.4 of the PMBOK® Guide are applicable to
1182 adaptive software project life cycles. Different adaptive software project life cycle
1183models (on the right side of Figure 2-1) incorporate various elements of software
1184development agility, as follows:1185
1186 • 0Iterative software development cycles that produce working deliverable software;
1187 the duration of an iterative cycle varies from daily to weekly to monthly, but usually not
1188more than monthly;
1189 • 0Continuous, ongoing involvement of a representative customer or user, where
1190 customer involvement may occur on a daily basis or during periodic demonstrations of
1191working, deliverable software on a weekly, biweekly, or monthly basis;
1192 • 0Small development teams (e.g., 10 or fewer members) with all team members
1193 assigned to one project at a time; large projects include multiple small teams;
1194 • 0Requirement and design may be initially defined or may emerge as the project
1195 evolves; in both cases product elements (requirements, design, code) evolve as the project
1196 evolves; and
1197 • 0Adaptive life cycles are iterative and incremental. Some typical attributes of
1198 iterative software development, which may be incorporated into an adaptive software
1199project life cycle, are presented in Table 2-1.1200
1201 Table 2-1. Attributes of Iterations in Adaptive Software Project Life Cycles
1202
Page 25
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
25/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
1203
1204The short duration iterations allows rework to be integrated within the iterations rather
1205 than accumulated as a large rework effort that must be accomplished at the end of software
1206development. Performing rework in small increments is more cost effective than the large
1207 amount of rework that typically occurs during the integration and testing phases of a
1208predictive life cycle for a software project.1209
1210Adaptive project life cycles are particularly appropriate when a precise, early definition
1211of customer needs is difficult or when the technology is used in a way that is different
1212 than has historically been applied. An adaptive approach is less expensive than delivering
1213 inadequate technical quality or failing to meet the customer’s needs. Although adaptive
1214practices improve overall quality and reduce total cost of ownership of the software
1215product over its life cycle, the cost-of-quality curve differs from that of traditional,
1216predictive software project life cycles. This point is discussed further in Section 8 on
1217Software Project Quality Management.1218
1219Another important aspect of adaptive software project life cycles is the relationships
1220 among product scope, size, cost, and schedule. For many adaptive life cycle projects the
1221 cost and schedule for each iterative cycle are fixed because the number of personnel is
1222 fixed and the time box for each iterative cycle is the same. The scope of work, and hence
1223 the product features that can be implemented (and the resulting amount of software that
1224 can be generated) on each iteration is adjusted to fit the constraints of fixed cost and
1225 fixed schedule per iteration.1226
1227Product size for adaptive software projects is often measured in stories, use cases, or
1228 features implemented rather than modules of lines of code implemented. An adaptive project
1229 team quickly learns by experience how much work can be accomplished during each iterative
1230 cycle. Experience also allows teams to accurately forecast how much time it will take to
1231 complete the implementation of a set of features. A measure of productivity call velocity,
1232which is the ratio of work products produced to amount of effort expended during an
1233 iterative cycle, can be accumulated during development iterations and used to track
1234planned versus actual progress and to forecast final cost and completion date, similar to
1235 the way traditional earned value is used to track predictive life cycle projects.1236
1237 • 0Intermediate-Adaptive Software Project Life Cycles. As the name implies,
1238 Intermediate-adaptive software project life cycles occupy the region of the life cycle
1239 continuum that lies between iterative-incremental and highly adaptive (see Figure 2-1). An
1240 illustration of an intermediate-adaptive software project life cycle is provided in Figure
12412-5.1242
1243
Page 26
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
26/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
1244
1245 Figure 2-5. An Intermediate-Adaptive Software Project Life Cycle1246
1247Key elements of the intermediate-adaptive software project life cycle include the feature
1248backlog and the iteration backlog. Each iterative cycle is based on a set of features and
1249other requirements selected from the feature backlog; this forms the iteration backlog.
1250During the iteration cycle, no changes to the features in the iteration backlog are
1251 allowed. Features and other requirements in the feature backlog can be added, deleted,
1252modified, and reprioritized at will. An iteration cycle is typically time-boxed to be one
1253 to a few weeks in duration; each cycle may have the same duration or the durations may
1254vary from cycle to cycle but the time box is all iterations is usually fixed. The
1255 frequency of internal iterations within an iteration cycle provides the developers with
1256 continuing demonstrations of progress; these internal iterations may occur hourly, daily,
1257or weekly, as desired. Daily stand-up meetings are short meetings in which the project
1258 team reviews progress, problems, and issues, and agrees on work tasks for that day. A
1259 typical approach that might be used internally by the software developers is illustrated
1260 in Figure 2-6.1261
1262
Page 27
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
27/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
1263
1264 Figure 2-6. Internal Development Cycles for Intermediate-Adaptive Life Cycle1265
1266Refactoring may be applied to restructure the existing product base to better accommodate
1267 the new feature(s). Some software developers alter the sequence “refactor, add new
1268 features, and test” to “test, add new features, and refactor.” The latter sequence
1269 indicates an approach that iteratively applies the tests to the code, which will fail
1270without the new features, iteratively writes code for the new features and tests until the
1271new code passes the tests, and then refactors the code.1272
1273The working software that now includes the new feature(s) is demonstrated. The
1274demonstration may result in accepting the software as demonstrated or may result in
1275 revisions. Corrections, additions, and adjustment to the software are easily accommodated
1276because the iteration cycles are short and the functionality that is added each day is
1277 small.1278
1279 It should also be noted that the scope of an adaptive software project life cycle includes
1280other elements of project scope, as appropriate to the needs of the project, such as
1281 initial architectural design, independent verification and validation, configuration
1282management, and quality assurance and quality control.1283
1284 • 0Highly Adaptive Software Project Life Cycles. Figure 2-7 illustrates a highly
1285 adaptive software project life cycle model that produces daily demonstrations of working
1286 software for a knowledgeable customer. The customer is involved on a continuing, daily
1287basis during development of the software product. The customer relates a user story or
1288 scenario for a desired feature of the software. Software developers specify product
1289 requirements and write test scenarios for implementation of the desired feature or
1290 features. The new feature(s) are added, and the test scenarios are applied.1291
1292
1293
1294 Figure 2-7. Illustrating a Highly Adaptive Software Project Life Cycle1295
1296The distinctions between Figure 2-6 and Figure 2-7 are as follows: the customer is “in the
1297 loop” on a daily basis in Figure 2-7; the developers are in the loop in Figure 2-6. Daily
1298 iterations in Figure 2-7 produce demonstrated capabilities for the customer; daily
1299 iterations produce demonstrations for the developers in Figure 2-6. The customer supplies
1300 the product requirements for the next iterative cycle in Figure 2-7; the developers select
1301 the requirements from the iteration backlog in Figure 2-6. In both cases, each iterative
1302 cycle produces working software; the working software must be in deliverable form in both
1303 cases.
Page 28
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
28/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
1304
1305 In Figure 2-7, the working software that now includes the new feature(s) is demonstrated
1306 to the customer, who may accept it as demonstrated, may request revisions, or may reject
1307 the added features because of miscommunication with the software developers. As stated
1308 above, corrections, additions, and adjustment to the software are easily accommodated
1309because the iteration cycles are short and the functionality added each day is small.1310
1311Because daily iteration cycles in Figure 2-7 produce working deliverable software, the
1312option exists to deliver the software product into the user environment at any point in
1313 time. It should also be noted that the customer determines the features to be included and
1314 therefore decides, from the business viewpoint, the value-added expenditure of development
1315 time, effort, resources, and money. The overall schedule and budget may be fixed or may
1316grow or shrink adaptively, based on value-added considerations of continuing or
1317 terminating product development.1318
13193 PROJECT MANAGEMENT PROCESSES FOR ASOFTWARE PROJECT
1320This section of the Software Extension to the PMBOK® Guide – Fifth Edition describes the
1321ways in which the project management processes in Section 3 of the PMBOK® Guide apply to
1322 the management of software projects, plus the adaptations and extensions that are commonly
1323used when managing software projects.1324
1325The introduction to Section 3 of the PMBOK® Guide makes the distinction between project
1326management processes and product-oriented processes as follows:1327
1328 • 0Project Management Processes. These processes ensure the effective flow of the
1329project throughout its existence. These processes encompass the tools and technique
1330 involved in applying the skills and capabilities described in the Knowledge Areas
1331 (Sections 4 through 13).
1332 • 0Product-Oriented Processes. These processes specify and create the project’s
1333product. Product-oriented processes are typically defined in the software project life
1334 cycle (as discussed in Section 2.4) and vary by application area as well as the stage of
1335 the product life cycle.1336
1337Sections 4 through 13 of this software extension are based on the corresponding sections
1338of PMBOK® Guide; they present the tools and techniques that are typically used to manage
1339 software projects. Section 2.4 of this software extension describes project life cycles
1340used to manage the various stages of the software product life cycle.1341
1342The project-oriented (project management) processes and the product-oriented processes for
1343 software projects are closely aligned in the iterative-incremental to highly adaptive life
1344 cycles part of the life cycle continuum for software projects presented in Section 2.4 of
1345 this extension.1346
1347As noted in Section 3 of the PMBOK® Guide, it should be used as a guide in managing a
1348project while considering the overall approach to be followed for the project. This effort
1349 is known as tailoring. Section 2.4 and Sections 4 through 13 of this extension provide
1350 tailoring guidelines for the processes in the PMBOK® Guide that are used to manage a
1351 software project.1352
1353This section of this software extension presents extensions to, and adaptations of, the
1354 five Process Groups presented in Section 3 of the PMBOK® Guide.1355
13563.1 Common Project Management Process Interactions
1357As stated in Section 3.1 of the PMBOK® Guide, application of the project management
1358processes is often iterative, with many processes repeated during a project. Section 2.4
Page 29
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
29/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
1359of this software extension indicates that software project life cycles commonly occupy a
1360 continuum ranging from predictive models on the one end to highly adaptive models at the
1361other end. Variations along this continuum are generally based on the manner in which life
1362 cycle elements are applied along the iterative-incremental to highly adaptive life cycle
1363 continuum for software projects.1364
1365There is an ongoing relationship between the Process Groups and the project phases for
1366 software projects. Predictive life cycles include activity-oriented phases (i.e.,
1367 analysis, design, implementation, etc.). For example, the requirements phase is initiated,
1368 the requirements targets are planned, the requirements phase is executed and monitored and
1369 controlled, and the requirements phase is closed out; the design phase is initiated and
1370 the cycle begins again.1371
1372The iterations that occur in the iterative-incremental to highly adaptive life cycles for
1373 software projects can be thought of as incremental phases. Each phase (each iteration)
1374 includes some degree of initiating, planning, executing, and monitoring and control.
1375Closing out an iteration typically involves the demonstration of working software. The
1376demonstration provides the basis for initiating and planning the next iteration. For
1377 software projects, the duration of a Planning and Executing process cycle typically varies
1378 from 2 to 4 weeks for an iterative-incremental cycle to as little as one day for a highly
1379 adaptive iteration.1380
1381Figure 3-3 in the PMBOK® Guide illustrates the interactions among the Planning, Executing,
1382 and Monitoring and Controlling Process Groups within a project phase. Figure 3-1 is an
1383 adaptation of PMBOK® Guide Figure 3-3 for software projects.1384
1385
Page 30
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
30/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
1386
1387Note: For software development, the planning, executing, and monitoring and controlling
1388processes require high levels of collaboration among project stakeholders.
1389 Figure 3-1. Interactions Among Process Groups for Software Development1390
1391For adaptive software project life cycles, these three Process Groups (Planning,
1392Executing, and Monitoring and Controlling) are often so closely interrelated that they are
1393not distinguishable as separate processes. For example, Planning (entry to an iteration
1394 cycle) may involve selecting the next set of features to be implemented, but daily
1395demonstrations of working software code may alter the planned set of features to be
1396 implemented within a given iteration cycle. Resources used and progress made provide
1397 tangible evidence for detailed Monitoring and Controlling. Exiting an adaptive development
1398 cycle involves demonstrating working software code to a customer or a designated user
1399 representative and obtaining their acceptance of the implemented functionality or
1400 accepting their requests for further changes. Figure 3-2 illustrates the interactions and
1401overlaps where each “hump” is an iterative development cycle; each cycle involves the
1402PMBOK® Guide process groups of planning, executing, and monitoring and controlling.1403
1404
1405 Figure 3-2. Overlap of the Planning, Executing, and Monitoring and Controlling Processes1406
1407The overlap of phases for adaptive software life cycles indicates that team members need
1408 to have all of the necessary skills to plan, execute, and monitor and control each
1409 iteration of an adaptive software project because all skills are constantly needed and
1410must be available within the team, rather than relying on other elements of the
1411organization to provide the needed skills.1412
Page 31
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
31/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
14133.2 Software Project Management Process Groups
1414According to the PMBOK® Guide, these five Process Groups have clear dependencies and are
1415 typically performed in the same sequence on each project. In contrast, and as indicated in
1416Section 2.4 of this software extension and the above discussion, the ways in which the
1417 five PMBOK® Guide Process Groups are applied to software projects may vary from project to
1418project and within the iterative cycles of a software project.1419
1420Software development projects based on adaptive life cycles involve frequent and closely
1421 coordinated interactions between the customer and the project’s processes—particularly in
1422 the translation of customer requirements into planning, which gets communicated to
1423 execution. Of particular importance, the process flow is not strictly one-directional
1424 feed-forward, where information is fed sequentially from one process to the next. In
1425 software development, there is a need for frequent feedback between planning and executing
1426 and monitoring and controlling to ensure that the emerging software product is consistent
1427with (possibly changing) expectations. Documentation of decisions made is necessary; but
1428documentation alone is not sufficient to provide the understanding needed to implement a
1429 software product that meets the needs of the customer and the business. Frequent
1430 interpersonal interactions are required to provide clarity for all stakeholders;
1431 therefore, the emphasis is placed on evolving, working software for each development cycle
1432of an adaptive software project life cycle, in addition to documentation.1433
1434 It is also important to recognize that the life cycle continuum for software projects is
1435not a thin line; it is multi-dimensional. All of the processes and support functions for
1436 software development (configuration management, quality assurance, documentation, and so
1437 forth) should be adapted to fit the needs of each software project life cycle.1438
14393.3 Initiating Process Group
1440As stated in the PMBOK® Guide, internal and external stakeholders who will interact and
1441 influence the overall outcome of the project are identified. One of the most important
1442 stakeholders for a successful software project is a knowledgeable customer or designated
1443user representative who can state the users’ wants and needs on a continuing, ongoing
1444basis. Identifying such a stakeholder early will allow for frequent demonstrations of the
1445 incrementally evolving product and the associated feedback will ensure that the right
1446features are delivered. It is also important to discuss issues with experienced project
1447managers and technical leaders on similar projects, or perhaps managers and leaders on
1448 releases of previous versions of a software product undergoing significant modifications.1449
14503.4 Planning Process Group
1451According to the PMBOK® Guide, The Planning Process Group consists of those processes
1452performed to establish the total scope of the effort, define and refine the objectives,
1453 and develop the course of action required to attain those objectives.1454
1455These processes are often overlapped, interleaved, and iterated in various ways for
1456 software projects. Section 5 of this software extension (Scope), explains that the scope
1457of a software project, the objectives to be obtained, and the courses of action to be
1458 followed when conducting a software project are often adjusted as the project evolves.
1459Adaptive software project life cycles are designed to encourage frequent customer
1460 interactions and to permit graceful incorporation of changes throughout the project life
1461 cycle.1462
14633.5 Executing Process Group
1464According to the PMBOK® Guide: During project execution, results may require planning
Page 32
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
32/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
1465updates and re-baselining. This may include changes to expected activity durations,
1466 changes in resource productivity and availability, and unanticipated risks.1467
1468Every software project is a unique undertaking and is, therefore, a learning experience.
1469Changes in activity durations, resource productivity and availability, and unanticipated
1470 risks are the norm for many software projects. Anticipating and facilitating these changes
1471 is a primary goal of adaptive software project lifecycles.1472
14733.6 Monitoring and Controlling Process Group
1474Depending on the software project life cycle used, monitoring and controlling of software
1475projects can vary from traditional techniques for predictive software project life cycles
1476 (i.e., preplanned milestones, earned value tracking, and technical performance
1477measurement) to reliance on frequent demonstrations of progress (or lack of progress) for
1478 adaptive software project life cycles. These iterative demonstrations vary from daily
1479demonstrations for the project team to weekly or monthly demonstrations for customers and
1480users.1481
14823.7 Closing Process Group
1483The techniques presented in the Closing Process Group for a software project, as specified
1484 in the PMBOK® Guide, are equally applicable to software projects. Demonstration of working
1485 software is an important approach to closing a predictive life cycle project or a project
1486phase (i.e., an iterative cycle) for software projects that use life cycles on the
1487 iterative-incremental to highly predictive side of the life cycle continuum presented in
1488Section 2.4 of this software extension. In all cases, it is important to conduct a
1489 retrospective, lessons-learned session; assess team performance; and update the
1490organizational knowledge base.1491
14923.8 Project Information
1493Project information collected during a software project can be used to predict attributes
1494 such as final cost and delivery date (for predictive software project life cycles) and
1495 incremental progress using measures such as velocity and burn down rate (for adaptive
1496 software lifecycles) (see the Glossary for definitions of these terms and Section 7 for
1497 additional information). Project information can be collected and saved in an
1498organizational database to provide a basis for estimating future software projects that
1499have similar characteristics (i.e., similar domains, customers, software developers,
1500development tools). Care should be taken to ensure that the attributes of past and future
1501projects are sufficiently similar when using past performance data to estimate a future
1502project.1503
15043.9 Role of the Knowledge Areas
1505As indicated in Section 3.9 of the PMBOK® Guide, the 47 project management processes
1506 identified in the PMBOK® Guide are further organized into ten separate Knowledge Areas
1507 (note PMI-specific use of the term processes, which is used in different contexts). These
150810 Knowledge Areas are presented in Sections 4 through 13 of the PMBOK® Guide and describe
1509 the tools and techniques that are used on most projects most of the time. In a similar
1510manner, the 10 Knowledge Areas presented in Sections 4 through 13 of this software
1511 extension describe the tools and techniques that are used for most software projects, most
1512of the time.1513
1514
4 SOFTWARE PROJECT INTEGRATION
MANAGEMENT
Page 33
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
33/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
MANAGEMENT
1515As stated in the introduction to Section 4 of the PMBOK® Guide: “Project Integration
1516Management includes the processes and activities needed to identify, define, combine,
1517unify, and coordinate the various processes and project management activities within the
1518Project Management Process Groups.” Many of the inputs, tools and techniques, and outputs
1519 in Section 4 of the PMBOK® Guide are applicable to integration management of software
1520projects. This section of the Software Extension to the PMBOK® Guide – Fifth Edition
1521presents extensions that are especially important for software project integration
1522management.1523
1524 It is important to note that “software project integration management” refers to the
1525 integration of the processes and activities in the PMBOK® Guide project Knowledge Areas
1526 (Sections 4 through 13); it does not refer to the software project life cycle process of
1527 integrating software components to form a partial or finished software product.1528
1529Planning and conducting a software project is mostly a proactive endeavor, rather than
1530 integration and coordination of subsidiary plans, as presented in Section 4 of the PMBOK®
1531Guide. Sometimes, other departments provide some software project functions (e.g.,
1532 configuration management, independent testing) but, for the most part, software project
1533managers are responsible for planning and conducting a wide scope of project activities
1534 (see Section 5).1535
1536Software projects have a wide range of influences that impact the rigor of and emphasis on
1537various project management activities. There is no single way best to manage a software
1538project. Every project management process needs to be addressed to determine the
1539 appropriate level of implementation for each project endeavor. Project managers should
1540 apply knowledge and skills appropriate to software projects by tailoring and adapting the
1541project management processes in the PMBOK® Guide and this software extension to maximize
1542 the potential of the project team to achieve the desired project performance.1543
1544Figure 4-1 provides an overview of Software Project Integration Management; it is an
1545 adaptation of Figure 4-1 in the PMBOK® Guide.1546
1547
Page 34
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
34/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
1548
1549 Figure 4-1. Software Project Integration Management Overview1550
15514.1 Develop Software Project Charter
1552According to the PMBOK® Guide, Section 4.1: “Develop Project Charter is the process of
1553developing a document that formally authorizes the existence of a project and provides the
1554project manager with the authority to apply organizational resources to project
1555 activities.” The inputs, tools and techniques, and outputs presented in Section 4.1 of the
1556PMBOK® Guide are applicable to developing a software project charter.1557
15584.1.1 Develop Software Project Charter: Inputs
1559The inputs in Section 4.1.1 of the PMBOK® Guide are applicable for software projects. An
1560 additional consideration is the role played by a software project portfolio when
1561developing a software project charter (see 4.1.1.6 of this extension).1562
Page 35
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
35/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
15634.1.1.1 Project Statement of Work
1564See Section 4.1.1.1 of the PMBOK® Guide.1565
15664.1.1.2 Business Case
1567See Section 4.1.1.2 of the PMBOK® Guide.1568
15694.1.1.3 Agreements
1570See Section 4.1.1.3 of the PMBOK® Guide.1571
15724.1.1.4 Enterprise Environmental Factors
1573See Section 4.1.1.4 of the PMBOK® Guide.1574
15754.1.1.5 Organizational Process Assets
1576See Section 4.1.1.5 of the PMBOK® Guide.1577
15784.1.1.6 Software Project Portfolios
1579Supporting business objectives are the primary reasons that organizations invest in IT and
1580 software projects. Contracted projects for external customers provide jobs and sources of
1581 revenue; internal projects support the mission and business strategy of the organization.
1582Many organizations maintain a portfolio of software projects and follow a portfolio
1583weighting and planning process for selecting software projects that will align with
1584business strategy. Within a portfolio, investments in projects are linked to strategic
1585objectives, identification of potential benefits, and order of magnitude estimates for
1586 completing projects, including the types and amounts of resources needed. Additional
1587weighting criteria include the number of resources needed (software developers, other
1588 software personnel, technology), the timeframe within which a product is needed, and
1589priority of need.
1590
1591Additional aspect of software portfolio management include identifying specific goals for
1592 each project by developing a preliminary scope statement along with benefits and
1593 constraints, group and prioritize related potential projects based on capacity, prepare a
1594 charter for the next most important project to maximize benefit, and coordinate projects
1595 to make the best use of delivery capability.1596
1597The result is a prioritized backlog of software projects mapped to the organization’s
1598 strategic plan and availability of resources. The relationship between software projects
1599 and software portfolio management were presented in Section 1 of this software extension
1600 and illustrated in Figure 1-1.1601
16024.1.2 Develop Software Project Charter: Tools and Techniques
1603The tools and techniques presented in Section 4.1.2 of the PMBOK® Guide are applicable for
1604developing a software project charter with the following additional information.1605
1606As discussed in Section 2, there is continuum of software project life cycles ranging from
1607predictive, where the project scope and life cycle tools and techniques are planned during
1608project initiation and planning; to iterative-incremental, where the project is planned to
1609generate successive increments of increasing functionality on each iteration; to adaptive,
1610where the product scope emerges during iteration cycles; Charters for software projects
1611 that use predictive and iterative-incremental life cycles on the predictive side of the
Page 36
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
36/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
1612 continuum provide clear and definitive statements of desired outcomes. Charters for
1613 adaptive projects state a clear vision or business goal and acceptable project constraints
1614under which to pursue that vision or business goal. The selected life cycle model
1615 influences project planning, execution, and monitoring and controlling of each of the
1616project management processes.1617
1618Domain experts should be consulted when developing a software project charter. Expertise
1619 in developing similar systems using similar development platforms, systems software,
1620product architecture, and information design (i.e., databases, data interchanges, and data
1621warehouses) can provide valuable insights and expose unrecognized complexities and risk
1622 factors. In addition, when software projects involve working with an existing
1623 implementation or team, inputs from experts familiar with the architecture, technical
1624 implementation, testing approach, and team capabilities can provide assistance in
1625developing the project charter as well.1626
16274.1.2 Develop Software Project Charter: Tools and Techniques
16284.1.2.1 Expert Judgment
1629See Section 4.1.2.1 of the PMBOK® Guide.1630
16314.1.2.2 Facilitation Techniques
1632See Section 4.1.2.2 of the PMBOK® Guide.1633
16344.1.3 Develop Project Charter: Outputs
1635See Section 4.1.3 of the PMBOK® Guide, with the addition of 4.1.3.2.1636
16374.1.3.1 Software Project Charter
1638See Section 4.1.3.1 of the PMBOK® Guide.1639
16404.1.3.2 Updates to the Organization’s Software Project Portfolio
1641An additional consideration when developing a software project charter is updating of the
1642 software project portfolio, if there is one, with the information developed during
1643preparation of the software project charter.1644
16454.2 Develop Software Project Management Plan
1646According to Section 4.2 of the PMBOK® Guide, Develop Project Management Plan is the
1647process of defining, preparing, and coordinating all subsidiary plans and integrating them
1648 into a comprehensive project management plan.1649
1650The extent to which planning software projects involves “defining, preparing, and
1651 coordinating all subsidiary plans and integrating them” depends on the software project
1652 life cycle selected, the organizational structure, and the project context. The software
1653project manager’s job may not be to perform all project planning activities—some may be
1654performed by a software project management office (such as preparing estimates based on
1655historical data) or by another organizational unit (such as independent testing). Project
1656 Integration Management ensures that all necessary processes are being performed with
1657 sufficient rigor and that sufficient project performance information will be produced so
1658 that the software project manager can perform the appropriate Monitor and Control
Page 37
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
37/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
1659 activities.1660
1661As discussed in Section 2 of this software extension, predictive software project life
1662 cycles typically involve more upfront planning than do adaptive life cycles. The pros and
1663 cons of each approach as well as the intermediate iterative-incremental approaches in the
1664 life cycle continuum are presented in Section 2.4.2 of this extension.1665
1666Developing a software project plan for a predictive life cycle project may involve upfront
1667planning specialists and other elements of the organization in process areas such as
1668 configuration management and quality assurance to a greater extent than when planning an
1669 adaptive software project. Regardless of the life cycle adopted, software projects may
1670 also need to integrate a number of additional plans such as an information security plan,
1671data management plan, product launch plan, deployment plan, and perhaps a team training
1672plan for new technologies or for a new domain.1673
1674Project managers of predictive life cycle software projects tend to put substantial effort
1675 into upfront development of the project plan and integration of subsidiary plans developed
1676by support personnel from other organizational units (e.g., estimation specialists in the
1677PMO). In adaptive projects, there is less upfront effort spent on developing detailed
1678 scope, cost, and schedule plans, but significant effort is typically spent on defining
1679monitor and control processes, such as requirements traceability, to ensure coordination
1680 among the project members or project teams as the emerging plans are implemented.1681
1682Project constraints that influence development of a software project plan include
1683organizational policies, the size and criticality of the project, risk mitigation
1684 strategies, and the complexity of the solution. Projects with rigid constraints may
1685 require increased emphasis on the Risk Management, Integration Management, Procurement
1686Management, Quality Management, and Stakeholder Management processes as described in the
1687 corresponding Knowledge Areas.1688
1689Because software is developed by the coordinated intellectual effort of the team members
1690 it is not advisable to plan a large team for a large software project. A better approach
1691 is to scale up by increasing the number of teams, which limits the number of communication
1692paths within each team. Small teams (ten or fewer members) can develop sub-elements that
1693have well-defined interfaces to the other product elements; the project plan can include
1694 the integration process, which typically occurs following software construction for
1695predictive life cycles and is integrated into adaptive life cycles. Software projects that
1696have multiple teams typically have team leaders who report to the project manager. The
1697 team leaders are technical contributors who also coordinate the team’s work.1698
1699Large complex projects may be organized as multiple subprojects with a project management
1700 team, or multiple distinct projects with a program manager to coordinate the multiple
1701projects, each of which will have a project manager and team leaders within each project.
1702 In these cases it is important to allocate requirements and interfaces to project,
1703 subproject, and team so that the development of product components can proceed
1704 concurrently with a plan for periodic integration of work products. There will be more
1705 emphasis on Human Resources Management and Communications Management processes as the
1706 scale of a project grows (see Sections 10 and 13).1707
1708The form of a software project management plan and the emphasis placed on various aspects
1709of the plan depends on many factors, including but not limited to the project and product
1710 scope, product requirements, the choice of software project life cycle model, the
1711organizational assets, the influence of contextual factors, and the nature of the customer
1712 relationship.1713
1714For example, the choice of a predictive or an adaptive project life cycle model will
1715 influence the planning for management of scope, time, cost, and product integration, among
1716others. A project that will involve a geographically distributed or virtual project team
1717will place emphasis on human resource issues and management of stakeholders. Perceived
1718 complexity of the product and familiarity of the software team with the problem domain and
1719 the technology to be used will place emphasis on planning for quality control, quality
Page 38
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
38/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
1720 assurance, and risk management. Dealing with vendors and subcontractors will place
1721 emphasis on planning for procurement activities.1722
1723The Knowledge Areas in the PMBOK® Guide and this software extension provide guidance on
1724dealing with these issues when preparing a software project management plan.1725
1726Regardless of the software project life cycle adopted, the development and integration of
1727 elements of a software project management plan is rarely a linear process as elements
1728 evolve at different rates and exert different levels of influence on each element.
1729Conducting a software project is a learning process that results in revision of the
1730project plan and subsidiary plans as understanding grows; re-planning of both the project
1731 and product is inevitable for software projects, regardless of the life cycle used.1732
17334.2.1 Develop Software Project Management Plan: Inputs
1734Figure 4-5 and Section 4.2.1 of the PMBOK® Guide indicate that developing a project
1735management plan involves integration of related and subordinate plans that have been
1736developed. Development of a software project plan tends to be a process of planning the
1737primary activities and coordinating subordinate plans rather than integration of plans
1738developed by others.1739
1740Estimates of cost, schedule, technical infrastructure, and risk provide important inputs
1741 for developing a project management plan, as indicated in Section 4.2.1 of the PMBOK®
1742Guide. Every software project differs from all past projects (because software replication
1743 is a trivial process) so there are typically many unknowns and uncertainties during the
1744 initiating and planning stages of a software project, which results in imprecise and
1745 sometimes inaccurate software project estimates. Estimation techniques include analogies,
1746 expert judgment (perhaps involving a Delphi process), rules of thumb, statistical
1747 techniques such as PERT, and estimation algorithms that rely on historical data for
1748 calibration to the local situation.1749
1750Many software project managers use two or more estimation techniques to expose differences
1751 in the assumptions and reasoning processes used to arrive at the (often disparate)
1752 estimates. Templates can be tailored and adapted to fit the needs of different software
1753projects; they can guide the thought processes and work activities of a software project
1754manager when preparing a project management plan.1755
1756 ISO/IEC/IEEE Standard 16326 – Systems and software engineering – Life cycle process –
1757Project Management [15] provides useful input information for planning software projects.1758
17594.2.1.1 Project Charter
1760See Section 4.2.1.1 of the PMBOK® Guide.1761
17624.2.1.2 Outputs from Other Processes
1763Outputs from the processes described in Sections 5 through 13 of the PMBOK® Guide and this
1764 software extension are integrated to create the project management plan.1765
17664.2.1.3 Enterprise Environmental Factors for Software Projects
1767Environmental factors that may impact planning a software project include existing
1768 technical assets such as software that can be reused, development and testing
1769 infrastructure and facilities, and the technical infrastructure, including networks, data
1770 centers, and simulation and modeling facilities.
1771
Page 39
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
39/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
17724.2.1.4 Organizational Process Assets for Software Projects
1773Organizational process assets listed in Section 4.2.1.4 of the PMBOK® Guide are applicable
1774 for software projects. In addition, change control and configuration management method and
1775 tools for software projects are needed to control software code baselines because software
1776 code is updated and changed frequently during software development; it is not uncommon for
1777 software code to be changed several times in one day when using an adaptive life cycle.
1778Without effective version control, the incorrect version of a software module may be used
1779 as the basis for further work or may be incorrectly integrated into a deliverable product
1780baseline.1781
1782Some product changes have local impact and other changes should be reviewed and approved
1783by a software change control board, depending on the wider impact of a proposed change.
1784Predictive life cycles tend to exert tighter control over the software code baselines
1785during software development than occurs for adaptive software project life cycles because,
1786when using an adaptive life cycle, the frequent iterations and demonstrations of working,
1787deliverable code will expose undesired side effects of changes that can be quickly
1788 corrected. Frequent, ongoing changes are typically more difficult when using a predictive
1789 software project life cycle model.1790
17914.2.2 Develop Software Project Management Plan: Tools and Techniques
1792The tools and techniques in Section 4.2.2 of the PMBOK® Guide are applicable to
1793development of a software project management plan. Templates and estimation tools are
1794useful when developing a software project plan.1795
17964.2.2.1 Expert Judgment
1797See Section 4.2.2.1 of the PMBOK® Guide.1798
17994.2.2.2 Facilitation Techniques
1800See Section 4.2.2.2 of the PMBOK® Guide.1801
18024.2.3 Develop Software Project Management Plan: Outputs
18034.2.3.1 Project Management Plan
1804 In addition to the project management plan listed as the output in Section 4.2.3.1 of the
1805PMBOK® Guide, the following software specific documents and plans may be included as
1806 supporting output documents:1807
1808 • 0Requirements management plan,
1809 • 0Configuration management plan,
1810 • 0Security plans (physical, project, data),
1811 • 0Enterprise technology insertion plan,
1812 • 0Information security plan,
1813 • 0Test and evaluation plan,
1814 • 0Data management plan,
1815 • 0Deployment plan,
1816 • 0Technology infrastructure plan, and
1817 • 0Training plan for the software team.1818
1819 In addition, deployment plans and technology infrastructure plans may be developed for IT
1820 infrastructure projects and for software projects that involve deployment of the software
1821product to external customer sites.
Page 40
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
40/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
1822
18234.3 Direct and Manage Software Project Work
1824Software project managers who manage predictive life cycle projects tend to follow more
1825 closely the traditional approaches to directing and managing project work as indicated in
1826Section 4.3 of the PMBOK® Guide than do managers of adaptive software project life cycle
1827projects. A desirable attribute of managing co-located multifunctional software teams is
1828 that they be self-enabled and self-directed, which places the project manager in a more
1829hands-off position in the day-to-day management of the project team than the manager of a
1830predictive life cycle project team. However, this does not mean the software project
1831manager is left without a role in directing and managing adaptive software projects.
1832Activities engaged in by project managers of adaptive life cycle software projects
1833 include, but are not limited to:1834
1835 • 0Communicating the project scope, resources, and schedule/budget constraints to
1836 the project team and other appropriate stakeholders;
1837 • 0Providing the resources and facilities needed by the collective software team;
1838 • 0Monitoring and controlling project resources, schedule, and budget;
1839 • 0Controlling changes to project scope, resources, schedule, and budget;
1840 • 0Consulting with and allocating the work among multiple software development teams;
1841 • 0Ensuring communication and coordination of work activities among multiple teams
1842 and coordinating the integration of resources and components;
1843 • 0Facilitating ongoing and continuous communications between the customer/user
1844 representatives and the software developers;
1845 • 0Monitoring productivity, product quality, and team performance while making
1846 adjustments as needed;
1847 • 0Managing risk;
1848 • 0Ensuring effective interactions with other organizational units, such as
1849 independent testing and user training;
1850 • 0Facilitating demonstrations of evolving product capabilities for appropriate stakeholders;
1851 • 0Facilitating delivery of early product capabilities into the user environment, as
1852desired;
1853 • 0Facilitating delivery and acceptance of the final product and closing the project; and
1854 • 0Coordinating dependencies with related projects, which may be elements of a
1855 common development program or milestone dependencies with related IT infrastructure
1856projects.1857
1858Managers of all software projects engage in these activities, whether using a predictive,
1859 iterative-incremental, or adaptive life cycle although the details vary with the life
1860 cycle model used.1861
18624.3.1 Direct and Manage Software Project Execution: Inputs
1863See Section 4.3.1 of the PMBOK® Guide for inputs that are generally applicable to
1864directing and managing software project execution.1865
18664.3.1.1 Project Management Plan
1867See Section 4.3.1.1 of the PMBOK® Guide.1868
18694.3.1.2 Approved Change Requests
1870See Section 4.2.1.2 of the PMBOK® Guide.1871
18724.3.1.3 Enterprise Environmental Factors
Page 41
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
41/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
1873See Section 4.3.1.3 of the PMBOK® Guide.1874
18754.3.2 Direct and Manage Software Project Execution: Tools and Techniques
1876The tools and techniques presented in Section 4.3.2 of the PMBOK® Guide are generally
1877 applicable to directing and managing software project execution. In addition to these,
1878 information dissemination is also an important tool/technique for directing and managing
1879 software project execution.1880
18814.3.2.1 Expert Judgment
1882See Section 4.3.2.1 of the PMBOK® Guide.1883
18844.3.2.2 Project Management Information System
1885See Section 4.3.2.2 of the PMBOK® Guide.1886
18874.3.2.3 Meetings
1888See Section 4.3.2.3 of the PMBOK® Guide.1889
18904.3.2.4 Information Dissemination
1891Because software tends to be an invisible product, as compared to physical artifacts,
1892 tools and techniques for disseminating project information are particularly important for
1893 software projects. Providing team members, management, customer, external stakeholders,
1894 and everyone who affects or is affected by a software project, at the level appropriate
1895 for each constituency, is thus an important activity for a software project manager. The
1896kind of information to be disseminated includes, but is not limited to:1897
1898 • 0Current status of the overall project;
1899 • 0Risks and status (watch list, monitored, confronted);
1900 • 0Current work assignments;
1901 • 0Daily progress and remaining work;
1902 • 0Number of use cases, features, or stories written/implemented/delivered;
1903 • 0Number of test cases and test scenarios written/passed;
1904 • 0Product components/features implemented with cost or staff-hours as the
1905 independent variable;
1906 • 0Resolutions and action items from the last retrospective meeting; and
1907 • 0Status of servers and other infrastructure equipment (up, down, in maintenance).1908
1909See Section 10 (Software Project Communications Management) for additional information
1910 concerning information dissemination.1911
1912Some software projects use large displays (i.e., information radiators) posted in
1913 locations where software developers and other team members can easily see them; the
1914displays are typically posted in locations where it is difficult to avoid seeing them. The
1915purpose of visual displays is to communicate essential project information that personnel
1916need to know without anyone having to ask questions. This approach facilitates increased
1917 communication with less confusion and misinterpretation for the project team and other
1918 stakeholders. Well-designed visual displays are:1919
1920 • 0Large and readily visible,
1921 • 0Understood at a glance, and
1922 • 0Changed periodically and kept up to date.1923
1924
Page 42
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
42/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
Typically, a visual display is paper-based and is posted in the team room or in a hallway.
1925Sometimes visual displays are presented on readily accessible Web pages. Visual displays
1926 can be used to inform stakeholders outside of the project team concerning project status
1927 and other issues that may be of concern to them.1928
19294.3.3 Direct and Manage Software Project Execution: Outputs
1930The outputs presented in Section 4.3.2 of the PMBOK® Guide are generally applicable to
1931directing and managing software project execution. In addition to these, an additional
1932output is provided in Section 4.3.3.6 of this extension.1933
19344.3.3.1 Deliverables
1935See Section 4.3.3.1 of the PMBOK® Guide.1936
19374.3.3.2 Work Performance Data
1938See Section 4.3.3.2 of the PMBOK® Guide.1939
19404.3.3.3 Change Requests
1941See Section 4.3.3.3 of the PMBOK® Guide.1942
19434.3.3.4 Project Management Plan Updates
1944See Section 4.3.3.4 of the PMBOK® Guide.1945
19464.3.3.5 Project Document Updates
1947See Section 4.3.3.1 of the PMBOK® Guide.1948
19494.3.3.6 Demonstrations of Working, Deliverable Software
1950 In addition to the outputs contained in See Section 4.3.3.1 of the PMBOK® Guide,,
1951 continuing and ongoing demonstrations of working, deliverable software are the most
1952 important indicators of tangible progress for directing and managing iterative-incremental
1953 and adaptive software projects. Productivity and progress indicators such as velocity,
1954burn-down rates, and buildup charts provide the work performance data for adaptive life
1955 cycle projects.1956
19574.4 Monitor and Control Software Project Work
1958The inputs, tools and techniques, and outputs for monitoring and controlling project work
1959 indicated in Section 4.4 of the PMBOK® Guide are applicable for managing software
1960projects. When managing adaptive software projects, delivered increments of working
1961 software code are evaluated against the project constraints, the team performance, and the
1962overall goals of the project to trigger change control events, as necessary, when those
1963 events exceed control limits.1964
1965Figure 4-2 illustrates how management of portfolios and programs can influence monitoring
1966 and controlling of software projects and the backlog of work for project teams.1967
Page 43
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
43/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
1968
1969 Figure 4-2: Relationships Among Software Portfolios, Programs, and Projects1970
19714.4.1 Monitor and Control Software Project Work: Inputs
1972The inputs for monitoring and controlling project work in Section 4.4.1 of the PMBOK®
1973Guide are applicable for monitoring and controlling software project work.1974
19754.4.1.1 Project Management Plan
1976See Section 4.4.1.1 of the PMBOK® Guide.1977
19784.4.1.2 Schedule Forecasts
1979See Section 4.4.1.2 of the PMBOK® Guide.1980
19814.4.1.3 Cost Forecasts
1982See Section 4.4.1.3 of the PMBOK® Guide.1983
Page 44
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
44/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
19844.4.1.4 Validated Changes
1985See Section 4.4.1.4 of the PMBOK® Guide.1986
19874.4.1.5 Work Performance Information
1988See Section 4.4.1.5 of the PMBOK® Guide.1989
19904.4.1.6 Enterprise Environmental Factors
1991See Section 4.4.1.6 of the PMBOK® Guide.1992
19934.4.1.7 Organizational Process Assets
1994See Section 4.4.1.7 of the PMBOK® Guide.1995
19964.4.2 Monitor and Control Software Project Work: Tools and Techniques
1997The tools and techniques for monitoring and controlling project work in Section 4.4.2 of
1998 the PMBOK® Guide are applicable to monitoring and controlling software projects.1999
20004.4.2.1 Expert Judgment
2001See Section 4.4.2.1 of the PMBOK® Guide.2002
20034.4.2.2 Analytical Techniques
2004See Section 4.4.2.2 of the PMBOK® Guide.2005
20064.4.2.3 Project Management Information System
2007See Section 4.4.2.3 of the PMBOK® Guide.2008
20094.4.2.4 Meetings
2010See Section 4.4.2.4 of the PMBOK® Guide.2011
20124.4.3 Monitor and Control Software Project Work: Outputs
2013The outputs for monitoring and controlling project work in Section 4.4.3 of the PMBOK®
2014Guide are applicable to monitoring and controlling software projects.2015
20164.4.3.1 Change Requests
2017See Section 4.4.3.1 of the PMBOK® Guide.2018
20194.4.3.2 Work Performance Reports
2020Work performance reports for software project, in addition to those in Section 4.4.3.2 of
2021 the PMBOK® Guide include:2022
Page 45
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
45/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
2023 • 0Earned value reports with projections of estimated actual cost and estimated
2024 completion date;
2025 • 0Updates to estimates (product size, delivered quality, delivery date);
2026 • 0Team productivity measures such as velocity metrics, feature burn down and burn up charts;
2027 • 0Feature backlogs; and
2028 • 0Configuration management reports.2029
20304.4.3.3 Project Management Plan Updates
2031See Section 4.4.3.3 of the PMBOK® Guide.2032
20334.4.3.4 Project Documents Updates
2034See Section 4.4.3.4 of the PMBOK® Guide.
2035
20364.5 Perform Integrated Software Change Control
2037See Section 4.5 of the PMBOK® Guide, which is applicable for managing software projects,
2038with the following extensions.2039
20404.5.1 Perform Integrated Software Change Control: Inputs
2041Variations that trigger change control processes differ for different software project
2042 life cycles. Control limits for schedule, cost, defects, and product scope are usually
2043 established for predictive software project life cycle projects. Exceeding a control limit
2044 triggers a change control process. For adaptive project life cycles, change control is not
2045usually required for occasional anomalies, as long as the vision and goals of the project
2046 can be achieved within the constraints of schedule and cost.2047
2048The inputs for performing integrated change control, as presented in the PMBOK® Guide, are
2049 applicable for performing integrated software change control.2050
20514.5.1.1 Project Management Plan
2052See Section 4.5.1.1 of the PMBOK® Guide.2053
20544.5.1.2 Work Performance Reports
2055See Section 4.5.1.2 of the PMBOK® Guide.2056
20574.5.1.3 Change Requests
2058See Section 4.5.1.3 of the PMBOK® Guide.2059
20604.5.1.4 Enterprise Environmental Factors
2061See Section 4.5.1.4 of the PMBOK® Guide.2062
20634.5.1.5 Organizational Process Outputs
2064See Section 4.5.1.4 of the PMBOK® Guide.2065
Page 46
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
46/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
20664.5.2 Perform Integrated Software Change Control: Tools and Techniques
2067Not all changes to software require formal approval, but all proposed changes should be
2068 evaluated for impacts on users and other operational stakeholders. Changing the color of
2069 and icon on a user display may not be important, or it may render the application unusable
2070 if some users are color blind or where compliance with disability regulations concerning
2071 color blindness may be required. Adding an additional choice on a web page may have no
2072 impact on present capabilities or it may render a data interchange capability inoperable.
2073Thus, some seemingly minor changes may have significant impacts.2074
2075For predictive software life cycle projects, a separate change control process that
2076 includes change requests and change control boards is used. For adaptive life cycle
2077projects, a change request is another element of the product backlog; the iteration
2078planning process does not distinguish between new scope, change requests, and defect fixes
2079 although the nature of the backlog element may determine the priority of the element
2080within the backlog.2081
2082The tools and techniques for performing integrated change control, as presented in the
2083PMBOK® Guide, are applicable for performing integrated software change control.2084
20854.5.2.1 Expert Judgment
2086See Section 4.5.2.1 of the PMBOK® Guide.2087
20884.5.2.2 Meetings
2089See Section 4.5.2.2 of the PMBOK® Guide.2090
20914.5.2.3 Change Control Tools
2092See Section 4.5.2.3 of the PMBOK® Guide.2093
20944.5.3 Perform Integrated Software Change Control: Outputs
2095See Section 4.5.3 of the PMBOK® Guide for outputs applicable to performing integrated
2096 change control for software projects.2097
20984.5.3.1 Approved Change Requests
2099See Section 4.5.3.1 of the PMBOK® Guide.2100
21014.5.3.2 Change Log
2102See Section 4.5.3.2 of the PMBOK® Guide.2103
21044.5.3.3 Project Management Plan Updates
2105See Section 4.5.3.3 of the PMBOK® Guide.2106
21074.5.3.4 Project Documents Updates
2108See Section 4.5.3.4 of the PMBOK® Guide.2109
Page 47
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
47/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
21104.6 Close Software Project or Phase
2111According to Section 4.6 of the PMBOK® Guide, Close Project or Phase is the process of
2112 finalizing all activities across all five Project Management Process Groups to formally
2113 complete the project or phase. The inputs, tools and techniques, and outputs for closing a
2114project, as indicated in Section 4.6 of the PMBOK® Guide are applicable to closing a
2115 software project.2116
2117Two items are particularly important when closing a software project: historical data and
2118 lessons learned. This information is captured in an organizational data repository or
2119 repositories. Historical data provides a basis for estimating future, similar projects.
2120Historical data and lessons learned can be used to identify trends, both positive and
2121negative, during the life cycle of the project. Positive trends can indicate areas for
2122organizational process improvement by indicating good practices used on the project that
2123 should be adopted throughout the organization. Negative trends and lessons learned
2124 indicate areas for needed process improvements throughout the software organization.2125
21264.6.1 Close Software Project or Phase: Inputs
2127The inputs for closing a project or phase in Section 4.6.1 of the PMBOK® Guide are
2128 applicable inputs for closing a software project or phase.2129
21304.6.1.1 Project Management Plan
2131See Section 4.6.1.1 of the PMBOK® Guide.2132
21334.6.1.2 Accepted Deliverables
2134See Section 4.6.1.2 of the PMBOK® Guide.2135
21364.6.1.3 Organizational Process Assets
2137See Section 4.6.1.3 of the PMBOK® Guide.2138
21394.6.2 Close Software Project or Phase: Tools and Techniques
2140The tools and techniques for closing a project or phase in Section 4.6.2 of the PMBOK®
2141Guide are applicable to closing a software project product or phase.2142
21434.6.2.1 Expert Judgment
2144See Section 4.6.2.1 of the PMBOK® Guide.2145
21464.6.2.2 Analytical Techniques
2147See Section 4.6.1.2 of the PMBOK® Guide.2148
21494.6.2.3 Meetings
2150See Section 4.6.2.3 of the PMBOK® Guide.2151
21524.6.3 Close Software Project or Phase: Outputs
Page 48
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
48/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
2153See Section 4.6.3 of the PMBOK® Guide for outputs applicable to closing a software project
2154product or phase.2155
21564.6.3.1 Final Product, Service, or Result Transition
2157See Section 4.6.3.1 of the PMBOK® Guide.2158
21594.6.3.2 Organizational Process Assets Updates
2160See Section 4.6.3.2 of the PMBOK® Guide.2161
21625 SOFTWARE PROJECT SCOPE MANAGEMENT
2163As stated in the introduction to Section 5 of the PMBOK® Guide, Project Scope Management
2164 includes the processes required to ensure that the project includes all the work required,
2165 and only the work required, to complete the project successfully.2166
2167This section of the Software Extension to the PMBOK® Guide – Fifth Edition describes the
2168generally accepted principles that are not common to management of most other kinds of
2169projects but are generally accepted principles for managing the scope of software
2170projects. The scope of a software project provides the basis for planning, executing, and
2171measuring and controlling schedule, budget, and resources as well as establishing and
2172maintaining a balance among process attributes (i.e., schedule, budget, personnel,
2173 resources) and development of work products (i.e., requirements, design specifications,
2174 software code, and verification and validation plans and results).2175
2176Project and product scope determine the effort needed to develop or modify a software
2177product; effort is used as the basis to estimate total cost, which includes overhead rates
2178 and the cost of additional resources, such as installation, user training, product
2179documentation, and/or an independent testing facility (or verification and validation
2180 facility). Effort is used as the basis for determining the schedule for a software project
2181or a project iteration, because software development is accomplished by team effort; a
2182project estimated to require 60 person-months of effort might be scheduled as 10 months
2183 for 6 people. See Sections 6 and 7 of this software extension for cost and time management
2184 considerations for software projects.2185
2186Section 2 of this software extension presents the continuum of life cycles for software
2187projects that lie within a spectrum from predictive life cycles to highly adaptive life
2188 cycles. This section of describes the manner in which the scope is managed for various
2189 life cycles within the continuum.2190
2191Figure 5-1 provides an overview of Software Project Scope Management; it is an adaptation
2192of Figure 5-1 in the PMBOK® Guide.2193
Page 49
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
49/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
2194
2195
2196 Figure 5-1. Software Project Scope Management Overview2197
21985.1 Plan Software Project Scope Management
2199Planning scope management for software projects involves determining how the project scope
2200will be defined, validated, and controlled. A scope management plan provides guidance on
2201how scope, for both process and product, will be managed throughout the project. Scope
2202management planning for a software project depends on the life cycle model used to
2203managing the project. Predictive software project life cycles rely on initially collecting
2204 and documenting the software product requirements and developing a top-level design; these
2205 are used as the basis for developing a work breakdown structure. A predictive life cycle
2206 for a software project is most likely to result in a successful project when the product
2207 is of a familiar kind and when stable software requirements can be developed in sufficient
2208detail during project initiation and planning. However, many software projects require
2209 innovations that cannot be initially foreseen and planned, perhaps because the user
Page 50
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
50/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
2210 community is not sure what is needed or how it could be provided, or perhaps new
2211 technology (new hardware, new infrastructure software) is involved, or perhaps
2212 environmental factors such as new policies and regulations are in place. Planning for an
2213 adaptive life cycle, in which the requirements and the product scope evolve together, are
2214 appropriate for these kinds of software projects.2215
22165.1.1 Plan Scope Management: Inputs
2217The inputs for planning the scope of a software project life cycle are typically those
2218presented in the PMBOK® Guide. In addition to those inputs, two additional inputs are
2219 applicable for software projects (see 5.1.1.5 and 5.1.1.6).2220
22215.1.1.1 Project Management Plan
2222See Section 5.1.1.1 of the PMBOK® Guide. A preliminary draft of the project plan is
2223developed and will be refined, based on the project scope.2224
22255.1.1.2 Project Charter
2226See Section 5.1.1.2 of the PMBOK® Guide.2227
22285.1.1.3 Enterprise Environmental Factors
2229See Section 5.1.1.3 of the PMBOK® Guide.2230
22315.1.1.4 Organizational Process Assets
2232See Section 5.1.1.4 of the PMBOK® Guide.2233
22345.1.1.5 Planning Product Scope for Adaptive Life Cycle Projects
2235The inputs for planning, revising, and expanding the product scope on successive
2236 iterations of an adaptive life cycle software project include customer input and the
2237demonstrated results of working software from the previous iteration. Some adjustments to
2238process scope may occur to accommodate the internal organization of the project (as
2239determined by the project team) and the overall scope of the project (as determined by the
2240 customer).2241
22425.1.1.6 Release Planning for Software Projects
2243As illustrated in Figure 5-2, Release planning for adaptive life cycle software projects
2244 (those in the iterative-incremental to highly adaptive part of the life cycle continuum)
2245 can provide an input for scope management.2246
2247As shown, the scope of an overall business goal is specified as a collection of feature
2248 sets. Each feature set is decomposed into a set of product increments that will be
2249developed in an iterative manner; each increment will be tested and demonstrated for
2250 acceptance. In some cases, it may be possible to specify a release plan during the
2251planning process for a software project. In other cases, the release plan may evolve in a
2252 rolling wave manner, as described in Section 5.6.2.3.2253
Page 51
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
51/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
2254
2255
2256 Figure 5-2. Release Planning for an Adaptive Software Project Life Cycle2257
22585.1.2 Plan Scope Management: Tools and Techniques
2259The tools and techniques used to plan the scope of a software project depend on the nature
2260of the life cycle model used; predictive life cycles and adaptive life cycles use
2261different tools and techniques. Techniques for planning the scope of a predictive life
2262 cycle software project include embedding the product structure in the WBS and documenting
2263 the work packages needed to accomplish the software development tasks (see Section 5.2).
2264Plans for scope management for adaptive software project life cycles are inherent in the
2265particular adaptive life cycle used.2266
2267The tools and techniques in Section 5.1.2 of the PMBOK® Guide are equally applicable to
2268planning scope management for a software project.
2269
22705.1.2.1 Expert Judgment
2271See Section 5.1.2.1 of the PMBOK® Guide.2272
22735.1.2.2 Meetings
2274See Section 5.1.2.2 of the PMBOK® Guide.2275
22765.1.3 Plan Scope Management: Outputs
2277The outputs for planning scope management of a predictive software project life cycle
2278 include the scope management plan and the requirements management plan, as indicated in
2279Section 5.1.3 of the PMBOK® Guide plus a revised project plan that includes a release plan
2280 (see Figure 5-2) or a WBS containing the top-level activities and product components (see
2281Figure 5-3), plus a template for the WBS work packages documented using a template which
2282may take the form illustrated in Figure 5-4 or some other standardized form.2283
2284The plan for scope management of an adaptive software project life cycle is implicit in
2285 the adaptive life cycle model used, as explained and illustrated in Section 5.3.2.4;
Page 52
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
52/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
2286outputs may include a release plan as illustrated in Figure 5-2.2287
2288The two outputs for planning scope management in Section 5.1.3 of the PMBOK® Guide
2289 (5.1.3.1 and 5.1.3.2) are applicable outputs for planning scope management of software
2290projects. They are the scope management plan and the requirements management plan.2291
22925.1.3.1 Scope Management Plan
2293See 5.1.3.1 of the PMBOK® Guide.2294
22955.1.3.2 Requirements Management Plan
2296See 5.1.3.2 of the PMBOK® Guide.2297
22985.2 Collect Software Requirements
2299Software requirements provide the basis for defining and managing the software product
2300 scope and also provide a basis for process activities including determination of resources
2301needs, schedule, and budget [16]. Predictive life cycles for software projects collect the
2302 software requirements during project initiation and planning, to the extent possible;
2303predictive collection of software requirements will be most successful for projects of a
2304 familiar kind and when there is experience in working with the customer (who may be either
2305 internal or external to the organization). However, many (perhaps most) software projects
2306 are characterized by uncertainty and unknown factors during project initiation and
2307planning that results in disruptive, unplanned revision of requirements and work processes
2308 throughout the project lifetime. Collection of requirements in an emergent manner as a
2309 software project evolves is one of the primary motivations for using an adaptive life
2310 cycle model.2311
23125.2.1 Collect Software Requirements: Inputs
2313For predictive life cycles, the five inputs to collecting software requirements are as
2314 stated in Section 5.2.1 of the PMBOK® Guide; they include the plans for scope management,
2315 requirements management, and stakeholder management plus the project charter and the
2316 stakeholder register.2317
2318As previously stated, the inputs for collecting software requirements when using an
2319 adaptive software project life cycle are inherent in the adaptive model used. The inputs
2320 that determine requirements for each iterative cycle include the results of testing and
2321demonstrating the current working version of the software plus the customer’s directions,
2322which may take the form of “stories” or features selected from a backlog of users’
2323 requirements.2324
23255.2.1.1 Scope Management Plan
2326See Section 5.2.1.1 of the PMBOK® Guide.2327
23285.2.1.2 Requirements Management Plan
2329See Section 5.2.1.2 of the PMBOK® Guide.2330
23315.2.1.3 Stakeholder Management Plan
2332See Section 5.2.1.3 of the PMBOK® Guide.
Page 53
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
53/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
2333
23345.2.1.4 Project Charter
2335See Section 5.2.1.4 of the PMBOK® Guide.2336
23375.2.1.5 Stakeholder Register
2338See Section 5.2.1.5 of the PMBOK® Guide.2339
23405.2.2 Collect Software Requirements: Tools and Techniques
2341The tools and techniques listed and described in Section 5.2.2 of the PMBOK® Guide are
2342 equally applicable for both predictive and adaptive software project lifecycles.
2343Prototyping is a particularly effective technique for collecting requirements when using a
2344predictive life cycle. Ongoing demonstration of working software is a primary technique
2345 for illustrating progress and collecting the next set of requirements to be implemented
2346when using an adaptive life cycle.2347
23485.2.2.1 Interviews
2349See Section 5.2.2.1 of the PMBOK® Guide.2350
23515.2.2.2 Focus Groups
2352See Section 5.2.2.2 of the PMBOK® Guide.2353
23545.2.2.3 Facilitated Workshops
2355See Section 5.2.2.3 of the PMBOK® Guide.2356
23575.2.2.4 Group Creativity Techniques
2358See Section 5.2.2.4 of the PMBOK® Guide.2359
23605.2.2.5 Group Decision-Making Techniques
2361See Section 5.2.2.5 of the PMBOK® Guide.2362
23635.2.2.6 Questionnaires and Surveys
2364See Section 5.2.2.6 of the PMBOK® Guide.2365
23665.2.2.7 Observations
2367See Section 5.2.2.7 of the PMBOK® Guide.2368
23695.2.2.8 Prototypes
2370See Section 5.2.2.8 of the PMBOK® Guide.2371
Page 54
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
54/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
23725.2.2.9 Benchmarking
2373See Section 5.2.2.9 of the PMBOK® Guide.2374
23755.2.2.10 Context Diagrams
2376See Section 5.2.2.10 of the PMBOK® Guide.2377
23785.2.2.11 Document Analysis
2379See Section 5.2.2.11 of the PMBOK® Guide.2380
23815.2.3 Collect Software Requirements: Outputs
2382The outputs in Section 5.2.3 of the PMBOK® Guide are applicable for outputs for collecting
2383 software requirements. Documentation guidelines for software requirements are presented in
2384 (ISO/IEC/IEEE Standard 830 [17] and ISO/IEC/IEEE Standard 1362 [18]). For adaptive life
2385 cycles, the customer is the source of evolving software requirements and the output from
2386 collecting software requirements provides the input for the next iterative cycle.2387
23885.2.3.1 Requirements Documentation
2389See Section 5.2.3.1 of the PMBOK® Guide. Requirements traceability is particularly
2390 important for software projects because of the lack of physical characteristics of
2391 software2392
23935.2.3.2 Requirements Traceability Matrix
2394See Section 5.2.3.1 of the PMBOK® Guide. Traceability provides visibility between software
2395 requirements, intermediate work products (e.g., design documentation, test plans, test
2396 results) and the deliverable product.2397
23985.3 Define Software Project and Product Scope
2399According to Section 5.3 of the PMBOK® Guide, Define Scope is the process of developing a
2400detailed description of the project and product. The key benefit of this process is that
2401 it describes the project boundaries. The inputs, tools and techniques, and outputs for
2402defining the scope of software process and product differ, depending on the position of
2403 the selected software project life cycle within the life cycle continuum. The nature of
2404 software and the fact that software development is the result of coordinated human effort
2405 results in a close integration of process and product scope.2406
2407The PMBOK® Guide states that since all of the requirements identified in Collect
2408Requirements will not be included in the project, Define Scope involves choosing the
2409 requirements that will be part of the product scope. For software projects, this issue is
2410 commonly dealt with by prioritizing the requirement using the criteria of value-added and
2411 the wants and needs of the customer and user communities. Risks, assumptions, and
2412 constraints are also analyzed and added or updated as necessary when defining the software
2413process and product scope.2414
24155.3.1 Define Software Project and Product Scope: Inputs
2416For predictive software projects, the inputs described in the PMBOK® Guide and listed
2417below are used as inputs for defining the detailed product and project scope. For adaptive
2418projects, the project scope is defined by the selected adaptive life cycle; the product
Page 55
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
55/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
2419 scope evolves during iterative development of the product. The project charter and
2420organizational assets provide inputs for defining software project and product scope for
2421 all software project life cycles within the software project life cycle continuum.2422
24235.3.1.1 Scope Management Plan
2424See Section 5.3.1.1 of the PMBOK® Guide.
2425
24265.3.1.2 Project Charter
2427See Section 5.3.1.2 of the PMBOK® Guide.2428
24295.3.1.3 Requirements Documentation
2430See Section 5.3.1.3 of the PMBOK® Guide.2431
24325.3.1.4 Organizational Process Assets
2433See Section 5.3.1.4 of the PMBOK® Guide.2434
24355.3.2 Define Software Project and Product Scope: Tools and Techniques
2436The tools and techniques listed in Section 5.3.2.1 through 5.3.2.4 are applicable for
2437defining the scope of a software project and product. In addition to these, see Sections
24385.3.2.5 through 5.3.2.7 for tools and techniques specific to software. For predictive life
2439 cycles, a primary tool for defining software project and product scope is the work
2440breakdown structure (WBS). The primary technique is documentation of WBS tasks using work
2441packages. Project and product scope evolve throughout adaptive life cycle projects.2442
24435.3.2.1 Expert Judgment
2444See Section 5.3.2.1 of the PMBOK® Guide.2445
24465.3.2.2 Product Analysis
2447See Section 5.3.2.2 of the PMBOK® Guide.2448
24495.3.2.3 Alternatives Generation
2450See Section 5.3.2.3 of the PMBOK® Guide.2451
24525.3.2.4 Facilitated Workshops
2453See Section 5.3.2.4 of the PMBOK® Guide.2454
24555.3.2.5 Using a Software WBS to Define Predictive Scope of Project and Product
2456The top level of a WBS depicts the full scope, at a high level, of all the work required,
2457 and only the work required, to complete the project successfully, as illustrated in Figure
24585-3. The top-level activities are decomposed in a hierarchical manner; the lowest level
2459 elements of the WBS are elements of work to be performed (the tasks).2460
Page 56
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
56/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
2461Figure 5-3 does not adequately illustrate the relationships between Manage Project and the
2462other elements of project scope. The organizational chart for the project would show the
2463other elements of project scope as subordinate to Manage Project and would indicate the
2464 relationships among the project manager, the software architect/lead designer (technical
2465 lead), the customer, and the project team or teams. In some instances, the project manager
2466may be a staff person who provides support for the software architect/lead designer and
2467 the project. In those cases, the architect/designer would occupy the superior position in
2468 the organizational chart; this is often the case for adaptive software projects.2469
2470Some of the software components to be included in a software product may be developed
2471during the software project, some may exist in a library of software components, some may
2472be acquired as open source components, and some may be procured from a software vendor or
2473 subcontractor. However, preexisting components typically require modifications to satisfy
2474 the product requirements, and thus are seldom used “as is.” In all cases, the scope of a
2475predictive software project includes explicit integration, verification, and validation of
2476 the initially developed and preexisting components that form the software product, as well
2477 as system-level verification and validation of the final product.2478
2479The scope of work needed to develop, otherwise obtain, and integrate software components
2480 can be embedded in the software project WBS, as depicted in Figure 5-3, which illustrates
2481 a partial WBS for developing the software for an automated teller machine; the product
2482 components are indicated in bold font; the product scope is thus embedded in the WBS. For
2483purposes of illustration, only the Develop Software element of the WBS is partially
2484decomposed.2485
2486
2487 Figure 5-3. Partially Decomposed WBS for an Automated Teller Machine Project2488
2489The PMBOK® Guide distinguishes between project scope and product scope. For software
2490projects, the two scopes are entwined because of the nature of software and the way in
2491which software is developed or modified by closely coordinated work tasks. The technique
2492of embedding the product structure within a software WBS illustrates the close connection
2493between project scope and product scope for software projects. Adaptive software project
2494 life cycles also entwine project scope and product scope, as discussed below.2495
Page 57
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
57/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
24965.3.2.6 Using Work Packages to Document Predictive Scope
2497Traditional projects that develop physical artifacts typically use work packages to
2498document the tasks (i.e., the lowest level elements) in the work breakdown structure. Work
2499packages are also used to document the tasks in a software project WBS. The primary
2500 factors documented in a software work package are estimated effort (expressed as the
2501product of personnel and duration), estimated duration, software components to be
2502developed or modified, the acceptance criteria for the software components, predecessor
2503 and successor tasks, and risk factors that may inhibit successful completion of the
2504 software component or components using the allocated effort and additional resources. A
2505 template for documenting software WBS work packages is presented in Figure 5-4.2506
2507
2508 Figure 5-4. Sample WBS Work Package Template for Predictive Software Projects2509
2510Because software estimation is an imprecise process, predictive life cycles for software
2511projects typically use two or more techniques to develop estimates. For example, a
2512 top-down estimate based on analogies and historical data may be used to determine the
2513 scope of overall effort and schedule; these estimated values are allocated to the various
2514 elements of the WBS down to the task level. Bottom-up estimation based on expert judgment
2515 (perhaps using a Delphi approach) may be used to estimate each task; these estimates are
2516 aggregated into a top-level estimate. Variations in the (two or more) estimates are then
2517 reconciled. Note that estimates of effort and resource needs can be obtained from a work
2518package using the information in Figure 5-4. A schedule for a collection of work packages
2519 can be constructed using the predecessor and successor information in each work package.
2520 (See Sections 6 and 7 of this software extension for additional information on time and
2521 cost estimation for software projects.)2522
2523Effort is the primary cost factor for most software projects because software is the
2524 result of intellectual work tasks. For predictive life cycles, effort is typically
2525 allocated to work packages in a top-down manner, based on a reconciled estimate of total
2526 effort. Effort, being the product of people and time, is decomposed into personnel and
2527 time as follows: a specified number of people having specified skills and the estimated
2528 time duration needed to complete the work package. For example, a two-person-week task
2529 could be specified as one person for two weeks or two people for one week (but not 10
2530people for one day). Additional resources, such as facilities and software tools, are also
2531 specified in each software work package, as needed.
Page 58
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
58/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
2532
2533The documented work packages determine the scope of work activities for a predictive
2534 software development project. The total project scope for a predictive software project
2535 life cycle includes the collective scope of the work packages plus the scopes of the other
2536 activities denoted at the top level of the WBS.2537
25385.3.2.7 Defining Adaptive Software Project and Product Scope
2539The approach to defining project and product scope for an adaptive software project life
2540 cycle is implicit in the adaptive life cycle model planned for the project. As described
2541 in Section 2.4, the process scope of an iterative-incremental life cycle on the adaptive
2542 side of the life cycle continuum includes analysis, design, design partitioning, and
2543 constructing, testing, and demonstrating progressive increments of growing product
2544 capabilities on each iterative cycle of software construction, perhaps using rolling wave
2545 elaboration of the WBS to progressively define the product scope as the project evolves
2546 and as the design and design partitioning are revised (see Section 5.6.2.2 for a
2547discussion of rolling wave elaboration of a software WBS).2548
2549 In adaptive life cycle software projects, the scope of the product is determined as a
2550 succession of outcomes; small increments (“stories”) deliver features that build toward a
2551business goal or product vision in a cascading manner. The outcomes may be based on a
2552 release plan, as illustrated in Figure 5-2 or they may emerge as the project evolves. As
2553 the project evolves, the details of product scope are clarified while maintaining
2554 integrity with the desired outcome.2555
2556The translation of Goals to Features to Product Increments is illustrated in Figure 5-5,
2557where incremental implementation of a succession of features is implemented as a sequence
2558of small increments.2559
2560
Page 59
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
59/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
2561 Figure 5-5. Delivery of Functionality as a Succession of Product Increments2562
2563For an adaptive project life cycle model, the process scope expands to accommodate
2564 frequent iterations of product construction, testing and refactoring, and demonstration,
2565 as illustrated in Figure 5-6 for a highly adaptive software project life cycle project
2566 (see also Figure 2-7 and the related discussion). The product scope expands during the
2567 iterations, at the direction of the customer.2568
2569The scope of requirements that can be implemented during an adaptive development cycle is
2570based on the story or stories to be implemented, the specified time period, and the
2571productivity of the development team. The estimated productivity is based on accumulated
2572 experience using measures such as velocity and burn down rate. Short-duration development
2573 cycles provide rapid feedback and the ability to easily revise and adjust the product
2574 scope based on demonstrations of working software.2575
2576
2577 Figure 5-6. A Highly Adaptive Life Cycle for a Software Project2578
2579Additional aspects of the adaptive life cycle illustrated in Figure 5-6 are the
2580development of requirements-based test scenarios before writing the software code and
2581 refactoring3 of the software structure, which may be necessary to better accommodate the
2582 code for the additional features being added. Also note in Figure 5-6 the option of
2583delivering working software into the user environment, at the end of each development
2584 cycle, which is possible because each software version, after initial start-up, results in
2585working, deliverable software.2586
2587Another aspect common to all adaptive life cycles is emphasis on a learning environment in
2588which customers and users clarify and prioritize requirements in an emergent manner, based
2589on value-adding priorities and periodic demonstrations of working software.
2590
25915.3.3 Define Software Process and Product Scope: Outputs
2592The outputs for defining scope in Section 5.3.3 of the PMBOK® Guide are equally applicable
2593 for defining software process and product scope. The modifications to 5.3.3.1 also
2594 applies.2595
25965.3.3.1 Software Project Scope Statement
2597For both predictive and adaptive software project life cycles, the statement of software
2598project scope describes deliverables and the work required to produce them. The project
2599 scope statements for both predictive and adaptive software project life cycle projects
Page 60
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
60/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
2600 typically include a statement of assumptions, constraints on the project plus exclusions
2601 for the project, and product attributes that are outside the project’s boundaries.
2602
2603Product acceptance criteria should also be included in the project scope statement. For
2604predictive life cycles, the acceptance criteria are provided in each work package that
2605produces a work product (see Figure 5-4). For adaptive life cycles, the acceptance
2606 criteria for the next product increment are stated at the beginning of the iterative cycle
2607 that will produce the increment. In addition, the process scope may evolve for adaptive
2608 life cycle projects. In an ideal predictive life cycle the scope statement would be a
2609 static document, although this is rarely the case. The project scope statement is planned
2610 to be an evolving document for adaptive life cycle software projects. Planning for the
2611 inevitable evolution of project scope is a primary factor that distinguishes adaptive
2612 software project life cycles from predictive life cycles.2613
26145.3.3.2 Project Documents Updates
2615See Section 5.3.3.2 of the PMBOK® Guide.2616
26175.4 Create Software WBS
2618The inputs, tools and techniques, and outputs for Create WBS in the PMBOK® Guide are
2619 equally applicable to creating work breakdown structures for predictive software project
2620 life cycles. Some considerations for developing a WBS for a predictive software project
2621 include:2622
2623The WBS can be developed top-down, by first specifying the project scope at the top level
2624 and decomposing each top element into details; or by first identifying low-level tasks to
2625be performed and grouping them into successively larger groupings (activities); or by
2626working “middle out” by identifying intermediate-level activities and decomposing them
2627downward and grouping them upward. In practice, all three approaches are typically used to
2628produce the WBS. Predefined templates for work breakdown structures and work packages,
2629 tailored to fit local needs, make the task of constructing a software WBS much easier than
2630 starting “from scratch.”2631
2632The PMBOK® Guide distinguishes between organizing a WBS by project phase or by product
2633deliverables. Using the technique of embedding the product structure in the WBS, as
2634described in Sections 5.3.2.5 and 5.6.2.2 removes this distinction for software projects.2635
2636Section 5.4.3.1 of the PMBOK® Guide indicates that a WBS dictionary should be developed as
2637part of the scope baseline. The work package template provided in Figure 5-4 of this
2638 software extension contains most of the information needed as inputs for a WBS data
2639dictionary, as specified in the PMBOK® Guide.
2640
26415.4.1 Create WBS: Inputs
2642The inputs in Section 5.4.1 of the PMBOK® Guide for creating a WBS are equally applicable
2643 for creating a software WVBS.2644
26455.4.1.1 Scope Management Plan
2646See Section 5.4.1.1 of the PMBOK® Guide.2647
26485.4.1.2 Project Scope Statement
2649See Section 5.4.1.2 of the PMBOK® Guide.
Page 61
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
61/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
2650
26515.4.1.3 Requirements Documentation
2652See Section 5.4.1.3 of the PMBOK® Guide.2653
26545.4.1.4 Enterprise Environmental Factors
2655See Section 5.4.1.4 of the PMBOK® Guide.2656
26575.4.1.5 Organizational Process Assets
2658See Section 5.4.1.5 of the PMBOK® Guide.2659
26605.4.2 Create WBS: Tools and Techniques
2661The tools and techniques for creating a WBS described in the PMBOK® Guide are equally
2662 applicable for creating a software WVBS2663
26645.4.2.1 Decomposition
2665See Section 5.4.2.1 of the PMBOK® Guide. The decomposition technique for creating a WBS,
2666 as described is equally applicable for creating a software WVBS.2667
26685.4.2.2 Expert Judgment
2669See Section 5.4.2.2 of the PMBOK® Guide.2670
26715.4.3 Create WBS: Outputs
2672The outputs for creating a WBS in Section 5.4.3 of the PMBOK® Guide are equally applicable
2673 for creating a software WVBS. In addition the software WBS is an output from creating a
2674 software WVBS.2675
26765.4.3.1 Scope Baseline
2677See Section 5.4.3.1 of the PMBOK® Guide.2678
26795.4.3.2 Project Documents Updates
2680See Section 5.4.3.2 of the PMBOK® Guide.2681
26825.5 Validate Scope
2683Validate Scope covers formalizing acceptance of the completed project deliverables. In
2684 software engineering, a distinction is made between verification and validation.
2685Verification is concerned with determining, in an objective manner, that the deliverable
2686 software is correct, complete, and consistent with respect to the product requirements,
2687design constraints, and other product parameters. Validation is concerned with
2688determining, in an objective manner, that the delivered software satisfies the needs and
2689 expectations of customers, users, and other stakeholders when installed in the operational
2690 environment. Colloquially, verification answers the question “did we build the software
2691 correctly?” and validation answers the question, “did we build the correct software?”
Page 62
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
62/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
2692
26935.5.1 Validate Scope: Inputs
2694 Inputs to validating the scope of software deliverables includes all of the deliverables,
2695 as specified in the scope plan. The primary deliverable is working software but other
2696deliverables may include user training materials and usage information, installation and
2697operating instructions, and guidance for maintainers. The intended users, operations, and
2698maintainers are those who validate these inputs for acceptability. These work products may
2699be in textual hard copy or accessible online. In some cases a suite of development work
2700products including some or all of requirements, design documentation, traceability
2701matrices, and test plans and test results may be inputs for validating scope.2702
2703For predictive software project life cycles, inputs for validating the delivered software
2704 include the requirements, one or more requirements traceability matrices, design
2705documentation, the software code, and the software validation plan. For software, a
2706distinction is made between the external stakeholders’ requirements, which are typically
2707documented in a Concept of Operations (ConOps)4 and the technical specifications, which
2708 are the translation (to the extent possible) of external requirements into objectively
2709quantified parameters that must be satisfied in order to satisfy the external
2710 requirements. The ConOps may also be known as an Operational Concepts Document (OCD), a
2711marketing analysis, or some equivalent name.2712
2713 ISO/IEC/IEEE Standards 830] and 1362] provide guidance for preparing the ConOps and the
2714 technical specifications. A traceability matrix is typically used to trace between the
2715 external stakeholders’ requirements and the technical specifications and one or more
2716 traceability matrices is used to establish the correspondences between technical
2717 specifications and design documentation, software code, details of the validation plan,
2718 and validation results.2719
2720The five inputs for validating scope in Section 5.5.1.1 to 5.5.1.6 of the PMBOK® Guide are
2721 applicable for validating the scope of predictive software project life cycle projects.
2722They are the scope management plan, scope baseline, requirements documentation,
2723requirements traceability matrix, validated deliverables, and work performance data.
2724
2725The additional input described in 5.5.1.6 is concerned with inputs for validating the
2726 scope of adaptive software project life cycle projects.2727
27285.5.1.1 Project Management Plan
2729See Section 5.5.1.1 of the PMBOK® Guide.2730
27315.5.1.2 Requirements Documentation
2732See Section 5.5.1.1 of the PMBOK® Guide.2733
27345.5.1.3 Requirements Traceability Matrix
2735See Section 5.5.1.1 of the PMBOK® Guide.2736
27375.5.1.4 Verified Deliverables
2738See Section 5.5.1.1 of the PMBOK® Guide.2739
27405.5.1.5 Work Performance Data
Page 63
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
63/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
2741See in Section 5.5.1.1 of the PMBOK® Guide.2742
27435.5.1.6 Inputs to Validate Scope of an Adaptive Software project life cycle Project
2744For adaptive software project life cycle projects, validation occurs incrementally during
2745 and at the end of each iterative cycle; the inputs are the test cases and demonstration
2746 scenarios developed before and during each iterative cycle. Inputs for adaptive life
2747 cycles may include formally documented requirements, one or more requirements traceability
2748matrices, design documentation, and the software code, all of which are updated
2749 incrementally as they evolve during iterative cycles. For example, user stories and the
2750 associated technical specifications are typically recorded and tracked using a version
2751 control tool that captures them, iteration by iteration. A formal validation plan may be
2752developed initially and applied throughout the project life cycle or validation may be an
2753 element that is built into each iterative cycle without a formal validation plan.2754
2755For adaptive software lifecycles, some validation tools and techniques, such as formal
2756 inspections and demonstrations, are applied by, and the results observed by the software
2757developers. End-of-cycle demonstrations of working software are conducted for the
2758designated customer and appropriate external stakeholders.2759
27605.5.2 Validate Scope: Tools and Techniques
2761The tools and techniques for validating scope in Section 5.5.2 of the PMBOK® Guide
2762 (5.5.2.1 and 5.5.2.2) are applicable for validating the scope of both predictive and
2763 adaptive software project life cycle projects. Testing and demonstrations are also useful
2764 tools and techniques for validating the scope of a software product. A software inspection
2765 is a formalized review process that involves preparation for the inspection; the roles to
2766be played by the inspectors; checklists and forms; a moderated meeting; and documented
2767 follow up activities. Other forms of reviews include peer reviews of working software,
2768management reviews of validation status, and reviews with external stakeholders.2769
2770 Ideally, a software test involves preparation of test inputs, test conditions, and an
2771objective statement of specified test results; execution of the test in a specified
2772 environment under specified conditions; and observation and recording of the test results.2773
2774A validation demonstration differs from a validation test, in that a test has objectively
2775 stated success criteria whereas a demonstration relies on the subjective observations of
2776witnesses to determine the success or failure of the demonstrated software features. As
2777 stated above, some demonstrations are conducted for developers and some are for the
2778designated customer and appropriate external stakeholders.2779
2780For predictive life cycle software projects, validation is a major phase of the software
2781project that occurs at the end of the software development or software modification
2782project. For an iterative-incremental life cycle project, validation occurs at the end of
2783 each iteration and at the end of the project. For adaptive life cycles, validation occurs
2784during and at the end of each iterative cycle. A major validation effort may accompany
2785delivery of the final product, at the end of the final iterative cycle.2786
27875.5.2.1 Inspection
2788See Section 5.5.2.1 of the PMBOK® Guide.2789
27905.5.2.2 Group Decision-Making Techniques
2791See Section 5.5.2.2 of the PMBOK® Guide.
2792
Page 64
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
64/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
27935.5.3 Validate Scope: Outputs
2794The outputs for Validate Scope from the PMBOK® Guide are applicable to software.2795
2796Change requests may be handled informally or may be handled by a process for review and
2797disposition using a Perform Integrated Change Control process (Section 4.5 of the PMBOK®
2798Guide), depending on the formality of the validation process.2799
28005.5.3.1 Accepted Deliverables
2801See Section 5.5.3.1 of the PMBOK® Guide.2802
28035.5.3.2 Change Requests
2804See Section 5.5.3.2 of the PMBOK® Guide. Change requests may be handled informally or may
2805be handled by a process for review and disposition using a Perform Integrated Change
2806Control process (Section 4.5 of the PMBOK® Guide), depending on the formality of the
2807validation process.2808
28095.5.3.3 Work Performance Information
2810See Section 5.5.3.3 of the PMBOK® Guide.2811
28125.5.3.4 Project Documents Updates
2813See Section 5.5.3.4 of the PMBOK® Guide.2814
28155.6 Control Scope
2816Control Scope is the process of monitoring the status of project and product scope and
2817managing changes to the scope baseline. The inputs, tools and techniques, and outputs used
2818 to control the scope of a software project vary with the life cycles along the continuum
2819of life cycle models.2820
28215.6.1 Control Scope: Inputs
2822The inputs for controlling scope in Section 5.6.1 of PMBOK® Guide), are applicable to
2823 controlling the scope of a predictive life cycle software project. A software project
2824based on an iterative-incremental life cycle relies on demonstrations of increasing
2825product capability at the end of the iterations as the primary input for assessing and
2826 controlling scope. Iterative-incremental projects on the predictive side of the life cycle
2827 continuum use more formal mechanisms to obtain inputs for scope control than do
2828 iterative-incremental projects on the adaptive side of the continuum.2829
2830Adaptive life cycle projects typically use short iteration cycles and frequent
2831demonstrations of progress to provide the input for ongoing control of process and product
2832 scope. The customer, in consultation with the software development team, determines the
2833 requirements and the time period for developing each successive version of the product.
2834The period of time boxing for iterations typically varies from one day to a few weeks,
2835depending on the customer’s wishes and the particular adaptive life cycle being used.2836
28375.6.1.1 Project Management Plan
2838See Section 5.6.1.1 of the PMBOK® Guide.
Page 65
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
65/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
2839
28405.6.1.2 Requirements Documentation
2841See Section 5.6.1.2 of the PMBOK® Guide2842
28435.6.1.3 Requirements Traceability Matrix
2844See Section 5.6.1.3 of the PMBOK® Guide.2845
28465.6.1.4 Work Performance Data
2847See Section 5.6.1.4 of the PMBOK® Guide.2848
28495.6.1.5 Organizational Process Assets
2850See Section 5.6.1.5 of the PMBOK® Guide.2851
28525.6.2 Control Scope: Tools and Techniques
2853Predictive life cycles for software projects typically use traditional project management
2854 technique for controlling scope, including milestone reviews, change requests, and change
2855 control boards, in addition to variance analysis, as described in Section 5.6.2 of the
2856PMBOK® Guide. Additional tools and techniques for controlling the scope of a software
2857project are provided in Sections 5.6.2.2 and 5.6.2.3.2858
2859As previously stated, a predictive, plan-driven life cycle for a software project is most
2860 likely to result in a successful project when the product is of a familiar kind, when
2861 stable software requirements can be developed in sufficient detail during project
2862 initiation and planning, and when the customer is a familiar one. However, many software
2863projects require innovations that cannot be initially foreseen and planned, perhaps
2864because the user community is not sure what is needed or how it could be provided, because
2865 the customer is new, or perhaps because new technology (new hardware, new infrastructure
2866 software) is involved.2867
2868An important aspect of adaptive life cycles for software projects is that the customer, in
2869 consultation with the development team, determines the scope of product elements to be
2870 included in each development cycle. The requirements are scoped to accommodate the time
2871 and resources available to construct the software for those requirements. The scope of the
2872product continues to expand during each development cycle until the customer requirements
2873 are fully satisfied, or until time and resources are exhausted. In the latter case, the
2874working, deliverable software will incorporate the most value-adding user features, which
2875were specified by the customer as input to the iterative cycles.2876
2877The overall project scope, including schedule and budget for an adaptive life cycle
2878project, may be fixed or may grow or shrink adaptively based on value-added considerations
2879of continuing or terminating product development. To reiterate, an adaptive software
2880project can deliver the software at the end of any iterative cycle after initial startup
2881because working deliverable software at the end of each iteration is a fundamental aspect
2882of adaptive software project life cycles.2883
2884 It should also be noted that the scope of an adaptive life cycle includes other elements
2885of project scope as appropriate to the needs of the project, such as a scope management
2886plan, initial architectural design, independent verification and validation, configuration
2887management, and quality assurance and quality control. The continuum of software project
2888 life cycles is not a thin line, but is multidimensional to accommodate additional aspects
2889of scope control.
Page 66
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
66/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
2890
28915.6.2.1 Variance Analysis
2892See Section 5.6.2.1 of the PMBOK® Guide.2893
28945.6.2.2 Evolve Predictive Scope Using Rolling Wave Planning
2895Every software project results in a unique product, either new or modified, because
2896 replication of existing software is a trivial process, as compared to replication of
2897physical artifacts. Most software projects thus require innovation and creative problem
2898 solving to satisfy new and evolving needs. The scope of the project and the product thus
2899 evolve during the project lifetime. For predictive software projects, the details of scope
2900 evolve (within the constraints of overall scope) by evolving the WBS in a rolling wave
2901manner; increased understanding of the problem to be solved permits elaboration of the
2902WBS. Some rolling wave modifications of a software project WBS may be accomplished within
2903 the overall scope constraints of schedule, budget, resources, and technology, while other
2904modifications may require renegotiation of the scope constraints.2905
2906Rolling wave elaboration of a software WBS is typically accomplished periodically, perhaps
2907monthly, to accommodate increased understanding of the problem to be solved. Rolling-wave
2908 elaboration also may be accomplished as circumstances dictate, such as changes to
2909 requirements, schedule, budget, resources, or technology.2910
2911An example of rolling wave elaboration of the WBS for the ATM project depicted in Figure
29125-3 is illustrated in Figure 5-7, where the details of building the financial transaction
2913 component have been added to Figure 5-3, perhaps after some prototyping and feasibility
2914 analysis. The work package for the Financial Transaction component in Figure 5-3 is
2915decomposed in Figure 5-7 into work packages for the four subordinate software components
2916plus the FINAT integration task. Note, as before, that the product components are denoted
2917 in boldface font. Also, note the decision to reuse existing recorder software from another
2918 software product. Software component development and integration may progress in an
2919 incremental manner before all of the components are completed. This approach would likely
2920be used for iterative-incremental life cycles on the predictive side of the predictive to
2921 adaptive continuum (see Section 2.4 of this extension).2922
2923
Page 67
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
67/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
2924 Figure 5-7 . Rolling Wave Elaboration of the ATM WBS in Figure 5-3.2925
2926 In summary, predictive software project life cycles for software projects attempt to
2927 initially develop software requirements that are complete, correct, consistent, and
2928detailed. The requirements provide the basis for determining the scope of the project and
2929 for developing the WBS and the work packages. Project scope is then managed by carefully
2930 controlling changes to the software requirements and the work activities need to implement
2931 those requirements. The impact of changes to product requirements on the project schedule,
2932budget, resources, and technology may require revision of the project scope and is
2933 reflected in changes to the WBS. Change control boards and a version control system are
2934 typically utilized to manage the changing scope of a software project when using a
2935predictive software project life cycle.2936
29375.6.2.3 Evolve Adaptive Scope Using Rolling Wave Planning
2938The scope of adaptive life cycle software projects can also evolve in a rolling wave
2939manner, as illustrated in Figure 5-8, which is the adaptive equivalent of a rolling wave
2940WBS. The “boxes” in each quarter (Q1 – Q4) are increments of functionality, as shown in
2941Figure 5-2.2942
2943
2944 Figure 5-8. Rolling Wave Elaboration for an Adaptive Software project life cycle Project2945
2946As shown, a business goal may be partially realized by a function (a set of features) that
2947 is decomposed into increments during Q1. The “rising curve” indicates planning for Q2
2948during Q1. The next feature set (function) is instantiated in Q2 and while the Q3 features
2949 are being planned. The cycle continues until the business goal is satisfied.2950
29515.6.3 Control Scope: Outputs
Page 68
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
68/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
2952The outputs for controlling scope in Section 5.6.3 of the PMBOK® Guide are applicable to
2953 controlling the scope of a software project.2954
2955For software projects, the outputs of scope control vary with the life cycle used along
2956 the continuum of software project life cycle models. For predictive life cycles, the
2957primary outputs of scope control are the decisions of the change control board to deny or
2958 accept change requests (the project manager and the software architect are members of the
2959CCB); acceptance may be scheduled for immediate or delayed response. For adaptive life
2960 cycles, the primary output of scope control is the decision of the customer concerning the
2961next set of requirements to be implemented or the changes to be made to the currently
2962working software. The development team may, in consultation with the customer, spend the
2963next interim period modifying the software architecture and doing significant refactoring
2964of the existing software base before continuing the iterative software development cycles.2965
2966 Independent of the life cycle used within the continuum of life cycles, the output of
2967 scope control may require the project manager, higher management, and the customer (or
2968 customers) to make significant changes to process parameters (schedule, budget, resources)
2969 and product parameters (requirements, technology, mission). These changes may be required
2970by factors that are beyond the control of the project manager, such as a changing
2971operational environment, changes in the organization’s strategic vision, changes in
2972 technology or infrastructure, or changes to competitors’ products.2973
29745.6.3.1 Work Performance Information
2975See Section 5.6.3.1 of the PMBOK® Guide.2976
29775.6.3.2 Change Requests
2978See Section 5.6.3.2 of the PMBOK® Guide.2979
29805.6.3.3 Project Management Plan Updates
2981See Section 5.6.3.3 of the PMBOK® Guide.2982
29835.6.3.4 Project Documents Updates
2984See Section 5.6.3.4 of the PMBOK® Guide.2985
29865.6.3.5 Organizational Process Assets Updates
2987See Section 5.6.3.5 of the PMBOK® Guide.2988
2989
29906 Software Project Time Management
2991Section 6 of the PMBOK® Guide includes seven processes that constitute Project Time
2992Management, which as stated in the introduction to Section 6 include the processes
2993 required to manage the timely completion of the project. This section of the Software
2994Extension to the PMBOK® Guide – Fifth Edition indicates the activities in the PMBOK® Guide
2995 that are applicable to time management for software projects and describes approaches that
2996 are especially important for time management of software projects.2997
2998Project Time Management for software projects is driven by risk, resource availability,
2999business value, and the scheduling method(s) used. Software project schedules should
3000 remain flexible throughout the life cycle of a software project to adjust to evolving
Page 69
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
69/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
3001 stakeholder understanding of value and risk. Understanding the different scheduling
3002methods and selecting one or more that are appropriate for dealing with scheduling risks
3003of a software project are critical for success. Because most of the development cost for a
3004 software project is human resource effort, and because effort is the product of people and
3005 time, this section on software project time management is closely linked to Section 7 of
3006 this software extension.3007
3008Key time management decisions depend on the schedule management plan that selects a
3009 scheduling methodology, a scheduling tool, and sets the format and establishes criteria
3010 for developing and controlling the project schedule. Scheduling methods, effort
3011 estimation, and time management procedures that are appropriate for software projects are
3012discussed in this section. All of these require life cycle (see Section 2.4) and scope
3013 (see Section 5) decisions that support their implementation.3014
3015Primary factors in selecting a scheduling method are risk, project environment, product
3016 architecture, and the different value propositions associated with each software
3017 capability to be implemented.3018
3019Selecting a scheduling method, like most software decisions, should consider the risks
3020 associated with the project and the environment, including organization culture and
3021organizational process assets. Using risk to determine the scheduling method is dependent
3022on the risk-related processes addressed in Section 11. For example, one significant risk
3023 for a project is the inability to provide immediate value, if initially reduced, to the
3024 customer to gain trust. In that situation, a scheduling method dependent on a predictive
3025 life cycle (big design up front) would be very risky. On the other hand, if human life or
3026 the company’s reputation is at stake and if the product is not as good as it could be or
3027 is in the process of being certified, more design upfront and increased priority on
3028quality-related processes (see Section 8) is warranted.3029
3030The project environment is a significant influence on the appropriateness of a scheduling
3031method. If the method is not supported by the culture of the organization or is not
3032 aligned with the management infrastructure and incentives, the project may fail to meet
3033 schedule commitments regardless of any risk-mitigating effects it might provide.3034
3035Software project scheduling is usually dependent on the existence and maturity of product
3036 architecture. The constraints and design attributes that are established by architecture
3037may need to be developed first, and therefore it may not be difficult and risky to
3038downstream work until the architecture is mature. Architecture is also an important
3039 enabler for early value delivery. Product architecture is a critical contributor to the
3040 ability to progressively deliver value and to allow the project team to respond to change
3041 late in a project, especially in the case of adaptive life cycles (iterative-increment to
3042highly adaptive).3043
3044Value for the customer is an important factor in all projects. However, in most cases, the
3045nature of software allows value to be provided in installments rather than in a single
3046 lump sum; this enables the scheduling method to take advantage of time-related or changing
3047values. It may be that highly valuable capabilities can be provided early in a project
3048 rather than only at completion. It may also be possible to provide less valuable
3049 capabilities while waiting for more valuable capabilities to mature. However, even if the
3050 customer is able to use partial functionality, this option is eliminated if the scheduling
3051method and the architecture are not structured to take advantage of progressive
3052 installments of value.3053
3054 In addition to the methods described in Section 6 of the PMBOK® Guide, examples of other
3055 scheduling methods used for software projects include:3056
3057 • 0Structured scheduling. This method involves a rigorous, structured approach and
3058 encompasses traditional scheduling methods described in the PMBOK, CMMI, and other project
3059governance models. This type of scheduling can be used when some or most of the following
3060 conditions apply: well-understood product requirements; related precedent work within the
Page 70
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
70/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
3061organization; strict architectural requirements; specific limits on the number, size, or
3062 frequency of deployments; critical backward compatibility issues; or heavy dependencies on
3063new infrastructure. This rigor is often needed for products with high safety, security, or
3064 regulatory constraints; for major version releases of high-profile products (e.g., MS
3065Office, SAP or Oracle), or for very large projects with significant amounts of multi-group
3066 coordination.3067
3068 • 0Schedule as independent variable (SAIV). This is a date-certain scheduling
3069method. It is used when there is a specific date after which the value of the project
3070declines precipitously. Examples are time to market considerations, an immovable event for
3071which the product is required (trade show, scheduled version release), or a date by which
3072 the enterprise is required to institute some element of a regulatory change. SAIV is
3073 characterized by careful prioritization of functional requirements and the strategy of
3074 ensuring availability of the most valued functionality by the required deadline. This is
3075 the same concept as “time boxing,” where time constrains the work done within an iteration
3076or incremental completion. More discussion is provided in Section 6.3.2.5.3077
3078 • 0Iterative planning with a backlog. This is a form of rolling wave planning used
3079 in adaptive projects, where the requirements are prioritized, roughly allocated into
3080 iterations, and iterations are refined just prior to execution. Iterative planning
3081 continues throughout the project life cycle and is central to the ongoing learning and
3082 adaptation that occurs on emergent projects. This approach is often used to deliver value
3083more quickly to the customer or when there are a large number of functions that need to be
3084 implemented, however, there are few dependencies between functions. This fits many types
3085of projects, as shown by the popularity of adaptive life cycle models.3086
3087 • 0On-demand scheduling. Based on the theory-of-constraints and lean manufacturing
3088pull-based scheduling concepts, this approach does not pre-schedule a project using
3089 increments, but directly pulls work from a backlog or intermediate queue of work
3090 immediately as resources become available. It provides the customer with a statistically
3091based estimate of time-to-complete for any given task (often referred to as lead time),
3092 and can be used to continually assess backlogged task-value to maximize value for
3093 customers. On-demand scheduling is often used for systems that are evolved incrementally
3094 (operational or sustainment environments), where tasks may be made relatively similar in
3095size and scope, or can be bundled in such manner. It may use classes of service to allow
3096 resource utilization flexibility, while ensuring that critical or time-sensitive tasks are
3097 “fast-tracked,” and necessary but not schedule-critical tasks are not put off
3098 indefinitely. The goals of such approaches are for work to take the least amount of time,
3099 estimation activities are minimized, and the value of the work accomplished maximized.3100
3101 • 0Portfolio management scheduling. This method follows the hierarchical practices
3102of defining the software investment as a priority of work for a project team where that
3103 sequence is valued by parameters set by the organization. Scheduling is not based on the
3104 size of the activity, but rather on its importance to the organization. Estimation using
3105 this method is based upon the value created vs. the time and/or cost of the development
3106project. This method is often used for strategic management of large enterprise systems or
3107 commercial services. See SWX Section 4.1 for more information. These methods form the
3108 foundation for much of the remainder of this section.3109
3110Figure 6-1 provides an overview of Software Project Time Management; it is an adaptation
3111of Figure 6-1 in the PMBOK® Guide.3112
Page 71
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
71/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
3113
3114
3115 Figure 6-1. Software Project Time Management Overview3116
31176.1 Plan Software Project Schedule Management
3118The inputs, tools and techniques, and outputs presented in Section 6.1 of the PMBOK® Guide
Page 72
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
72/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
3119 are generally applicable to planning a software project schedule, when the issues outlined
3120previously are taken into account. Enterprise environmental factors (Section 6.1.1.3) that
3121may impact planning software project schedule management include software project
3122portfolios and enterprise architectures. Organizational process assets (Section 6.1.1.4)
3123may include governance documents and project life cycles predefined for use within the
3124 software development organization.3125
31266.1.1 Plan Software Project Schedule Management: Inputs
3127The inputs in Section 6.1.1 of the PMBOK® Guide) are applicable to for planning software
3128project schedule management.3129
31306.1.1.1 Project Management Plan
3131See Section 6.1.1.1 of the PMBOK® Guide.3132
31336.1.1.2 Project Charter
3134See Section 6.1.1.2 of the PMBOK® Guide.3135
31366.1.1.3 Enterprise Environmental Factors
3137See Section 6.1.1.3 of the PMBOK® Guide.3138
31396.1.1.4 Organizational Process Assets
3140See Section 6.1.1.4 of the PMBOK® Guide3141
31426.1.2 Plan Software Project Schedule Management: Tools and Techniques
3143The tools and techniques in Section 6.1.2 of the PMBOK® Guide are applicable for planning
3144 software project schedule management.3145
31466.1.2.1 Expert Judgment
3147See Section 6.1.2.1 of the PMBOK® Guide.3148
31496.1.2.2 Analytical Techniques
3150See Section 6.1.2.2 of the PMBOK® Guide.3151
31526.1.2.3 Meetings
3153See Section 6.1.2.3 of the PMBOK® Guide.3154
31556.1.3 Plan Software Project Schedule Management: Outputs
3156The output in Section 6.1.3 of the PMBOK® Guide is applicable for planning software
3157project schedule management.3158
31596.1.3.1 Schedule Management Plan
Page 73
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
73/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
3160See Section 6.1.3.1 of the PMBOK® Guide.3161
31626.2 Define Software Project Activities
3163Defining activities in software projects is based on the functional and nonfunctional
3164 requirements, project scope, and the project environment. These are also determined by the
3165development approach and project life cycle selected.3166
3167As described in Section 2, software project activities and processes are detailed in
3168 ISO/IEC 12207:2008. Many of these processes and activities are included in the PMBOK®
3169Guide and are also addressed in this software extension. Software activities are not
3170 rigidly ordered and may be performed sequentially, iteratively, concurrently, or in
3171whatever way best meets the needs and risks of the project. Section 2 provides additional
3172 information on project life cycles and how they are selected for a project.3173
31746.2.1 Define Software Project Activities: Inputs
3175The inputs for defining project activities in Section 6.2.1 of the PMBOK® Guide are
3176generally applicable to defining inputs for software project activities. In addition to
3177 these, Section 6.2.1.5 is applicable to defining software project activities. Other
3178 factors that may influence the definition of software project activities include existing
3179work orders and enhancement requests; technical debt remaining from previous iterations,
3180 incomplete functionality and needed rework; and external activities such as database or
3181operating system upgrades and business process changes.3182
31836.2.1.1 Schedule Management Plan
3184See Section 6.2.1.1 of the PMBOK® Guide.3185
31866.2.1.2 Scope Baseline
3187As stated previously, an organization’s enterprise architecture, if there is one, is an
3188 environmental factor that may influence the definition of software project activities.3189
31906.2.1.3 Enterprise Environmental Factors
3191See Section 6.2.1.3 of the PMBOK® Guide.3192
31936.2.1.4 Organizational Process Assets
3194 In addition to those in Section 6.2.1.4 of the PMBOK® Guide, organizational process assets
3195that may influence defining project activities include governance documents, project life
3196 cycle models, team velocity measures and other productivity measures such as SAIV
3197described in the introduction to Section 6 of this extension, and cadence or flow measures
3198 such as time-in-process statistics for adaptive and on-demand scheduling.3199
32006.2.1.5 Organization Parameters
3201Organization parameters provide metadata requirements for software projects so that
3202projects, programs, and portfolio information can be rolled up into scorecards and
3203 strategic plans. Understanding and using these parameters will ease project reporting and
3204 eliminate rework by the portfolio manager.3205
Page 74
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
74/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
32066.2.2 Define Software Project Activities: Tools and Techniques
3207The tools and techniques for defining project activities in Section 6.2.2 of the PMBOK®
3208Guide are generally applicable for defining the tools and techniques for software project
3209 activities. In addition to these, Sections 6.2.2.5 through 6.2.2.7 apply to defining
3210 software project activities.3211
32126.2.2.1 Decomposition
3213See Section 6.2.2.1 of the PMBOK® Guide.3214
32156.2.2.2 Rolling Wave Planning
3216See Section 6.2.2.2 of the PMBOK® Guide.3217
32186.2.2.3 Expert Judgment
3219See Section 6.2.2.3 of the PMBOK® Guide.3220
32216.2.2.4 Feature or Story Breakdown Structures
3222As with most other kinds of projects, work activities for software projects may be
3223 assigned to different life cycle phases or executed by different elements of a project
3224 team. For example, activities could be defined and assigned to dedicated resources within
3225 the traditional phases of requirements, design, implementation, validation, and
3226 transition, as in a predictive life cycle. In contrast, a software project manager may
3227group work activities into clusters associated with some required capability. Given an
3228 enabling architecture, a capability may be developed as a single activity integrating most
3229or all of the traditional, predictive life cycle activities. These capabilities may be
3230 called features or stories and represent some part of the software product’s functional
3231 and nonfunctional requirements as one entity.3232
3233Complex stories may be defined as epics, described at a high level, and refined into
3234 stories at a later date. Stories that are associated by a common factor, such as
3235 functionality, data source, security level, or use case, may be associated within a theme.
3236All of these are ways to define work activities that will deliver software capabilities.
3237Other project work (procurement, documentation, risk management, training, etc.) may also
3238be referenced as stories or features and tracked and managed using backlogs.3239
3240Defining software project activities in this manner provides a number of benefits, as
3241 follows:
3242
3243 • 0Holistic estimation and value assessment of capabilities in terms of user desires,
3244 • 0Progressive delivery of value through incremental capability deployment,
3245 • 0More rapid learning and progressive elaboration of user needs,
3246 • 0Quicker response in changing environments,
3247 • 0Reduced late rework when it is most expensive, and
3248 • 0Within a given feature or capability development, lessons learned and the
3249 resulting process improvement actions can be quickly identified and adopted, thereby
3250 immediately impacting project productivity.3251
3252More information on this can be found in the discussion in Section 2 of this extension.3253
32546.2.2.6 Storyboards
3255Storyboards for defining software capabilities are similar to those used in television and
Page 75
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
75/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
3256movie production. They provide a graphical overview of the project that illustrates the
3257order in which certain capabilities or user stories are to be completed.3258
32596.2.2.7 Use Cases
3260Use cases describe a software product’s functionality from the user’s point of view. Use
3261 cases provide scenarios of operation (step-by-step interactions) between a user and the
3262product for a desired functional capability. A use-case scenario can be specified using an
3263 itemized list of steps or by using a UML/SysML notation such as a sequence diagram,
3264 activity diagram, or state diagram. Software tools are available for these notations; the
3265 tools support various forms of analysis and elaboration of the diagrams for software
3266 implementation. Use cases that have alternate paths, exceptions, and business rules, in
3267 addition to the primary scenario, can be used to slice use case stories into features to
3268be implemented, as shown in Figure 6-2.3269
3270
3271
3272 Figure 6-2. Creating Features from a Use Case3273
32746.2.3 Define Software Project Activities: Outputs
3275The outputs in Section 6.2.3 of the PMBOK® Guide are applicable to defining software
3276project activity outputs with the modifications below. In addition to these, the outputs
3277described in 6.2.3.4 and 6.2.3.5 also apply to software project activities.3278
32796.2.3.1 Activity List
3280
Page 76
See also Section 6.2.3.1 of the PMBOK® Guide. Activity lists for software projects may
3281 include coordination with entities external to the software project. The software
3282development team may need access to testing facilities, infrastructure equipment, and
3283 access to multiple user environments. These project elements may be outside the control of
3284 the software project manager and may require external scheduling to avoid a negative
3285 impact to the software project schedule.3286
32876.2.3.2 Activity Attributes
3288See also Section 6.2.3.2 of the PMBOK® Guide. Attributes that may be included for
3289 activities on a software project activity list include but are not limited to the
3290 following:3291
3292 • 0Dependencies and enabling precedent activities,
3293 • 0Stakeholder value or priority,
3294 • 0Estimated effort, size, complexity, and/or risk,
3295 • 0Security and/or safety standards and constraints,
3296 • 0Special competency requirements for staff resources,
3297 • 0Required resources for development, testing, and validating of equipment, and
3298 • 0Class of service for on-demand scheduling.3299
33006.2.3.3 Milestone List
3301See also Section 6.2.3.3 of the PMBOK® Guide. Milestones for software projects are defined
3302 in various ways for various development environments and project life cycles. For example,
3303 some software project life cycles (e.g., the Rational Unified Process) define anchor
3304points, which are points in time when major project life cycle phase transitions occur.3305
3306 In incremental software development, milestones may be set to denote architectural design
3307 reviews, customer delivery, and acceptance points, or as feature set accomplishments.
3308Often each increment includes a completion or validation milestone, but that is not
3309 required.3310
3311On-demand scheduling methods do not usually have specific milestones; progress is measured
3312by customer satisfaction within the time-to-complete cadence. Calendar-based coordination
3313 conferences may be held to discuss performance, but these are rarely associated with a
3314 specific goal or technical criterion.3315
3316A useful technique for reducing project risk is to define joint milestones with
3317 interdependent projects such as hardware procurement, installation and configuration for
3318platform and environment delivery. Identified risks can then be mitigated. This type of
3319program/ portfolio management is often critical to the successful delivery of software
3320products especially in a constrained schedule.3321
33226.2.3.4 Safety and Security Analyses
3323Public safety and cyber security issues may impact the sequencing of some software
3324 activities to satisfy requirements and standards during a software project.3325
33266.3 Sequence Software Project Activities
3327According to Section 6.3 of the PMBOK® Guide, Sequence Activities is the process of
3328 identifying and documenting relationships among the project activities. Sequencing
3329 activities for software projects differ somewhat to those in Section 3 of the PMBOK® Guide
3330because the sequencing methods used may be based on customer value, technical risk,
3331 technical architecture and design, specific expertise availability, as well as other
3332 technical and staffing dependencies.
Page 77
3333
3334Dependencies in database structure, infrastructure needs and other architecture and design
3335 concerns exist in many software projects. However, for a new application domain or a
3336 large, complex software project in a new or existing domain, there is often a need to
3337 establish and refine the operational concepts, build prototypes, and/or define an
3338 architecture or infrastructure before specifying the functional requirements for the
3339product. How much time is needed for these activities and how concurrently they can be
3340 accomplished depends on the familiarity, size, and complexity of the product; and on the
3341 risk profiles; and, in particular, on the likelihood of changes in the product
3342 requirements.3343
3344Architecture has a significant impact on sequencing in several areas. First, the actual
3345 architecture development is not easily estimated, and therefore, any software directly
3346 related to the architectural design may need to be delayed until the architecture is
3347 complete. In some instances, only some of the architectural decisions are unknown, so
3348 early investment in activities that prove the effectiveness of an architectural solution
3349or build an initial architectural structure may be effective. These activities may be
3350 called firing tracer rounds or developing walking skeletons or steel threads, but the
3351 intent is to make sure that the key architectural decisions are feasible and that the
3352 solutions are available for functional development. For example, exception handling, data
3353 assurance, and security patterns need to be established early for consistency across the
3354 system. Second, the architecture supports the ability to define pieces of the product that
3355 can be tested and the efficacy of mockups, stubs, or dummies that allow testing of
3356 incomplete functionality. This work needs to precede the development so that testing
3357 techniques such as test driven development, have a framework to grow around. This is of
3358particular significance in larger systems that integrate with outside or legacy systems
3359beyond the project manager’s control.3360
3361 In a similar way, the nonfunctional and quality requirements impact the sequencing of
3362 activities by requiring time to implement cross-cutting strategies (such as
3363 error-handling, function criticality, failure modes). The need for certification of
3364 software components due to regulatory, safety, or security requirements may also affect
3365 sequencing due to the overhead costs of certification. It is usually more cost-effective
3366 to bundle changes to certified code so that recertification activities are not repeated
3367unnecessarily.3368
3369Software schedules are frequently revised. In-process prototyping and coding
3370 experimentation may be needed to support decision making. These kinds of activities may
3371not be identified during initial scheduling, so the ripple effects they cause can impact
3372 sequencing in real time. Needed rework to fix defects is another sequencing issue.
3373Activities that were not anticipated but are still necessary for project completion often
3374 arise. This unanticipated work (sometimes referred to as dark matter) can often take
3375precedence over other work and is sometimes tracked independently. Section 6.7 discusses
3376 the roles burn-down and burn-up charts in relation to these issues.3377
3378Adjustments to schedule sequencing for adaptive life cycle software projects is more
3379dynamic and occurs more frequently than for predictive life cycle projects, and generally
3380provides more opportunities to absorb unscheduled work. A plan is created to provide
3381 structure and focus for the adaptive iterations, their content, and any product release
3382points. However, the plan is revisited often to incorporate changes related to business
3383 feedback based on factors such as demonstrations of the evolving product, productivity
3384 (velocity) data gathered during development, unscheduled work, and retrospective findings.3385
3386Adaptive software projects usually sequence activities prior to beginning iterative
3387development, but the scope of this initial sequencing may be vague and will be refined as
3388 the project progresses. In some cases, higher levels in feature and story breakdowns are
3389used to coordinate lower levels—with the unscheduled work absorbed into the estimates for
3390 the higher-level deliverables.3391
3392On-demand scheduling techniques, and some highly adaptive life cycles, allow the work to
3393 flow to whatever suitable staff resources become available. This is sometimes referred to
Page 78
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
78/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
3394 as late binding of the work to the resources. However, the order of sequence execution is
3395nondeterministic until the actual time of binding the work item to the available resource
3396or resources. The available staff resource, or resources, dynamically selects the next
3397work to be done based on the value of the queued work activities. Value is defined by
3398project specific risks or constraints (e.g., cost of delay, value to customer, class of
3399 service, or criticality).3400
3401Rather than a date-certain schedule of events or a specified increment where a certain
3402number of tasks are in scope to be completed, on-demand techniques establish a regular
3403 cadence of releases (or other events). The timing of the cadence is determined through
3404measures such as velocity or a statistics-based typical lead or transit time for a task.
3405The cadence then provides an indication of how long a customer or software project manager
3406 can expect to wait for a particular activity or task to complete. Work-in-progress limits
3407 are used to maintain resource viability and even out flow, and are adjusted according to
3408 statistical measures maintained throughout the process. There may be a visual indicator (a
3409workflow chart) to provide broad visibility and help to identify and resolve bottlenecks
3410or make better use of available resources.3411
34126.3.1 Sequence Software Project Activities: Inputs
3413The inputs for sequencing software project activities in Section 6.3.1 of the PMBOK® Guide
3414 are generally applicable for sequencing software project activities, with the modification
3415of 6.3.1.6 and the additional inputs in of 6.3.1.8 and 6.3.1.9.3416
3417See Section 6.3.1.1 of the PMBOK® Guide.6.3.1.1 Schedule Management Plan
3418See Section 6.3.1.1 of the PMBOK® Guide.3419
34206.3.1.2 Activity List
3421See Section 6.3.1.2 of the PMBOK® Guide.3422
34236.3.1.3 Activity Attributes
3424See Section 6.3.1.3 of the PMBOK® Guide.3425
34266.3.1.4 Milestone List
3427See Section 6.3.1.4 of the PMBOK® Guide.3428
34296.3.1.5 Project Scope Statement
3430See Section 6.3.1.5 of the PMBOK® Guide.3431
34326.3.1.6 Enterprise Environmental Factors
3433See Section 6.3.1.6 of the PMBOK® Guide.3434
34356.3.1.7 Organizational Process Assets
3436Governance models often have set anchor points, templates, and environmental issues that
3437 can impact the scheduling sequence for software projects. The enterprise architecture, if
3438 there is one, may also impact the sequencing. Organizational parameters for valuing
Page 79
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
79/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
3439 software investments may be of use in identifying the value of functionality to the
3440 customer and thus impact sequencing.3441
34426.3.1.8 Architectural and IV&V Constraints
3443Architecture and IV&V plans can significantly impact the sequencing when there are
3444 constraints on the functionality needed to verify and validate cross functional,
3445multi-system, multi-platform, or multi-environment requirements (See Section 6.3).3446
34476.3.1.9 Safety and Security Analyses
3448Public safety and cyber security issues may impact the sequencing of some software
3449 activities to meet requirements and standards. Certification activities are always
3450 expensive, so the sequencing should try to minimize the number of certification cycles.3451
34526.3.2 Sequence Software Project Activities: Tools and Techniques
3453The tools and techniques for sequencing project activities in Section 6.3.2 of the PMBOK®
3454Guide are applicable to sequencing software project activities. In addition to these, the
3455 tools and techniques in 6.3.2.4 through 6.3.2.8 are applicable to sequencing software
3456project activities.3457
34586.3.2.1 Precedence Diagramming Method
3459See Section 6.3.2.1 of the PMBOK® Guide.3460
34616.3.2.2 Dependency Determination
3462See Section 6.3.2.1 of the PMBOK® Guide.
3463
34646.3.2.3 Leads and Lags
3465See Section 6.3.2.1 of the PMBOK® Guide.3466
34676.3.2.4 Portfolio Management Approaches
3468See Section 1.4.1 of this software extension.3469
34706.3.2.5 SAIV and Time Boxing
3471Using SAIV (Schedule As Independent Variable) for sequencing software project activities
3472 can help to ensure that the most valuable features or functionality are available when
3473 time is exhausted because the most important features have been implemented. The SAIV
3474 concept is applied in a variety of techniques, including time boxing and date-certain
3475 scheduling. As shown in Figure 6-3, product scope can be varied varying when cost and time
3476have been set. SAIV can be applied within increments, releases, or for complete products.3477
Page 80
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
80/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
3478
3479
3480 Figure 6-3. Schedule as Independent Variable3481
3482This method depends on the ability to set relative values on items of work such as
3483 features or stories. These values may change over time, but adaptive life cycles allow for
3484 that change by frequently reassessing value. This presupposes that the customer or other
3485 stakeholders are either available or are represented by surrogates whenever values are
3486 assessed.3487
3488SAIV can also be applied to exploratory work done when determining architectures and
3489designs. One method is to define the hypothesis that needs to be proven, and a time box
3490within which the proof must be completed. It is important to create a clear hypothesis
3491 (for example using a statement or if-then format) from which to design the experiment.3492
34936.3.2.6 Work in Progress Limits and Classes of Service
3494See on-demand scheduling in Section 6.1 of this extension.3495
34966.3.2.7 Feature Sets
3497A feature set specifies an aggregate of functionality that delivers business value and may
3498 include work activities in addition to functions. Different software development methods
3499use different terminology to refer to features. It is up to the software project manager
3500 and the project team to decide which terminology to use.3501
3502As shown in Figure 6-4, by identifying feature sets, the team designs, builds, and
3503delivers all the stories within a feature before moving on to the next feature. This is an
3504 important structure for feedback purposes. Even when the same code base is impacted by
3505more than one feature, in feature sets, the team does all the work for one feature, tests,
3506 and remediates; then the next feature, tests and remediates; and so on, until the planned
3507 scope is accomplished or the increment is completed. This incurs a cost to development for
3508 a return in reduced testing complexity and deferring the commitment of design and
3509 functionality until the next feature is built.3510
Page 81
3511
3512 Figure 6-4. Scheduling Using Feature Sets3513
35146.3.2.8 Service Level Agreements
3515There may be an agreement between the developer and the customer or other stakeholder that
3516 sets the amount of work to be accomplished expected from an organization over a specified
3517period of time. This establishes the required development capacity and may impact
3518 sequencing.3519
35206.3.3 Sequence Software Project Activities: Outputs
3521The outputs for project sequencing in the PMBOK® Guide are applicable for sequencing
3522 software project activities. In addition to these, the outputs specific to software
3523project sequencing activities are provided in 6.3.3.3 through 6.3.3.5.3524
35256.3.3.1 Project Schedule Network Diagrams
3526See Section 6.3.3.1 of the PMBOK® Guide.3527
35286.3.3.2 Project Documents Updates
3529See Section 6.3.3.2 of the PMBOK® Guide.3530
35316.3.3.3 Features Sets
3532See Section 6.3.2.8 of this software extension.
3533
35346.3.3.4 Release Plans
3535A release plan lays out the overall project schedule in iterative stages for the delivery
3536of functionality for customer evaluation and/or delivery into the users’ environment. The
3537 release plan is highly dependent upon the velocity of the software development team.
3538Comparing estimated velocity to the actual time it takes to accomplish the work over a
Page 82
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
82/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
3539period of several iterations provides a baseline for estimating the time for future
3540 releases.3541
35426.3.3.5 Architectural and Nonfunctional Dependencies
3543Architectural and nonfunctional dependencies need to be updated to reflect the planned
3544project activities to prevent duplication of work or rework by other project teams or
3545 initiatives.3546
35476.4 Estimate Software Project Activity Resources
3548According to Section 6.4 of the PMBOK® Guide estimating resources for project activities
3549 is the process of estimating the type and quantities of material, people, equipment, or
3550 supplies required to perform each activity.3551
3552Because software is developed by the intellectual efforts of software developers, software
3553projects are heavily dependent upon human resources more than any other kind of software
3554project resource. The skills and abilities of the software developers is a significant
3555 factor in estimating the number of software developers needed. Studies have shown as much
3556 as 26:1 variations in individual software developer productivity, and 10:1 variations are
3557not uncommon even among software developers having similar education and work experience
3558 [20].3559
3560The process of determining the roles required for the project can be determined by
3561 reviewing the product requirements, the project objectives, stakeholder’s goals, and
3562budget and schedule constraints. As a software project evolves, requirements will be
3563 refined, features and user stories will be identified, and the human resources needed to
3564 satisfy the project goals are checked against the current team’s collective skills. Gaps
3565may indicate that additional or different roles are required. Likewise, productivity
3566 (velocity) and quality metrics may provide insights into team role requirements as the
3567project progresses. In some cases, the software project manager may be given a collection
3568of team members without the opportunity to identify needed project roles or to adjust them
3569 as the project evolves. In other cases, the project manager may be asked for the kinds of
3570 roles that need to be filled, the timing for the roles, and in what quantities.3571
3572Other resource requirements for software projects may include resources for architectural
3573 studies and several kinds of support activities (e.g., configuration management, quality
3574 assurance, documentation, user training). Test facilities, software for performance
3575 testing and multi-configuration test suites, and multiple target environments or platforms
3576 for deployment are examples of other software resources that may be required.3577
35786.4.1 Estimate Software Project Activity Resources: Inputs
3579As stated in 6.4, software developers are the most important resources for a software
3580project. Because software productivity varies widely among software developers (even among
3581 those having similar educations and work experiences) historical data concerning
3582productivity at the team and individual levels is a valuable input for estimating software
3583project activity resources, in addition to the inputs described in Section 6.4.1 of the
3584PMBOK® Guide. Software project managers who use adaptive life cycles have the opportunity
3585 to collect productivity data on a frequent, ongoing basis and may be able to adjust human
3586 resources as the project progresses. Personnel adjustments are typically more difficult
3587 for predictive life cycle software projects.3588
3589Other inputs for estimating software project activity resources involve using a results
3590 chain and other forms of analyses to identify key assumptions and resources outside of the
3591 software development activities for a software project3592
3593The inputs in Section 6.4.1 of the PMBOK® Guide are applicable inputs for estimating
Page 83
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
83/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
3594 software project activity resources.3595
35966.4.1.1 Schedule Management Plan
3597See Section 6.4.1.1 of the PMBOK® Guide.3598
35996.4.1.2 Activity List
3600See Section 6.4.1.2 of the PMBOK® Guide.3601
36026.4.1.3 Activity Attributes
3603See Section 6.4.1.3 of the PMBOK® Guide.
3604
36056.4.1.4 Resource Calendars
3606See Section 6.4.1.4 of the PMBOK® Guide.3607
36086.4.1.5 Risk Register
3609See Section 6.4.1.5 of the PMBOK® Guide.3610
36116.4.1.6 Activity Cost Estimates
3612See Section 6.4.1.6 of the PMBOK® Guide.3613
36146.4.1.7 Enterprise Environmental Factors
3615See Section 6.4.1.7 of the PMBOK® Guide.3616
36176.4.1.8 Organizational Process Assets
3618See Section 6.4.1.8 of the PMBOK® Guide.3619
36206.4.2 Estimate Software Project Activity Resources: Tools and Techniques
3621The tools and techniques for estimating project activity resources in the PMBOK® Guide are
3622 applicable for software projects. In addition to these, the tools and techniques in
36236.4.2.6 and 6.4.2.7 apply to estimating software project activity resources.3624
36256.4.2.1 Expert Judgment
3626See Section 6.4.2.1 of the PMBOK® Guide.3627
36286.4.2.2 Alternative Analysis
3629See Section 6.4.2.2 of the PMBOK® Guide.3630
36316.4.2.3 Published Estimating Data
Page 84
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
84/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
3632See Section 6.4.2.3 of the PMBOK® Guide.3633
36346.4.2.4 Bottom-Up Estimating
3635See Section 6.4.2.4 of the PMBOK® Guide.3636
36376.4.2.5 Project Management Software
3638See Section 6.4.2.5 of the PMBOK® Guide.3639
36406.4.2.6 Service Level Agreements
3641There may be an agreement between the developer and the customer or other stakeholder that
3642 sets the amount of work to be accomplished expected from an organization over a specified
3643period of time. This establishes the required development capacity and may impact resource
3644 estimation.3645
36466.4.2.7 Other Tools and Techniques
3647Other tools and techniques for estimating software project activity resources include use
3648of algorithmic estimation models and function point/story point/use-case estimation tools.3649
36506.4.3 Estimate Software Project Resources: Outputs
3651The outputs listed in Section 6.4.3 of the PMBOK® Guide are applicable for estimating
3652 software project resources.3653
36546.4.3.1 Activity Resource Requirements
3655See Section 6.4.3.1 of the PMBOK® Guide.3656
36576.4.3.2 Resource Breakdown Structure
3658See Section 6.4.3.2 of the PMBOK® Guide.3659
36606.4.3.3 Project Documents Updates
3661See Section 6.4.3.3 of the PMBOK® Guide.3662
36636.5 Estimate Software Project Activity Duration
3664The difficulty in estimating software project activity durations is the result of many
3665 factors: fundamental intangibility of software, broad variance in productivity of software
3666professionals, need for change to meet emergent requirements, often unprecedented nature
3667of the software product, unknown competencies of staff resources or product team, unknown
3668 existing hardware or software defects, and need to incorporate legacy software, commercial
3669 software, customer-supplied software, or open-source software into the software product.
3670Even if these factors are taken into consideration, the result may be accurate for the
3671known work, but cannot account for the unidentified, unknown work that will need to be
3672performed.3673
3674Exacerbating the estimation challenges in software projects is the nonlinear nature of the
Page 85
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
85/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
3675 scaling of software work; a product twice as big or twice as complex, however measured,
3676 typically requires more than twice as much work, and more than twice as much time because
3677of the interdependencies of the work activities and the increased communication needs of
3678 the software developers. Adding additional work activities may result in significant
3679delays in the delivery of each increment of value and may result in schedule
3680perturbations, which future complicates the ability to accurately update estimated
3681durations. The software project life cycle and scheduling method used should account for
3682 the significant risk of the likely estimation error.3683
3684Because effort is the product of people and time, the schedule durations of software
3685project activities depend on estimated effort and personnel resources available. Section
36867.2.2 provides information on additional ways to estimate effort for software projects.3687
36886.5.1 Estimate Software Project Activity Durations: Inputs
3689The inputs in Section 6.5.1 of the PMBOK® Guide can be used to estimate software project
3690 activity durations. They are the schedule management plan, the activity list, activity
3691 attributes, activity resource requirements, resource calendars, project scope statement,
3692 risk register, resource breakdown structure, enterprise environmental factors, and
3693organizational process assets. See Section 6.5.1.1 – 6.5.1.10 of the PMBOK® Guide.3694
36956.5.1.1 Schedule Management Plan
3696See Section 6.5.1.1 of the PMBOK® Guide.3697
36986.5.1.2 Activity List
3699See Section 6.5.1.2 of the PMBOK® Guide.3700
37016.5.1.3 Activity Attributes
3702See Section 6.5.1.3 of the PMBOK® Guide.3703
37046.5.1.4 Activity Resource Requirements
3705See Section 6.5.1.4 of the PMBOK® Guide.3706
37076.5.1.5 Resource Calendars
3708See Section 6.5.1.5 of the PMBOK® Guide.3709
37106.5.1.6 Project Scope Statement
3711See Section 6.5.1.6 of the PMBOK® Guide.3712
37136.5.1.7 Risk Register
3714See Section 6.5.1.7 of the PMBOK® Guide.3715
37166.5.1.8 Resource Breakdown Structure
3717See Section 6.5.1.8 of the PMBOK® Guide.3718
Page 86
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
86/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
37196.5.1.9 Enterprise Environmental Factors
3720See Section 6.5.1.9 of the PMBOK® Guide.3721
37226.5.1.10 Organizational Process Assets
3723See Section 6.5.1.10 of the PMBOK® Guide.
3724
37256.5.1.11 Additional Inputs
3726 In addition to those presented in Section 6.5.1 of the PMBOK® Guide lists of activities,
3727 features organized as lists or groups, and customer stories are useful inputs for
3728 estimating software project activity durations. Velocity and rework metrics are also
3729useful inputs.3730
37316.5.2 Estimate Software Project Activity Durations: Tools and Techniques
3732The tools and techniques presented in Section 6.5.2 of the PMBOK® Guide are applicable for
3733 estimating software project activity durations.3734
37356.5.2.1 Expert Judgment
3736See Section 6.5.2.1 of the PMBOK® Guide.3737
37386.5.2.2 Analogous Estimating
3739See Section 6.5.2.2 of the PMBOK® Guide.3740
37416.5.2.3 Parametric Estimating
3742See Section 6.5.2.3 of the PMBOK® Guide.3743
37446.5.2.4 Three-Point Estimating
3745See Section 6.5.2.4 of the PMBOK® Guide.3746
37476.5.2.5 Group Decision-Making Techniques
3748See Section 6.5.2.5 of the PMBOK® Guide.3749
37506.5.2.6 Reserve Analysis
3751See Section 6.5.2.6 of the PMBOK® Guide.3752
37536.5.2.7 Service Level Agreements
3754There may be an agreement between the developer and the customer or other stakeholder that
3755 sets the amount of work to be accomplished expected from an organization over a specified
3756period of time. This establishes the required development capacity and may impact
3757 sequencing.3758
Page 87
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
87/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
37596.5.3 Estimate Software Project Activity Durations: Outputs
3760The outputs for estimating project activity durations are applicable for software
3761projects.3762
37636.5.3.1 Activity Duration Estimates
3764See Section 6.5.3.1 of the PMBOK® Guide.3765
37666.5.3.2 Project Documents Updates
3767See Section 6.5.3.2 of the PMBOK® Guide.3768
37696.6 Develop Software Project Schedule
3770The form of the software project schedule may be the same as described in Section 6.5 of
3771 the PMBOK® Guide or it may take a different form altogether. In addition to the approach
3772described in the PMBOK® Guide, a more flexible approach facilitates the expected changes
3773 that inevitably occur in a software project schedule. Software project schedules and plans
3774 change, driven by customer requests, project feedback, and by the emergence of previously
3775unidentified work activities. The format of a software project schedule may be unfamiliar
3776 to some stakeholders. Instead of using a network diagram, a prioritized backlog of work
3777may be the preferred method for illustrating and managing the sequence of project
3778 activities. Tools and deliverables that are easy to change are often preferred instead of
3779 the harder-to-update network diagrams.3780
3781The approach of maintaining a prioritized backlog of work activities is similar to rolling
3782wave planning, where a top-level schedule is completed for the entire project and only the
3783proximate elements of the schedule are completed in detail as the project evolves.3784
37856.6.1 Develop Software Project Schedule: Inputs
3786The inputs for developing a project schedule in the PMBOK® Guide are applicable for
3787developing a software project schedule. In addition to these, an additional input is
3788 listed in 6.6.1.14.3789
37906.6.1.1 Schedule Management Plan
3791See Section 6.6.1.1 of the PMBOK® Guide.3792
37936.6.1.2 Activity List
3794See Section 6.6.1.2 of the PMBOK® Guide.3795
37966.6.1.3 Activity Attributes
3797See Section 6.6.1.3 of the PMBOK® Guide.3798
37996.6.1.4 Project Schedule Network Diagrams
3800See Section 6.6.141 of the PMBOK® Guide.3801
38026.6.1.5 Activity Resource Requirements
Page 88
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
88/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
3803See Section 6.6.1.5 of the PMBOK® Guide.3804
38056.6.1.6 Resource Calendars
3806See Section 6.6.1.6 of the PMBOK® Guide.3807
38086.6.1.7 Activity Duration Estimates
3809See Section 6.6.1.7 of the PMBOK® Guide.
3810
38116.6.1.8 Project Scope Statement
3812See Section 6.6.1.8 of the PMBOK® Guide.3813
38146.6.1.9 Risk Register
3815See Section 6.6.1.9 of the PMBOK® Guide.3816
38176.6.1.10 Project Staff Assignments
3818See Section 6.6.1.10 of the PMBOK® Guide.3819
38206.6.1.11 Resource Breakdown Structure
3821See Section 6.6.1.11 of the PMBOK® Guide.3822
38236.6.1.12 Enterprise Environmental Factors
3824See Section 6.6.1.12 of the PMBOK® Guide.3825
38266.6.1.13 Organizational Process Assets
3827See Section 6.6.1.13 of the PMBOK® Guide.3828
38296.6.1.14 Additional Inputs
3830Additional inputs for developing a software project schedule include activity lists,
3831 features and feature sets, and stories. Other inputs include historical data on project
3832 team cadence and velocity, and service level agreements for on-demand scheduling.3833
38346.6.2 Develop Software Project Schedule: Tools and Techniques
3835The tools and techniques for developing a project schedule are applicable to developing a
3836 software project schedule, with the modification of 6.6.2.8. In addition to those in
3837Section 6.6.2 of the PMBOK® Guide, the tools and techniques described in 6.6.2.7 and
38386.6.2.9 are applicable when developing a software project schedule:3839
38406.6.2.1 Schedule Network Analysis
Page 89
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
89/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
3841See Section 6.6.2.1 of the PMBOK® Guide.3842
38436.6.2.2 Critical Path Method
3844See Section 6.6.2.2 of the PMBOK® Guide.3845
38466.6.2.3 Critical Chain Method
3847See Section 6.6.2.3 of the PMBOK® Guide.3848
38496.6.2.4 Resource Optimization Techniques
3850See Section 6.6.2.4 of the PMBOK® Guide.3851
38526.6.2.5 Modeling Techniques
3853See Section 6.6.2.5 of the PMBOK® Guide.3854
38556.6.2.6 Leads and Lags
3856See Section 6.6.2.6 of the PMBOK® Guide.3857
38586.6.2.7 Schedule Compression for Software Projects
3859Compressing the schedule of a software project results in lower technical quality and/or a
3860nonlinear increase in effort because more people will be needed to meet the schedule and
3861 the number of communication paths among increased numbers of project members increases
3862 exponentially (on the order of n-squared, where n is the number of project members). The
3863non-linearity in staffing thus results from the increased communication and coordination
3864 that occur when a software development team becomes larger. A well-known rule of thumb
3865 states that software projects rarely succeed if the project schedule is compressed more
3866 than 25%, regardless of the number of people added to the project. And, the well-known
3867Brooks Law states “adding manpower to a late project makes it later.” [21]3868
38696.6.2.8 Scheduling Tool
3870See Section 6.6.2.8 of the PMBOK® Guide.3871
38726.6.2.9 Release and Iteration Planning for Software Projects
3873Release and iteration planning processes for adaptive software project life cycles are
3874used to develop the sequencing of work activities to be accomplished based on the ordering
3875of deliverable increments of software. During release planning, the project schedule is
3876ordered by the priority of the deliverables and is roughly divided up into release cycles,
3877 such as weekly, monthly, or quarterly. This determines the estimated number of iterative
3878 cycles. Unanticipated work is by definition unknowable at the beginning of a project.
3879However, its existence is almost a certainty. When planning for a software release, the
3880 likelihood of unanticipated work activities should be taken into account.3881
3882The adaptive life cycle team then plans the work activities for the next iterative cycle
3883 in just enough detail to accomplish the work, typically with daily reviews of the work
3884 accomplished. By working directly with customers or other stakeholders, the software
3885developers can readily understand their needs and develop, build, and deliver the software
3886 efficiently and effectively. Using this method of planning, the anticipated unknowns may
Page 90
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
90/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
3887 indicate that the selected increments are too large for delivery within the required
3888 release cycle. When this occurs, the team partitions the functionality to deliver what can
3889be delivered, which requires an adjustment in the prioritization of work activities and
3890 the product backlog.3891
38926.6.3 Develop Software Project Schedule: Outputs
3893The outputs from developing a project schedule are applicable to software projects. In
3894 addition to these, the output in 6.6.3.9 applies to developing a software project
3895 schedule.3896
38976.6.3.1 Schedule Baseline
3898See Section 6.6.3.1 of the PMBOK® Guide.3899
39006.6.3.2 Project Schedule
3901See Section 6.6.3.2 of the PMBOK® Guide.3902
39036.6.3.3 Schedule Data
3904See Section 6.6.3.3 of the PMBOK® Guide.3905
39066.6.3.4 Project Calendars
3907See Section 6.6.3.4 of the PMBOK® Guide.3908
39096.6.3.5 Project Management Plan Updates
3910See Section 6.6.3.5 of the PMBOK® Guide.3911
39126.6.3.6 Project Documents Updates
3913See Section 6.6.3.6 of the PMBOK® Guide.3914
39156.6.3.7 Release and Iteration Plan Updates
3916Release and iteration plans and updates to those plans are additional outputs from
3917developing a schedule for an adaptive life cycle software project.3918
39196.7 Control Software Project Schedule
3920Controlling a software project schedule is a challenging proposition. To evaluate schedule
3921variance, the software project manager needs to understand the technical variance as well.
3922Technical variance in software can be as intangible as the software itself. For this
3923 reason, measures and reviews need to be focused and evidence-based.3924
3925For adaptive life cycle software projects, the rate of work activity completion (i.e.,
3926velocity), results from retrospective reviews and customer feedback from periodic
3927demonstrations of the evolving software project are used to adapt the upcoming release and
3928 iteration plans to incorporate mid-course adjustments and align the project with
3929 stakeholder objectives. This may include reprioritization of the backlog of remaining work
3930 (e.g., stories), changing the development team’s work processes, or adjusting the
Page 91
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
91/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
3931 engagement model with the customer. As the project progresses more emphasis should be
3932placed on emerging velocity trends as an indicator of the final completion date.3933
3934Establishing stable software development teams and limiting the amount of work in process
3935 can significantly reduce the variables associated with schedule control. Therefore, in
3936 addition to reprioritization and refactoring of the remaining work, schedule control often
3937 involves making changes to team structures and managing the flow of work through the
3938 teams.3939
39406.7.1 Control Software Project Schedule: Inputs
3941The inputs for controlling a project schedule in Section 6.7.1 of the PMBOK® Guide are
3942 applicable to controlling software project schedules, with the modification of 6.7.1.3.3943
39446.7.1.1 Project Management Plan
3945See Section 6.7.1.1 of the PMBOK® Guide.3946
39476.7.1.2 Project Schedule
3948See Section 6.7.1.2 of the PMBOK® Guide.3949
39506.7.1.3 Work Performance Data for Software Projects
3951The cadence of recent work completion, current velocity metrics, and service-level
3952 agreements for on-demand scheduling can provide work performance data for adaptive life
3953 cycle software projects.3954
39556.7.1.4 Project Calendars
3956See Section 6.7.1.4 of the PMBOK® Guide.3957
39586.7.1.5 Schedule Data
3959See Section 6.7.1.5 of the PMBOK® Guide.
3960
39616.7.1.6 Organizational Process Assets
3962See Section 6.7.1.6 of the PMBOK® Guide.3963
39646.7.2 Control Software Project Schedule: Tools and Techniques
3965The tools and techniques presented in Section 6.7.2 of the PMBOK® Guide for controlling a
3966project schedule are applicable to controlling a software project schedule with the
3967 following modification of 6.7.2.6 and the addition of 6.7.2.8 through 6.7.2.14.3968
39696.7.2.1 Performance Reviews
3970 In many software methods, performance reviews (as described in the PMBOK® Guide) are part
3971of the technical review cycle. In most cases, the best measurement of performance is the
3972value created/delivered over time. However, care should be taken when reviewing software
3973performance to ensure that all the ancillary activities that are not specifically related
3974 to the software development are progressing as well. Ancillary activities include
Page 92
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
92/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
3975 infrastructure, testing environments, test cases, interface control, configuration
3976management, equipment or supply acquisition, deployment planning, and logistics
3977 activities.3978
39796.7.2.2 Project Management Software
3980See Section 6.7.2.2 of the PMBOK® Guide.3981
39826.7.2.3 Resource Optimization Techniques
3983See Section 6.7.2.3 of the PMBOK® Guide.3984
39856.7.2.4 Modeling Techniques
3986See Section 6.7.2.4 of the PMBOK® Guide.3987
39886.7.2.5 Leads and Lags
3989See Section 6.7.2.5 of the PMBOK® Guide.3990
39916.7.2.6 Schedule Compression
3992As described in Section 6.6.2.6 of this software extension, compressing a software project
3993 schedule more than 25% by increasing staff results in a nonlinear increase in schedule
3994 thus making the project later. The only possible way to compress a software schedule is to
3995 remove features, thus reducing the work to be accomplished.3996
39976.7.2.7 Scheduling Tool
3998See Section 6.7.2.7 of the PMBOK® Guide.3999
40006.7.2.8 Variance Analysis
4001As stated in Section 6.7.1.3, cadence of recent work completion, current velocity metrics,
4002 and service-level agreements for on-demand scheduling can indicate variances in work
4003performance data when using an adaptive software project life cycle.4004
40056.7.2.9 Evidence-Based Anchor Point Milestone and Architectural Reviews
4006These technical project reviews evolved from early work at Bell Labs and have been
4007 recommended in various standards (including ISO/IEC/IEEE 12207, ISO/IEC/IEEE Standard
40081028, USC MBASE and the Rational Unified Process). They suggest the following guidelines:4009
4010 • 0Base reviews on evidence (e.g. demonstrations of working software, simulations)
4011provided by the developer and validated by independent experts. A laundry list of
4012disassociated work products completed is not evidence.
4013 • 0Develop a feasibility description to integrate the evidence.
4014 • 0Provide evidence to indicate that if the system is built to the specified
4015 architecture, it will:
4016 • Satisfy the requirements—that is, capability, interfaces, level of service, and evolution;
4017 • Support the operational concept;
4018 • Be buildable within the budgets and schedules in the plan;
4019 • Generate a viable return on investment; and
4020 • Generate satisfactory outcomes for all of the success-critical stakeholders.
Page 93
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
93/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
4021 • 0Resolve all major risks or cover in risk management plan.
4022 • 0Utilize to serve as basis for stakeholders’ commitment to proceed.
4023
40246.7.2.10 Retrospectives
4025Retrospectives are a variant of the performance reviews listed in Section 6.7.2.1 in the
4026PMBOK® Guide but they are typically held more frequently than traditional performance
4027 reviews—usually after each development iteration.4028
40296.7.2.11 Cumulative Flow Diagrams
4030Cumulative flow diagrams (CFDs) (see Figure 6-5) provide a simple method of tracking
4031work-in-progress and visually analyzing the trend line for the projected delivery of
4032 implemented features. CFDs provide metrics that allows teams and managers to react early
4033 to developing problems and, in addition they provide visibility into the overall project
4034 life cycle. Because CFDs plot both the total product scope and the progress of individual
4035work items, they visually communicate progress as well as the proportion of total
4036 completeness.4037
4038
4039 Figure 6-5. A Cumulative-Flow Diagram for Tracking Product Features4040
40416.7.2.12 Workflow Board with Daily Walkthrough
4042A workflow board is a visual depiction of work flowing through a software project using an
4043on-demand scheduling approach. Daily walkthroughs provide immediate feedback on blockages
4044 and resource issues for the entire team, effectively supporting decisions.
4045
40466.7.2.13 Reprioritization Reviews
4047Reprioritization reviews are elements of the iterative scheduling process. Project
4048progress may require adjustment of priorities among planned work activities.4049
40506.7.2.14 Burn-up and Burn-down Charts
4051A burn-up or burn-down chart visually illustrates the accomplishments of the software team
4052
Page 94
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
94/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
in their delivery of business value as measured by completed features, stories, or other
4053work units. A release burn-up chart is illustrated in Figure 6-6.4054
4055
4056 Figure 6-6. Release Burn-up Chart4057
40586.7.3 Control Software Project Schedule: Outputs
4059The outputs for controlling a project schedule in Section 6.7.3 of PMBOK® Guide are
4060 applicable for controlling a software project schedule, with the addition of 6.7.3.7.4061
40626.7.3.1 Work Performance Information
4063See Section 6.7.3.1 of the PMBOK® Guide.4064
40656.7.3.2 Schedule Forecasts
4066See Section 6.7.3.2 of the PMBOK® Guide.4067
40686.7.3.3 Change Requests
4069See Section 6.7.3.3 of the PMBOK® Guide.4070
40716.7.3.4 Project Management Plan Updates
4072See Section 6.7.3.4 of the PMBOK® Guide.4073
40746.7.3.5 Project Documents Updates
4075See Section 6.7.3.5 of the PMBOK® Guide.4076
40776.7.3.6 Organizational Process Assets Updates
4078See Section 6.7.3.6 of the PMBOK® Guide.4079
40806.7.3.7 Additional Outputs
Page 95
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
95/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
4081Release and iteration plan updates and velocity measures are useful outputs for adaptive
4082 life cycle software projects, as are service level agreement adjustments for on-demand
4083 scheduling.4084
40857 Software Project Cost Management
4086As stated in the introduction to Section 7 of the PMBOK® Guide, Project Cost Management
4087 includes the processes involved in estimating, budgeting, funding, managing, and
4088 controlling costs so that the project can be completed within the approved budget. This
4089 section of the Software Extension to the PMBOK® Guide – Fifth Edition discusses this topic
4090 from a software project perspective.4091
4092A large corporation or government agency may develop many new software products and modify
4093hundreds of existing products every year. As a result, software cost estimating is now a
4094mainstream activity for every organization that builds software; it has become a critical
4095process for those organizations. The effort required to develop or modify software is
4096 almost entirely dependent on the skills and abilities of individual team members, the
4097 interactions among team members, technical leadership direction, and the culture and
4098processes in the software development environment. Cost estimation for software projects
4099may include identifying and forecasting the cost of maintaining and evolving a software
4100product and licensing or updating commercially acquired components over many years, in
4101 addition to making estimates for developing or modifying software. Estimating with this
4102 amount of variability is difficult even when a significant amount of historical data
4103 exists.4104
4105Effort and schedule are closely related for software projects. Because staff-hours are the
4106primary cost factor for software development, effort estimation is the basis for
4107 estimating the cost of a software project. Section 6 of this software extension provides
4108guidance on managing the relationship between effort estimation and schedule estimation
4109 for software projects. This section addresses effort estimation, in addition to other
4110 aspects of managing software project cost, to ensure that software project managers
4111understand the impact of the variability of software cost drivers on software project cost
4112 estimates. When using adaptive life cycle models, which maintain flexibility as late into
4113 the development process as possible, project managers still need to estimate the effort
4114 and cost of the project. However, the volatility of project attributes, such as rapidly
4115 evolving technology, changing and emerging architecture and requirements, and the varying
4116productivity of software developers, has a significant impact on cost estimating and cost
4117management.4118
4119The PMBOK® Guide states that the ability to influence costs is greatest at the early
4120 stages of the project, making early scope definition or time-boxing of the project
4121 critical to estimating costs. Stable architecture, testing capabilities, and enabling
4122 technologies (such as configuration management, testing, and deployment tools) have a
4123 strong influence on software cost—especially the cost of late changes. Flexible or
4124 scalable architecture, continuous testing, and enabling technologies can also reduce the
4125 long-term cost of using, maintaining, and supporting a software product.4126
4127The financial benefit of conducting the project can be continuously evaluated during
4128 evolution of the product. Each tradeoff in scope and implementation details is based on
4129predicting and analyzing the prospective financial performance of the project’s product.
4130As the project progresses, and the understanding of the product progresses, adaptive
4131projects will have varying degrees of emerging scope. Scope management for software
4132projects is addressed in Section 5 of this software extension.4133
4134Figure 7-1 provides an overview of Software Project Cost Management; it is an adaptation
4135of Figure 7-1 in the PMBOK® Guide.
Page 96
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
96/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
4136
4137
Page 97
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
97/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
4138
4139 Figure 7-1. Software Project Cost Management Overview4140
41417.1 Plan Software Project Cost Management
4142As stated in the PMBOK® Guide, Plan Cost Management is a process that establishes the
4143policies, processes, and documentation for planning, managing, executing, and controlling
4144project costs. This includes identifying incremental funding models and establishing
4145 change control to manage variations from the cost control plan. The inputs, tools and
4146 techniques, and outputs for planning cost management in Section 7.1 of the PMBOK® Guide
4147 are applicable to planning cost management for software projects, with the following
4148 additions and extensions:4149
41507.1.1 Plan Software Project Cost Management: Inputs
4151The inputs in Section 7.1.1 of the PMBOK® Guide are applicable for planning cost
4152management for software projects, with the modification of 7.1.1.4 and the addition of the
4153 inputs in 7.1.1.5 through 7.1.1.8.4154
41557.1.1.1 Project Management Plan
4156See Section 7.1.1.1 of the PMBOK® Guide.4157
41587.1.1.2 Project Charter
4159See Section 7.1.1.2 of the PMBOK® Guide.4160
41617.1.1.3 Enterprise Environmental Factors
4162See Section 7.1.1.3 of the PMBOK® Guide.4163
41647.1.1.4 Organizational Process Assets
4165 In addition to those described in 7.1.1.4 of the PMBOK® Guide, organizational process
4166 assets for software project cost management include governance documents and the product
4167portfolio.4168
41697.1.1.5 Software Project Charter
4170 In addition to providing the summary budget from which the detailed project costs are
4171developed, the project charter also highlights the overall goals of the project and the
4172project approval requirements that will influence the management of the project costs.
4173These will form the focus for the tradeoff decisions that will be made throughout the
4174project.4175
41767.1.1.6 Direct Cost Drivers
Page 98
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
98/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
4177Estimated size and complexity of software are highly correlated with effort for software
4178projects, and therefore drive software cost; large and more complex products require more
4179 effort. Other cost drivers include skills and abilities of software developers;
4180 interactions among develop team members; relationships with customers and other
4181 stakeholders; and organizational influences. Historical values of these cost drivers and
4182 their impact on effort (i.e., cost) are often maintained as an organizational asset for
4183various domains for which the organization develops software.4184
41857.1.1.7 Governance Policies
4186 In some organizations, top-level executive governance controls the objectives, policies,
4187 and procedures that may have a significant impact on the cost management plans for
4188 software projects. The organizational governance may impose a standard set of estimating,
4189 cost reporting, or software testing or review processes which need to be included in
4190project cost. Particularly for software with safety, security, health, or financial impact
4191 for the users, policies or regulations may impact the governance controls to be built into
4192 the software. These may lead to more complex software that checks to ensure processes are
4193being computed properly (checks and balances in intermediate results, user intervention in
4194 completing or safely terminating a software process), limits access to authorized groups
4195of people who perform some functions (segregation of duties), or preserves audit records
4196of who performed certain functions (such as adjusting a paycheck).4197
4198Operating policies and procedures, and the resulting software functions and controls, may
4199be based on IT governance standards and guidance from sources such as COBIT (Control
4200Objectives in Information and related Technology), COSO (Committee of Sponsoring
4201Organizations of the Treadway Commission), ITIL® (Information Technology Infrastructure
4202Library), CMMI® (Capability Maturity Model Integration), ISO/IEC 20000 (IT Service
4203Management) or ISO/IEC 27000 (Systems and Software Security Engineering). Other inputs to
4204 software project cost include fiduciary requirements or government regulations that
4205mandate the financial and security controls to be built into the software system. For
4206 example, the Sarbanes Oxley Act (SOX Compliance), Basel-III, Health Insurance Portability
4207 and Accountability Act (HIPAA), and others may need to be included in the software project
4208 cost management purview.4209
42107.1.1.8 Portfolios
4211Priorities and constraints on an organizational portfolio of software and projects may
4212provide inputs to planning cost management for a software project. The availability of
4213COTS/Open Source software influences how much of the desired software will have to be
4214original development or new integration/service development work. Even when COTS sources
4215 are available, an organization may decide to add to its portfolio and build new software,
4216developing wholly owned Intellectual Property (IP) for future reuse or resale.4217
42187.1.2 Plan Software Project Cost Management: Tools and Techniques
4219The tools and techniques in Section 7.1.2 of the PMBOK® Guide are also applicable to
4220planning cost management for software projects, with the modifications to 7.1.2.2 and
42217.1.2.3.4222
42237.1.2.1 Expert Judgment
4224See 7.1.2.1 in the PMBOK® Guide.4225
42267.1.2.2. Analytical Techniques
4227Organizations apply historical data and policy to determine the financial control limits
Page 99
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
99/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
4228 and decision thresholds for software projects. This is especially useful for adaptive life
4229 cycle projects where performance data is collected for each cycle of software development.
4230When control limits are set too low, there can be significant overhead and delay
4231 introduced through revisions that require change control. An unacceptable level of risk is
4232 introduced when control limits are set too broadly.4233
42347.1.2.3. Meetings
4235After the preliminary cost management plan is drafted and proposed control limits are
4236 established, a meeting is typically held with the project sponsors to reach agreement on
4237 the cost management plan.4238
42397.1.3 Plan Software Project Cost Management: Outputs
4240The output in Section 7.1.3 of the PMBOK® Guide is also applicable to planning cost
4241management for software projects, with the following modification. In addition, the
4242outputs in 7.1.3.2 – 7.1.3.4 also apply to planning software project cost management.4243
42447.1.3.1 Cost Management Plan
4245The cost management plan for a software project typically includes the level of estimate,
4246units of measure and the cost performance measurement method. The values of these
4247 attributes can differ significantly in for software projects.4248
42497.1.3.2 Level of Estimate
4250The level of estimate accounts for the accuracy of a cost estimate, as compared to actual
4251 cost. In general, software estimation is error-prone, and predicting the accuracy of an
4252 estimate is difficult. A rough order-of-magnitude estimate is typically generated at the
4253 initiation stage of a software project, when requirements are immature, the actual
4254parameters of the development are being formulated, and the development team may or may
4255not have been identified. Estimation accuracy can deviate by as much as ±150% or more at
4256 this point. A budgetary estimate might be created when the requirements or feature set and
4257high-level design is stable or the project team and schedule have been set. This estimate
4258may deviate by ±50%, depending on the complexity of the design, the stability of the
4259 requirements, and the skills of the team that will develop the software. A definitive
4260 estimate for a development cycle of 2-4 weeks might be accurate to within ±10% of actual
4261 cost; however, that depends on factors such as the stability of the design and accurate
4262 translation of the customer’s story into product requirements.4263
4264 Inaccurate estimates made to a high level of precision may not be worth the time and
4265 effort it takes to develop them. Early, rough estimates are more likely to be
4266 cost-effective, provided they are refined as the project evolves and uncertainties are
4267 resolved.4268
42697.1.3.3 Units of Measure
4270The cost management plan for a software project typically includes a definitive unit of
4271measure for each project metric such as person-hours for effort measurement, and a size
4272measure such as Source Lines of Code (SLoC) or Function Points (FPs). More holistic
4273measures of software such as test cases, use cases or user stories are also used. Note
4274 that a large amount of SLoC does not necessarily correspond to higher business value of
4275 the software or to the completion of required software functions in usable software. For
4276 each unit of measure like SLOC and Function Point (FP) it is necessary to introduce a
4277 concept to quantify (e.g., size of function point or SLOC) and a base unit (e.g., data
Page 100
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
100/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
4278movement or statement) that helps to obtain the base quantity (e.g., number of data
4279movements or number of statements).4280
42817.1.3.4 Cost Performance Measurement Method
4282Methods of performance measurement are specified in the cost management plan. Adaptive
4283 life cycle software projects, for example, use performance trends based on estimated
4284 amount of work needed versus the actual work performed to develop working, deliverable
4285 software. This can be reflected in measures such as velocity or earned value reporting for
4286 adaptive life cycle projects and shown in visual presentations such as burn-down charts
4287 and continuous flow diagrams.4288
42897.2 Estimate Software Project Costs
4290The inputs, tools and techniques, and outputs for estimating project costs in Section 7.2
4291of the PMBOK® Guide are applicable to estimating costs of software projects, with the
4292 following clarifications and extensions.4293
4294Software project managers tend to use multiple estimation approaches and then reconcile
4295 the differences among the estimates. Estimates of software project cost may need to
4296 include a number of additional factors beyond development and deployment costs, such as
4297 licensing fees for vendor software included in the software product and infrastructure
4298upgrades for internal systems. Some of these costs may be captured in corporate overhead,
4299 such as the infrastructure resources and tools for development operations. On other
4300projects, infrastructure resources and tools may be seen as direct charges to the software
4301project, or assessed on a per seat basis for the team.4302
4303 • 0Project direct costs. The dynamics of individual performances, team skills,
4304 complexity of the software product, and integration with other systems are critical
4305 success factors for software projects. Because software development projects are
4306 effort-intensive, the primary cost for most software projects is the cost associated with
4307 the people who develop the software. Productivity, skills, and motivation are widely
4308variable among software developers, so effort data from previous projects may not be
4309directly comparable.
4310 • 0Fiduciary requirements and government regulations. Meeting statutory or
4311 regulatory constraints may need to be included in a software project cost estimate.
4312 • 0Standards compliance. Some software projects may include costs for conforming to
4313 standards that are part of the organizational governance framework. However, conformance
4314 to process standards is considered to reduce project risk and cost of rework, resulting in
4315 lower overall life-cycle costs.
4316 • 0Organizational changes. The cost of organizational changes that may impact the
4317 actual cost of a software project is typically included in the cost estimate.
4318 • 0Cost and value risk. For some software projects, the probability that the product
4319may not return the value anticipated can impact the cost planning of the project or lead
4320 to incremental estimates at milestones when the project is re-evaluated.
4321 • 0Funding costs. Additional funding cost factors may include TOC (total ownership
4322 cost), payback period, break-even point, and return on investment. For
4323 iterative-incremental and adaptive life cycle projects, it may be possible to deliver
4324working software early in the development life cycle. This can provide early payback to
4325 the sponsoring organization. The impact of the time-value of money can be reflected in the
4326business case. Benefits that are to be realized from the project or from project’s product
4327 are often considered only after the fact.4328
43297.2.1 Estimate Software Project Costs: Inputs
4330The inputs for estimating project costs in Section 7.2.1 of the PMBOK® Guide are
4331 applicable to estimating costs of software projects, with the modification of 7.2.1.3 –
Page 101
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
101/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
43327.2.1.5. In addition, the inputs in 7.2.1.8 and 7.2.1.9 apply.4333
43347.2.1.1 Cost Management Plan
4335See Section 7.2.1.1 in the PMBOK® Guide.4336
43377.2.1.2 Human Resource Plan
4338See Section 7.2.1.2 in the PMBOK® Guide.4339
43407.2.1.3 Scope Baseline
4341Theoretically, the fixed scope and requirements set of a predictive project can result in
4342 a reliable initial cost estimate. In contrast, many successful large software projects use
4343 feature driven delivery (FDD) where high-level scope and a set of candidate features, use
4344 cases or “epics” (complex, overarching user stories) are defined early in the project and
4345 are then evolved as uncertainties are resolved. Using an adaptive approach for a software
4346project intentionally limits upfront planning to high-level scope, which in itself may not
4347be a sufficient basis for an accurate initial cost estimate.4348
43497.2.1.4 Project Schedule
4350As described in Section 6 of this software extension, adaptive software project life
4351 cycles make minimal initial plans and evolve the plans, including the project schedule, as
4352 the project evolves. The schedule versus priority of features to be implemented is
4353 continually evolved.4354
43557.2.1.5 Risk Register
4356As described in Section 11 of this software extension, all projects (predictive,
4357 iterative-incremental, or adaptive) can benefit from initial risk analysis. Confidence in
4358 a cost estimate is dependent on the probability of and the potential impact of identified
4359 risk factors, such as the availability of subject matter experts (SMEs). Opportunity
4360management is also pursued to identify opportunities for cost savings and additional
4361 investment/benefit returns. Risk analysis is particularly important in estimating the cost
4362 and price to be bid for a competitively sourced software project.4363
43647.2.1.6 Enterprise Environmental Factors
4365The level and maturity of the product architecture, whether for a single product or the
4366 entire enterprise, has a significant impact on the effort and thus the cost of software
4367development. Use of an existing architecture often lowers the amount of effort required
4368 for design, while it imposes constraints on the solution, particularly in the use of COTS
4369or other non-developmental items. Once architectural decisions are made, some development
4370 tasks can be performed in parallel, thus allowing shorter schedules at higher completion
4371 rates. The result for the cost estimate is a reduced time span when the LOE costs of the
4372 supporting processes such as the PM, CM, and QA are needed.4373
43747.2.1.7 Organizational Process Assets
4375See Section 7.2.1.7 in the PMBOK® Guide.4376
43777.2.1.8 Software Size and Complexity
Page 102
4378Software size and complexity are the most important factors that affect software cost, so
4379 size is a key input to most cost models. Deriving an appropriate size estimate is neither
4380 straightforward nor trivial, due to uncertainty of the requirements. Even during late
4381 stages of software development, the process of sizing is subject to wide variations.
4382Sizing techniques include analogy, expert judgment (including Delphi), historical data,
4383 rules of thumb, and estimation algorithms (calibrated using local historical data).
4384Because of the uncertainties associated with size estimation, estimators typically use
4385more than one approach to estimating size. Sizing estimates are typically revised
4386periodically as the overall cost estimate is updated.4387
4388Often, software estimates are made on small parts and rolled up (bottom-up estimation). If
4389 estimates are made only on the work to be performed to complete the software components,
4390 the cost of integration and testing of the integrated components is added. Continuous
4391 integration and testing is a key aspect of adaptive software projects.4392
43937.2.1.9 Rate of Work for Software Projects
4394Organizations with stable cross-functional teams that have worked together over time can
4395 establish a predictable rate for producing working, deliverable software. This rate is
4396 called velocity; it can be used to provide accurate estimates across the full scope of
4397 software development.4398
43997.2.2 Estimate Costs: Tools and Techniques
4400After determining the project and product scope, and planning software project cost
4401management, the software project manager and project team can estimate the cost to deliver
4402 the product. The first level of estimation is typically a preliminary high-level estimate
4403based on features to be implemented, which is used to drive initial planning. The goal of
4404 initial estimation is to quickly converge on a reasonable high-level estimate. Analogies,
4405historical data, and expert judgment are typically used at this point.4406
4407Experts may be asked, either individually or as a group (perhaps using a Delphi process),
4408 to develop estimates. Since each expert may use a different estimation method, some
4409perspective on the realism of individual estimates is provided. This approach may be time
4410 consuming, and is only as good as the experts’ judgment. It can be especially useful when
4411 a software project involves new technologies.4412
4413 • 0Estimation Units. The units of measure adopted by a project team or a software
4414organization used to estimate project work may be in work units or ideal time. Both
4415 approaches exclude non-programming time and non-development time.
4416 • 0Work Units. A work unit is a relative measure that is not treated as actual
4417 effort and time. Implementation of function points, for example, can be used to determine
4418 the relative amount of work required to implement a software feature, compared to
4419 implementing function points for other similar features. After a team has worked through
4420 several iterative cycles together and achieved a consistent velocity, their work units can
4421be more accurately aligned to units of actual time and effort.4422
4423Some adaptive methods utilize story points or use case points for estimating. A story
4424point is an approximation of the complexity of software functions, as expressed in a
4425narrative of user interactions with the system (the user story). Story points are
4426 comparisons of the complexity of a new story to a well-defined base story commonly
4427understood by the team. Story points are then awarded from a specific range of values in
4428 comparison to the base story. Some teams use a story point range defined as a modified
4429Fibonacci sequence [i.e., 1, 2, 3, 5, 8, 13, 20, 40, 100] to scale the complexity of
4430 stories. If the base story represents 5 story points, then a 3-point story would take 60%
4431of the base story's work to complete. Note that these are relative rather than absolute
4432values, and may differ from team to team and project to project, limiting their
Page 103
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
103/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
4433 applicability across an organization or generally.4434
4435 • 0Ideal Time. The time expected for an “ideal” software developer or a development
4436 team to deliver a feature or complete another task, without regard to actual time used for
4437distractions, overhead functions, lost time such as holidays or to recover from disasters
4438 such as lost code.4439
4440The tools and techniques for estimating project costs in Section 7.2.2 of the PMBOK® Guide
4441 are applicable to estimating costs of software projects. They are expert judgment,
4442 analogous estimating, parametric estimating bottom-up estimating, three-point estimating,
4443 reserve analysis, cost of quality, project management software, vendor bid analysis, and
4444group-decision making techniques. The following modifications and additions (7.2.2.11 –
44457.2.2.15) also apply.4446
44477.2.2.1 Expert Judgment
4448See Section 7.2.2.1 of the PMBOK® Guide.4449
44507.2.2.2 Analogous Estimating for Software Projects
4451A software project team that has worked together to develop software in the past can
4452 effectively estimate the number of work units they can deliver in a given amount of time.
4453Some algorithmic approaches utilize analogous historical values of productivity to
4454 estimate future projects. Early estimates are often based on nominal measures such as
4455 small, medium, and large.4456
4457Software development teams, when using an adaptive approach, develop the ability to
4458 estimate their velocity more accurately. A team’s velocity (amount delivered over a given
4459period of time) can be used to estimate future effort. Velocity becomes a more accurate
4460predictor after a team has completed several iterations together; it may not be applicable
4461 for a team that has not worked together until some performance data on the current project
4462 is collected.4463
44647.2.2.3 Parametric Estimation Models for Software Projects
4465Software project managers use most of the estimation models listed in the PMBOK® Guide,
4466but different approaches are used in different situations. Parametric estimation models
4467 are used to make estimates for large-phased projects, where the law of large numbers can
4468 compensate for variation in individual productivity. Analogy and expert judgment are used
4469 as for most software projects, particularly for small, highly adaptive life cycle
4470projects.4471
4472Widely used software estimation models typically include a primary estimation algorithm
4473with parametric adjustment factors for specific cost drivers derived from historical data.
4474These models are calibrated for the specific software development organization,
4475 infrastructure tools, complexity of the software to be developed, and experience or
4476 ability of the team personnel, in order to produce reasonably accurate estimates. Most
4477 estimation models for software projects use some measure of product size as the primary
4478 input variable, such as source lines of code or function points. Some models permit the
4479 estimator to use raw data on the size of the project, effort, and cost drivers to
4480 calibrate the own model. Some models include functions to adjust the effort based on the
4481 size of the projects and cost drivers. COCOMO II is an example of a software estimating
4482model. There is little established common data from industry with which to calibrate a
4483predictive or parametric model, particularly since the infrastructure tools and methods
4484used on projects are frequently changed for newer technology, and the historical
4485productivity data is often closely held by an organization.4486
Page 104
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
104/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
44877.2.2.4 Bottom-Up Estimating for Software Projects
4488Bottom-up estimation is often used to estimate effort and cost of software projects. The
4489 large number of variables that can impact an estimate requires making many assumptions
4490that need to be documented (and tracked in the risk register as well). It is also
4491 important to include, in the cost estimate, the effort to integrate and test the software
4492 components.4493
44947.2.2.5 Three-Point Estimating for Software Projects
4495Estimating software code size can be based on expert judgment and the three-point PERT
4496 algorithm. Experts estimate code size as SL, (the smallest size); and SM (the 50% probable
4497 size), and SH (the largest likely size) for each software component. Lowest likely and
4498 largest likely sizes are stated at certain levels of probability (typically 5% and 95% or
449920% and 80% probable). The PERT algorithms are used to estimate the mean and standard
4500deviation of size ranges for each software component and the mean and standard deviation
4501 for the collection of components. These probability distributions can be used to calculate
4502 effort at various level of probable size.4503
45047.2.2.6 Reserve Analysis for Software Projects
4505PERT three-point estimates, analogy estimates, and algorithmic estimates may be used to
4506 establish the reserve, at a given level of probability, to be included in the project
4507 estimate and the project budget. Historical project artifacts can also be analyzed to
4508 support the amount of reserve to be included for a new project by determining the
4509difference between the known effort at the start of the last project and the amount of
4510 effort that was eventually required to deliver the project.4511
45127.2.2.7 Cost of Quality for Software Projects
4513Cost of quality and the cost of other nonfunctional requirements exert a significant
4514 impact on software cost estimation. High quality (such as safety-critical or
4515mission-critical software) can multiply the effort and thus the cost of development.
4516 Identifying quality-critical features and function up front can reduce the overall cost,
4517 as opposed to testing them in at the end of a software project. Failure Modes and Effects
4518 and Criticality Analysis (FMECA) and the processes in RTCA DO-178B/C for safety-critical
4519 avionics software are systems engineering tools that support identification of
4520quality-critical cost factors. Also, results chains and business process analyses can
4521 identify high cost but possibly low-value, nonfunctional requirements. Such nonfunctional
4522 requirements can be expensive to implement and undetectable by the user in the operating
4523 environment.4524
4525At the same time, failing to estimate and include the cost of resources needed to meet
4526 legitimate requirements for performance, security, safety and other nonfunctional
4527 requirements can inhibit market or customer acceptance and cause huge additional costs in
4528 rework at the end of a project when the rework is most expensive. The cost impact of
4529making software readily usable by humans for real-time, critical functions (and
4530demonstrating its usability) is another aspect of the cost of quality.4531
4532Cost of quality also includes the cost to fix functional or technical defects found in the
4533 course of the project. These costs include effort associated with reestablishing the
4534development environment to verify fixes, interrupting the flow of value-added work, and
4535updating project artifacts related to the defective code. These costs of rework can be
4536 considerable and are very difficult to anticipate at the beginning of a project.4537
4538For adaptive life cycle software projects with stable teams and a history of delivery, a
Page 105
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
105/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
4539historical velocity (analogy estimating) may be used to account for much of the cost of
4540quality. In other projects, expert judgment, estimating models, and reserve analysis from
4541prior projects can be used to establish a management reserve to handle the uncertainty
4542 associated with the cost of quality.4543
4544A key to reducing these costs in adaptive life cycle projects is gathering feedback early
4545 in the process. See also Section 8 of the PMBOK® Guide for more information on the cost of
4546quality for software projects.4547
45487.2.2.8 Project Management Software
4549See Section 7.2.2.8 of the PMBOK® Guide.4550
45517.2.2.9 Vendor Bid Analysis
4552See Section 7.2.2.9 of the PMBOK® Guide.4553
45547.2.2.10 Group Decision-Making Techniques
4555See Section 7.2.2.10 of the PMBOK® Guide.4556
45577.2.2.11 Time-Boxed Estimating for Software Projects
4558Adaptive projects that are time-boxed with an evolving product scope take care that their
4559 cost estimates are not just Level of Effort (LOE) aggregates. The resources available and
4560 the current production rate determine cost. For example, if a backlog of software features
4561 is required to be delivered in 12 months and 5 people are available, then the effort will
4562be 60 person-months. Although this approach sometimes produces an accurate estimate, care
4563must be taken because it may provide unrealistic estimates unless the requirements and
4564 features to be included are scaled to what can be done by those 5 people in 12 months.4565
45667.2.2.12 Function Point and Source Lines of Code Estimating
4567Historically, the estimated number of source lines of code [SLOC] or function points is
4568used as the primary input variable for effort estimation. Function point estimates are
4569 considered more accurate and more easily applied from one project to another, since SLOC
4570vary significantly by programming language and by programmer for the same function.
4571 ISO/IEC 20926, Software and systems engineering—Software measurement—IFPUG functional size
4572measurement method 2009, provides a guide for software size estimation.
4573
45747.2.2.13 Adaptive Story Point Estimating
4575The use of adaptive life cycles for software projects avoids a complete upfront
4576 requirements or product design decomposition to make a baseline estimate. These projects
4577 intentionally use different sizing units than are traditionally used to estimate software
4578 size. The values assigned to the estimation units are specific to each software project
4579 and are not generally transferable to other projects. The values are used in the context
4580of a project and are not compared to similarly named units in other projects.4581
45827.2.2.14 Estimating Reusable Code Effort
4583Software project estimators take into account whether software code will be developed from
4584 scratch, will be reused as is, adapted from a previous project, or some combination
4585 thereof. The amount of effort required to reuse code without modification may be small.
Page 106
4586 Integration testing to check that the reused code was integrated correctly may be all that
4587 is required. In some cases, additional effort may be required to modify the existing code
4588base to accommodate the reused code. Adapted code requires some amount of redesign,
4589 recoding, and testing. The amount of effort required depends on the amount of modification
4590 required. It is possible that (1) the adapted code may have the correct design but
4591 requires conversion because the new software is in a different language; or (2) the
4592 adapted code may require some amount of redesign to change or add capabilities. Some
4593 estimation models include parameters to account for estimated effort of reuse.4594
45957.2.2.15 Price-to-Win for Software Projects
4596A further step from estimating the cost of performing a software project is estimating the
4597price. Especially in competitive acquisitions, price is cost plus profit or fee, that is,
4598what the customer pays. The price-to-win needs to be a price the customer is willing to
4599pay (not exceeding the customer's budget for the project), and slightly lower than other
4600 competitors are expected to bid, but not so low that it will be rejected by the customer’s
4601 evaluators as unreasonable or showing that the supplier does not understand the project. A
4602 risk evaluation is performed on the price to win (as described further in Section 11) so
4603 that the risk of having to perform the project at that price is acceptable to the
4604 supplier’s organization. (This discussion ignores the competitive strategy of bidding a
4605 small project at a price with a low probability of being profitable, or even below the
4606most likely cost, with the intention of gaining experience or intellectual property for
4607 future, more profitably priced projects.)4608
46097.2.3 Estimate Software Project Costs: Outputs
4610The outputs in Section 7.2.3 of the PMBOK® Guide are applicable for estimating software
4611project costs.4612
46137.2.3.1 Activity Cost Estimates
4614See Section 7.2.3.1 of the PMBOK® Guide.4615
46167.2.3.2 Basis of Estimates
4617See Section 7.2.3.2 of the PMBOK® Guide.4618
46197.2.3.3 Project Documents Updates
4620See Section 7.2.3.3 of the PMBOK® Guide.4621
46227.3 Determine Software Project Budget
4623The inputs, tools and techniques, and outputs for determining budget in Section 7.3 of the
4624PMBOK® Guide are applicable to determining the budget for software projects.4625
46267.3.1 Determine Software Project Budget: Inputs
4627The inputs for determining budget in Section 7.3.1 of the PMBOK® Guide are applicable to
4628determining the budget for a software project.4629
46307.3.1.1 Cost Management Plan
Page 107
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
107/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
4631See Section 7.3.1.1 of the PMBOK® Guide.4632
46337.3.1.2 Scope Baseline
4634See Section 7.3.1.2 of the PMBOK® Guide.4635
46367.3.1.3 Activity Cost Estimates
4637See Section 7.3.1.3 of the PMBOK® Guide.4638
46397.3.1.4 Basis of Estimates
4640See Section 7.3.1.4 of the PMBOK® Guide.4641
46427.3.1.5 Project Schedule
4643See Section 7.3.1.5 of the PMBOK® Guide.4644
46457.3.1.6 Resource Calendars
4646See Section 7.3.1.6 of the PMBOK® Guide.4647
46487.3.1.7 Risk Register
4649See Section 7.3.1.7 of the PMBOK® Guide.4650
46517.3.1.8 Agreements
4652See Section 7.3.1.8 of the PMBOK® Guide.4653
46547.3.1.9 Organizational Process Assets
4655See Section 7.3.1.9 of the PMBOK® Guide.4656
46577.3.2 Determine Software Project Budget: Tools and Techniques
4658The tools and techniques for determining budget in Section 7.3.2 of the PMBOK® Guide are
4659 applicable to determining the budget for a software project, with the modification of
46607.3.2.2.4661
46627.3.2.1 Cost Aggregation
4663See Section 7.3.2.1 of the PMBOK® Guide.4664
46657.3.2.2 Reserve Analysis for Software Projects
4666A software project budget is based on the sum of estimates for all identified work plus an
4667 additional reserve for work that will potentially emerge. During the project, reserved
4668budget is either applied to meet contingencies or preserved as surplus or profit. Ideally,
4669 as the project progresses and the risks and uncertainties are resolved, the amount of
4670 reserve needed is reduced to zero by the end of a project. When charted over time, the
4671
Page 108
amount of reserve needed looks like a cone (the “cone of uncertainty,” large at the
4672beginning of the project and narrowing to zero by the end of the project).The reserve may
4673be divided between the amount that the project manager can use directly and the management
4674 reserve, which will require authorization to be applied to the project. Adaptive projects
4675 that adjust to changes in priorities and rolling-wave planning may find that the level of
4676uncertainty remains higher throughout the project, affecting the need for a budgeted
4677 reserve. Conversely, after several iterations, the adaptive project team may have
4678developed a consistent idea of velocity and lowered risk of needing the management reserve
4679 to finish the work.4680
46817.3.2.3 Expert Judgment
4682See Section 7.3.2.3 of the PMBOK® Guide.4683
46847.3.2.4 Historical Relationships
4685See Section 7.3.2.4 of the PMBOK® Guide.4686
46877.3.2.5 Funding Limit Reconciliation
4688See Section 7.3.2.5 of the PMBOK® Guide.4689
46907.3.3 Determine Software Project Budget: Outputs
4691The outputs for determining budget in Section 7.3.1 of the PMBOK® Guide (7.3.3.1 –
46927.3.3.3) are applicable to determining the budget for software projects.4693
46947.3.3.1 Cost Baseline
4695See Section 7.3.3.1 of the PMBOK® Guide.4696
46977.3.3.2 Project Funding Requirements
4698See Section 7.3.3.2 of the PMBOK® Guide.4699
47007.3.3.3 Project Documents Updates
4701See Section 7.3.3.3 of the PMBOK® Guide.4702
47037.4 Control Software Project Costs
4704The inputs, tools and techniques, and outputs for controlling costs in Section 7.4 of the
4705PMBOK® Guide are applicable to controlling costs of software projects, with the following
4706 clarifications.4707
4708Effective software project managers constantly monitor changes to stakeholder requirements
4709 and other changes as they evolve to analyze their potential impact on project cost. Some
4710 changes will be “in scope” and require no changes to effort allocations (and therefore
4711 cost) and other changes may be “out of scope” and will require changes to effort (cost)
4712 and schedule. This is especially important for adaptive life cycle software projects
4713because stakeholder requirements are dynamic in nature, and changes can occur rapidly as
4714 the project progresses. Also, different organizations and their customers use different
4715 cost accrual methods for measuring software project success. For example, a project
4716deliverable may be considered as value-adding after successful integration and
Page 109
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
109/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
4717verification testing by some organizations and their customers, while others may consider
4718 it value-adding only after successful user acceptance testing and product acceptance.4719
47207.4.1 Control Software Project Costs: Inputs
4721The inputs for controlling costs of software projects in Section 7.4.1 of the PMBOK® Guide
4722 are applicable to controlling costs of software projects.4723
47247.4.1.1 Project Management Plan
4725See Section 7.4.1.1 of the PMBOK® Guide.4726
47277.4.1.2 Project Funding Requirements
4728See Section 7.4.1.2 of the PMBOK® Guide.4729
47307.4.1.3 Work Performance Data
4731See Section 7.4.1.3 of the PMBOK® Guide.4732
47337.4.1.4 Organizational Process Assets
4734See Section 7.4.1.4 of the PMBOK® Guide.4735
47367.4.2 Control Software Project Costs: Tools and Techniques
4737The tools and techniques for controlling costs of software projects in Section 7.4.2 of
4738 the PMBOK® Guide are applicable to controlling costs of software projects, with the
4739 following modification of 7.4.2.1 and 7.4.2.2, and the addition of 7.4.2.8.4740
47417.4.2.1 Earned Value Management for Software Projects
4742Earned value management, as applied to projects that produce physical artifacts, and as
4743 applied to predictive life cycle software projects, is concerned with measuring cost and
4744 schedule progress against an overall plan for cost, schedule, and delivered work products.
4745Earned value reporting can be successfully applied to predictive software projects
4746provided the work products are tracked using control gates that give no credit for work in
4747progress until the work product successfully satisfies its pre-specified acceptance
4748 criteria (i.e., binary tracking). Actual cost and schedule for completing the work product
4749 is then compared to planned (i.e., budgeted) cost and schedule to develop cost and
4750 schedule performance indices (CPI and SPI) that are used to project the estimate at
4751 completion (EAC), estimate to complete (ETC), and estimated completion date (ECD) using
4752values of the current CPI and SPI. Periodic updating of CPI and SPI, based on accumulation
4753of past performance and recent performance, provides increasingly accurate values of EAC
4754 and ECD. This approach, based on objective acceptance criteria for work products and
4755binary control gates, can provide accurate tracking information and avoids the 95%
4756 complete syndrome that commonly occurs for predictive life cycle software projects.4757
4758For adaptive life cycle software projects, a detailed project plan is not developed
4759upfront; the initial project plan typically provides estimates at a high level of project
4760 scope, based on estimates for implementing the identified product features. The plan is
4761 elaborated in detail as the project evolves: new features emerge and existing features are
4762 elaborated (much like rolling wave planning for predictive software projects). As software
4763 is delivered in increments of working, deliverable software, earned value management
Page 110
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
110/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
4764 focuses on directly measuring the performance of delivered product increments versus
4765 allocated time and effort to develop the product increments.4766
4767Adaptive development of software evolves in an iterative, nonlinear fashion, with feedback
4768 loops that affect the initial plan. Frequent changes are to be expected throughout the
4769project life cycle, thus measuring progress relative to the initial plan can be misleading
4770unless the plan is frequently updated. Project management techniques for adaptive life
4771 cycle projects, such as burn charts that indicate the amount of functionality delivered
4772over time versus the amount of functionality remaining to be developed, provide status and
4773progress information very similar to earned value measurement for predictive life cycle
4774projects. Costs can be added to the charts to view cost performance together with rate of
4775 feature completion.4776
4777For predictive life cycle projects, deviations from the budgeted actual cost and scheduled
4778 completion date may indicate the need to: (1) apply contingency reserve funds and reserved
4779 schedule time to bring project performance into alignment with the project plan; (2)
4780modify the plan to reflect actual performance; or (3) use a combination of updating the
4781plan and applying contingency reserves. For adaptive projects, additional effort and
4782 schedule may be allocated to a feature when detailed planning shows more time and effort
4783 is needed than was estimated, provided the allocations are within the bounds of control
4784 accounting. Change control is exercised to access management reserve when the control
4785 reserve is exhausted.
4786
47877.4.2.2 Forecasting for Software Projects
4788Desirable attributes of a software development forecasting method include providing
4789 credible estimates in a short amount of time, quickly communicating the need for decisions
4790or actions, and empowering the project sponsors to choose how their software development
4791 funds are to be spent. Earned value tracking, burn-down charts, and cumulative flow
4792diagrams (CFDs) provide indicators of the costs expended to-date on a project and provide
4793 forecasts of project cost at completion. Earned value charts, burn-down charts, and
4794 cumulative flow diagrams typically report cost in units of labor (i.e., staff-hours) or in
4795monetary units that account for labor costs or may include additional costs.4796
4797The information is presented as calculated amounts, but it is the visibility of the charts
4798 that is most valuable to project managers, software teams, and other stakeholders. The
4799 charts indicate cumulative progress, how much effort or money is being expended on the
4800project, and how much remains to be done. This is important because it represents the
4801 amount of effort or money needed to keep the project operational regardless of the amount
4802of work assigned to be done. A simple calculation of the resources that are needed, the
4803percentage of allocation, and all costs associated can be placed on the earned value,
4804burn-down or cumulative flow chart. Often there is a major effort to re-estimate and
4805 re-baseline a large project and significant customer discussions may occur concerning
4806 scope adjustment and the deferral and prioritization of product features. On smaller
4807projects, it may be simpler to do an extrapolation of how the cost and schedule need to be
4808 adjusted in order to deliver the desired software functionality and to then adjust the
4809 scope to stay within budget. Cost is controlled as an independent variable. It is up to
4810 the economic decision maker to adjust the functionality to be developed so that it can be
4811 completed within the specified budget and time, or to adjust the budget and time, or some
4812 combination thereof.4813
48147.4.2.3 To-Complete Performance Index (TCPI)
4815See Section 7.4.2.3 of the PMBOK® Guide.4816
48177.4.2.4 Performance Reviews
4818
Page 111
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
111/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
See Section 7.4.2.4 of the PMBOK® Guide.4819
48207.4.2.5 Project Management Software
4821See Section 7.4.2.5 of the PMBOK® Guide.4822
48237.4.2.6 Reserve Analysis
4824See Section 7.4.2.6 of the PMBOK® Guide.4825
48267.4.2.7 Management Metrics for Software Projects
4827Earned value graphs, burn-down charts, and cumulative flow diagrams that are based on
4828planned versus actual cost, time, and product features depict the software cost
4829measurement for project control.4830
4831 • 0Earned value graphs. A traditional earned value graph for a predictive life cycle
4832project displays budgeted and actual cost on the vertical axis versus time on the
4833horizontal axis. Cumulative trend lines based on periodic earned value reports display the
4834deviations of planned versus actual cost and planned versus schedule progress as well as
4835 the projections of estimated actual cost and estimated completion date versus the
4836 estimated actual cost and estimated completion date.
4837 • 0Burn-down charts. A burn-down chart is a graphical representation of remaining
4838work versus time. The remaining work (i.e., backlog) is typically displayed on the
4839vertical axis, with time along the horizontal. A burn-down chart is thus a run chart of
4840 remaining work. It can be used to visualize project completion. A set of previous
4841burn-down charts can provide trends for the project. A typical burn-down chart is shown in
4842Section 10.2.3.7.
4843 • 0Cumulative flow diagrams. As shown in Section 6, cumulative flow diagrams (CFDs)
4844provide a method for tracking the progress of adaptive life cycle projects. CFDs
4845 communicate absolute progress while visually providing a proportional message of total
4846 completeness because they plot both the total scope and the progress of individual
4847 activities. These diagrams can be correlated with resource expenditures to support cost
4848 control. They can also be used to track flow attributes such as work in progress and lead
4849 time for specific tasks or features.4850
48517.4.3 Control Software Project Costs: Outputs
4852The outputs in Section 7.4.3 of the PMBOK® Guide are applicable to controlling the costs
4853 for software projects..4854
48557.4.3.1 Work Performance Information
4856See Section 7.4.3.1 of the PMBOK® Guide.4857
48587.4.3.2 Cost Forecasts
4859See Section 7.4.3.2 of the PMBOK® Guide.4860
48617.4.3.3 Change Requests
4862See Section 7.4.3.3 of the PMBOK® Guide.4863
Page 112
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
112/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
48647.4.3.4 Project Management Plan Updates
4865See Section 7.4.3.4 of the PMBOK® Guide.
4866
48677.4.3.5 Project Documents Updates
4868See Section 7.4.3.5 of the PMBOK® Guide.4869
48707.4.3.6 Organizational Process Assets Updates
4871See Section 7.4.3.6 of the PMBOK® Guide.4872
48738 Software Project Quality Management
4874According to the PMBOK® Guide, Project Quality Management includes the processes and
4875 activities of the performing organization that determine quality policies, objectives, and
4876 responsibilities so that the project will satisfy the needs for which it was undertaken.
4877Project Quality Management involves three main processes: Plan Quality, Perform Quality
4878Assurance, and Perform Quality Control. Figure 8-1 provides an overview of software
4879project quality management. Most of the tools and techniques for project quality
4880management in Section 8 of the PMBOK® Guide are applicable to software projects. This
4881 section presents considerations that are unique to, or especially important when planning
4882 software quality management, performing software quality assurance, and controlling
4883 software quality. This section also discusses how software quality is defined and how
4884 software project managers plan for, perform, and control software quality management. This
4885 section covers both product quality and process quality; that is, how software managers
4886 and teams plan for, perform, and control the processes to ensure the quality of the
4887delivered software product, and how to improve the quality of processes used on software
4888projects and in software organizations.4889
4890Software quality is relative, and not an absolute to be attained. The PMBOK® Guide defines
4891quality as delivered performance: “the degree to which a set of inherent characteristics
4892 fulfill requirements.” The definition from software engineering is similar: “the degree to
4893which a software product satisfies stated and implied needs when used under specified
4894 conditions.” [21]. To paraphrase Drucker: “Quality of a software product or service is not
4895what the developers put in. It is what the customer gets out and is willing to pay for”
4896 [22]. For example, a software product used for checking the whereabouts of one’s friends
4897may not need the same qualities of timeliness, accuracy, and precision as software used to
4898guide missile trajectories. Attainment of high levels of quality attributes is more
4899prevalent in critical software, which has impact on human health, safety, and welfare, and
4900 for the protection of personal or business proprietary information.4901
4902Quality reflects the requirements or needs, which may initially be unstated. As previously
4903discussed in Section 5, skilled software engineers elicit needs from the software users
4904 and other stakeholders. ISO/IEC/IEEE Std 830 provides an extensive list of the types of
4905 requirements that should be considered but sometimes are not. Nevertheless the project
4906needs to generate an acceptable level of quality in fulfilling those requirements.4907
4908The PMBOK® Guide states that performing quality assurance is the process of auditing the
4909quality requirements and the results from quality control measurements to ensure that
4910 appropriate quality standards and operational definitions are used; and that quality
4911 control is the process of monitoring and recording results of executing quality activities
4912 to assess performance and recommend necessary changes. See also [31].4913
4914Software Quality Assurance (SQA) is primarily concerned with assessing and improving the
4915quality of the processes used to develop software. Because software is developed by
4916 individuals and teams who use processes and apply tools and techniques, it is a
Page 113
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
113/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
4917 fundamental principle in software engineering that high-quality processes, when executed
4918by competent personnel, result in high-quality products. Software Quality Control (SQC) is
4919primarily concerned with the methods, tools, and techniques applied to the software work
4920products (including but not limited to software code) to ensure that the work products
4921will satisfy the quality requirements in a cost-effective manner.4922
4923Successful software development organizations follow consistent and repeatable processes
4924 and focus on improving those processes over time. This approach results in improvements in
4925 the resulting software products and advantages for the producing organization. These
4926improving processes are not rigidly segmented steps, but allow room for learning and
4927 adjustment to situation-specific judgment during software development. Mature teams find a
4928balance between process rigor and situation-specific decision-making. SQA and SQC play
4929 critical roles in helping the development organization tune their processes to maximize
4930performance and achieve the potential for project success.4931
4932 In organizations that use predictive approaches to software development, software quality
4933 assurance (SQA) and software quality control (SQC) have prominent roles near the end of
4934 the life cycle, using an independent interpretation of the requirements as the control.
4935This deferred involvement of QA can lead to great pressure on project management, eager to
4936 release the software and complete the project, to ignore or suppress quality findings of
4937 software defects and to shortened or inadequate software testing.4938
4939For reasons of objectivity in evaluating quality, the PMBOK® Guide recommends independence
4940of quality audits. Independence can be obtained by using a third-party organization for
4941quality control, setting up a different line of reporting for the QC person on the
4942project, or at the least, having a different developer perform peer review or unit tests.4943
4944Mature teams work together in collaboration to achieve quality, rather than viewing QC as
4945 an adversary. In smaller projects, SQA personnel may even be members of the development
4946 team. While larger organizations may mandate a separation of SQA and SQC personnel from
4947development activities, so that SQA and SQC can investigate, audit, and recommend changes
4948based on newly recognized opportunities or issues that arise, collaborative exploration is
4949 still easily achieved within cross-functional product teams. On the other hand, when SQA
4950 and SQC are independent functional groups, and are not included in cross-functional teams,
4951 collaborative exploration of quality issues may be lost and SQA and SQC then become
4952 adversaries to software development.4953
4954The user role in determining whether software has acceptable quality may be played by
4955different persons, depending on the project’s context. In a commercial software product
4956 company, the user may be represented by the product manager or documented in a fictional
4957persona that provides the knowledge, tasks, and interests of a typical user. In an IT
4958 enterprise project, the user may be an authorized subject matter expert in the business
4959processes the software will serve. For a software project conducted under contract, the
4960 accepting authority of the acquiring organization may represent the user. It is important
4961 for software project managers to ensure that the project team understands that the user is
4962 the person or persons who defines what “quality” and ”fit for use” mean in order to
4963 satisfy user needs. However, the project manager must always keep in mind that the users
4964may not be able a priori to enunciate what they really want and need. For this reason, the
4965Project Manager must rely on the expertise of Business Analysts and others who know how to
4966 elicit quality expectations.4967
4968Software quality has been a fundamental issue from the early days of developing algorithms
4969 to perform mathematical calculations quickly and accurately to the present day. Beyond the
4970basic pass/fail questions of whether the software runs and returns a usable result
4971 (sometimes called a software smoke test), the quality attributes for a particular software
4972product may include elements from a very long list, which includes concepts that range
4973 from accessibility, adaptability, analyzability, availability, compatibility, and
4974 complexity, to survivability, testability, understandability, and usability (the
4975well-known “ilities” of software).
Page 114
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
114/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
4976
4977Some software quality attributes are important for users (e.g., efficiency, safety,
4978 security, reliability, availability) while others are important to other stakeholders
4979 (e.g., maintainability is important to those who provide sustainment services). The
4980 ISO/IEC 25010 series of standards provides a complete list of software quality attributes
4981 aligned with different stakeholder needs.4982
4983The complexities of software quality have led to a number of quality views and models such
4984 as those in ISO/IEC 25010 [23] and the other standards referenced in this section. Models
4985 include process quality, product (internal and external) quality, quality in use, data
4986quality, and quality of the software code, which is appraised by inspections or “static”
4987 testing, and by exercising the software in “dynamic” testing.4988
4989From the perspective of process quality, the manager considers: How is the work organized
4990 to produce software? Are the processes efficient and effective in achieving the project
4991 and product goals, and also in building a strong, cohesive team for ongoing work? What
4992methods and tools are used and are they used effectively?4993
4994The internal quality model looks at the software itself as an open “white box,” where
4995 reviewers can directly examine the code and the accompanying artifacts, such as design
4996documents, even as they are being developed. Automated software tools are available to
4997perform many aspects of white-box examination. They include static and dynamic testing
4998 tools that check for code coverage, adherence to coding standards, uninitialized
4999variables, and many other types of coding errors.5000
5001The external quality model treats the software as a “black box”: testers assess how it
5002behaves from the input-output behavior, measure the software’s performance, examine how
5003well it performs its functions, and observe the conditions under which it breaks. External
5004quality assessment is typically accomplished by functional black box testing, which is
5005performed by a testing group or by a representative of the intended user community.5006
5007Even if the software passes predefined evaluations of its internal and external quality,
5008users may still think it lacks quality. The quality in use perspective looks at the impact
5009of the product on users and other stakeholders when it is used in a specific environment
5010 and context. Usability is defined as the degree to which a product or system can be used
5011by specified users to achieve specified goals with effectiveness, efficiency and
5012 satisfaction in a specified context of use [24]. Characteristics of quality in use include
5013 (1) effectiveness (gets the job done), (2) satisfaction (usefulness, trust, pleasure in
5014use, comfort), and (3) freedom from risk (economic risk mitigation, health and safety risk
5015mitigation, environmental risk mitigation).5016
5017A data quality model applies to how structured data is acquired, manipulated, and used by
5018 a computer system to satisfy user’s needs; it includes data that can be shared within the
5019 same computer system or across different computer systems. Some examples of data quality
5020 characteristics are consistency, currency, completeness, precision, and accuracy.5021
5022Figure 8-1 provides an overview of Software Project Quality Management; it is an
5023 adaptation of Figure 8-1 in the PMBOK® Guide.5024
Page 115
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
115/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
5025
5026
5027 Figure 8-1. Software Project Quality Management Overview5028
50298.1 Plan Quality Management
5030Most of the methods, tools, and techniques for planning quality management in Section 8.1
5031of the PMBOK® Guide are equally applicable to software projects. This section presents
5032 considerations that are unique to, or especially important when planning quality
5033management for software projects.5034
5035Planning Software Quality Management for both process and product is an inseparable
5036 element of project planning in general. Determining the scope and goals of the project and
5037 establishing the life cycle processes to be used leads to decisions about how to integrate
5038quality assurance and quality control into the software development processes. Identifying
5039 the criticality of the software and balancing the tradeoffs between quality, schedule, and
5040 cost determine how much emphasis will be given to product quality during the project.
5041Defining what is acceptable quality to meet the users’ needs determines when the product
5042 is ready for release and when the project can be closed. Explicit planning for process
5043 improvement can lead to midcourse changes in projects, as well as result in benefits for
5044 future projects within the organization.5045
5046A significant part of planning software project quality management activities is
5047determining which of the software quality attributes are priorities for a particular
5048project, and how the attributes are specified in the software requirements. Defining what
5049quality attributes will be built into the product, and how the attributes will be measured
5050by SQA and SQC activities, such as testing and reviews, significantly affects the scope
5051 and resources required to successfully plan and execute a software project.5052
5053 ISO/IEC/IEEE Standard 15026 for Systems and software engineering – Systems and Software
5054Assurance [25], is a multi-part standard that provides a comprehensive framework for
5055developing the appropriate assurance case(s) to guide software development projects where
5056one or more critical properties must be achieved.5057
5058Testing provides a good example of how quality management activities span the three key
5059processes of software quality management (planning, performing, controlling): test
Page 116
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
116/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
5060planning is a component of Plan Quality, defect data analysis is a component of Perform
5061Quality Assurance, and test execution is part of Perform Quality Control. But planning for
5062SQA and SQC is more than designating a small group of testers and auditors who are
5063budgeted proportionately to the developer team and scheduled to pick out defects at the
5064 end of a project. Since it is less expensive to “build a little, test a little” than to
5065 spend months developing and integrating a complex system that fails testing, software
5066quality assurance and quality control need to be performed by everyone on the team,
5067 through continuing peer reviews, walkthroughs, inspections, automated regression tests,
5068 and analyses. SQA and SQC is best planned to occur as part of requirements specification,
5069 architecture and data design, and software development, as well as through configuration
5070management and formal testing.5071
5072Adaptive software project life cycles that rely on frequent iterations to produce working,
5073 testable, and deliverable software are well suited for planning an integrated approach to
5074SQA and SQC. For predictive software project life cycles that consist of distinct
5075development phases, SQA and SQC are planned as distinct processes.5076
50778.1.1 Plan Software Project Quality Management: Inputs
5078The inputs for planning quality management in Section 8.1.1 of the PMBOK® Guide are
5079 applicable for software projects. The following considerations also apply to the inputs
5080 for planning software project quality management.5081
5082 In addition to the quality planning inputs identified in the PMBOK® Guide, software
5083project managers typically place emphasis on identifying the stakeholders and the product
5084 requirements, as well as quality statistics from previous projects.5085
5086 In general, software projects fail because the software product does not meet user
5087 expectations of functionality and quality. The software project manager is responsible for
5088 ensuring that all stakeholders understand failure to meet users’ quality expectations will
5089 result in project failure. Project stakeholders can be documented in a stakeholder
5090 register. In addition to the end users and their managers, other stakeholders are those
5091who will affect or be affected by the software product, either while it is under
5092development or during operation after it is delivered. For example, the stakeholders of an
5093 enterprise resource planning (ERP) system include the members of IT operations who will be
5094 responsible for sustaining the ERP system; their concerns will include the
5095 interoperability, performance, and robustness of the system. Each member of the product
5096development team is also a product stakeholder. (See Section 13 of this software extension
5097 for more considerations about communicating with stakeholders.)5098
5099Requirements for software product quality are established when the functional requirements
5100 are established. The quality requirements are an element of the requirements for product
5101 release or product acceptance. In software product companies, the quality requirements are
5102usually included in the market requirements document (MRD). IT projects may simply use a
5103 features/backlog list. If so, the project manager needs to make sure that the quality
5104 requirements are included.5105
5106External customers may not be able to precisely state performance requirements and other
5107nonfunctional quality requirements. A software project manager may need to engage product
5108managers and other appropriate stakeholders in the elicitation of nonfunctional
5109 requirements to determine which quality attributes are most important to the external
5110 customers. Requirements for software product quality may also include regulatory
5111 requirements (e.g., for life-critical systems) and in contractual requirements that may be
5112imposed on component providers and on suppliers of custom-built or customized software
5113 components.5114
5115 Inputs for planning the management of software process quality typically includes quality
5116 analyses from past projects or from previous iterations of the present project. Inputs for
5117 software process quality planning are associated with various quality analyses at the
Page 117
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
117/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
5118 story, iteration or release (e.g., to determine whether code reviews and other types of
5119 evaluations were executed as anticipated and if they were successful); defect find/fix
5120 rates can be examined (to determine whether the numbers are rising or falling); time spent
5121on defect fixes can be examined (to determine if they are adversely impacting planned
5122 feature development and whether reviews and testing are yielding the expected results);
5123 and previous lists of known problems and deferred defects by severity and by feature or
5124module can be investigated (to determine whether there are error-prone areas in the
5125 software).5126
51278.1.1.1 Project Management Plan
5128See Section 8.1.1.1 of the PMBOK® Guide.5129
51308.1.1.2 Stakeholder Register
5131See Section 8.1.1.2 of the PMBOK® Guide.5132
51338.1.1.3 Risk Register
5134See Section 8.1.1.3 of the PMBOK® Guide.5135
51368.1.1.4 Requirements Documentation
5137See Section 8.1.1.4 of the PMBOK® Guide.5138
51398.1.1.5 Enterprise Environmental Factors
5140See Section 8.1.1.5 of the PMBOK® Guide.5141
51428.1.1.6 Organizational Process Assets
5143See Section 8.1.1.6 of the PMBOK® Guide.
5144
51458.1.2 Plan Software Project Quality Management: Tools and Techniques
5146The tools and techniques for planning quality management in Section 8.1.2 of the PMBOK®
5147Guide are applicable for software projects. In addition to the tools and techniques listed
5148below, the following considerations also apply to for planning software project quality
5149management.5150
5151 In addition to the quality planning tools discussed in the PMBOK® Guide, planning for
5152 software quality includes confirming user needs and requirements, cost-benefit analysis
5153 (CBA), cost of quality, developing a testing strategy, and selecting a defect management
5154 and quality control approach. Some comments follow:5155
5156 • 0Planning for software quality. The users may not have experience in defining
5157 their quality expectations as testable requirements; therefore, the project team needs to
5158be adept in eliciting the needed information. This often requires ongoing validation from
5159 the users that the software will meet their needs, using techniques such as prototypes,
5160mock-ups, and other simulations.
5161 • 0Cost benefit analysis. For most software projects, there are trade-offs among the
5162various levels of product quality, the amount of functionality delivered, and the time and
5163 effort required to fix defects. An example of CBA is comparing the cost of testing and
Page 118
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
118/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
5164 rework for different levels of defect removal. Determining an acceptable level of defects
5165may involve comparative benchmark evaluation of the relevant quality attributes in the
5166major competitors’ products. While it is natural for the team to want to correct all
5167problems detected, the software project manager typically does not plan for a
5168 significantly higher amount of defect correction than is warranted by user expectations.
5169For example, depending on the context of the user and user environment, there may be no
5170need to correct a defect that will rarely be encountered and for which there is a
5171work-around.
5172 • 0Cost of quality (COQ). Analyzing and reducing the COQ for software includes costs
5173of the following QC activities:
5174 • Appraisal: cost of finding software defects,
5175 • Internal: cost to fix defects discovered during software development or modification,
5176 • External: cost to fix software defects reported by users, and
5177 • Prevention: cost of eliminating the root causes of software defects.5178
5179Appraisal techniques for software include reviews and inspections of work products
5180 (requirements, design, code, test plans, documentation) and testing and demonstration of
5181working software.5182
5183 In software projects, the cost of quality is not just the relatively small cost of
5184 correcting the code, but the larger costs associated with the testing effort to verify the
5185 change and validate its effectiveness, to communicate the change to all affected parties,
5186 and to change the work products or processes that use the software. This cost is greatly
5187 increased once the software is in use and patches or new versions are released and
5188 applied.5189
5190Software quality planning includes developing a test policy or testing strategy. In
5191 software, the “design of experiments” is captured in the test strategy, as reflected in
5192 test plans and scenarios and the level of test coverage of the code base. Software systems
5193may have thousands of potential branches through the code, which could be exercised with
5194 an infinite range and volume of valid and invalid inputs, running the software with
5195previously developed modules on test hardware with more or less fidelity to the
5196performance of the full production system, in isolation or in combination with other
5197 infrastructure software. Test planning also takes into account the need for rework, data
5198 refresh, and retest, because rarely does one cycle of testing produce completely
5199 acceptable results. Since it is almost never possible, too time-consuming, or not
5200 cost-effective to test everything, part of quality planning is choosing the test strategy,
5201 so that the most valuable and predictive tests are scheduled. Risk-based test strategy
5202 applies design, development and test resources to the areas with the most impact on
5203 successful delivery and use of the software.5204
5205A goal of planning a predictive life cycle software project is to arrange the sequence of
5206work activities to obtain feedback from testing and reviews as early as possible. Software
5207 architects and software designers can help in identifying opportunities to build the
5208 software in a manner that provides early quality feedback.5209
5210When using adaptive software project life cycles, different levels of testing that happen
5211 at different points. Story level testing is the validation of business rules and code
5212quality relevant to the small increment of software that has just been developed by the
5213 team. Verifying the small increments with given inputs and outputs in the same iteration
5214 cycle as development of a software increment finds defects quickly and reduces the cost of
5215 testing later in the project.5216
5217Functional testing (including feature-level testing) includes integration testing as well
5218 as quality-in-use testing across product features. Good practice is to validate the
5219product as early as possible using sample customer databases, to mitigate the risk of
5220 regression in quality. Good practice is to coordinate work across the project so this
5221 level of testing can be performed throughout the project, rather than late in the project.
5222 If these levels of testing are being performed throughout the project, the risk of major
5223defects being identified late in the project is reduced.5224
Page 119
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
119/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
5225The software project manager also needs to plan for processes and systems to identify,
5226 categorize, measure, and treat defects. Defect metrics need to be defined in the project’s
5227 release criteria. Release criteria are a specialized form of testable requirements and
5228provide an input to the software release management or change management process.5229
5230Software defects are generally categorized by severity (how many users will be affected
5231 and how badly). ISO/IEC/IEEE Standard 1044 – Classification for Software Anomalies [26]
5232provides guidance in establishing defect classifications that are generally meaningful for
5233 all software projects. Typically, the acceptable level of defects is specified by the
5234planned kind of release (beta, general availability, customized). It is typical to allow
5235none of the highest category defects to be released, but the percentage of second and
5236 third level defects often depends on the type of release and the user’s expectations.
5237Release criteria are project specific and may involve a level of uncertainty. Defects are
5238balanced against risk considerations (see Section 11 of this software extension). Some
5239users prefer earlier functionality to freedom from noncritical bugs. Some projects in the
5240 safety-critical domain have very high levels of release criteria. Other software products,
5241 such as static web pages, cause very little risk to safety, but may affect reputation if
5242poorly done. Risk management techniques are important in developing a test strategy and
5243 assessing the impact of latent defects not discovered or removed before a software
5244 release.5245
52468.1.2.1 Cost-Benefit Analysis
5247See Section 8.1.2.1 of the PMBOK® Guide.5248
52498.1.2.2 Cost of Quality (COQ)
5250See Section 8.1.2.2 of the PMBOK® Guide.5251
52528.1.2.3 Seven Basic Quality Tools
5253See Section 8.1.2.3 of the PMBOK® Guide.5254
52558.1.2.4 Benchmarking
5256See Section 8.1.2.4 of the PMBOK® Guide.5257
52588.1.2.5 Design of Experiments
5259See Section 8.1.2.5 of the PMBOK® Guide.
5260
52618.1.2.6 Statistical Sampling
5262See Section 8.1.2.6 of the PMBOK® Guide.5263
52648.1.2.7 Additional Quality Planning Tools
5265See Section 8.1.2.7 of the PMBOK® Guide.
5266
52678.1.2.8 Meetings
5268See Section 8.1.2.8 of the PMBOK® Guide.
Page 120
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
120/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
5269
52708.1.3 Plan Software Project Quality Management: Outputs
5271The outputs for planning quality management in Section 8.1.3 of the PMBOK® Guide are
5272 applicable for software projects. The following considerations also apply to the tools and
5273 techniques for planning software project quality management.5274
5275 In addition to the quality planning outputs discussed in the PMBOK® Guide, special
5276 considerations apply to the software quality management plan, quality metrics measurement
5277plan, and quality checklists.5278
52798.1.3.1 Quality Management Plan
5280See Section 8.1.3.1 of the PMBOK® Guide.5281
5282 In addition, a software quality management plan should address configuration management
5283 topics, including: (1) version control of source code, object code, and other artifacts,
5284 and (2) control of a definitive media library for approved file versions and approved
5285product baselines. Practices such as continuous integration, closed-loop change processes,
5286 and iteration retrospectives are typically considered. ISO/IEC/IEEE Standard 730 –
5287Software Quality Assurance Plans [27] contains most of the content to be included in a
5288quality management plan, including detailed requirements for software quality assurance
5289plans.5290
52918.1.3.2 Process Improvement Plan
5292See Section 8.1.3.2 of the PMBOK® Guide.5293
52948.1.3.3 Quality Metrics
5295See Section 8.1.3.3 of the PMBOK® Guide.5296
5297A software quality management plan may also contain the quality metrics measurement plan,
5298 including such elements as software size measures, software quality measures, and
5299 acceptance thresholds. Software size measures are a way to estimate the size of the
5300 software product, which affect the size of the software quality effort. Software measures
5301may be based on lines of code, but those can vary in different programming languages and
5302depend on the elegance of the coding. Lengthier code that is well commented and factored
5303 into functional modules may be easier to maintain than highly compressed code, resulting
5304 in a lower overall cost of quality. Rather than measuring by lines of code, software
5305 functionality is better measured by the number of requirements, function points, number of
5306 features, use cases, user stories, and technical artifacts. Typical software quality
5307metrics relate to the characteristic or attribute being measured and may include churn in
5308 requirements, percent of new requirements, defect find/fix ratios, and trends. Based on
5309 the nature, size, or context of the project, more metrics can be added to address specific
5310quality attributes, such as performance, throughput, resistance to hacking, or usability
5311of the software and documentation.5312
5313The measurement plan, quality management plan, or project management plan may also define
5314how project efficiency and thus process quality will be measured. The most basic
5315measurements, suitable for all types of software projects, are elapsed time and expended
5316 effort (staff-days) per function. Measures of productivity help in planning how quickly
5317 functionality can be produced, including getting found defects corrected. These indicators
5318 reflect the quality of the planning for the iteration/project, and will be input into
5319Project Cost Management (Section 7) and Project Time Management (Section 6). These
5320measurements are essential for projects when pursuing process improvement.5321
Page 121
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
121/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
53228.1.3.4 Quality Checklists
5323See Section 8.1.3.4 of the PMBOK® Guide.5324
5325Checklists are reminders to complete all steps in a procedure or test, either to train
5326developers who are being introduced to new tools or to document that the experienced
5327developers have not inadvertently skipped steps. In software projects, checklists cover,
5328 for example, the steps necessary to run a successful build or to check code in and out of
5329 repositories. They are one of the easiest ways to assure consistency and accuracy in
5330performing repetitive tasks and assuring that the tasks are carried out the same way, no
5331matter who is performing the tasks.5332
53338.1.3.5 Project Documents Updates
5334See Section 8.1.3.5 of the PMBOK® Guide.5335
53368.2 Perform Software Project Quality Assurance
5337Most of the methods, tools, and techniques for Perform Quality Assurance in Section 8.2 of
5338 the PMBOK® Guide are equally applicable to software projects. This section presents
5339 considerations that are unique to or especially important when planning quality management
5340 for software projects.5341
5342The PMBOK® Guide states that Perform Quality Assurance is the process of auditing the
5343quality requirements and the results from quality control measurements to ensure that
5344 appropriate quality standards and operational definitions are used. In software project
5345management, SQA involves a broader view of the entire project to ensure that processes are
5346being performed as documented and are producing acceptable results. In this extension to
5347 the PMBOK® Guide, software quality assurance (SQA) is defined as a set of activities that
5348define and assess the adequacy of the software processes used to develop and modify
5349 software products. SQA provides evidence for a justified statement of confidence that the
5350 software processes will produce software products that conform to their requirements and
5351will satisfy users’ needs.5352
5353SQA thus covers more than audits of requirements and the results of software quality
5354measurements. SQA comprises a full set of planned and systematic activities that can be
5355demonstrated to provide confidence that a product or service will fulfill its requirements
5356 for quality. SQA uses the classic tools of demonstration, inspection, analysis, and
5357 testing (often divided into verification testing and validation testing) as well as
5358 audits. Both SQA and SQC can involve analysis of defects and problems and recommendations
5359 for improvement.5360
5361 IEEE standards that may be useful include ISO/IEC/IEEE Standard 829 – Software and System
5362Test Documentation [28]; ISO/IEC/IEEE Standard 1008 – Unit Testing [29]; and ISO/IEC/IEEE
5363Standard 1012 – System and Software Verification and Validation [30].5364
53658.2.1 Perform Software Project Quality Assurance: Inputs
5366The inputs for performing quality assurance in Section 8.2.1 of the PMBOK® Guide are
5367 applicable to performing quality assurance for software projects.5368
53698.2.1.1 Quality Management Plan
5370See Section 8.2.1.1 of the PMBOK® Guide.5371
53728.2.1.2 Process Improvement Plan
Page 122
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
122/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
5373See Section 8.2.1.2 of the PMBOK® Guide.5374
53758.2.1.3 Quality Metrics
5376See Section 8.2.1.3 of the PMBOK® Guide.5377
53788.2.1.4 Quality Control Measurements
5379See Section 8.2.1.4 of the PMBOK® Guide.5380
53818.2.1.5 Project Documents
5382See Section 8.2.1.5 of the PMBOK® Guide.5383
5384Additional considerations include the following:5385
5386 • 0Inputs for performing software product and process software quality assurance
5387 include the release plan and test plan, project or organizational procedures, project
5388 records and test result records, reports of design and code reviews, inspections, and
5389 audits. Automated tools for requirements management, software configuration management,
5390 release management, and problem management are common sources of records for an SQA review
5391 and audit. In some software projects, there may be documented records demonstrating that
5392 the planned efforts occurred. In other cases, those who are responsible for quality
5393 assurance personally witness the steps to satisfy themselves that the process is working
5394 as planned. On small projects, it may be the development manager or the project manager
5395who assumes this responsibility.5396
5397 • 0In today’s software projects, the SQA team participates during analysis to define
5398 acceptance criteria and test plan details ahead of development. The test plans themselves
5399become part of the requirements communicated to the delivery team. Other inputs for SQA
5400 are various analytical simulations that predict the most likely number of defects to be
5401 expected in the code, based on previous test results, the complexity of the software, the
5402 experience of the developers, and other factors. When this analysis has been performed,
5403 the results are inputs to performing SQA. This information is used to check the validity
5404of the tests results.5405
5406 • 0For software projects that use adaptive life cycles, the details of test plans,
5407 including specific acceptance criteria are progressively elaborated along with the
5408 requirements. Feature-level criteria are developed as part of the analysis and design at
5409 the feature level. Detailed story-level acceptance criteria are defined as part of making
5410 the requirements backlog ready for the development team. This means that the SQA team is
5411 continuously involved with the development team from analysis to acceptance of the
5412delivered increments of software.5413
5414 • 0Inputs also include work performance data, such as work effort and elapsed time
5415 and cost to date, because they will be compared to the project’s plans in order to measure
5416 the variance between the plans and the actual results; burn-down charts are analyzed for
5417 adaptive life cycle projects. By doing this type of comparison at frequent intervals, the
5418project is able to determine where changes may be necessary to procedures or to schedules.
5419Thus, the quality of planning is improved throughout the project.5420
54218.2.2 Perform Software Project Quality Assurance: Tools and Techniques
5422The tools and techniques for performing quality assurance in Section 8.2.2 of the PMBOK®
5423Guide are applicable to performing quality assurance for software projects. Additional
5424 considerations include the following.5425
Page 123
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
123/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
5426For predictive software project life cycles, specialized SQA personnel who are independent
5427of the development process typically conduct SQA activities. That is, developers do not
5428perform acceptance testing on their own work and those responsible for SQA do not report
5429directly to the project manager or software development lead. For predictive software
5430projects, SQA budgets are usually not controlled by the development manager.5431
5432For safety-critical projects, SQA is sometimes conducted by an external group, that is
5433 chartered to ensure that an organization’s software projects and products meet the
5434organization’s and customer’s standards throughout the software project life cycle. These
5435 activities verify the extent to which quality objectives were met, and the effectiveness
5436of the quality control methods and activities are assessed.5437
5438 In adaptive life cycle projects, internal SQA activities are conducted by the project team
5439 itself through techniques such as pair programming, peer reviews5, functional testing, and
5440demonstrations of working software within the development team. Iterative-incremental
5441 software projects typically use a blend of these approaches; story-level testing is part
5442of the development team process while feature-level and release-level testing are
5443 conducted by an external testing group.5444
5445Quality auditors compare actual processes to documented processes by observation and
5446 inspection of records. Quality auditors may discover a lack of documentation or erroneous
5447documentation that needs to be updated. As described in Section 8.2 of the PMBOK® Guide,
5448QA personnel audit the results from quality control measurements to assess whether or not
5449 the quality requirements are being met. If not, the software project manager assures that
5450 action is taken to correct the discrepancies. While adaptive life cycle teams value
5451working, deliverable software over documentation, some level of documentation is necessary
5452 to meet internal and external quality requirements. Quality auditors ensure that project
5453 teams are meeting the necessary level of working, deliverable software and the supporting
5454documentation.5455
5456SQA also includes examination of the volatility of software product requirements. Frequent
5457 changes to requirements can be a warning that there are serious problems in the project.
5458This may indicate that the system boundaries are not well defined, or that affordability
5459 constraints need to be addressed by adjusting the scope of product features for a release.
5460Note, however, that emerging or derived requirements (i.e., those that further elaborate
5461high-level requirements) are not classified as symptoms of volatility. These are simply
5462 refinements. An adaptive development project may begin work on one set of features that is
5463 sufficiently well understood even if other requirements are still unknown or changing, or
5464 the project team may produce a prototype to allow users to agree whether the approach will
5465 fulfill their quality expectations.5466
5467The practice of code reviews (i.e., walkthroughs and inspections), sometimes called static
5468 testing, is one of the most cost-effective methods to remove defects early in the
5469development process and assure code quality. Another technique that supports software
5470quality assurance is frequent testing. Software builds (often on a daily or even
5471 continuous basis) integrate changes to the software and are followed by smoke tests.5472
5473Usability evaluations, in the form of heuristic evaluations or cognitive walkthroughs, are
5474 cost effective at finding defects that might later on require reworking the software.
5475Structured video-recorded usability testing with user representatives, using a
5476 “think-aloud” approach, is also useful for finding defects well before release to the
5477 end-user.5478
5479Quality assurance is integrated into adaptive software project life cycles by the
5480 inclusion of retrospective reviews on each iterative cycle. The retrospective review is
5481used to assess the results of the completed iteration and to plan for process improvements
5482in successive iterations. Retrospectives can sometimes result in finger pointing or may
5483occur at times when the developers are feeling rushed due to insufficient time to produce
5484 features. An important way to overcome any frustration is to make sure that the software
5485developers are involved in the specification of the release criteria, so that they
Page 124
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
124/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
5486understand the goals and will ensure that planning for the next iteration incorporates the
5487needed process changes. This approach contributes to team learning and builds continuous
5488 improvement into the project iterations.5489
5490Process analysis is a foundational element of process improvement. Widely used in other
5491 areas of business, process analysis (and process flow diagramming) helps software project
5492 teams to gain and increased understanding of how they can work together in a more
5493 efficient and more effective manner. Focusing on the throughput of software features or
5494maintenance changes is well suited to process improvement efforts that identify
5495bottlenecks, process delays, and sources of error. Tools such as flowcharts and process
5496 flow diagrams, as well as state charts, originally used for designing programs, can be
5497used as process improvement tools to document process flows and process state transitions.
5498For example, the various states that a defect passes through from first being reported
5499until being resolved may be depicted in a flow diagram or a state-transition diagram.5500
5501Training is covered in Section 10 (Human Resources); however, training may also be
5502 regarded as a quality assurance technique, particularly the training required for
5503 individual software development processes and team software processes.5504
55058.2.2.1 Quality Management and Control Tools
5506See Section 8.2.2.1 of the PMBOK® Guide.5507
55088.2.2.2 Quality Audits
5509See Section 8.2.2.2 of the PMBOK® Guide.5510
55118.2.2.3 Process Analysis
5512See Section 8.2.2.3 of the PMBOK® Guide.5513
55148.2.3 Perform Software Project Quality Assurance: Outputs
5515The outputs for performing quality assurance in Section 8.2.3 of the PMBOK® Guide are
5516 applicable to performing quality assurance for software projects.5517
55188.2.3.1 Change Requests
5519See Section 8.2.3.1 of the PMBOK® Guide.5520
55218.2.3.2 Project Management Plan Updates
5522See Section 8.2.3.2 of the PMBOK® Guide.5523
55248.2.3.3 Project Documents Updates
5525See Section 8.2.3.3 of the PMBOK® Guide.5526
55278.2.3.4 Organizational Process Assets Updates
5528See Section 8.2.3.4 of the PMBOK® Guide.5529
5530Additional considerations include the following.5531
Page 125
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
125/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
5532As described in Section 8.2.3 of the PMBOK® Guide, the outputs of the Quality Assurance
5533process are audit reports and change requests that provide inputs to the Perform
5534 Integrated Change Control process (see Section 4.5 of the PMBOK® Guide and of this
5535 software extension). Audit reports and change requests may also show the need for changes
5536 in software project planning. These changes will be reflected in the software project
5537 team’s process and product documented work activities.5538
5539 • 0Cost of Corrective Rework. The cost of corrective rework for software is often a
5540 significant percentage of the total cost of developing a software product. However, these
5541 costs are often not known. For example, in projects using test-driven development,
5542 internal defects may be significantly reduced during development, but because defects are
5543 found and addressed the same day, thereby reducing later rework, the cost is not
5544 separately identified. Nonetheless, it is well known that investment in quality
5545 improvement by software organizations to prevent (or reduce) the occurrence of defects
5546 reduces rework and often results in impressive returns on investment, in addition to
5547 improvements in intangible factors, such as team morale and customer satisfaction. The
5548 intangible costs of poor quality include the loss of reputation that accrues to late
5549delivery and poor quality of a delivered software product. Also, constant rework to fix
5550defects can impact the morale of software developers.5551
5552 • 0Technical Debt. The concept of technical debt is closely related to the cost of
5553quality. For predictive, plan-driven, or time-driven software projects, defects are often
5554not discovered (or are not corrected) near the point of injection. They become
5555 exponentially more expensive to fix the longer they persist. It is not uncommon in such
5556projects that a requirements defect not found until systems testing may cost, in time and
5557 effort, 100 times more to fix than it would cost to find and fix it during a requirements
5558 review. Fixing customer-discovered defects becomes even more expensive. Failure to find
5559 and fix defects early and deferring the fixing of known defects creates technical debts
5560 that are repaid later by the cost incurred for corrective rework. Accumulation of
5561 technical debt is sometimes referred to as “mortgaging the future”; the interest rate on
5562 the mortgage can be excessive in linear, plan-driven projects. Projects strive to minimize
5563 technical debt by focusing on and correcting defects throughout the development process
5564without incurring significant costs.5565
55668.3 Control Software Project Quality
5567Section 8.3 of the PMBOK® Guide states that Control Quality is the process of monitoring
5568 and recording results for executing the quality activities to assess performance and
5569 recommend necessary changes. SQC is a system of routine technical activities used to
5570measure and control the quality of the development processes and the quality of the
5571product as it is being developed.5572
5573The most effective method of controlling and improving software quality is to focus on
5574 early detection and removal of software defects using continuous verification and
5575validation techniques and to focus on changing the software development process to improve
5576defect prevention. A large part of quality control for software products has historically
5577 relied on a predictive approach of post-development techniques, including staged levels of
5578 software testing and analysis of the detected defects. Adaptive software project life
5579 cycles integrate testing and demonstration of working, deliverable software on repetitive
5580 cycles throughout the software development process.5581
5582Software quality control (SQC) includes operational techniques and activities to verify
5583 that requirements for quality are being met and to take action when they are not. SQC is
5584defined as a set of activities that evaluate and report the quality of software project
5585 artifacts throughout the project life cycle. For purposes of this standard, “evaluate the
5586quality” means comparing work products to their requirements (including agreements, plans,
5587policies, requirements, and designs). SQC often relies on statistical methods such as
5588 control charts and Pareto diagrams to analyze software defects and the associated rework
Page 126
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
126/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
5589 to correct the defects. Interventions may be required to prevent the release of defective
5590 software. This may involve feedback for process correction or process improvement.5591
55928.3.1 Control Software Project Quality: Inputs
5593The inputs for controlling quality in Section 8.3.1 of the PMBOK® Guide are applicable to
5594 controlling quality for software projects. As described in the PMBOK® Guide, inputs to
5595 software quality control include management plans and checklists. Another significant
5596 input is the measurement plan for the prioritized quality attributes as defined in the
5597 release criteria. Project records, especially test records and CM records, are essential
5598 inputs and are typically maintained in controlled repositories.5599
56008.3.1.1 Project Management Plan
5601See Section 8.3.1.1 of the PMBOK® Guide.5602
56038.3.1.2 Quality Metrics
5604See Section 8.3.1.2 of the PMBOK® Guide.5605
56068.3.1.3 Quality Checklists
5607See Section 8.3.1.3 of the PMBOK® Guide.5608
56098.3.1.4 Work Performance Data
5610See Section 8.3.1.4 of the PMBOK® Guide.5611
56128.3.1.5 Approved Change Requests
5613See Section 8.3.1.5 of the PMBOK® Guide.5614
56158.3.1.6 Deliverables
5616See Section 8.3.1.6 of the PMBOK® Guide.5617
56188.3.1.7 Project Documents
5619See Section 8.3.1.7 of the PMBOK® Guide.
5620
56218.3.1.8 Organizational Process Assets
5622See Section 8.3.1.8 of the PMBOK® Guide.5623
56248.3.2 Control Software Project Quality: Tools and Techniques
5625The tools and techniques for controlling quality in Section 8.3.2 of the PMBOK® Guide are
5626 applicable to controlling quality for software projects (see Sections 8.3.2.1 – 8.3.2.4).
5627Additional considerations include the following.5628
5629The basic quality tools of statistical process control, including control charts, run
5630
Page 127
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
127/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
charts, histograms, and Pareto diagrams, can be applied to the analysis of defect patterns
5631 in software, thus providing the basis for identify areas for preventative actions.5632
5633Along with those items listed in the PMBOK® Guide, techniques for SQC include reviews,
5634 testing, and the version control elements of configuration management. Reviews take many
5635 forms, such as code walkthroughs, design inspections, and reviews of other work products,
5636 for example, user manuals and installation instructions. Static analysis and testing tools
5637 are typically used. Of the QC tools and techniques identified in the PMBOK® Guide,
5638 inspection (also called examination or walkthrough) is one of the most effective ways to
5639 identify software defects and omissions in software and documentation. The reviews may be
5640manual or they may use specific tools that check for common coding errors or spelling
5641 errors. Defects are corrected when found, thereby controlling the quality of the work
5642products.5643
5644Test-driven development has long proved its use in verifying the quality of software. In
5645 this approach, test cases are written before writing any functional code, and the test
5646 cases are run to demonstrate that they fail. Then the new code is added, after which the
5647 test cases are run again to demonstrate that they no longer fail. Tools are commonly used
5648 to automate such testing, but these can be desk exercises, by walking through the code.5649
5650Software testing includes unit testing, integration and verification testing, validation
5651 and acceptance testing, and regression testing. Often, development teams will build
5652 scaffolding, or temporary modules, to support early testing, simulating inputs from other
5653 (nonexistent) parts of the system or the integration of various modules that have not yet
5654been constructed. This allows integration or regression testing to be performed at an
5655 early stage in software development. Testing may also focus on specific quality
5656 attributes, such as performance testing, load testing, security testing, or usability
5657 testing. User observation, formalized as usability testing, and user surveys measure
5658quality-in-use characteristics, such as user satisfaction or efficiency.
5659
5660Testing tools and scripts can execute repeat tests consistently with little or no manual
5661 intervention, automatically collect and store the test results, and refresh the data for
5662 another round of testing. Testing tools may save time for the test team to focus on the
5663design of tests and analysis of the results.5664
5665For some types of systems or domains, software quality can be further improved by
5666 automatically generating it from specifications or higher-level languages, where possible.
5667This reduces the amount of error-prone coding. Model-driven development involves
5668generating substantial parts of software from “models” written in languages such as UML
5669 and/or domain-specific languages.5670
5671Configuration management (CM) also plays a significant role in improving quality during
5672 software development. CM provides routine and consistent checks to ensure the integrity,
5673 correctness, and completeness of each software build, often based on execution of scripts.
5674Enforced configuration control avoids the problems that arise if more than one developer
5675works on the same branch of code at the same time. Configuration management is usually
5676 automated by several tools working together. Control of versions of each source file
5677document, script and the “configurations” or sets of these that belong together is
5678 accomplished using configuration management tools, available as free open-source or as
5679 commercial products. These tools can also manage the different ways that components are
5680put together to create different end-products in a software product line or software
5681product family. Tools are also used to track the defects and other issues related to the
5682 software, and the resolution of these issues. ISO/IEC/IEEE Standard 828 – Configuration
5683Management in Systems and Software Engineering [32] provides guidance on all aspects of
5684 configuration control for systems and software.5685
5686SQC can also identify record, analyze, and treat software defects. Software defects may be
5687 classified for severity (i.e., the impact on the user), urgency (i.e., the importance to
5688users, often designated as “priority”), root cause of the defect, or location of the
5689defect the code. In addition, defect find/fix data provides statistical data to assess the
Page 128
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
128/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
5690 level of stability or instability of a software system at a point in time.5691
5692SQC uses most of the quality tools described in the PMBOK® Guide, particularly control
5693 charts, run charts, Pareto charts, and histograms. These charts help the software manager
5694 to visualize extensive data and discern patterns and causes.5695
5696Control charts are one of the most common tools used in software projects, even though
5697 they are not usually called control charts. These charts are used to track information
5698 such as numbers of open defects by severity, numbers of changes to the code, and numbers
5699of changes to requirements. In these cases, the lower limit is zero, and the upper limits
5700 are specified in the release criteria.5701
5702Run charts are often used for defect analysis. The numbers of defects found each week (or
5703day) are plotted with their dates. A chart can present all defects along with a breakdown
5704of defects by severity. The chart will show trends, such as declining numbers of defects
5705 found as the product gains stability. By recording the number of defects identified and
5706 corrected each day, the SQC team can see the rate at which defects are being fixed. If
5707 there is a significant number of unresolved defects, the project manager and stakeholders
5708need to decide if the project duration will be extended until the issues are resolved, or
5709 if the defects will carry over to the next release, which will reduce the intake of new
5710work from the requirements backlog.5711
5712Pareto charts can be used to show the distribution of defects across product components.
5713Those components that show high levels of defects (error-prone components) may require a
5714design or code review by senior members of the team to determine the cause of the
5715problems. Pareto charts are also used to graph data from software configuration
5716management. Software components that are changing excessively may indicate a dangerous
5717kind of code volatility, for example, a situation in which each defect “fix” breaks some
5718other part of the code.5719
5720Histograms are useful in identifying process failures. For example, when software builds
5721 are failing frequently over time, it is necessary to investigate. By keeping track of
5722 reasons why the builds fail, the changes that need to be made can be identified. In the
5723 case of software build failure, it is often determined that the build process hasn’t been
5724 automated and that the checklist needed for successful manual operation is incomplete,
5725wrong, or missing. Similarly, if regression tests fail, the cause may be that a “fix”
5726broke something else, earlier fixes were faulty, or possibly that the wrong code was
5727 compiled.5728
57298.3.2.1 Seven Basic Quality Tools
5730See Section 8.3.2.1 of the PMBOK® Guide.5731
57328.3.2.2 Statistical Sampling
5733See Section 8.3.2.2 of the PMBOK® Guide.5734
57358.3.2.3 Inspection
5736See Section 8.3.2.3 of the PMBOK® Guide.5737
57388.3.2.4 Approved Change Requests Review
5739See Section 8.3.2.4 of the PMBOK® Guide.5740
57418.3.3 Control Software Project Quality: Outputs
Page 129
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
129/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
5742The outputs for controlling quality in Section 8.3.3 of the PMBOK® Guide are applicable to
5743 controlling quality for software projects (see Section 8.3.3.1 – 8.3.3.8). Additional
5744 considerations include the following.5745
5746The outputs of quality control presented in the PMBOK® Guide are applicable for software
5747projects:5748
5749 • 0Measurements of the quality attributes specified in the quality management plan
5750 and the release criteria.
5751 • 0Changes to software and other artifacts validated by testing or inspection.
5752 • 0Deliverables validated by testing or inspection to conform to the scope
5753 identified at the start of the project or iteration.
5754 • 0Identification of gaps between planned and actual performance and reasons for the gaps.
5755 • 0Updated checklists, tests, and other process assets.
5756 • 0Lessons learned by means of the project or iteration retrospective, along with
5757 the team’s recommendations for changes in the process or product, and the resultant change
5758 requests.
5759 • 0Updates to the management plans (e.g., schedule, resources, configuration
5760management, test planning).5761
57628.3.3.1 Quality Control Measurements
5763See Section 8.3.3.1 of the PMBOK® Guide.5764
57658.3.3.2 Validated Changes
5766See Section 8.3.3.2 of the PMBOK® Guide.5767
57688.3.3.3 Verified Deliverables
5769See Section 8.3.3.3 of the PMBOK® Guide.5770
57718.3.3.4 Work Performance Information
5772See Section 8.3.3.4 of the PMBOK® Guide.5773
57748.3.3.5 Change Requests
5775See Section 8.3.3.5 of the PMBOK® Guide.
5776
57778.3.3.6 Project Management Plan Updates
5778See Section 8.3.3.6 of the PMBOK® Guide.5779
57808.3.3.7 Project Documents Updates
5781See Section 8.3.3.7 of the PMBOK® Guide.5782
57838.3.3.8 Organizational Process Assets Updates
5784See Section 8.3.3.8 of the PMBOK® Guide.5785
5786
Page 130
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
130/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
5787
9 SOFTWARE PROJECT HUMAN RESOURCEMANAGEMENT
5788As stated in the PMBOK® Guide, Project Human Resource Management includes the processes
5789 that organize, manage, and lead the project team. The PMBOK® Guide provides excellent
5790general purpose Human Resource Management advice that is suitable for a variety of project
5791 environments. It covers how to acquire appropriate project resources, develop them, and
5792manage them from a domain independent viewpoint. It can be applied to machinists,
5793 construction workers, or researchers.5794
5795However, because of the need to provide universal guidance applicable on any project, the
5796PMBOK® Guide does not focus on domain specific help for knowledge worker projects.
5797Software projects are staffed by knowledge workers who collaborate to solve problems in
5798novel environments with incomplete data. To most effectively manage these resources it is
5799 appropriate to utilize the knowledge worker recommendations of Peter Drucker, and Don
5800Reinertson. [33].5801
5802Software project team members typically possess technical knowledge and skills superior to
5803 the project managers managing them. Therefore, to be most effective, project managers need
5804 to find ways to tap into and leverage the knowledge and skills of software project team
5805members. Successful software project managers typically put less emphasis on directing the
5806work and more on facilitating the efficiency and effectiveness of project teams. This
5807 subtle, but crucial shift dramatically changes the way teams are created, developed, and
5808managed. It effectively changes the approach to “Plan Human Resource Management” and
5809 “Manage Project Team(s).”5810
5811Also, since software teams spend a large proportion of their time collaborating,
5812discussing ideas and making joint decisions, the “fit” of participants within the team is
5813 extremely important. Rather than hiring a competent programmer who can do good work in
5814 isolation, the ease and effectiveness of interacting with the members of the software team
5815 can be as important as their technical ability. So it is desirable to have team members
5816 engaged in the selection process of other team members. This influences the “Acquire
5817Project Team” roles on a project.5818
5819Software project teams often build novel solutions using new technology, therefore, they
5820will not have the necessary solutions available upfront on the project. Instead they are
5821 encouraged to innovatively solve problems, iterate on proofs of concepts, and improve
5822 their processes as they develop the software product. This leads to the desirability of
5823 self-empowered teams who self diagnose, engage in retrospection, and continuously improve.
5824The process of instilling and promoting these ideas is common in successful software
5825projects and influences the way we develop and manage project teams.5826
5827These changes to how we Plan Human Resource Management, Acquire Project Teams, Develop
5828Project Team, and Manage Project Teams are described in the following sections of this
5829 software extension.5830
5831Figure 9-1 provides an overview of Software Project Human Resource Management; it is an
5832 adaptation of Figure 9-1 in the PMBOK® Guide.5833
Page 131
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
131/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
5834
5835
5836 Figure 9-1. Software Project Human Resource Management Overview5837
58389.1 Plan Human Resource Management
5839The Plan Human Resource Management process involves identifying and documenting project
5840 roles, responsibilities, required skills, reporting relationships, and creating a staffing
5841management plan. The inputs, tools and techniques, and outputs in Section 9.1 of the
5842PMBOK® Guide are applicable to planning human resource management for software projects.5843
58449.1.1 Plan Human Resource Management: Inputs
5845The inputs for planning human resource management in the PMBOK® Guide are applicable to
5846planning human resource management for software projects.
5847
5848
Page 132
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
132/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
9.1.1.1 Project Management Plan
5849See Section 9.1.1.1 of the PMBOK® Guide.5850
58519.1.1.2 Activity Resource Requirements
5852See Section 9.1.1.2 of the PMBOK® Guide.5853
58549.1.1.3 Enterprise Environmental Factors
5855See Section 9.1.1.3 of the PMBOK® Guide.5856
58579.1.1.4 Organizational Process Assets
5858See Section 9.1.1.4 of the PMBOK® Guide.5859
58609.1.2 Plan Human Resource Management: Tools and Techniques
5861The tools and techniques for planning human resource management in the PMBOK® Guide are
5862 applicable tools and techniques for planning human resource management for software
5863projects.5864
58659.1.2.1 Organization Charts and Position Descriptions
5866See Section 9.1.2.1 of the PMBOK® Guide.5867
58689.1.2.2 Networking
5869See Section 9.1.2.2 of the PMBOK® Guide.5870
58719.1.2.3 Organizational Theory
5872See Section 9.1.2.3 of the PMBOK® Guide.5873
58749.1.2.4 Expert Judgment
5875See Section 9.1.2.4 of the PMBOK® Guide.5876
58779.1.2.5 Meetings
5878See Section 9.1.2.5 of the PMBOK® Guide.5879
58809.1.3 Plan Human Resource Management: Outputs
5881The output for planning human resource management in the PMBOK® Guide (human resource
5882plan) is applicable for planning human resource management for software projects.5883
58849.1.3.1 Human Resource Management Plan
5885See Section 9.1.3.1 of the PMBOK® Guide.5886
Page 133
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
133/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
5887For software projects, planning human resource management occurs with recognition of some
5888 additional software project truisms and characteristics.5889
5890Software projects require collaboration and information sharing to solve problems and
5891build new products. Team members are motivated by opportunities to expand their skills,
5892 solve interesting problems, build innovative software, and use effective software tools.
5893Failing to recognize the motivational factors of software developers when planning HR
5894management can create many problems later on in a project.5895
5896Software teams perform better with less of a command-and-control structure and more of a
5897 facilitation approach to project management [34]. Instead of planning to give detailed
5898 task lists to team members, effective software project managers plan on presenting work as
5899questions or problems to be solved and letting team members organize as they see best to
5900meet these challenges. Not only does this provide a more stimulating and rewarding
5901 environment for software teams, it also defers design decisions and keeps solutions open
5902 to creative solutions that may not have been envisioned during the initiation and planning
5903phases of a software project.5904
5905A commonly used approach to managing software projects is to adopt a servant leadership
5906 role by the project manager, which enables empowered teams. Team members are encouraged to
5907wear many hats and pitch-in regardless of their formal title, which balances the workload
5908 and enables completion of the tasks required for project success.
5909
5910 In recognition of the professionalism generally seen on software projects, project
5911managers are encouraged to take more of a Theory Y view of team members and less of a
5912Theory X approach [35].5913
5914McGregor’s Theory X asserts that employees are inherently lazy and will avoid work
5915whenever they can. Theory X managers believe that workers need to be closely supervised
5916 and comprehensive systems of controls must be developed and enforced. Theory Y posits that
5917 employees are ambitious and self-motivated. They enjoy creative problem solving, but their
5918 talents are underused in most organizations. Theory Y managers communicate openly with
5919 team members, minimize the difference between superior-subordinate relationships, and
5920 create a comfortable environment in which subordinates can develop and use their talents
5921 and abilities. This climate includes shared decision making so that subordinates have a
5922 say in decisions that influence them and their work products [36].5923
5924So, when planning Software Project Human Management, software project managers modify the
5925 approach for the characteristics of software project workers, try to avoid command and
5926 control structures, and instead tap into the problem-solving motivational factors that
5927drive software professionals. Also, software project managers plan for cross-functional
5928 teams with all the skills needed to deliver the product represented on the team.5929
59309.2 Acquire Software Project Team
5931The inputs, tools and techniques, and outputs for acquiring a project team in Section 9.2
5932of the PMBOK® Guide are applicable to acquiring a software project team.5933
59349.2.1 Acquire Software Project Team: Inputs
5935The inputs for acquiring a project team in the PMBOK® Guide are applicable to acquiring a
5936project team for software projects.5937
59389.2.1.1 Human Resource Management Plan
5939See Section 9.2.1.1 of the PMBOK® Guide.5940
Page 134
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
134/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
59419.2.1.2 Enterprise Environmental Factors
5942See Section 9.2.1.2 of the PMBOK® Guide.5943
59449.2.1.3 Organizational Process Assets
5945See Section 9.2.1.3 of the PMBOK® Guide. In addition, it is to be observed that software
5946organizations sometimes acquire software project team members by hiring contract personnel
5947 to perform various project duties. Contract personnel may be members of the software
5948development team or they may be hired to perform specialized tasks such as design or
5949 testing. These contracted personnel do not always have allegiance to the organization or
5950 the project and may not adapt readily to the corporate culture of the organization.5951
59529.2.2 Acquire Software Project Team: Tools and Techniques
5953The tools and techniques for acquiring a project team in the PMBOK® Guide are applicable
5954 to acquiring a project team for software projects.5955
59569.2.2.1 Pre-assignment
5957See Section 9.2.2.1 of the PMBOK® Guide.5958
59599.2.2.2 Negotiation
5960See Section 9.2.2.2 of the PMBOK® Guide.5961
59629.2.2.3 Acquisition
5963See Section 9.2.2.3 of the PMBOK® Guide.5964
59659.2.2.4 Virtual Teams
5966See Section 9.2.2.4 of the PMBOK® Guide.
5967
59689.2.2.5 Multi-Criteria Decision Analysis
5969See Section 9.2.2.5 of the PMBOK® Guide.5970
59719.2.3 Acquire Project Team: Outputs
5972The outputs for acquiring a project team in the PMBOK® Guide are applicable for acquiring
5973project teams for software projects.5974
5975 In addition, the following considerations address some particular aspects of acquiring a
5976 software project team.5977
5978Since software project team members share and manipulate information rather than tangible
5979materials, team stability and dedicated team members are important attributes that reduce
5980 reiterating the goals, the agreed-to approach, and the mechanisms for determining project
5981 status that occurs if there is turnover in the team. Software project teams work best
5982within strong matrix and projectized environments, where a dedicated team can work on a
5983 single project with few interruptions. Team members work together most effectively when
5984 they are co-located and face-to-face communications can occur on a continuous, ongoing
Page 135
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
135/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
5985basis.5986
5987The goal of acquiring software project team members is to create stable, co-located teams
5988 that have all of the skills needed to conduct the project. Silo teams with matrix
5989 reporting structures are less likely to be committed to shared project goals since some of
5990 their allegiance will be to their host group. If colocation is not possible, stable teams
5991 in different time zones are preferred to silo teams.5992
5993 Involvement of present team members, in addition to the project manager, when acquiring
5994new team members also increases the likelihood of building an integrated team. HR and
5995project management representatives do the normal front-end screening of candidates to weed
5996out unsuited or unskilled applicants. The acceptable candidates are then invited for peer
5997 interviews where team members assess the candidate to determine whether they can work with
5998 the candidate, whether the candidate will be a good fit for the team, and whether the
5999 candidate will make the team stronger or weaker. Of course, care must be taken to ensure
6000 that new team members will bring diversity of viewpoints and fresh thinking to the team.6001
6002By engaging different software groups, for example, software developers and QA staff,
6003different characteristics of the candidate will be evaluated. Everyone wins when engaging
6004 the team in the interview process. The project team wins because they have already met and
6005 endorsed the prospective candidate. Candidates win because they get to meet their
6006potential peers, learn what the project is about, and are better able to assess the
6007 corporate culture. The project manager wins because the team members, who have the
6008 technical knowledge, will ask the appropriate technical questions. Finally, all subgroups
6009within the project win by learning what characteristics are important to other subgroups
6010within the project, thereby increasing their awareness and maturity.6011
60129.2.3.1 Project Staff Assignments
6013See Section 9.2.3.1 of the PMBOK® Guide.6014
60159.2.3.2 Resource Calendars
6016See Section 9.2.3.2 of the PMBOK® Guide.6017
60189.2.3.3 Project Management Plan Updates
6019See Section 9.2.3.3 of the PMBOK® Guide.6020
60219.3 Develop Software Project Team
6022The inputs, tools and techniques, and outputs for developing the project team in Section
60239.3 of the PMBOK® Guide are applicable to developing a software project team.6024
60259.3.1 Develop Software Project Team: Inputs
6026The inputs for developing a project team in the PMBOK® Guide are applicable to developing
6027 a project team for software projects.6028
60299.3.1.1 Human Resource Management Plan
6030See Section 9.3.1.1 of the PMBOK® Guide.6031
60329.3.1.2 Project Staff Assignments
Page 136
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
136/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
6033See Section 9.3.1.2 of the PMBOK® Guide.6034
60359.3.1.3 Resource Calendars
6036See Section 9.3.1.3 of the PMBOK® Guide.6037
60389.3.2 Develop Software Project Team: Tools and Techniques
6039The tools and techniques for acquiring a project team in the PMBOK® Guide are applicable
6040 to acquiring a project team for software projects.6041
60429.3.2.1 Interpersonal Skills
6043See Section 9.3.2.1 of the PMBOK® Guide.6044
60459.3.2.2 Training
6046See Section 9.3.2.2 of the PMBOK® Guide.6047
60489.3.2.3 Team-Building Activities
6049See Section 9.3.2.3 of the PMBOK® Guide.6050
60519.3.2.4 Ground Rules
6052See Section 9.3.2.4 of the PMBOK® Guide.6053
60549.3.2.5 Colocation
6055See Section 9.3.2.5 of the PMBOK® Guide.6056
60579.3.2.6 Recognition and Rewards
6058See Section 9.3.2.6 of the PMBOK® Guide.6059
60609.3.2.7 Personnel Assessment Tools
6061See Section 9.3.2.7 of the PMBOK® Guide.6062
60639.3.3 Develop Software Project Team: Outputs
6064The outputs from Develop Project Team in the PMBOK® Guide are applicable to developing a
6065 software project team (see Sections 9.3.3.1 and 9.3.3.2).6066
6067The following considerations address some additional aspects of developing a software
6068project team.6069
6070Develop Software Project Team is concerned with the process of improving the competencies,
6071 team interactions, and the overall team environment to enhance project performance. On
6072 software projects this is a nested, recurring pattern that happens continuously on cycles
Page 137
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
137/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
6073of exploration and feedback that typically occur on hourly, daily, weekly, biweekly, and
6074monthly iteration cycles.6075
6076The practice of pair programming, where two software developers share a task, can assist
6077greatly with skills improvement and learning of good practices. Often, team members of
6078dissimilar skill levels are paired (senior with junior) and pair members are rotated
6079 frequently in order to maximize learning opportunities. This also has the benefit of
6080 sharing project and technical knowledge throughout the team, and reducing the dependency
6081on key individuals for their knowledge. If a team member happens to leave the project, the
6082 impact is not as significant because they are others who understand the topic.6083
6084The practice of test driven development (TDD) also helps improve team competencies through
6085 short feedback cycles of experimental learning. TDD or “red, green, refactor” refers to
6086 the steps of writing a test (that fails), then writing code until the test passes, then
6087 refactoring the code for clarity; this process may occur many times each day. By
6088 encouraging developers to think about how code will be tested before writing code,
6089business purpose and usability are considered frequently, which enhances quality and
6090 acceptance. However, the main benefit is for the team, who will learn through rapid cycles
6091of exploration, test, and feedback. These concepts, as they are reinforced in adaptive
6092 software project life cycle projects, are illustrated in Figure 9-2.6093
6094
6095 Figure 9-2. Attributes that Increase Software Project Team Effectiveness6096
6097Software project teams coalesce and become more productive if they are stable and
6098 co-located. It takes time for teams to progress through the Tuckman stages of forming,
6099 storming, norming, and finally to performing to optimize team output [38]. Swapping people
6100 in and out of a team triggers the storming and norming phases again as new team members
6101 find their place in the team and the team adjusts to them.6102
Page 138
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
138/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
6103Part of the storming and norming process for software project team members is learning how
6104 to deal with team conflict, gaining commitment for decisions, and ultimately developing a
6105 sense of accountability for the project outcomes. These are complex issues that impact all
6106projects where skilled people need to collaborate on building novel solutions; these are
6107particularly important issues for software project teams. Getting skilled people to work
6108 together and harness constructive disagreement and rigorously test decisions is a primary
6109goal of software team development.6110
6111Colocation of team members helps this process and allows direct face-to-face
6112 communication. Colocation is not always possible, but given a choice of two teams, one
6113 experienced but dispersed, and one more junior but local, the local team is often the best
6114 choice for a software project.6115
6116The challenges software teams face in working together and learning to trust one another,
6117 thrash out issues, make decisions, and commit to shared responsibility are well described
6118by The Five Dysfunctions of a Team [39]:6119
6120 • 0Absence of trust. Unwillingness to be vulnerable within the group. People must be
6121open about mistakes and weaknesses to build a foundation of trust.
6122 • 0Fear of conflict. Teams that lack trust cannot engage in unfiltered debate.
6123 Instead they resort to veiled discussions and guarded comments.
6124 • 0Lack of commitment. Without passionate debate, team members rarely if ever buy-in
6125 to and commit to decisions, though they may feign agreement during meetings.
6126 • 0Avoidance of accountability. Due to lack of commitment and buy-in, most people
6127will hesitate to constructively confront their peers on actions and behaviors that seem
6128 counterproductive to the good of the team and the project.
6129 • 0Inattention to results. Failure to hold one another accountable leads to putting
6130 individual goals (or department goals) ahead of the project.6131
6132These dysfunctions are ever-present risks for software teams. Project managers can help
6133build a culture of trust and acceptance by sharing their mistakes with the team and
6134demonstrating that it is OK to admit to mistakes.6135
6136Colocation also helps to facilitate unfiltered debate. Without the barriers of video
6137 conferencing, email, and telephone, it is much easier to get to the heart of an issue when
6138 in direct communication. Empowered teams and shared decision-making helps to build
6139 commitment.6140
6141Daily stand-up meetings, iteration planning meetings, and retrospectives at the ends of
6142 iterations reinforce and reiterate team member work commitments and team accountability
6143 for results.6144
6145Self-organizing teams schedule their own work and take ownership for problems and
6146 solutions wherever possible. For some teams, this may come naturally; for others, it will
6147be a big transition that requires training and encouragement by senior management.6148
61499.3.3.1 Team Performance Assessments
6150See Section 9.3.3.1 of the PMBOK® Guide.6151
61529.3.3.2 Enterprise Environmental Factors Updates
6153See Section 9.3.3.2 of the PMBOK® Guide.6154
61559.4 Manage Software Project Team
6156The process of managing a project team in Section 9.4 of the PMBOK® Guide, which covers
6157 tracking team member performance, providing feedback, resolving issues, and managing
Page 139
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
139/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
6158 changes to optimize project performance, is applicable to managing a software project
6159 team. The inputs, tools and techniques, and outputs in Section 9.4 of the PMBOK® Guide are
6160 applicable to managing a software project team.6161
61629.4.1 Manage Software Project Team: Inputs
6163The inputs for managing a project team in the PMBOK® Guide are applicable to managing a
6164 software project team.6165
61669.4.1.1 Human Resource Management Plan
6167See Section 9.4.1.1 of the PMBOK® Guide.6168
61699.4.1.2 Project Staff Assignments
6170See Section 9.4.1.2 of the PMBOK® Guide.6171
61729.4.1.3 Team Performance Assessments
6173See Section 9.4.1.3 of the PMBOK® Guide.6174
61759.4.1.4 Issue Log
6176See Section 9.4.1.4 of the PMBOK® Guide.6177
61789.4.1.5 Work Performance Reports
6179See Section 9.4.1.5 of the PMBOK® Guide.6180
61819.4.1.6 Organizational Process Assets
6182See Section 9.4.1.6 of the PMBOK® Guide.6183
61849.4.2 Manage Software Project Team: Tools and Techniques
6185The tools and techniques for managing a project team in the PMBOK® Guide are applicable to
6186managing a software project team. They are observation and conversation, project
6187performance appraisals, conflict management, and interpersonal skills.6188
61899.4.2.1 Observation and Conversation
6190See Section 9.4.2.1 of the PMBOK® Guide.6191
61929.4.2.2 Project Performance Appraisals
6193See Section 9.4.2.2 of the PMBOK® Guide.6194
61959.4.2.3 Conflict Management
6196See Section 9.4.2.3 of the PMBOK® Guide.6197
Page 140
61989.4.2.4 Interpersonal Skills
6199See Section 9.4.2.4 of the PMBOK® Guide.6200
62019.4.3 Manage Software Project Team: Outputs
6202The outputs from managing a project team in the PMBOK® Guide are applicable to managing a
6203 software project team.6204
62059.4.3.1 Change Requests
6206See Section 9.4.3.1 of the PMBOK® Guide.6207
62089.4.3.2 Project Management Plan Updates
6209See Section 9.4.3.2 of the PMBOK® Guide.6210
62119.4.3.3 Project Documents Updates
6212See Section 9.4.3.3 of the PMBOK® Guide.6213
62149.4.3.4 Enterprise Environmental Factors Updates
6215See Section 9.4.3.4 of the PMBOK® Guide.6216
62179.4.3.5 Organizational Process Assets Updates
6218See Section 9.4.3.5 of the PMBOK® Guide.6219
6220The following considerations address some additional aspects of developing a software
6221project team.6222
6223Tracking team member performance on a software project is a delicate issue. It is
6224 important to assess individual performance, interactions with colleagues, and development
6225of skills. At the same time, care must be taken to not publicize measured performance at
6226 an individual level because many factors affect individual performance on a software
6227project. For example, a talented project member may exhibit decreased productivity when
6228working on the most complex part of the product. In addition, publicizing individual
6229performance can result in self-centered behavior and provides little reward for
6230 collaborating with and helping other team members.6231
6232For these reasons, it is desirable to track performance at the team level; team members
6233 are incentivized to help colleagues in order to boost the team’s overall productivity. For
6234 this reason “velocity” (the amount of work done per iteration) is measured at the team
6235 level, and not at the level of individuals.6236
6237Project managers who engage one-on-one with individual team members can learn each
6238member’s career development objectives. By developing the individual skills and roles of
6239 team members and then finding ways to build opportunities to use these skills on the
6240project greatly improves individual commitment and satisfaction. Team members become more
6241 aligned and committed to the project goals when they see how their personal goals are
6242 linked to project execution.6243
6244Because many software projects work with short iterations, new roles can be tried for an
6245 iterative cycle or two before adopting or abandoning the new role. This opportunity to try
6246new roles is appreciated by team members as being proactive to their needs without being
Page 141
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
141/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
6247 too disruptive to the project.6248
6249Regular intervals for experimentation are also advantageous to the project manager who
6250 rapidly obtains feedback on self-directed team adjustments. Iterative approaches provide
6251 short time periods for experimentation and feedback to team members, which most people
6252 find responsive and rewarding.6253
6254Feedback is obtained by demonstrating an increment of working software after which a
6255 retrospective team meeting is held. These two events provide valuable feedback to the
6256project team members, project manager, and customer. The demonstration provides feedback
6257on what the customer thinks of the new work, information is gained on how the project is
6258meeting its goals, and retrospectives and introspection aids in adjusting and improving
6259 the development processes.6260
6261Resolving team issues and conflict also needs careful balance. Most team conflict is
6262harmless and indeed positive, being a sign of a trusting environment where it is
6263 acceptable to present a dissenting view. Passionate debate over technical issues builds
6264 commitment to outcomes; conflict is only an issue when it extends beyond business and
6265 technical issues to become personal.6266
6267Because of the flexible nature of software, there is rarely only one way to solve a
6268problem and so debate and discussion over approaches is normal and healthy as long as the
6269discussions do not escalate beyond what the team can solve or overflow into personal
6270 conflict. If they do, the approaches to resolving conflict recommended in the PMBOK® Guide
6271 can be used.6272
627310 SOFTWARE PROJECT COMMUNICATIONSMANAGEMENT
6274According to Section 10 of the PMBOK® Guide, Project Communications Management includes
6275 the processes that are required to ensure timely and appropriate planning, collection,
6276 creation, distribution, storage, retrieval, management, control, monitoring, and the
6277ultimate disposition of project information. This section of the Software Extension to the
6278PMBOK® Guide – Fifth Edition addresses project communication for software projects by
6279 addressing issues that are important for managing software project communication and that
6280merit attention beyond that provided in the PMBOK® Guide.6281
6282The role of project communication is a primary consideration for software projects,
6283because teams of individuals who engage in closely coordinated, intellectual activities
6284develop software. With no physical product to reference, effective communication is
6285paramount for keeping team members productively engaged and stakeholders informed.
6286Software teams reduce complexity and enhance communication through a combination of
6287 communication approaches that include information radiators, colocation (when possible),
6288 and an emphasis on face-to-face communication.6289
6290Figure 10-1 provides an overview of Software Project Communication Management; it is an
6291 adaptation of Figure 10-1 in the PMBOK® Guide.6292
Page 142
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
142/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
6293
6294
6295 Figure 10-1. Software Project Communications Management Overview6296
629710.1 Plan Software Project Communications Management
6298The inputs, tools and techniques, and outputs in Section 10.1 of the PMBOK® Guide are
6299 applicable to planning project communication management for software projects.6300
6301Software projects often exhibit high rates of change to accommodate changing and evolving
6302 requirements and shifting priorities. Frequent and productive communication among team
6303members is important and can be achieved through daily stand-up meetings, frequent
6304demonstrations of progress, and retrospective meetings. These approaches are typically,
6305but not exclusively, applied to software projects that use adaptive project life cycles.
6306Adaptive life cycles and the related communication techniques used may create confusion
6307 among stakeholders who are not familiar with them. In this case, the organization should
6308plan extra time to explain the project life cycle processes. Additional communications and
6309 feedback cycles should be planned to ensure that all stakeholders understand why the
6310project is operating this way, how team and other stakeholder communications works, and
6311 their involvement in the communication processes.6312
6313Face-to-face (FTF) communication allows two-way dialogs; issues and questions can be
6314 addressed immediately, and emotion is readily conveyed. For example, when discussing a
6315 topic, if someone begins nodding their head, indicating an understanding or agreement with
6316 the speaker, further explanation can be curtailed and the discussion can be moved on to
6317other topics. Because of the higher bandwidth, opportunity for Q&A, and lower costs,
6318 face-to-face communication is the preferred means of communication for software
6319development projects, whenever possible.6320
6321 It is easy to productively use face-to-face communication for small, co-located teams.
6322Video conferencing and voice-over-internet protocol (VOIP) technologies can be used to
6323 simulate face-to-face interactions if team members are geographically distributed.6324
6325To facilitate communication, the preferred solution for a growing team size is to break up
6326 large teams into multiple smaller sub-teams that can leverage face-to-face communication
6327
Page 143
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
143/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
and tacit knowledge within each of the smaller teams, with well-defined communication
6328 channels among the teams.6329
6330The following equation can be used to calculate the number of communication paths, P,
6331 among a collection of project teams, where n is the number of members per team and N is
6332 the number of teams. An assumption is made that each member of each project team
6333 communicates with all other members of their team, and one member of each project team
6334 communicates with all of the other project teams.6335
6336P = [n (n-1) / 2] + [N (N-1) / 2]6337
6338For a single team (N = 1) the number of communications paths is P = n (n-1) / 2; that is,
6339 communication paths within a project team increase on the order of the square of the
6340number of team members.6341
6342Note, also, that a single team of 10 members has 45 communication paths, whereas two teams
6343of 5 have 11 communication paths. Of course, the single point of contact for each team
6344with the other team (i.e., the team leader) should have sufficient bandwidth to ensure
6345 effective communications between the two teams and among other teams when there are more
6346 than two teams.6347
634810.1.1 Plan Software Project Communications: Inputs
6349The inputs in Section 10.1.1 of the PMBOK® Guide are applicable for planning software
6350project communications. The following additional observation is also applicable.6351
6352Adaptive life cycles for software projects often include iteration and release plans for
6353 the iterations of the life cycle. These plans communicate the agreed-upon content for the
6354next iteration and the content of the next iterative release (where a release may be used
6355 for a customer demonstration or for internal review by the project team). These plans
6356provide an important input for planning software project communications.6357
635810.1.1.1 Project Management Plan
6359See Section 10.1.1.1 of the PMBOK® Guide.6360
636110.1.1.2 Stakeholder Register
6362See Section 10.1.1.2 of the PMBOK® Guide.6363
636410.1.1.3 Enterprise Environmental Factors
6365See Section 10.1.1.3 of the PMBOK® Guide.6366
636710.1.1.4 Organizational Process Assets
6368See Section 10.1.1.4 of the PMBOK® Guide.6369
637010.1.2 Plan Software Project Communications: Tools and Techniques
6371The tools and techniques in Section 10.1.2 of the PMBOK® Guide are applicable for planning
6372 software project communications.6373
637410.1.2.1 Communication Requirements Analysis
Page 144
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
144/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
6375See Section 10.1.2.1 of the PMBOK® Guide.6376
637710.1.2.2 Communication Technology
6378See Section 10.1.2.2 of the PMBOK® Guide.6379
638010.1.2.3 Communication Models
6381See Section 10.1.2.3 of the PMBOK® Guide.6382
638310.1.2.4 Communication Methods
6384See Section 10.1.2.4 of the PMBOK® Guide.
6385
638610.1.2.5 Meetings
6387See Section 10.1.2.5 of the PMBOK® Guide.6388
638910.1.3 Plan Software Project Communications: Outputs
6390The in Section 10.1.3 of the PMBOK® Guide are applicable for planning software project
6391 communications.6392
639310.1.3.1 Communications Management Plan
6394See Section 10.1.3.2 of the PMBOK® Guide.6395
639610.1.3.2 Project Documents Updates
6397See Section 10.1.3.2 of the PMBOK® Guide.6398
6399Additionally, when planning communications management for a software project, it is
6400 important that the characteristics of software and knowledge work are recognized and
6401 incorporated. [37] These include:6402
6403 • 0Software projects are often new or novel to their customers and host
6404organizations; therefore, communication may be needed to explain the tools and techniques
6405 that will be used when managing the project, especially to manage ambiguity during the
6406 initiating and planning processes of a software development project.6407
6408 • 0Software project life cycles are often complex, so significant communication is
6409needed to explain the development process that will be used and the roles that various
6410 stakeholders will play.6411
6412 • 0Software projects often experience high rates of change as product requirements
6413 evolve, so it is important that frequent communications are provided to keep stakeholders
6414up to date. Communication mechanisms may include daily standup meetings, demonstrations of
6415 the evolving software product, and retrospectives to provide communication and
6416 coordination.6417
6418 • 0Software projects are often undertaken by geographically dispersed teams, so
6419electronic communication tools such as voice over internet protocol (VOIP), instant
6420messaging, video conferencing, and project websites are often utilized.6421
6422 • 0Both push (publish) and pull (subscribe) communication mechanisms are used to
Page 145
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
145/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
6423 accommodate the high rate of information exchange often seen in software projects.6424
6425Adaptive life cycles for software projects address these characteristics of project
6426 communication by frequently demonstrating the evolving functionality and regularly
6427delivering functionality into the users’ environment, if desired, to provide higher
6428project visibility for most stakeholders. A major attribute of adaptive life cycles is to
6429 eliminate the long periods of internal project activity, which make it difficult for
6430 external stakeholders to understand what is happening.6431
6432Adaptive life cycle techniques facilitate the planning of software project communication
6433because project information is a byproduct of the development processes—this is a major
6434design feature of adaptive life cycles. However, reliance on face-to-face interaction
6435 requires participation by the appropriate project stakeholders (customer, users, users’
6436 representatives, and others). Stakeholder attendance at planning meetings and iterative
6437demonstrations of the evolving product is crucial. Where face-to-face communications are
6438not possible, more traditional communications will be required.6439
6440Also, ongoing engagement of and communication with stakeholders is important throughout
6441 the entire project life cycle, because requirements, assumptions, and constraints often
6442 change as a software project evolves. And, it is important to ensure that project
6443 stakeholders receive the information they need during planning meetings, product
6444demonstrations, and project retrospectives. Stakeholders should be encouraged to actively
6445participate in these meetings. They should be asked what information they need, and every
6446 attempt should be made to provide it.6447
644810.2 Manage Software Project Communications
6449The inputs, tools and techniques, and outputs in Section 10.2 of the PMBOK® Guide are
6450 applicable to managing software project communications.6451
645210.2.1 Manage Software Project Communications: Inputs
6453The inputs in Section 10.2.1 of the PMBOK® Guide, are applicable inputs for managing
6454 software project communications. In addition, the input in 10.2.1.5 applies to managing
6455 software project communications.6456
645710.2.1.1 Communications Management Plan
6458See Section 10.2.1.1 of the PMBOK® Guide.6459
646010.2.1.2 Work Performance Reports
6461See Section 10.2.1.2 of the PMBOK® Guide.6462
646310.2.1.3 Enterprise Environmental Factors
6464See Section 10.2.1.3 of the PMBOK® Guide.6465
646610.2.1.4 Organizational Process Assets
6467See Section 10.2.1.4 of the PMBOK® Guide.6468
646910.2.1.5 Release and Iteration Plans
Page 146
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
146/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
6470As stated in Section 10.1.1 of this software extension, adaptive life cycles for software
6471projects often include iteration and release plans. These plans provide an important input
6472 for the managing software project communications.6473
647410.2.2 Manage Software Project Communications: Tools and Techniques
6475Because of the potential for high rates of change and the lack of a tangible, evolving
6476product, managing communications on software projects is especially important. Project
6477 information can be provided via push and pull mechanisms. Information such as status
6478 reports should be pushed out to stakeholders on a regular basis (perhaps weekly).
6479 Information can be published in a repository so that stakeholders can access the desired
6480 information at the desired level of detail.6481
6482The tools and techniques in Section 10.2.2 of the PMBOK® Guide are applicable tools and
6483 techniques for managing software project communications. In addition, Section 10.2.2.6
6484–10.2.2.9 are applicable to managing software project communications.6485
648610.2.2.1 Communication Technology
6487See Section 10.2.2.1 of the PMBOK® Guide.
6488
648910.2.2.2 Communication Models
6490See Section 10.2.2.2 of the PMBOK® Guide.6491
649210.2.2.3 Communication Methods
6493See Section 10.2.2.3 of the PMBOK® Guide.6494
649510.2.2.4 Information Management Systems
6496See Section 10.2.2.4 of the PMBOK® Guide.
6497
649810.2.2.5 Performance Reporting
6499See Section 10.2.2.5 of the PMBOK® Guide.6500
650110.2.2.6 Information Radiators
6502As stated previously, information radiators are large, graphic displays of the project
6503 status and metrics that can be used to distribute software project information. They are
6504 frequently updated and located where the project team can easily see them. Common kinds of
6505 information radiator graphs include task boards, burn-up and burn-down graphs, defect
6506 reports, status of rework, and so forth.6507
6508A storyboard is a kind of information radiator for a software project. Post-it or similar
6509 sticky notes are placed on a white board to describe project tasks. The columns of a
6510 storyboard can be used to display items such as stories, all tasks, tasks in progress,
6511 tasks completed, story bugs (defects), and tasks completed. The rows show the progress of
6512 the items in columns. A storyboard is depicted in Figure 10-2.6513
Page 147
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
147/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
6514
6515 Figure 10-2. Depiction of a Storyboard6516
651710.2.2.7 Velocity Statistics
6518Software projects that use predictive life cycles track velocity data on each iteration of
6519 the development cycle and communicate it to the project team. Velocity is a measure of the
6520work completed by the project team during each iteration. It is an indicator of team
6521 capacity and a measure of productivity and progress. Velocity can be tracked using
6522person-day metrics (i.e., ideal developer-days) or in less precise measures of time, such
6523 as story points completed.6524
652510.2.2.8 Yesterday’s Weather
6526 “Yesterday’s weather” describes the team’s productivity during the previous period (i.e.,
6527velocity). It is useful because it reflects the fully loaded capability of the team’s
6528 resources including the impacts of defect remediation, support, and other work demands.
6529Using yesterday’s weather is a reliable way of estimating the team’s current iteration
6530 capacity.6531
6532Yesterday’s weather uses recent performance as an indicator for likely future performance.
6533For example, if the team completed 30 story points last week, using 30 story points as an
6534 estimate for progress this week is probably more valid than using the 45 story points per
6535week estimated at the beginning of the project.6536
653710.2.2.9 Online Collaboration Tools
6538Online collaboration tools can also be used so that those who are remote from the team can
6539visit the project website and view project information such as big visible charts and
6540yesterday’s weather.6541
654210.2.3 Manage Software Project Communications: Outputs
6543The outputs in Section 10.2.3 of the PMBOK® Guide are applicable outputs for managing
6544 software project communications. In addition, the outputs in 10.2.3.5 – 10.2.3.7 are
6545 applicable to managing software project communications.6546
654710.2.3.1 Project Communications
6548See Section 10.2.3.1 of the PMBOK® Guide.6549
Page 148
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
148/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
655010.2.3.2 Project Management Plan Updates
6551See Section 10.2.3.2 of the PMBOK® Guide.6552
6553 10.2.3.3 Project Documents Updates
6554See Section 10.2.3.3 of the PMBOK® Guide.6555
655610.2.3.4 Organizational Process Assets Updates
6557See Section 10.2.3.4 of the PMBOK® Guide.6558
655910.2.3.5 Special Communication Tools
6560Software projects that use adaptive life cycles often use special communications tools to
6561 specify and measure scope, schedule, budget, progress, and risks. These communications may
6562 include product backlogs, release maps, cumulative flow diagrams, and risk burn-down
6563 charts. These terms are defined in the Glossary.6564
656510.2.3.6 Online Collaboration Tools
6566Software projects often use online collaboration tools to share and communicate project
6567 status. These tools allow geographically dispersed members to access project information.
6568These tools are also continuously available to a project group that may be located in a
6569different time zone. Online collaboration tools can provide a rich environment for storing
6570documents, images, videos of product demonstrations, and threaded discussion forums.6571
657210.2.3.7 Updated Information Radiators
6573The project’s information radiators are updated to reflect the latest available
6574 information. A burn-down chart and a parking lot diagram are illustrated in Figures 10-3
6575 and 10-4. A cumulative-flow diagram is illustrated in Figure 6-5.6576
6577
6578
6579 Figure 10-3. Burn-down Chart for a Software Project Iteration6580
Page 149
6581
6582 Figure 10-4. Parking Lot Diagram for a Software Project6583
658410.3 Control Software Project Communications
6585According to Section 10.3 of the PMBOK® Guide, Control Communications is the process of
6586monitoring and controlling communications throughout the entire project life cycle to
6587 ensure the information needs of project stakeholders are met. The techniques presented in
6588Section 10.3 of the PMBOK® Guide are generally applicable to controlling communications in
6589 software projects. The following extensions to Section 10.3 are also applicable to
6590 software projects.6591
6592Controlling communications for a software project involves providing insight into the
6593development progress as issues arise. There are many metrics that can be reported for
6594 software projects, but few are useful. Commonly reported and useful metrics include
6595measures of cost, schedule, product volume, defects, and progress.6596
6597Good metrics are simple and relevant to the end goal of delivering an acceptable product
6598within the constraints of schedule, budget, resources, technology, and other relevant
6599 factors. Software project measures should be byproducts of the processes used; it should
6600not require an inordinate effort to produce them.6601
6602For adaptive life cycles, the content of the evolving product is the primary measure of
6603progress. Iterations of the life cycle add increments to the evolving product. Newly added
6604 content, in combination with existing content, is tested and demonstrated at the end of
6605 the iterations. The demonstrations, in combination with the prioritized features in the
6606product backlog (prioritized by business value), provide a measure of value-adding work
6607 that remains to be done. For adaptive life cycles, metrics such as stories developed (and
6608 tested) compared to stories remaining, meet the criteria of being simple to produce and
6609 relevant to the end goal.6610
6611Adaptive reporting tools such as cumulative flow diagrams, burn-up/burn-down graphs, and
6612parking lot diagrams also provide valuable project information.6613
661410.3.1 Control Software Project Communications: Inputs
6615The inputs in Section 10.3.1 of the PMBOK® Guide are applicable inputs for controlling
6616 software project communications. In addition, the inputs in 10.3.1.6 and 10.3.1.7 are
6617 applicable for controlling software project communications.6618
661910.3.1.1 Project Management Plan
Page 150
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
150/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
6620See Section 10.3.1.1 of the PMBOK® Guide.6621
662210.3.1.2 Project Communications
6623See Section 10.3.1.2 of the PMBOK® Guide.6624
662510.3.1.3 Issue Log
6626See Section 10.3.1.3 of the PMBOK® Guide.6627
662810.3.1.4 Work Performance Data
6629See Section 10.3.1.4 of the PMBOK® Guide.6630
663110.3.1.5 Organizational Process Assets
6632See Section 10.3.1.5 of the PMBOK® Guide.6633
663410.3.1.6 Prioritized Backlog
6635For adaptive software project life cycles, the prioritized product backlog plays a key
6636 role in controlling communications. It is the primary method used to communicate the
6637 agreed-upon work and the sequence of upcoming development. The backlog can take the form
6638of an online tool, a spreadsheet, or a stack of task cards.6639
664010.3.1.7 Velocity Statistics and Projections
6641For adaptive life cycles, current velocity information and historical trends are used to
6642determine the rate at which work was completed in previous iterations. This information is
6643 essential for estimating the amount of work that can be completed in subsequent
6644 iterations. Figure 10-5 illustrates a typical velocity chart for a software project.6645
6646
Page 151
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
151/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
6647 Figure 10-5. A Velocity Chart for a Software Project6648
664910.3.2 Control Software Project Communications: Tools and Techniques
6650The tools and techniques in Section 10.3.2 of the PMBOK® Guide are applicable for managing
6651 software project communications. In addition, the tools and techniques in Sections
665210.3.2.4 and 10.3.2.5 are applicable to managing software project communications.6653
6654 10.3.2.1 Information Management Systems
6655See Section 10.3.2.1 of the PMBOK® Guide.6656
6657 10.3.2.2 Expert Judgment
6658See Section 10.3.2.2 of the PMBOK® Guide.6659
6660 10.3.2.3 Meetings
6661See Section 10.3.2.3 of the PMBOK® Guide.6662
666310.3.2.4 Considerate Communications
6664Software development requires concentration in a quiet setting to enter the productive
6665 state of flow. It is often reported that this takes about 20 minutes to achieve and can be
6666disrupted by a phone call or a minute or two of conversation [36]. This presents a paradox
6667 for software developers; on the one hand they need to get to a state of flow, but on the
6668other hand, they need a co-located team environment with high bandwidth and face-to-face
6669 communications for resolving issues and obtaining rapid feedback.6670
6671One approach is, when possible, to arrange a work area that includes quiet rooms in which
6672 to work and a common work area where team members can discuss issues. Another approach is
6673 the use of quiet hours that provide the quiet atmosphere of a library. During specified
6674quiet hours, phones are disabled and no visitors or meetings are scheduled.6675
6676The use of electronic messaging when team members are physically co-located in a common
6677 area can also be used to minimize the impact on concentration flow while still allowing
6678 communication. Regardless of the approach used, communications control should support the
6679 concentrated effort required for creative work.6680
668110.3.2.5 Automated Systems
6682Systems that automatically collect project status can be used to improve communications
6683 efficiencies. These systems, often used to control communication in software projects
6684 include Wiki sites, project websites, and collaboration-based internet sites.6685
668610.3.3 Control Software Project Communications: Outputs
6687The outputs in Section 10.3.3 of the PMBOK® Guide are applicable for controlling software
6688project communications. In addition, the outputs listed in Sections 10.3.3.6 and 10.3.3.7
6689 are also applicable.6690
669110.3.3.1 Work Performance Information
6692See Section 10.3.3.1 of the PMBOK® Guide.6693
Page 152
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
152/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
669410.3.3.2 Change Requests
6695See Section 10.3.3.2 of the PMBOK® Guide.6696
669710.3.3.3 Project Management Plan Updates
6698See Section 10.3.3.3 of the PMBOK® Guide.6699
670010.3.3.4 Project Documents Updates
6701See Section 10.3.3.4 of the PMBOK® Guide.6702
670310.3.3.5 Organizational Process Assets Updates
6704See Section 10.3.3.5 of the PMBOK® Guide.
6705
670610.3.3.6 Release/Iteration Plan Updates
6707An important part of managing stakeholder expectations is ensuring there are no surprises
6708 for anyone. So, for adaptive life cycles, it is important to distribute and explain
6709updates to release and iteration plans that are typically amended frequently. Release
6710plans describe when releases will occur and what functionality they will contain.
6711 Iteration plans confirm the work the project team has committed to deliver at the end of
6712 the next iteration. An iteration plan provides an early indication of the functionality
6713 that will be user acceptance-tested and demonstrated at the end of each iteration.6714
671510.3.3.7 Reprioritized Backlog
6716When using adaptive life cycles for software projects, the customer has the opportunity to
6717 reprioritize the backlog of features to be developed throughout the project lifecycle. The
6718backlog of work describes the remaining work to be done and the current priorities. The
6719work backlog also shows the planned sequence of development and, using average velocity
6720 and “yesterday’s weather,” the schedule for development of these features can be
6721 estimated. The backlogs of product features and remaining work, along with estimates of
6722 scheduled feature delivery, are important elements of project communication that help to
6723 control customer/product owner expectations and eliminate unpleasant surprises.6724
672511 Software Project Risk Management
6726According to Section 11 of the PMBOK® Guide, Project Risk Management includes the
6727processes of conducting risk management planning, identification, analysis, response
6728planning, and controlling risk on a project. The objectives of Project Risk Management are
6729 to increase the probability and impact of positive events, and decrease the probability
6730 and impact of negative events in the project. This section of the Software Extension to
6731 the PMBOK® Guide – Fifth Edition addresses risk management for software projects by
6732describing risks and risk mitigation strategies that are important for managing software
6733projects, and which merit attention beyond that provided in the PMBOK® Guide.6734
6735As defined in the Glossary, risk is an uncertain event or condition that, if it occurs,
6736has a positive or negative effect on a project’s objectives. In ISO Guide 73:2009 – Risk
6737Management: Vocabulary [40], risk is defined as the “combination of the probability of an
6738 event and its consequence.” This widely used definition is applied in the principal
6739 software engineering standard for risk management: ISO/IEC/IEEE 16085 – Systems and
Page 153
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
153/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
6740 software engineering—Life cycle processes—Risk management [41].6741
6742Each software development project has different uncertainties and risks, because each
6743project is a unique combination of requirements, design, and construction, resulting in
6744distinct software products (uncertainty arises from a lack of information; risk is a
6745potential issue). Software technical risks and software project risks affect every
6746 stakeholder. Therefore, almost every recommended activity in the PMBOK® Guide and this
6747 software extension is intended to manage risks. Software risk management aims to improve
6748 the probability of achieving the project goals; software opportunity management aims to
6749 exceed the project goals. Opportunity management is commonly applied in software project
6750management, especially in adaptive projects that have the opportunity to respond to
6751 customer-requested changes, apply new technology, or receive additional resources. The
6752 risk management process is “a continuous process for systematically identifying,
6753 analyzing, treating, and monitoring risk throughout the life cycle of a product or
6754 service” [41].6755
6756Software project risk management and opportunity management for software projects includes
6757planning, identifying, and analyzing software project risks and opportunities; performing
6758 software project qualitative and quantitative risk and opportunity analyses; planning risk
6759 and opportunity responses; and monitoring and controlling project risks and opportunities.
6760Figure 11-1 provides an overview of the Project Risk Management processes. Commonly
6761occurring risks for software projects include technical, schedule, cost, quality (e.g.,
6762 security, safety, availability), team dynamics, and customer/stakeholder risk factors.
6763Risk treatments include accepting, avoiding, transferring, or mitigating risk. Mitigating
6764 risk can occur by either immediate action or tracking and deferred action, if warranted.6765
6766While this section primarily addresses software development project risk management, the
6767 techniques and approaches are also applicable to delivery of software as a service. In
6768 that case, the primary risk is a break in service continuity, that is, the inability to
6769 continually deliver services at agreed-upon levels.6770
6771Figure 11-1 provides an overview of Software Project Risk Management; it is an adaptation
6772of Figure 11-1 in the PMBOK® Guide.6773
6774
Page 154
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
154/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
6775
6776 Figure 11-1. Software Project Risk Management Overview6777
677811.1 Plan Software Project Risk Management
6779The inputs, tools and techniques, and outputs for planning risk management in Section 11.1
6780of the PMBOK® Guide are applicable to planning risk management for software projects with
6781 the following additions and clarifications.6782
678311.1.1 Plan Software Project Risk Management: Inputs
6784The inputs for planning risk management in Section 11.1.1 of the PMBOK® Guide are
6785 applicable for planning software project risk management.6786
6787 11.1.1.1 Project Management Plan
6788See Section 11.1.1.1 of the PMBOK® Guide.6789
6790 11.1.1.2 Project Charter
6791See Section 11.1.1.2 of the PMBOK® Guide.6792
6793 11.1.1.3 Stakeholder Register
6794See Section 11.1.1.3 of the PMBOK® Guide.6795
6796 11.1.1.4 Enterprise Environmental Factors
Page 155
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
155/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
6797See Section 11.1.1.4 of the PMBOK® Guide.6798
6799 11.1.1.5 Organizational Process Assets
6800See Section 11.1.1.5 of the PMBOK® Guide.6801
6802The following considerations are also applicable. Software risk planning occurs
6803 repeatedly, beginning with an initial formal or informal risk-benefit analysis and
6804decision either to initiate or not initiate the project. For large, formal software
6805projects, projects in regulated environments, and projects involving safety-critical
6806 software, a documented risk management plan is essential. Most projects have less formal
6807 risk management procedures or follow an overall enterprise risk management plan.
6808Specialized domain knowledge may make risks more apparent to some team members. While all
6809 team members should be responsible for identifying and communicating risks, there should
6810be a risk management lead.6811
6812Risk management planning accompanies project planning and is reflected in the project at
6813many levels, including risk management activities, data gathering, monitoring, decisions
6814 and assessments and changes to work plans. Depending upon the nature of risks, the life
6815 cycle model and processes are adjusted. Each of the assumptions and constraints used to
6816develop the project plan should be examined for risk. Projects can take a proactive
6817 risk-driven approach. Prioritizing high-risk items and tackling them early in the project
6818while there is time to try alternative approaches and to improve upon initial efforts
6819 accomplish this. By proactively undertaking high-risk work early, the software project
6820 team can reduce the overall impact to the project. By deferring risky work, problems may
6821 result and the probability of rework or a revised approach is much higher while the time
6822 remaining to recover from problems is short. Simply put, it is more cost-effective to
6823 resolve risks earlier than later.6824
682511.1.2 Plan Software Project Risk Management: Tools and Techniques
6826The tools and techniques for planning risk management in the PMBOK® Guide are applicable
6827 tools and techniques for planning software project risk management.6828
682911.1.2.1 Analytical Techniques
6830See Section 11.1.2.1 of the PMBOK® Guide.6831
683211.1.2.2 Expert Judgment
6833See Section 11.1.2.2of the PMBOK® Guide.
6834
683511.1.2.3 Meetings
6836See Section 11.1.2.3 of the PMBOK® Guide.6837
6838The following considerations also apply. Adaptive life cycle software projects pull
6839 requirements and user stories from a backlog that can entail frequent reprioritization to
6840permit risk management actions as early as possible in the life cycle, minimizing delayed
6841 and compounded effects. Also, since integration and regression testing is built into each
6842 iterative cycle, the probability of untested risky elements remaining in the product
6843 towards the end of the project is greatly reduced. Adaptive life cycles can be called
6844 risk-driven, because the software project team can pull high-risk stories forward from the
6845backlog.6846
6847Adaptive life cycle projects allow for frequent reassessment of risks and reprioritization
6848 at the end of each iteration, which can take advantage of newly identified opportunities
6849 to add features or take action to mitigate newly identified risks. The project team can
Page 156
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
156/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
6850 add risk avoidance and risk reduction actions into the backlog and choose to proactively
6851 attack the risks before they have an impact on the project. The team should think of risk
6852 avoidance and risk mitigation as part of the value proposition for the adaptive planning
6853 cycle.6854
685511.1.3 Plan Risk Management: Outputs
6856The output for planning risk management in Section 11.1.3 of the PMBOK® Guide, the risk
6857 register, is applicable to planning software project risk management.6858
685911.1.3.1 Risk Management Plan
6860See Section 11.1.3 of the PMBOK® Guide.6861
6862 In addition, when planning for the next iteration of an adaptive life cycle, the project
6863 team typically balances delivering business value with risk reduction. Sometimes the team
6864may select a next feature to be implemented that has the best return on investment.
6865Sometimes they will undertake an action to avoid or mitigate risk since the impact of the
6866 risk occurring would be greater than the ROI value of the next feature in the backlog, as
6867depicted in Figure 11-2.6868
6869
6870
6871 Figure 11-2. Business and Risk Reduction Activities Prioritized in the Product Backlog6872
6873The software project manager needs to ensure that risk management procedures, reporting
6874 rhythms, and risk register are established at the beginning of the project. The risk
6875 register can be as simple as a spreadsheet or whiteboard with annotated note cards or
6876 stories attached. For large projects and critical software products, specialized software
6877 tools aid in managing the outputs from planning risk management.6878
687911.2 Identify Software Project Risks
6880The inputs, tools and techniques, and outputs for identifying risks in Section 11.2 of the
6881PMBOK® Guide are applicable to identifying risks for software projects.6882
688311.2.1 Identify Software Project Risks: Inputs
6884The inputs for identifying project risk in the PMBOK® Guide are applicable for identifying
6885 software project risks.6886
688711.2.1.1 Risk Management Plan
6888See Section 11.2.1.1 of the PMBOK® Guide.6889
Page 157
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
157/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
689011.2.1.2 Cost Management Plan
6891See Section 11.2.1.2 of the PMBOK® Guide.6892
689311.2.1.3 Schedule Management Plan
6894See Section 11.2.1.3 of the PMBOK® Guide.6895
689611.2.1.4 Quality Management Plan
6897See Section 11.2.1.4 of the PMBOK® Guide.6898
689911.2.1.5 Human Resource Management Plan
6900See Section 11.2.1.5 of the PMBOK® Guide.6901
690211.2.1.6 Scope Baseline
6903See Section 11.2.1.6 of the PMBOK® Guide.6904
690511.2.1.7 Activity Cost Estimates
6906See Section 11.2.1.7 of the PMBOK® Guide.6907
690811.2.1.8 Activity Duration Estimates
6909See Section 11.2.1.8 of the PMBOK® Guide.6910
691111.2.1.9 Stakeholder Register
6912See Section 11.2.1.9 of the PMBOK® Guide.6913
691411.2.1.10 Project Documents
6915See Section 11.2.1.10 of the PMBOK® Guide.6916
691711.2.1.11 Procurement Documents
6918See Section 11.2.1.11 of the PMBOK® Guide.
6919
692011.2.1.12 Enterprise Environmental Factors
6921See Section 11.2.1.12 of the PMBOK® Guide.6922
692311.2.1.13 Organizational Process Assets
6924See Section 11.2.1.13 of the PMBOK® Guide.6925
6926The following considerations also apply. While every software project needs to identify
6927 risk factors, it is helpful to be aware of the more common types of risks for software
Page 158
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
158/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
6928projects. The Software Engineering Institute (SEI) has published several three-level risk
6929 taxonomies, notably for operational risk and development project risk. These taxonomies
6930break down risks by class, for example, program constraints, product engineering, and
6931development environment; then by element, such as requirements within product engineering;
6932 and then by attribute, such as stability or formality of requirements.66933
6934Table 11-1 is a simple first-level risk breakdown structure, with examples of common
6935 software project risks.6936
6937 Table 11-1 First-Level Risk Breakdown Structure6938
6939
6940
Page 159
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
159/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
694111.2.2 Identify Software Project Risks: Tools and Techniques
6942The tools and techniques in Section 11.2.2 of the PMBOK® Guide for identifying risks are
6943 applicable to identifying risks for software projects.6944
694511.2.2.1 Documentation Reviews
6946See Section 11.2.2.1 of the PMBOK® Guide.6947
694811.2.2.2 Information Gathering Techniques
6949See Section 11.2.2.2 of the PMBOK® Guide.6950
695111.2.2.3 Checklist Analysis
6952See Section 11.2.2.3 of the PMBOK® Guide.6953
695411.2.2.4 Assumptions Analysis
6955See Section 11.2.2.4 of the PMBOK® Guide.6956
695711.2.2.5 Diagramming Techniques
6958See Section 11.2.2.5 of the PMBOK® Guide.6959
696011.2.2.6 SWOT Analysis
6961See Section 11.2.2.6 of the PMBOK® Guide.6962
696311.2.2.7 Expert Judgment
6964See Section 11.2.2.7 of the PMBOK® Guide.6965
6966 In addition, the following considerations also apply. During retrospective meetings,
6967project teams evaluate the evolving system, review areas that may be behind in
6968development, and discuss areas with the most problems and concerns regarding the remaining
6969work to be done. In doing so, project risks may be uncovered.6970
6971Risks are often expressed as potential problems, but it is more effective to identify them
6972 as areas for improvement (i.e., opportunities). Software project risks may be expressed as
6973 if–then statements: “If [risk/opportunity becomes an actual issue], then
6974 [adverse/favorable outcomes will occur].” This form of risk statement focuses attention on
6975 the potential outcome, which is a necessary part of the probability × impact calculation
6976 in classic risk analysis. It also draws attention to the threshold trigger that would
6977 cause a potential problem (i.e., risk) to become a real problem.6978
697911.2.3 Identify Software Project Risks: Outputs
6980The output in Section 11.2.3 of the PMBOK® Guide on identifying risks is applicable for
6981 identifying risks for software projects.6982
698311.2.3.1 Risk Register
6984See Section 11.2.3.1 of the PMBOK® Guide.
Page 160
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
160/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
6985
698611.3 Perform Software Project Qualitative Risk Analysis
6987The inputs, tools and techniques, and outputs in Section 11.3 of the PMBOK® Guide for
6988performing qualitative risk analysis are applicable to performing qualitative risk
6989 analysis for software projects, with the following additions and clarifications.6990
6991 It is human nature to focus on the more immediate risks, but advanced risk management is
6992used to control the longer-term risks. Software product development needs to be
6993 sustainable, from various viewpoints: financial, team continuity, the software design
6994 framework, and the quality of code for future changes. Risk analysis should also look for
6995 immediate and sustained opportunities.6996
699711.3.1 Perform Software Project Qualitative Risk Analysis: Inputs
6998The inputs for performing qualitative risk analysis in Section 11.3.1 of the PMBOK® Guide
6999 are applicable to performing qualitative risk analysis for software projects.7000
700111.3.1.1 Risk Management Plan
7002See Section 11.3.1.1 of the PMBOK® Guide.7003
700411.3.1.2 Scope Baseline
7005See Section 11.3.1.2 of the PMBOK® Guide.7006
700711.3.1.3 Risk Register
7008See Section 11.3.1.3 of the PMBOK® Guide.7009
701011.3.1.4 Enterprise Environmental Factors
7011See Section 11.3.1.4 of the PMBOK® Guide.7012
701311.3.1.5 Organizational Process Assets
7014See Section 11.3.1.5 of the PMBOK® Guide.7015
7016 In addition, considerations for performing qualitative risk analysis for software projects
7017 include: (1) criticality of the software product (its impact on its users and the
7018operational environment), (2) the effect should a risk interfere with the completion and
7019 successful delivery of the software product, and (3) the overall effect on the producing
7020organization (that is, a “bet the company” project or an optional enhancement to a mature
7021product).7022
702311.3.2 Perform Software Project Qualitative Risk Analysis: Tools and Techniques
7024The tools and techniques for performing qualitative risk analysis in Section 11.3.2 of the
7025PMBOK® Guide are applicable to performing qualitative risk analysis for software projects.7026
7027
702811.3.2.1 Risk Probability and Impact Assessment
7029See Section 11.3.2.1 of the PMBOK® Guide.
Page 161
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
161/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
7030
703111.3.2.2 Probability and Impact Matrix
7032See Section 11.3.2.2 of the PMBOK® Guide.7033
703411.3.2.3 Risk Data Quality Assessment
7035See Section 11.3.2.3 of the PMBOK® Guide.7036
703711.3.2.4 Risk Categorization
7038See Section 11.3.2.4 of the PMBOK® Guide.7039
704011.3.2.5 Risk Urgency Assessment
7041See Section 11.3.2.5 of the PMBOK® Guide.7042
704311.3.2.6 Expert Judgment
7044See Section 11.3.2.6 of the PMBOK® Guide.7045
7046The following considerations also apply. Qualitative analyses of risk are, by definition,
7047difficult or impossible to quantify and are usually based on subjective and limited
7048 experience. Accurately estimating the probability of a risk requires a large experience
7049base of similar projects (similar in complexity, criticality, infrastructure and tools,
7050 team experience, and organizational process resources). In practice, only very large
7051organizations are able to accumulate experience bases and, for competitive reasons, are
7052 reluctant to share it with external stakeholders and other organizations. Often,
7053 experience concerning the rate of work completion (i.e., velocity) is not available until
7054 the project is well underway when there is less time to exert corrective measures.7055
7056Additional causal analysis (e.g. asking “why” three times) can help identify root causes
7057of identified risks. Qualitative risk analysis benefits from recent experience, (e.g., for
7058 similar infrastructure and team members accustomed to working together). The analysis may
7059be distorted by the impact of recent work (i.e., the tendency to emphasize the most recent
7060 experience rather than the long-term average). A risk that became a problem on a previous
7061project may be considered likely to occur in the next project. Conversely, the problems
7062 encountered in previous projects may be considered to be thoroughly nullified by lessons
7063 learned and mitigations applied, so that the probability of recurrence is considered to be
7064minimal. However, the precautionary mitigations may impose extraordinary costs in
7065monitoring and control, such as attempting exhaustive testing, scheduling a large number
7066of project reviews and executive presentations, and imposing heavy documentation
7067 requirements, which in themselves create the risk of excessive cost and noncompetitive
7068business processes.7069
7070Performing both Qualitative and Quantitative Risk Analyses involves analyzing identified
7071project risks and prioritizing then to identify the highest-risk items, features, and/or
7072 stories.7073
7074Qualitative ratings of risks for software projects can be based on subjective values such
7075 as low, medium, high, or very high for both probability and potential impact, as
7076 illustrated in Table 11-2. A low-risk exposure might correspond to a small schedule delay
7077or cost overrun or a minor quality issue; a medium value to a more significant value of a
7078project or product parameter, a high value to a major issue; and a very high value to a
7079potentially catastrophic situation.7080
7081Quantitative ratings can be based on numeric values, as illustrated in Table 11-3. The
Page 162
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
162/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
7082 entries in Table 11-3 are the products of the corresponding values of probability and
7083normalized impacts; this product is called the risk exposure. A project manager or
7084 assigned risk manager may assign both an unmitigated risk exposure and a mitigated risk
7085 exposure, along with the cost of risk mitigation. Risk leverage factors (the difference
7086between unmitigated and mitigated risk exposures divided by the cost of risk mitigation)
7087 can be used to evaluate the effectiveness of various risk reduction strategies. See also
7088Figure 11-11 in the PMBOK® Guide.7089
7090 Table 11-2. A Qualitative Risk Exposure Matrix7091
7092
7093
7094 Table 11-3. A Quantitative Risk Exposure Matrix7095
7096
7097
7098For adaptive life cycle projects, a risk exposure matrix can be used to prioritize
7099 features for inclusion in the next iterative cycle by focusing on the features that will
7100have the largest risk/return value for the business or the end users, as illustrated in
7101Figure 11-2. This is similar to opportunity analysis, stated in risk management terms.7102
710311.3.3 Perform Software Project Qualitative Risk Analysis: Outputs
7104The output for performing qualitative risk analysis in Section 11.3.3 of the PMBOK® Guide
7105 is applicable to performing qualitative risk analysis for software projects.7106
710711.3.3.1 Project Documents Updates
7108See Section 11.3.3.1 of the PMBOK® Guide.7109
711011.4 Perform Software Project Quantitative Risk Analysis
7111The inputs, tools and techniques, and outputs for performing quantitative risk analysis in
7112Section 11.4 of the PMBOK® Guide are applicable to performing quantitative risk analysis
7113 for software projects.7114
7115Quantitative techniques are often used on major software projects, such as competitive
7116 software acquisitions or enterprise initiatives. The time and expertise required for
7117 extensive quantitative modeling may not be justified for shorter, simpler projects.
7118
7119Quantitative analysis may be used to prioritize (1) unmitigated risks in the product
7120backlog, and (2) risk avoidance and risk mitigation activities. A software project
7121
Page 163
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
163/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
technical risk has an impact cost, and a risk mitigation or risk transfer option has a
7122quantifiable cost, such as the cost of procuring software in comparison to the labor cost
7123of building the software—these can be translated into monetary units. Similarly, human
7124 resource and business risks can be estimated in monetary terms. Of course, not all risks
7125have avoidance or mitigation steps that can be scheduled into a software project. Some
7126 risks may have to be accepted (e.g., the project is delayed while waiting for a procured
7127 component), but those steps that can be proactively addressed can be prioritized in the
7128 iterative project’s backlog.7129
7130Quantitative risk analysis has several practical limitations. It is not possible to
7131 estimate the probability and impact of all potential problems (risks). For example,
7132 consider the risk of developing software that makes it easy for hackers to access private
7133user data. There is no cost until after the project is ended when the software is being
7134used in the operational environment. At that time, a security breach could result in
7135 fines, legal fees, and remediation costs to the users for credit monitoring, litigation
7136 costs, and loss of future business. The expenses are potentially large and serious, but
7137not easily quantified at the time of risk analysis during software development.7138
7139For software projects, risk identification and risk analysis attempt to focus on the most
7140probable and highest-impact risks rather than the cumulative impact of a succession of
7141minor risks. Also, the impact of some risks may be hard to quantify as far as direct costs
7142 to the project or organization. The precision of the monetary value may not be great, but
7143 the point of quantitative risk analysis for software projects is usually to take action
7144based on relative scorings rather than precise numbers. The goal is to reach consensus
7145with the software project stakeholders on justifiable numbers to use as a basis for
7146prioritization, not to report costs on a balance sheet.7147
7148The objectivity and relevance of a quantitative risk analysis ultimately depends on
7149qualitative judgment, the availability of an experience base, and the objectivity of the
7150 experts estimating the best, most likely and worst-case points.7151
715211.4.1 Perform Software Project Quantitative Risk Analysis: Inputs
7153The inputs in Section 11.4.1 of the PMBOK® Guide for performing quantitative risk analysis
7154 are applicable to performing quantitative risk analysis for software projects.7155
715611.4.1.1 Risk Management Plan
7157See Section 11.4.1.1 of the PMBOK® Guide.7158
715911.4.1.2 Cost Management Plan
7160See Section 11.4.1.2 of the PMBOK® Guide.7161
716211.4.1.3 Schedule Management Plan
7163See Section 11.4.1.3 of the PMBOK® Guide.7164
716511.4.1.4 Risk Register
7166See Section 11.4.1.4 of the PMBOK® Guide.7167
716811.4.1.5 Enterprise Environmental Factors
7169See Section 11.4.1.5 of the PMBOK® Guide.7170
Page 164
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
164/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
717111.4.1.6 Organizational Process Assets
7172See Section 11.4.1.6 of the PMBOK® Guide.7173
717411.4.2 Perform Software Project Quantitative Risk Analysis: Tools and Techniques
7175The tools and techniques in Section 11.4.2 of the PMBOK® Guide for performing quantitative
7176 risk analysis are applicable to performing quantitative risk analysis for software
7177projects with the following extensions to Data Gathering and Representation Techniques and
7178Quantitative Risk Analysis and Modeling Techniques.7179
718011.4.2.1 Data Gathering and Representation Techniques
7181See Section 11.4.2.1 of the PMBOK® Guide.7182
7183The calculation of risk impact × probability is also used to calculate risk expected
7184monetary value expressed as mitigation cost times probability.7185
7186Risk expected monetary value = Risk impact (in monetary units) × Risk probability (0.0 –
71871.0)7188
7189A software project thus has a quantitative value (cost or benefit) for each risk
7190mitigation activity in comparison to the cost and value of new work. For example, assume
7191 there is risk of having an inadequate reporting tool in place (assume $0 future cost for
7192 the existing tool) which could be completely mitigated by buying and using a
7193high-performance reporting engine that costs $10,000 to buy, implement, and run. If the
7194project estimates that there is a 50% chance of needing this tool, then the evaluated cost
7195 (or economic value) of purchasing the new tool is $5,000 ($10,000 × 50%).7196
7197On the other hand, even though the existing tool has a zero cost for use, suppose that the
7198 cost of staff time over the same period to collect and analyze data and compile reports is
7199 estimated to be $25,000 and, based on experience, there is again a 50% chance that reports
7200will not be usable or ready on time. The cost of continuing with the existing tool is
7201$12,500; therefore, purchasing the new tool is the better value.7202
7203Using this approach, a software risk manager can rank project risks to produce a
7204prioritized list of risks ordered by expected monetary value, which can be used to
7205prioritize the value of requirements in terms of risk. These activities actions support
7206meaningful discussions with the software project sponsors. In Figure 11-3, the second risk
7207 from the top has an expected monetary value of $8000 × 50% or $4000. Therefore, when it
7208 comes to selecting requirements (features) for an upcoming iteration, the risk mitigation
7209 action associated with risk #2 ranks similar to the functional requirements value for
7210number #2. In other words, this risk mitigation work is of equal value to the organization
7211 as the addition of a new software feature.7212
7213
7214
7215
Page 165
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
165/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
Figure 11-3. Comparative Priorities of Risk Treatment and Business Value7216
721711.4.2.2 Quantitative Risk Analysis and Modeling Techniques
7218See Section 11.4.2.2 of the PMBOK® Guide.
7219
7220The following consideration also applies. Quantitative simulations may identify the need
7221 for more extensive risk mitigation, and for applying schedule and budget contingency
7222 reserves. Monte Carlo simulations may be used to compute project outcomes at various
7223 levels of probability and to indicate the probability of obtaining the “most likely”
7224 estimate (see Figures 11-14 and 11-18 of the PMBOK® Guide).7225
722611.4.2.3 Expert Judgment
7227See Section 11.4.2.3 of the PMBOK® Guide.7228
722911.4.3 Perform Software Project Quantitative Risk Analysis: Outputs
7230The output in Section 11.4.3 of the PMBOK® Guide for performing quantitative risk analysis
7231 is applicable to performing quantitative risk analysis for software projects.7232
723311.4.3.1 Project Documents Updates
7234See Section 11.4.3.1 of the PMBOK® Guide.7235
723611.5 Plan Software Project Risk Responses
7237Planning risk responses for software projects includes the evaluation and selection of
7238 risk treatment alternatives. The project leaders evaluate the risk exposure of an
7239untreated risk, the exposure after treatment (the residual risk), and the cost of the risk
7240 treatment. If the cost of the risk treatment is high compared to the impact of the risk,
7241 accepting the risk may be the best response. Accepted risks remain on a watch list or in a
7242 risk register for ongoing monitoring.7243
7244The inputs, tools and techniques, and outputs for planning risk responses in Section 11.5
7245of the PMBOK® Guide are applicable to planning risk responses for software projects.7246
724711.5.1 Plan Software Project Risk Responses: Inputs
7248The inputs for planning risk responses in Section 11.5.1 of the PMBOK® Guide are
7249 applicable to planning risk responses for software projects.7250
725111.5.1.1 Risk Management Plan
7252See Section 11.5.1.1 of the PMBOK® Guide.7253
725411.5.1.2 Risk Register
7255See Section 11.5.1.2 of the PMBOK® Guide.7256
725711.5.2 Plan Software Project Risk Responses: Tools and Techniques
7258
Page 166
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
166/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
The tools and techniques for planning risk responses in Section 11.5.2 of the PMBOK® Guide
7259 are applicable for software projects.7260
726111.5.2.1 Strategies for Negative Risks or Threats
7262See Section 11.5.2.1 of the PMBOK® Guide.7263
726411.5.2.2 Strategies for Positive Risks or Opportunities
7265See Section 11.5.2.2 of the PMBOK® Guide.7266
726711.5.2.3 Contingent Response Strategies
7268See Section 11.5.2.3 of the PMBOK® Guide.7269
727011.5.2.4 Expert Judgment
7271See Section 11.5.2.4 of the PMBOK® Guide.7272
7273 In addition to the tools and techniques for planning risk responses in Section 11.5.2 of
7274 the PMBOK® Guide, risk-based testing assesses the probability of elements of the software
7275being defective and the consequences of those defects. Where the probability and
7276 consequence are high, that element is tested more extensively. Where the probability and
7277 consequence are low, that element is either tested less extensively or not tested at all.
7278This allows the limited testing resources on a software project to be focused on providing
7279 the highest benefit.7280
7281Risk leverage factors (RLF) may be calculated for various risks as an aid to planning
7282 software project risk responses by calculating the risk exposure of an untreated risk
7283 (REut = probability × impact), risk exposure after treatment (REat = residual probability
7284× impact) and including the cost of the risk treatment, RTc, where all three factors are
7285 expressed in monetary terms:7286
7287RLF = [REut – REat]/RTc7288
7289Risk leverage factors for identified risks can be used to prioritize the application of
7290 limited risk treatment funds. Higher values of RLF indicate higher cost-return benefits.7291
729211.5.3 Plan Software Project Risk Responses: Outputs
7293The outputs for planning risk responses in Section11.5.3 of the PMBOK® Guide are
7294 applicable for software projects.7295
729611.5.3.1 Project Management Plan Updates
7297See Section 11.5.3.1 of the PMBOK® Guide.7298
729911.5.3.2 Project Documents Updates
7300See Section 11.5.3.2 of the PMBOK® Guide.7301
7302The following considerations also apply. Aside from quickly remedied risks, risk responses
7303 to avoid, transfer, or mitigate risk may require detailed planning to execute. The summary
7304maintained in the risk register should include the specific risk treatment planned, who is
7305 responsible, affected stakeholders, cost and schedule for the risk treatment, monitoring
Page 167
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
167/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
7306 schedule, and measures to evaluate the progress and effectiveness of the risk treatment.
7307The impact of the risk treatment should also be noted; the risk treatment may itself
7308 introduce secondary risks, safety concerns, or environmental impacts.7309
7310Table 11-4 contains typical risk responses used to avoid, mitigate, or transfer risk for
7311 software projects. No special approaches need to be stated for accepting risk; often the
7312 risk is accepted until a more cost-effective way to mitigate or transfer the risk is
7313 identified.7314
7315 Table 11-4 Typical Risk Responses for Software Projects
7316
7317
7318
731911.6 Control Software Project Risks
7320The inputs, tools and techniques, and outputs for controlling risks in Section 11.6 of the
7321PMBOK® Guide are applicable to controlling risks for software projects with the following
7322 additions and extensions.7323
7324Risk monitoring and control for software projects includes tracking identified risks,
Page 168
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
168/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
7325monitoring residual risks, executing risk treatment plans, and evaluating their
7326 effectiveness. On small software projects, monitoring and controlling risks are part of
7327 the project manager’s duties. On large programs, another individual, often a quality
7328 assurance or planning specialist, is designated as the risk manager and is delegated the
7329 responsibility for recording new risks in the risk register and ensuring that risk
7330mitigations are being implemented and completed by agreed-upon completion dates.7331
733211.6.1 Control Software Project Risks: Inputs
7333The software project manager (or risk manager) typically schedules regular reviews of risk
7334 impacts and probabilities until risks are closed out. Risk managers also capture
7335 experience data and lessons learned for use in future phases and other projects.7336
7337Organizations vary in their tolerance of risk. The risk threshold is the point at which a
7338 the probability of a risk becomes large enough that it can no longer be accepted and needs
7339 further treatment. To determine when the risk threshold is reached, software projects use
7340 indicators such as technical performance measures (TPM) or more selectively, key
7341performance indicators (KPI), which show how successfully a risk is being managed. For
7342 example, if the churn in requirements exceeds a defined percentage, or the number of test
7343defects per thousand lines of code (KLOC) passes a defined level, or the cost or schedule
7344performance index (CPI or SPI) exceeds a pre-specified limit, a risk threshold has been
7345 reached. This condition is called a risk trigger for the risk manager to initiate a
7346 contingency plan for risk treatment.7347
7348The inputs for controlling risks in Section 11.6.1 of the PMBOK® Guide are applicable to
7349 controlling risks for software projects.7350
735111.6.1.1 Project Management Plan
7352See Section 11.6.1.1 of the PMBOK® Guide.7353
735411.6.1.2 Risk Register
7355See Section 11.6.1.2 of the PMBOK® Guide.7356
735711.6.1.3 Work Performance Data
7358See Section 11.6.1.3 of the PMBOK® Guide.7359
736011.6.1.4 Work Performance Reports
7361See Section 11.6.1.4 of the PMBOK® Guide.7362
736311.6.2 Control Software Project Risks: Tools and Techniques
7364The tools and techniques for controlling risks in Section 11.6.2 of the PMBOK® Guide are
7365 applicable to planning risk responses for software projects.7366
736711.6.2.1 Risk Reassessment
7368See Section 11.6.2.1 of the PMBOK® Guide.7369
737011.6.2.2 Risk Audits
Page 169
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
169/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
7371See Section 11.6.2.2 of the PMBOK® Guide.7372
737311.6.2.3 Variance and Trend Analysis
7374See Section 11.6.2.3 of the PMBOK® Guide.7375
737611.6.2.4 Technical Performance Measurement
7377See Section 11.6.2.4 of the PMBOK® Guide.7378
737911.6.2.5 Reserve Analysis
7380See Section 11.6.2.5 of the PMBOK® Guide.7381
738211.6.2.6 Meetings
7383See Section 11.6.2.6 of the PMBOK® Guide.7384
7385The following considerations also apply. Adaptive life cycle software projects incorporate
7386many mechanisms for dealing with change (an easily reprioritized backlog, short
7387 iterations, daily stand-up meetings, frequent demonstrations of working, deliverable
7388 software, and planning retrospectives) that also lend themselves to proactive response to
7389 risks as follows:7390
7391 • 0Daily stand-up meetings. At the daily stand-up meeting, asking if there are any
7392 issues or impediments blocking progress can surface new project risks from the development
7393 team as today’s issues and blockers could become tomorrow’s risks and problems for the
7394project. So it is important to pay attention to the issues being raised and transfer any
7395 appropriate issues to the risk log and undertake the necessary risk assessment steps.
7396Also, when the team reports “impediments to progress” at the daily stand-up meetings,
7397 these may be candidates for potential risks, so the risk management plan should account
7398 for this iterative nature of review and potential source of risk identification.
7399From a risk management perspective, the purpose of the daily meeting is for the team to
7400 identify potential new risks, issues, or signs of trouble, which if left unchecked could
7401be a real threat to the project. The daily meetings also overcome the risk that team
7402members will not prioritize their time productively or will be less able to solve
7403 technical issues without coordination. Over the course of a project, adaptive software
7404deveopment teams use tools such as risk burn-down graphs and risk profiles to illustrate
7405 the effectiveness of the risk-driven approach. The goal is to rapidly reduce risks on the
7406project. During a retrospective meeting immediately following an iterative cycle a team
7407may close out risks that have been eliminated, and reevaluate the likelihood of risks
7408occurring or recurring during the next period.7409
7410 • 0Retrospective results—Retrospectives that regularly review the project for work
7411 that went well in addition to work that did not go well are good vehicles for identifying
7412 risk for the project.7413
7414 • 0Software evaluation feedback—Prototype evaluations reveal stakeholder concerns
7415with the proposed solution, which can result in technical and schedule risks. Addressing
7416 the concerns will likely require updates to the release and iteration plans and
7417 reprioritization of risk mitigations.7418
7419Adaptive life cycles provide some techniques for good risk management; they do not
7420 risk-proof or insulate projects from risks. Indeed, if an adaptive approach is new to an
7421organization, then its introduction will be a risk; anything new represents a risk of
7422misapplication, misunderstanding, confusion and failure. Having an active project sponsor
7423 and informed stakeholder involvement, wisely selecting team leaders with experience using
Page 170
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
170/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
7424 the adaptive approach, and scheduling time for team training are common techniques to
7425overcome the risk of introducing new methods and processes.7426
742711.6.3 Control Software Project Risks for Software Projects: Outputs
7428The outputs in Section 11.6.3 of the PMBOK® Guide for controlling risks are applicable for
7429 controlling risks for software projects.7430
743111.6.3.1 Work Performance Information
7432See Section 11.6.3.1 of the PMBOK® Guide.7433
743411.6.3.2 Change Requests
7435See Section 11.6.3.2 of the PMBOK® Guide.7436
743711.6.3.3 Project Management Plan Updates
7438See Section 11.6.3.3 of the PMBOK® Guide.7439
744011.6.3.4 Project Documents Updates
7441See Section 11.6.3.4 of the PMBOK® Guide.7442
744311.6.3.5 Organizational Process Assets Updates
7444See Section 11.6.3.5 of the PMBOK® Guide.7445
7446 In addition, risk burn-down charts, similar to progress burn-down charts, can be used to
7447 track the number of risks identified and closed out; they can be displayed as visual
7448 charts for the project team. Information in a risk register can be summarized in a risk
7449profile. According to ISO/IEC/IEEE Standard 16085 [41] the project risk profile includes
7450 the risk management context, a record of each risk’s current and historical state and
7451priority, and all of the risk action requests. The risk action state includes the
7452probability, consequences, and risk threshold for the risk.
7453
745412 Software Project Procurement Management
7455The introduction to Section 12 of the PMBOK® Guide states: Project Procurement Management
7456 includes the processes necessary to purchase or acquire products, services, or results
7457needed from outside the project team. The organization can be either the buyer or seller
7458of the products, services, or results of a project.7459
7460Large software organizations, like other engineering organizations, typically have a
7461procurement department that deals with contracting issues related to the procurement of
7462products and services. Small software organizations may not have a similar support
7463 function and, as a result, the software project manager may play an increased role in
7464managing software project procurements.7465
7466Also, as indicated in the introductory paragraph of Section 12 of the PMBOK® Guide, an
7467organization may be the seller of the products, services, or results of a project. In some
7468 cases, a software organization may be a prime contractor or a subcontractor (seller) to
7469 another organization or governmental agency. In these cases, some or all of the processes
7470
Page 171
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
171/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
to be followed and the metrics to be reported by the software project manager may be
7471 elements of the statement of work for the project.7472
7473This section of the Software Extension to the PMBOK® Guide – Fifth Edition focuses on the
7474 considerations involved in procuring services for a software project or new software
7475products, such as a procuring a custom-built software application or turn-key
7476 infrastructure. It addresses planning, conducting, controlling, and closing out software
7477project procurements, primarily from the point of view of the acquiring software project
7478manager. It also addresses the acquisition of commercially available (COTS) software for
7479use on a software project. Licensing of software packages, obtaining rights to modify open
7480 source software, reuse of existing components, and the purchase of specialty services to
7481build software are all elements of software procurement.7482
7483Software may also be procured as a service. Just as with commercially available software,
7484 it is important to understand the exact nature of the services provided; how they might
7485 evolve over time; and what control the customer retains over the data provided to be
7486processed under the service, the results obtained, and any security obligations. These
7487 considerations are usually covered in a service level agreement (SLA). Often, the standard
7488 agreement issued by the provider may not meet the acquirer’s (i.e., the software
7489project’s) specific needs.7490
7491Procured services can include complete outsourcing of software development, assistance
7492 from software consultants and experts in software development processes, staff
7493 augmentation by contracted developers and testers, and provision of supporting services
7494 such as data migration and conversion, QA, CM, and product documentation.7495
7496Because software requires frequent updates to meet changes in security threats,
7497 infrastructure upgrades, and new functional requirements, it is rarely purchased outright
7498without provisions for ongoing maintenance. In some cases, the software acquirer will
7499obtain a license or right to use the software or a lease with specific terms and
7500 conditions rather than having complete control of the software source code. If there is no
7501 initial purchase price, as with freeware or open source software, the refresh and
7502 adaptation costs, as well as support costs, versioning, and maintenance are procurement
7503 considerations.7504
7505This section does not address the specialized work of procurement agents such as
7506 subcontract administrators and software buyers, nor does it address the legal and
7507 regulatory particularities of contracts and agreements for software, documentation, and
7508other intellectual property, which vary from country to country. Successful suppliers and
7509vendors of software establish and use effective processes, work as part of a mature
7510organization, and are likely to do the following:7511
7512 • 0Plan and execute acquisitions predictably,
7513 • 0Support those programs with a management infrastructure that will enable them to succeed,
7514 • 0Communicate more accurately and frequently, and
7515 • 0Stay on schedule and deliver acceptable quality products.7516
7517Figure 12-1 provides an overview of Software Project Procurement Management; it is an
7518 adaptation of Figure 12-1 in the PMBOK® Guide.7519
Page 172
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
172/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
7520
7521
7522 Figure 12-1. Software Procurement Management Overview7523
752412.1 Plan Software Project Procurement Management
7525The first step in planning for software procurement is making the decision that a software
7526product or service needs to be acquired. The organization may perform a business case
7527 analysis, trade study, or market survey of available capabilities, conduct a needs
7528 assessment, or a make-or-buy study to determine that the best way to meet a resource need
7529 is to acquire a software product or service (see Section 12.1.2.1 of the PMBOK® Guide). It
7530 is a good practice to document the alternatives considered before proceeding with
7531procurement and to communicate the procurement strategy to the project stakeholders.7532
7533Once the decision to procure is made, the organization needs a procurement strategy. In
7534 fact, there may be a formal plan and schedule for the procurement. Major activities in
7535planning the procurement of software include: (1) identifying potential suppliers, (2)
7536 specifying the requirements by preparing a statement of objectives or statement of work,
7537 (3) establishing evaluation criteria, (4) preparing preferred terms and conditions, and
7538 (5) developing procurement documents (request for proposals or request for tender).7539
Page 173
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
173/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
7540 • 0Identifying suppliers. Bidders’ conferences with potential suppliers are often
7541 conducted as part of the initial market surveys. Architectural and technical decisions may
7542 severely limit the options for potential suppliers, since the supplier should have
7543 experience with the intended software environment. Procuring infrastructure such as an
7544operating system, middleware, or a common development environment will drive how custom
7545 software capabilities are created. Conversely, the architecture of the software product
7546needs to provide the necessary organization, infrastructure, and interfaces to enable
7547 integration of special functionality, application support, or utility software that may be
7548procured.7549
7550 • 0Statement of objective or statement of work. The choice of how to specify
7551 requirements for procurement depends on the scope, impact, and audience affected by the
7552 software or service, as indicated in Figure 12-2.7553
7554
7555
7556 Figure 12-2. Level of Detail for Software/Service Acquisition Requirements7557
7558 In all cases, the acquirer needs to specifically identify the required deliverables. A
7559 statement of objectives (SOO) is often used in performance-based contracting, where the
7560 acquirer indicates the results to be achieved, leaving the supplier to determine the
7561processes, tools, and resources needed to deliver the service or product.7562
7563Detailed requirements statements are sometimes used for software procurements, but can be
7564 extremely complex for full specifications. Overly specifying may lead to much higher
7565development costs when most of the essential features are already available in one or more
7566 commercially available software (COTS) products. However, without the critical features
7567 crisply identified, the likelihood of the software meeting the project needs is greatly
7568 reduced. Requirements may also include a list of the standards or specifications to which
7569 the system or service is required to conform. Lack of a detailed requirements statement at
7570 the onset of a project often leads to an adaptive strategy in which a few outcomes or
7571 scenarios are specified to get an acquisition project started.7572
7573A statement of work (SOW) details the work to be performed and is often appropriate for
7574 time-and-effort support with or without specific performance standards or service levels.
Page 174
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
174/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
7575An SOW for software procurement typically includes the scope of contractual obligations
7576 for the contracted (i.e., bespoke) software and may include development processes to be
7577used, metrics to be reported, and early delivery of product subset capabilities. (Section
757812.1.3.2 of the PMBOK® Guide provides additional details concerning the Procurement SOW.)7579
7580Management requirements should be specified as well as technical requirements, including
7581 requirements for status reports, inputs for schedule updates, and participation in project
7582meetings and reviews.7583
7584 • 0Establishing proposal evaluation criteria. Criteria for evaluation procurement
7585proposals submitted by potential suppliers (i.e., bidders) identify the supplier’s
7586 specific technical capabilities, management approach, experience, and cost factors to be
7587 considered in selecting the supplier and explain how the factors will be weighted and
7588 evaluated. Usually, cost is not the most important factor in selecting a software or
7589 service provider, and within the cost factors, the initial cost is less important than the
7590 total cost over the project or product life cycle.7591
7592 In addition to the evaluation criteria for the received proposals, the acquiring project
7593manager needs to define the acceptance criteria or performance standard for the product or
7594 service to be provided. Acceptance of custom software may come, for example, on successful
7595 completion of acceptance testing by the users, or only after installation into the
7596production environment.7597
7598 • 0Preparing terms and conditions. Terms and conditions provide the details on how,
7599where, and when the software product or service will be delivered. The supplier may have a
7600preferred set of contract conditions related to cost, schedule, capabilities, maintenance,
7601 contract type, intellectual property rights, and data rights; the acquirer may also have a
7602preferred set of contract conditions, which may be very different from those of the
7603 supplier. Therefore, it is critical that the software project manager participate in the
7604development of the terms and conditions and understand their impact.7605
7606The upfront determination of an appropriate licensing approach (ownership of intellectual
7607property and data rights) is critical in nearly all software procurements. Specifics as to
7608who owns the product, non-compete clauses, warranties, and data management are a few of
7609 the issues to be resolved. It is important to objectively identify the project’s needs for
7610 licensing rights and to determine the appropriate license type. The acquirer may develop a
7611 licensing strategy for computer software and require the vendor to provide a list of
7612 software products that have restrictions not explicitly stated in their commercial
7613 agreements. The licensing strategy should address four questions:7614
7615 • Who needs to use the product or modify it and to what extent?
7616 • What restrictions apply to accessing the supplied software by computer
7617 terminals and central processing units?
7618 • What restrictions apply to transferring the supplied software to other parts of
7619 the buyer’s organization and to sharing it with other parts of the organization?
7620 • Are there any plans to incorporate the supplied software into the buyer’s products?7621
7622Terms and conditions should include the type of contract, payment schedule, and expected
7623period of performance. Since the acquired product or service needs to arrive in time for
7624 the overall project schedule, the software project manager should understand and account
7625 for the schedule risk associated with delivery of custom-built (bespoke) software by
7626 allowing a significant margin in the time for acquired software to be integrated with
7627project-developed software.7628
7629 • 0Developing a procurement package. A request for proposal (RFP) provides the
7630necessary information to potential suppliers. It includes the technical requirements (SOO
7631or SOW), the terms and conditions, the evaluation criteria, and instructions for bidders.
7632The instructions explain what information should be included in the proposal, the
7633 anticipated procurement schedule, and the anticipated start date and period of
Page 175
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
175/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
7634performance. Instructions often specify a maximum length for the proposal and the required
7635 structure of the proposal, so responses can be more easily compared. Software proposal
7636 instructions commonly require that proposals contain information needed to evaluate a
7637bidder’s capabilities and stability, such as descriptions of related projects, customer
7638 references, information on the qualifications of key personnel and staff certifications,
7639 and descriptions of facilities and technical resources.7640
764112.1.1 Plan Software Project Procurement Management: Inputs
7642The inputs in Section 12.1.1 of the PMBOK® Guide are applicable for planning software
7643procurement management.7644
764512.1.1.1 Project Management Plan
7646See Section 12.1.1.1 of the PMBOK® Guide.7647
764812.1.1.2 Requirements Documentation
7649See Section 12.1.1.2 of the PMBOK® Guide.7650
765112.1.1.3 Risk Register
7652See Section 12.1.1.3 of the PMBOK® Guide.7653
765412.1.1.4 Activity Resource Requirements
7655See Section 12.1.1.4 of the PMBOK® Guide.7656
765712.1.1.5 Project Schedule
7658See Section 12.1.1.5 of the PMBOK® Guide.7659
766012.1.1.6 Activity Cost Estimates
7661See Section 12.1.1.6 of the PMBOK® Guide.7662
766312.1.1.7 Stakeholder Register
7664See Section 12.1.1.7 of the PMBOK® Guide.7665
766612.1.1.8 Enterprise Environmental Factors
7667See Section 12.1.1.8 of the PMBOK® Guide.7668
766912.1.1.9 Organizational Process Assets
7670See Section 12.1.1.9 of the PMBOK® Guide.7671
767212.1.2 Plan Software Project Procurement Management: Tools and Techniques
7673The tools and techniques in Section 12.1.1 of the PMBOK® Guide are applicable for planning
Page 176
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
176/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
7674 software procurement management.7675
767612.1.2.1 Make-or-Buy Analysis
7677See Section 12.1.2.1 of the PMBOK® Guide.7678
767912.1.2.2 Expert Judgment
7680See Section 12.1.2.2 of the PMBOK® Guide.7681
768212.1.2.3 Market Research
7683See Section 12.1.2.3 of the PMBOK® Guide.7684
768512.1.2.4 Meetings
7686See Section 12.1.2.4 of the PMBOK® Guide.7687
768812.1.3 Plan Software Project Procurement Management: Outputs
7689The outputs in Section 12.1.3 of the PMBOK® Guide are applicable for planning software
7690procurement management.7691
769212.1.3.1 Procurement Management Plan
7693See Section 12.1.3.1 of the PMBOK® Guide.7694
769512.1.3.2 Procurement Statement of Work
7696See Section 12.1.3.2 of the PMBOK® Guide.7697
769812.1.3.3 Procurement Documents
7699See Section 12.1.3.3 of the PMBOK® Guide.7700
770112.1.3.4 Source Selection Criteria
7702See Section 12.1.3.4 of the PMBOK® Guide.7703
770412.1.3.5 Make-or-Buy Decisions
7705See Section 12.1.3.5 of the PMBOK® Guide.7706
770712.1.3.6 Change Requests
7708See Section 12.1.3.6 of the PMBOK® Guide.7709
771012.1.3.7 Project Documents Updates
7711See Section 12.1.3.7 of the PMBOK® Guide.7712
Page 177
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
177/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
771312.2 Conduct Software Project Procurements
7714Section 12.2 of the PMBOK® Guide indicates that the primary activities in software project
7715procurement include providing the procurement package to potential suppliers and
7716 communicating with them, receiving and evaluating offers, making a preliminary selection
7717of one or more suppliers, and negotiating the agreement with the supplier.7718
7719For commercially available software packages, price can be the primary determinant, but
7720 the lowest proposed price may not be the lowest cost if the seller proves to be unable to
7721deliver the products, services, or results in a timely and technically acceptable manner.
7722Evaluations of suppliers should consider the supplier’s project management practices and
7723organizational stability. Ideally, the risk of supplier default on delivery will be low so
7724 that the burden on the buyer to manage and control the subcontractor will be minimized.7725
7726On reviewing the proposals, the acquirer may determine that the best choice for the
7727project may be to modify the requirements in the SOO or SOW. Changes between the RFP
7728 requirements and the final agreement may be negotiated to support such considerations as
7729 affordability, timely completion of a basic set of software features, provision of named
7730key personnel who are considered essential to performance of the work, reduced risk,
7731 alignment of the supplier's schedule with the project's master schedule, or additional
7732 tasks or functions and future upgrades. Negotiations may also address topics such as
7733product acceptance, reporting, cost, usage, intellectual property rights, and data rights.
7734One way of controlling risk is to add a contract provision for placing the source code
7735 into escrow, in the event of a contract dispute or dissolution of the supplier’s
7736organization.7737
773812.2.1 Conduct Software Project Procurements: Inputs
7739The inputs in Section 12.2.1 of the PMBOK® Guide are applicable inputs for conducting
7740 software procurements.
7741
774212.2.1.1 Procurement Management Plan
7743See Section 12.2.1.1 of the PMBOK® Guide.7744
774512.2.1.2 Procurement Documents
7746See Section 12.2.1.2 of the PMBOK® Guide.7747
774812.2.1.3 Source Selection Criteria
7749See Section 12.2.1.3 of the PMBOK® Guide.7750
775112.2.1.4 Seller Proposals
7752See Section 12.2.1.4 of the PMBOK® Guide.7753
775412.2.1.5 Project Documents
7755See Section 12.2.1.5 of the PMBOK® Guide.7756
775712.2.1.6 Make-or-Buy Decisions
Page 178
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
178/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
7758See Section 12.2.1.6 of the PMBOK® Guide.7759
776012.2.1.7 Procurement Statement of Work
7761See Section 12.2.1.7 of the PMBOK® Guide.7762
776312.2.1.8 Organizational Process Assets
7764See Section 12.2.1.8 of the PMBOK® Guide.7765
776612.2.2 Conduct Software Project Procurements: Tools and Techniques
7767The tools and techniques in Section 12.2.1 of the PMBOK® Guide are applicable for
7768 conducting software procurements.7769
777012.2.2.1 Bidder Conferences
7771See Section 12.2.2.1 of the PMBOK® Guide.7772
777312.2.2.2 Proposal Evaluation Techniques
7774See Section 12.2.2.2 of the PMBOK® Guide.7775
777612.2.2.3 Independent Estimates
7777See Section 12.2.2.3 of the PMBOK® Guide.7778
777912.2.2.4 Expert Judgment
7780See Section 12.2.2.4 of the PMBOK® Guide.7781
778212.2.2.5 Advertising
7783See Section 12.2.2.5 of the PMBOK® Guide.7784
778512.2.2.6 Analytical Techniques
7786See Section 12.2.2.6 of the PMBOK® Guide.7787
778812.2.2.7 Procurement Negotiations
7789See Section 12.2.2.7 of the PMBOK® Guide.7790
779112.2.3 Conduct Software Project Procurements: Outputs
7792The outputs in Section 12.2.1 of the PMBOK® Guide are applicable for conducting software
7793procurements.7794
779512.2.3.1 Selected Sellers
Page 179
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
179/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
7796See Section 12.2.3.1 of the PMBOK® Guide.7797
779812.2.3.2 Agreements
7799See Section 12.2.3.2 of the PMBOK® Guide.7800
780112.2.3.3 Resource Calendars
7802See Section 12.2.3.3 of the PMBOK® Guide.7803
780412.2.3.4 Change Requests
7805See Section 12.2.3.4 of the PMBOK® Guide.7806
780712.2.3.5 Project Management Plan Updates
7808See Section 12.2.3.5 of the PMBOK® Guide.7809
781012.2.3.6 Project Documents Updates
7811See Section 12.2.3.6 of the PMBOK® Guide.7812
781312.3 Control Software Project Procurements
7814 In addition to the issues addressed in Section 12.3 of the PMBOK® Guide, the following
7815 considerations apply to procurement of commercially available software (COTS) products.
7816Because COTS products have frequent release cycles (typically 9 to 12 months), staying
7817 current requires an ongoing expenditure of resources to install and maintain the latest
7818versions of COTS products. It is also helpful be aware of the likely evolution and life
7819 expectancy for a COTS product. The COTS provider may discontinue support of a COTS product
7820and those who provided the expertise may be unavailable.
7821
782212.3.1 Control Software Project Procurements: Inputs
7823The inputs in Section 12.3.1 of the PMBOK® Guide are applicable for controlling software
7824procurements.7825
782612.3.1.1 Project Management Plan
7827See Section 12.3.1.1 of the PMBOK® Guide.
7828
782912.3.1.2 Procurement Documents
7830See Section 12.3.1.2 of the PMBOK® Guide.7831
783212.3.1.3 Agreements
7833See Section 12.3.1.3 of the PMBOK® Guide.7834
783512.3.1.4 Approved Change Requests
Page 180
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
180/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
7836See Section 12.3.1.4 of the PMBOK® Guide.7837
783812.3.1.5 Work Performance Reports
7839See Section 12.3.1.5 of the PMBOK® Guide.7840
784112.3.1.6 Work Performance Data
7842See Section 12.3.1.6 of the PMBOK® Guide.7843
784412.3.2 Control Software Procurements: Tools and Techniques
7845The tools and techniques in Section 12.3.2 of the PMBOK® Guide are applicable for
7846 controlling software procurements.7847
784812.3.2.1 Contract Change Control System
7849See Section 12.3.2.1 of the PMBOK® Guide.7850
785112.3.2.2 Procurement Performance Reviews
7852See Section 12.3.2.2 of the PMBOK® Guide.7853
785412.3.2.3 Inspections and Audits
7855See Section 12.3.2.3 of the PMBOK® Guide.7856
785712.3.2.4 Performance Reporting
7858See Section 12.3.2.4 of the PMBOK® Guide.7859
786012.3.2.5 Payment Systems
7861See Section 12.3.2.5 of the PMBOK® Guide.7862
786312.3.2.6 Claims Administration
7864See Section 12.3.2.6 of the PMBOK® Guide.7865
786612.3.2.7 Records Management System
7867See Section 12.3.2.7 of the PMBOK® Guide.7868
786912.3.3 Control Software Project Procurements: Outputs
7870The outputs in Section 12.3.3 of the PMBOK® Guide are applicable for controlling software
7871procurements.7872
787312.3.3.1 Work Performance Information
Page 181
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
181/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
7874See Section 12.3.3.1 of the PMBOK® Guide.7875
787612.3.3.2 Change Requests
7877See Section 12.3.3.2 of the PMBOK® Guide.7878
787912.3.3.3 Project Management Plan Updates
7880See Section 12.3.3.3 of the PMBOK® Guide.
7881
788212.3.3.4 Project Documents Updates
7883See Section 12.3.3.4 of the PMBOK® Guide.7884
788512.3.3.5 Organizational Process Assets Updates
7886See Section 12.3.3.5 of the PMBOK® Guide.7887
788812.4 Close Software Project Procurements
7889While a software procurement activity usually ends before the software project ends, the
7890need for the acquired service or software product may continue. Closing one procurement
7891 activity may signal the need to open another for ongoing maintenance. Another
7892 consideration is long-term technology relevance and the ability of the supplier to support
7893 technical change over time. If a software project manager plans to integrate a COTS
7894product or custom-built software into their product, the project manager needs to be aware
7895 that the technology used to develop the COTS product or custom-built software could
7896 adversely affect the ability to make product enhancements in the future. Additional
7897 considerations for closing software procurements are provided in Section 12.4 of the
7898PMBOK® Guide.7899
790012.4.1 Close Software Project Procurements: Inputs
7901The inputs in Section 12.4.1 of the PMBOK® Guide are applicable for closing software
7902procurements.7903
790412.4.1.1 Project Management Plan
7905See Section 12.4.1.1 of the PMBOK® Guide7906
790712.4.1.2 Procurement Documents
7908See Section 12.4.1.2 of the PMBOK® Guide7909
791012.4.2 Close Software Project Procurements: Tools and Techniques
7911The tools and techniques in Section 12.4.2 of the PMBOK® Guide are applicable for
7912 controlling software procurements.7913
791412.4.2.1 Procurement Audits
Page 182
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
182/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
7915See Section 12.4.2.1 of the PMBOK® Guide.7916
791712.4.2.2 Procurement Negotiations
7918See Section 12.4.2.2 of the PMBOK® Guide.7919
792012.4.2.3 Records Management System
7921See Section 12.4.2.3 of the PMBOK® Guide.7922
792312.4.3 Close Software Project Procurements: Outputs
7924The outputs in Section 12.4.3 of the PMBOK® Guide are applicable for closing software
7925procurements.7926
792712.4.3.1 Closed Procurements
7928See Section 12.4.3.1 of the PMBOK® Guide.7929
793012.4.3.2 Organizational Process Assets Updates
7931See Section 12.4.3.2 of the PMBOK® Guide.7932
793313 SOFTWARE PROJECT STAKEHOLDERMANAGEMENT
7934The introduction to Section 13 of the PMBOK® Guide states: Project Stakeholder Management
7935 includes the processes required to identify all people or organizations impacted by the
7936project, analyzing stakeholder expectations and impact on the project, and developing
7937 appropriate management strategies for effectively engaging stakeholders in project
7938decisions and execution.7939
7940The PMBOK® Guide also states that stakeholder management focuses on continuous dialogue
7941with stakeholders to meet their needs and expectations, addressing issues as they occur,
7942 and fostering appropriate stakeholder engagement in project decisions and activities.
7943Stakeholder satisfaction should be managed as a key project deliverable.7944
7945Most of the material in Section 13 of the PMBOK® Guide is applicable to software projects.
7946This section of the Software Extension to the PMBOK® Guide – Fifth Edition presents
7947 additional considerations for managing stakeholders of software projects.7948
7949Figure 13-1 provides an overview of Software Project Stakeholder Management; it is an
7950 adaptation of Figure 13-1 in the PMBOK® Guide.7951
Page 183
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
183/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
7952
7953
7954 Figure 13-1. Software Project Stakeholder Management Overview7955
7956Stakeholder management is critical for achieving successful outcomes for software projects
7957because software has no physical presence and is often novel. Software is difficult to
7958visualize until it is demonstrated. In addition, there often exists a gulf of expectation
7959between what a customer or product owner states and what the developer interprets.
7960Misalignments among stakeholders represent a major risk for successful completion of
Page 184
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
184/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
7961 software projects.7962
7963Adaptive life cycles for software projects raise the visibility of the evolving product
7964 and the engagement of the customer and other stakeholders through frequent demonstrations,
7965discussions, negotiations, and collaborative planning. As illustrated in Figure 13-2,
7966predictive life cycle software projects have high stakeholder involvement at the beginning
7967of the project when plans and requirements are being developed and at the end when user
7968 testing and product acceptance occur. Adaptive lifecycle software projects include
7969 frequent demonstrations of evolving increments of functional, deliverable software for the
7970 customer and other stakeholders, thus maintaining product visibility and stakeholder
7971 engagement throughout the duration of the software project.7972
7973
7974
7975 Figure 13-2. Product Visibility and Stakeholder Engagement7976
797713.1 Identify Software Project Stakeholders
7978The material in Section 13.1 of the PMBOK® Guide is applicable to identifying stakeholders
7979 for software projects.7980
798113.1.1 Identify Software Project Stakeholders: Inputs
7982The inputs in Section 13.1.1 of the PMBOK® Guide are applicable for identifying software
7983project stakeholders.7984
798513.1.1.1 Project Charter
7986See Section 13.1.1.1 of the PMBOK® Guide.7987
798813.1.1.2 Procurement Documents
7989See Section 13.1.1.2 of the PMBOK® Guide.7990
799113.1.1.3 Enterprise Environmental Factors
7992See Section 13.1.1.3 of the PMBOK® Guide.7993
Page 185
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
185/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
799413.1.1.4 Organizational Process Assets
7995See Section 13.1.1.4 of the PMBOK® Guide.7996
799713.1.2 Identify Software Project Stakeholders: Tools and Techniques
7998The tools and techniques in Section 13.1.2 of the PMBOK® Guide, are applicable for
7999 identifying software project stakeholders. In addition, Section 13.1.2.4 is applicable for
8000 identifying software project stakeholders.8001
800213.1.2.1 Stakeholder Analysis
8003See Section 13.1.2.1 of the PMBOK® Guide.8004
800513.1.2.2 Expert Judgment
8006See Section 13.1.2.2 of the PMBOK® Guide.8007
800813.1.2.3 Meetings
8009See Section 13.1.2.3 of the PMBOK® Guide.8010
801113.1.2.4 Persona Modeling for Software Projects
8012Software teams sometimes use persona modeling to identify and analyze project
8013 stakeholders. Personas are visual summaries of key stakeholders and their interests.
8014Personas may be real people or composites. They have the following characteristics: an
8015 archetypal description, grounded in reality; goal-oriented; specific and relevant; and
8016 tangible and actionable. They are not a replacement for requirements but instead augment
8017 and support prioritization of the requirements. Personas provide insight by providing
8018 focus, understanding, and empathy for the users of a system. An example of persona
8019modeling is illustrated in Figure 13-3.
8020
8021
8022
8023 Figure 13-3. Depiction of Software Project Persona Modeling8024
8025Persona attributes may include goals, influencers, questions, and frustrations and pain
8026points in addition to knowledge, activities, and interest. These attributes can be
Page 186
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
186/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
8027 tailored to software projects to provide descriptions of stakeholder personas and provide
8028 a basis for stakeholder analysis.8029
8030Personas support better decision making by keeping a team focused on delivery of
8031value-adding product features. Teams can shorten discussions by referencing personas that
8032 team members are familiar with to settle issues of needs, wants, and exclusions.8033
803413.1.3 Identify Software Project Stakeholders: Outputs
8035The output in Section 13.1.3 of the PMBOK® Guide, are applicable for identifying software
8036project stakeholders.8037
803813.1.3.1 Stakeholder Register
8039See Section 13.1.3.1 of the PMBOK® Guide.8040
804113.2 Plan Software Project Stakeholder Management
8042As stated in the introduction to Section 13 of the PMBOK® Guide, stakeholder management
8043 also focuses on continuous dialogue with stakeholders to meet their needs and
8044 expectations, addressing issues as they occur, and fostering appropriate stakeholder
8045 engagement in project decisions and activities.8046
8047For software projects, it is especially important to plan for close and frequent
8048 involvement of customers and product owners (i.e., business-stakeholder involvement) to
8049provide validation that the project is progressing towards the desired goal and that the
8050 evolving product is suitable, because software functionality and behavior are difficult to
8051 assess until demonstrated. The acronym IKIWISI (I’ll Know It When I See It) is often used
8052 to describe this issue and highlights the need for frequent demonstrations and trials to
8053 fine-tune required (and desired) functionality and behavior. Because of the opportunity
8054 for divergent expectations among stakeholders and project team members, software project
8055managers should plan for demonstrations in timeframes of weeks rather than months.8056
805713.2.1 Plan Software Project Stakeholder Management: Inputs
8058The inputs in Section 13.2.1 of the PMBOK® Guide, are applicable for identifying software
8059project stakeholders, with the modification of Section 13.2.1.3. An additional input for
8060 identifying software project stakeholders is provided in 13.2.1.5.8061
806213.2.1.1 Project Management Plan
8063See Section 13.2.1.1 of the PMBOK® Guide.8064
806513.2.1.2 Stakeholder Register
8066See Section 13.2.1.2 of the PMBOK® Guide.8067
806813.2.1.3 Enterprise Environmental Factors for Software Projects
8069Bureaucracy, office politics, and personal dynamics lead to inefficiencies in
8070decision-making and are an unavoidable input to stakeholder management. Although these
8071 factors are present in all business situations, these issues are typically exposed early
8072 in software projects that use adaptive project life cycles because team members interact
8073 closely with project stakeholders. These issues may be less visible when using a
Page 187
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
187/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
8074predictive software project life cycle to manage a software project.
8075
807613.2.1.4 Organizational Process Assets
8077See Section 13.2.1.4 of the PMBOK® Guide.8078
807913.2.1.5 Organizational Factors and Adaptive-Iteration Durations
8080Software projects that use adaptive life cycles and that have limited availability of
8081 stakeholders to review product increments, or that share resources with slow cadence
8082projects will likely adopt iteration durations in the 2-4 week range. Projects without
8083 these restrictions will likely adopt iteration durations in the 1-2 week range. The
8084 software processes and tools used to release software to a test environment may also
8085 influence the duration of iterations.8086
808713.2.2 Plan Software Project Stakeholder Management: Tools and Techniques
8088The tools and techniques in Section 13.2.2 of the PMBOK® Guide, are applicable for
8089 identifying software project stakeholders.8090
809113.2.2.1 Expert Judgment
8092See Section 13.2.2.1 of the PMBOK® Guide.8093
809413.2.2.2 Meetings
8095See Section 13.2.2.2 of the PMBOK® Guide.8096
809713.2.2.3 Analytical Techniques
8098See Section 13.2.2.3 of the PMBOK® Guide.8099
810013.2.3 Plan Software Project Stakeholder Management: Outputs
8101The outputs in Section 13.2.3 of the PMBOK® Guide, are applicable for planning software
8102project stakeholder management. In addition, Section 13.2.3.3 is applicable to planning
8103 software project stakeholder management.
8104
810513.2.3.1 Stakeholder Management Plan
8106See Section 13.2.3.1 of the PMBOK® Guide.8107
810813.2.3.2 Project Documents Updates
8109See Section 13.2.3.2 of the PMBOK® Guide.8110
811113.2.3.3 Iteration Plans
8112For software projects that use adaptive life cycles, retrospectives that involve
8113 stakeholders in planning and reviewing activities that occur at the start and end of
8114 iterative cycles will be recorded in iteration plans.8115
Page 188
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
188/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
811613.3 Manage Software Project Stakeholder Engagement
8117Software projects that develop new and unprecedented software products are, or should be,
8118 collaborative explorations towards functionally and financially acceptable solutions. This
8119 rarely happens by accident and, in most cases, stakeholder engagement is actively managed
8120 to ensure that project objectives are stated and met. For adaptive software project life
8121 cycles, this takes the form of scheduled demonstrations and user trials of working,
8122deliverable software at the end of selected iterations that produce increments of product
8123 capability.8124
8125When receiving feedback from customers, users, and other stakeholders following their
8126 evaluation of an increment of functionality, it may be tempting to interpret no comments
8127 as good news and not as issues or problems. Rarely is “no news” from stakeholders
8128 considered to be good news, especially early in a software project. Lack of feedback is
8129more likely a sign of insufficient stakeholder involvement. Efforts should be made to
8130 ensure that project stakeholders seriously and thoroughly evaluate incremental versions of
8131 the product. If this does not occur, issues and desired changes may be discovered later in
8132 the project when the issues are more costly to fix, or it may be too late too incorporate
8133 requested changes while maintaining the delivery schedule.8134
813513.3.1 Manage Software Project Stakeholder Engagement: Inputs
8136The inputs for managing project stakeholder engagement in Section 13.3.1 of the PMBOK®
8137Guide are applicable for software projects. In addition, the input in Section 13.3.1.5 is
8138 applicable for software projects.8139
814013.3.1.1 Stakeholder Management Plan
8141See Section 13.3.1.1 of the PMBOK® Guide.8142
814313.3.1.2 Communications Management Plan
8144See Section 13.3.1.2 of the PMBOK® Guide.8145
814613.3.1.3 Change Log
8147See Section 13.3.1.3 of the PMBOK® Guide.8148
814913.3.1.4 Organizational Process Assets
8150See Section 13.3.1.4 of the PMBOK® Guide.8151
815213.3.1.5 Reviews, Meetings, and Plans
8153Milestone reviews provide opportunities for stakeholder engagement in predictive life
8154 cycle software projects. Periodic technical interface meetings (TIMs) can also be held.
8155For software projects that use adaptive life cycles, iteration plans provide an important
8156 input for managing software project stakeholder engagement. These plans provide an initial
8157 estimate of what will be included in each iterative release of the software. Retrospective
8158meetings during each release demonstration provide the opportunity to dynamically update
8159 release plans.8160
816113.3.2 Manage Software Project Stakeholder Engagement: Tools and Techniques
Page 189
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
189/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
8162The tools and techniques in Section 13.3.2 of the PMBOK® Guide are applicable for software
8163projects. In addition, Sections 13.3.2.4 and 13.3.2.5 are applicable to software projects.8164
816513.3.2.1 Communication Methods
8166See Section 13.3.2.1 of the PMBOK® Guide.8167
816813.3.2.2 Interpersonal Skills
8169See Section 13.3.2.2 of the PMBOK® Guide.8170
817113.3.2.3 Management Skills
8172See Section 13.3.2.3 of the PMBOK® Guide.8173
817413.3.2.4 Information Radiators
8175As explained in Section 10, information radiators are large, graphical displays of project
8176 status and the metrics used to report project status. They are frequently updated and
8177 located in view of the software project team and other project stakeholders. Commonly used
8178graphs include task boards, burn-up and burn-down graphs, cumulative flow diagrams, and
8179defect lists. Information radiators replace diffuse internal politics and unhealthy
8180 competition with project-relevant information. See Section 10 of this extension for
8181 examples of information radiators.8182
818313.3.2.5 Velocity Metrics and Yesterday’s Weather
8184See Section 10 of this software extension for a discussion of velocity metrics and
8185yesterday’s weather.8186
818713.3.3 Manage Software Project Stakeholder Engagement: Outputs
8188The outputs for managing stakeholder engagement in Section 13.3.3 of the PMBOK® Guide are
8189 applicable for software projects. In addition, the output in 13.3.3.6 is applicable to
8190managing stakeholder engagement for software projects.8191
819213.3.3.1 Issue Log
8193See Section 13.3.3.1 of the PMBOK® Guide8194
819513.3.3.2 Change Requests
8196See Section 13.3.3.2 of the PMBOK® Guide8197
819813.3.3.3 Project Management Plan Updates
8199See Section 13.3.3.3 of the PMBOK® Guide8200
820113.3.3.4 Project Documents Updates
8202See Section 13.3.3.4 of the PMBOK® Guide8203
Page 190
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
190/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
820413.3.3.5 Organizational Process Assets Updates
8205See Section 13.3.3.5 of the PMBOK® Guide8206
820713.3.3.6 Adaptive Project Communication Tools
8208As discussed in Section 10 of this extension, adaptive life cycle models for software
8209projects use a set of communications tools for describing scope, schedule, progress, and
8210 risks. These tools include product backlogs, release maps, cumulative flow diagrams, and
8211product burn-down graphs, and risk burn-down graphs.8212
821313.4 Control Software Project Stakeholder Engagement
8214Controlling and managing stakeholder engagement and expectations is arguably the single
8215most important success factor for any software project manager. Techniques for managing
8216 adaptive life cycle software projects offer some unique challenges as well as some
8217 advantages over software stakeholder engagement techniques for predictive lifecycles. In
8218particular, software project managers and the software team must have stakeholder
8219 acceptance of, and ongoing participation in the adaptive life cycle model being used.8220
8221Management and execution of adaptive life cycles should be explained to and supported by
8222 customers and other stakeholders. The software project team also needs to know what is
8223 expected of them when interacting with customers. Getting true buy-in by external
8224 stakeholders and by an inexperienced project team can be challenging and time consuming.8225
8226For adaptive life cycles, it is important that the customer and other decision-making
8227 stakeholders understand that they are responsible for feature identification, feature
8228prioritization, and sequencing of development; that they control what gets worked on; and
8229 that they are to be provided with demonstrations on progress and product functionality,
8230which will require their objective feedback. Controlling stakeholder expectations is much
8231 easier when this occurs than with major milestone reviews that are typical of stakeholder
8232 involvement in predictive life cycle projects. The development process becomes transparent
8233 and is easily adjusted as needed.8234
8235The inputs, tools and techniques, and outputs for controlling project stakeholder
8236 engagement in Section 13.4 of the PMBOK® Guide are applicable for controlling software
8237project stakeholder engagement.8238
823913.4.1 Control Software Project Stakeholder Engagement: Inputs
8240The inputs for controlling project stakeholder engagement in Section 13.4.1 of the PMBOK®
8241Guide are applicable for software projects.8242
824313.4.1.1 Project Management Plan
8244See Section 13.4.1.1 of the PMBOK® Guide.8245
824613.4.1.2 Issue Log
8247See Section 13.4.1.2 of the PMBOK® Guide.8248
824913.4.1.3 Work Performance Data
8250See Section 13.4.1.3 of the PMBOK® Guide.
8251
Page 191
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
191/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
8252
13.4.1.4 Project Documents
8253See Section 13.4.1.4 of the PMBOK® Guide.8254
825513.4.2 Control Software Project Stakeholder Engagement: Tools and Techniques
8256The tools and techniques for controlling stakeholder engagement in Section 13.4.2 of the
8257PMBOK® Guide are applicable to controlling software project stakeholder engagement.8258
825913.4.2.1 Information Management Systems
8260See Section 13.4.2.1 of the PMBOK® Guide.8261
826213.4.2.2 Expert Judgment
8263See Section 13.4.2.2 of the PMBOK® Guide.8264
826513.4.2.3 Meetings
8266See Section 13.4.2.3 of the PMBOK® Guide.8267
826813.4.3 Control Software Project Stakeholder Engagement: Outputs
8269The outputs for controlling stakeholder engagement in Section 13.4.3 of the PMBOK® Guide
8270 are applicable for controlling software project stakeholder engagement.8271
827213.4.3.1 Work Performance Information
8273See Section 13.4.3.1 of the PMBOK® Guide.8274
827513.4.3.2 Change Requests
8276See Section 13.4.3.2 of the PMBOK® Guide.8277
827813.4.3.3 Project Management Plan Updates
8279See Section 13.4.3.3 of the PMBOK® Guide.8280
828113.4.3.4 Project Documents Updates
8282See Section 13.4.3.4 of the PMBOK® Guide.8283
828413.4.3.5 Organizational Process Assets Updates
8285See Section 13.4.3.5 of the PMBOK® Guide.8286
8287
8288Footnotes:
8289 () The boldface numbers in parentheses refer to a list of references at the end of this
8290 standard.
Page 192
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
192/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
8291 (2) Available from http://www.sei.cmu.edu/
8292 (3) Refactoring of software involves modifying the structure of a (partial or complete)
8293 software product without altering its behavior.
8294 (4) The ConOps may also be known as a mission statement, a marketing analysis, or by some
8295other name.
8296 (5) ISO/IEC/IEEE Standard 1038 can be helpful in establishing peer review processes.
8297 (6) Available from www.sei.cmu.edu/library/abstracts/reports/93tr006.cfm.8298
8299
8300References
8301 {ED NOTE: this is a rough draft of the references. The style and specific listings will be
8302 finalized prior to publication.}8303
8304 [1] Project Management Institute, 2013. A Guide to the Project Management Body of
8305Knowledge (PMBOK® Guide) Fifth Edition. Newtown Square, PA: author.
8306 [2] IEEE Standard 24765 (SEVOCAB)
8307 [3] Project Management Institute, 2012. PMI Lexicon of Project Management Terms. Newtown
8308Square, PA: author.
8309 [4] PMI Code of Ethics and Professional Conduct
8310 [5] Software Engineering Code of Ethics and Professional Practice;
8311http://www.computer.org/cms/Computer.org/Publications/code-of-ethics.pdf
8312 [6] Association of Information Technology Professionals (AITP) Code of Ethics and
8313Standards of Conduct;
8314http://c.ymcdn.com/sites/www.aitp.org/resource/resmgr/forms/code_of_ethics.pdf
8315 [7] American Society for Information Science and Technology (AIS&T) Professional
8316Guidelines; http://www.asis.org/AboutASIS/professional-guidelines.html
8317 [8] ISO/IEEE Standard 15528 Systems and software engineering—System life cycle processes
8318 [9] ISO/IEEE Standard 12207 Systems and software engineering—Software project life cycle
8319processes
8320 [10] SEI. November 2010. Capability Maturity Model Integrated for Development (CMMI-DEV
8321V1.3); www.sei.cmu.edu/reports/10tr033.pdf
8322 [11] SEI. November 2010. Capability Maturity Model Integrated for Services (CMMI-SVC
8323V1.3); www.sei.cmu.edu/reports/10tr034.pdf
8324 [12] Conway, M. “How Do Committees Invent?,” Datamation, April, 1968.
8325 [13] ISO/IEC/IEEE 16326: Systems and software engineering—Life cycle processes—Project
8326management
8327 [14] SEI. November 2010. CMMI for Acquisition (CMMI-ACQ V1.3);
8328www.sei.cmu.edu/reports/10tr032.pdf
8329 [15] IEEE Standard 16326 Systems and software engineering—Life cycle process—Project
8330Management
8331 [16] IEEE Standard 830-1998 Recommended Practice for Software Requirements Specifications
8332 [17] IEEE Std 830-1998. IEEE Recommended Practice for Software Requirements.
8333Specifications
8334 [18] IEEE Std 1362-1998 IEEE Guide for Information Technology—System Definition —Concept
8335of Operations (ConOps) Document
8336 [19] Fairley, R., Managing and Leading Software Projects, Wiley, Hoboken, NJ, 2009
8337 [20] Tom DeMarco and Tim Lister: Peopleware: Productive Projects and Teams. Dorset House
8338Publishing Company. New York, NY, 1999.
8339 [21] Brooks, Frederick P. Jr., The Mythical Man-Month, Anniversary Edition, Addison
8340Wesley, 1995
8341 [22] Peter Drucker Management Challenges for the 21st Century, HarperBusiness; 1st edition
8342 (June 26, 2001)
8343 [23] ISO/IEC 25010
8344 [24] ISO Standard 9241-11: Guidance on Usability (1998)
8345 [25] ISO/IEC/IEEE Standard 15026: Systems and software engineering – Systems and Software
8346Assurance
Page 193
15/12/12 ExposureDraft - Software Extension to the PMBOK® Guide Fifth Edition
193/193ed.pmi.org/Pages/PrintDocument.aspx?documentId=20
©2012 Project Management Institute, Inc. | Exposure Draft v1.2.8.16672
8347 [26] IEEE Std 1044 – Classification for Software Anomalies
8348 [27] IEEE Standard 730 – Software Quality Assurance Plans
8349 [28] IEEE Std 829 (Software and System Test Documentation);
8350 [29] IEEE Std 1008 (Unit Testing)
8351 [30] IEEE Std 1012 (System and Software Verification and Validation)
8352 [31] IEEE Std 1028 – Software Reviews and Audits
8353 [32] IEEE Standard 828 Configuration Management in Systems and Software Engineering
8354 [33] Don Reinertson, Managing The Design Factory, Free Press (October 1, 1997)
8355 [34] Paul Glen, David Maister, Warren Bennis. Leading Geeks: How to Manage and Lead the
8356People Who Deliver Technology, Jossey-Bass (November 1, 2002)
8357 [35] McGregor, D. The Human Side of Enterprise, McGrawHill. (1960).
8358 [36] Tom DeMarco, Peter Hruschka, Tim Lister, Steve McMenamin, James Robertson, Suzanne
8359Robertson Adrenaline
8360 [37] Junkies and Template Zombies: Understanding Patterns of Project Behavior Dorset House
8361 (March 3, 2008)
8362 [38] Bruce Tuckman, “Developmental Sequences in Small Groups” Psychological Bulletin 63
8363 (1965): 384–99
8364 [39] Patrick M. Lencioni, The Five Dysfunctions of a Team: A Leadership Fable (San
8365Francisco: Jossey-Bass, 2002), 188–89.
8366 [40] ISO Guide 73:2009, Risk Management: Vocabulary
8367 [41] ISO/IEC 16085:2006, Standard for Software Engineering – Software project life cycle
8368Processes – Risk Management8369