exposuredraft - software extension to the pmbok guide fifth edition

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



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.



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:



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



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,



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



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



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.



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



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



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



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

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,



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



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:



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



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



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



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



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



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.

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



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



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



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



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



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.



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



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



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



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



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



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



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



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


15694.1.1.3 Agreements


15724.1.1.4 Enterprise Environmental Factors


15754.1.1.5 Organizational Process Assets


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



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


16314.1.2.2 Facilitation Techniques


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


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



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



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


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



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



17994.2.2.2 Facilitation Techniques


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.



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



18694.3.1.2 Approved Change Requests






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



18844.3.2.2 Project Management Information System


18874.3.2.3 Meetings


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



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


19374.3.3.2 Work Performance Data


19404.3.3.3 Change Requests


19434.3.3.4 Project Management Plan Updates


19464.3.3.5 Project Document Updates


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



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



19784.4.1.2 Schedule Forecasts


19814.4.1.3 Cost Forecasts




19844.4.1.4 Validated Changes


19874.4.1.5 Work Performance Information






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



20034.4.2.2 Analytical Techniques


20064.4.2.3 Project Management Information System




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



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



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



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









20634.5.1.5 Organizational Process Outputs




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





20914.5.2.3 Change Control Tools


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



21014.5.3.2 Change Log








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



21334.6.1.2 Accepted Deliverables




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







21524.6.3 Close Software Project or Phase: Outputs



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


21594.6.3.2 Organizational Process Assets Updates


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



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



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


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







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



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





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;



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



23285.2.1.2 Requirements Management Plan


23315.2.1.3 Stakeholder Management Plan




2333



23375.2.1.5 Stakeholder Register


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


23515.2.2.2 Focus Groups


23545.2.2.3 Facilitated Workshops


23575.2.2.4 Group Creativity Techniques


23605.2.2.5 Group Decision-Making Techniques


23635.2.2.6 Questionnaires and Surveys


23665.2.2.7 Observations


23695.2.2.8 Prototypes




23725.2.2.9 Benchmarking


23755.2.2.10 Context Diagrams


23785.2.2.11 Document Analysis


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



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



2425







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



24465.3.2.2 Product Analysis


24495.3.2.3 Alternatives Generation


24525.3.2.4 Facilitated Workshops


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



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



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.



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



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



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



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



26485.4.1.2 Project Scope Statement




2650







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



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




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?”



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







27375.5.1.4 Verified Deliverables





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




2792



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



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





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





2839


2841See Section 5.6.1.2 of the PMBOK® Guide2842







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.



2890

28915.6.2.1 Variance Analysis


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



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



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











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



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



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




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



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









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







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




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




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




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



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


32156.2.2.2 Rolling Wave Planning




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



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

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.

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



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






34266.3.1.4 Milestone List







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



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


34616.3.2.2 Dependency Determination


3463

34646.3.2.3 Leads and Lags


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



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

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




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



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



3594 software project activity resources.3595







3604

36056.4.1.4 Resource Calendars


36086.4.1.5 Risk Register


36116.4.1.6 Activity Cost Estimates






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



36286.4.2.2 Alternative Analysis


36316.4.2.3 Published Estimating Data




36346.4.2.4 Bottom-Up Estimating


36376.4.2.5 Project Management Software





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


36576.4.3.2 Resource Breakdown Structure




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



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























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



37386.5.2.2 Analogous Estimating


37416.5.2.3 Parametric Estimating


37446.5.2.4 Three-Point Estimating




37506.5.2.6 Reserve Analysis





3756period of time. This establishes the required development capacity and may impact

3757 sequencing.3758



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




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







37996.6.1.4 Project Schedule Network Diagrams

3800See Section 6.6.141 of the PMBOK® Guide.3801









3810





38176.6.1.10 Project Staff Assignments








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




38436.6.2.2 Critical Path Method


38466.6.2.3 Critical Chain Method


38496.6.2.4 Resource Optimization Techniques


38526.6.2.5 Modeling Techniques




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


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



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


39006.6.3.2 Project Schedule


39036.6.3.3 Schedule Data


39066.6.3.4 Project Calendars






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



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





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


39586.7.1.5 Schedule Data


3960



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



3975 infrastructure, testing environments, test cases, interface control, configuration

3976management, equipment or supply acquisition, deployment planning, and logistics

3977 activities.3978



39826.7.2.3 Resource Optimization Techniques


39856.7.2.4 Modeling Techniques




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


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.



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



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



40656.7.3.2 Schedule Forecasts










40806.7.3.7 Additional Outputs



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.



4136

4137



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








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



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


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



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



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 –



43327.2.1.5. In addition, the inputs in 7.2.1.8 and 7.2.1.9 apply.4333


4335See Section 7.2.1.1 in the PMBOK® Guide.4336

43377.2.1.2 Human Resource Plan



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


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


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


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



43777.2.1.8 Software Size and Complexity

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



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



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



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



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



45517.2.2.9 Vendor Bid Analysis




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.

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



46167.2.3.2 Basis of Estimates




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









46397.3.1.4 Basis of Estimates












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


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

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



46847.3.2.4 Historical Relationships


46877.3.2.5 Funding Limit Reconciliation


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


46977.3.3.2 Project Funding Requirements




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



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



47277.4.1.2 Project Funding Requirements






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



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)


48177.4.2.4 Performance Reviews

4818



See Section 7.4.2.4 of the PMBOK® Guide.4819





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



48587.4.3.2 Cost Forecasts








4866





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



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).



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




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



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



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













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



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



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


52498.1.2.2 Cost of Quality (COQ)


52528.1.2.3 Seven Basic Quality Tools


52558.1.2.4 Benchmarking


52588.1.2.5 Design of Experiments


5260

52618.1.2.6 Statistical Sampling


52648.1.2.7 Additional Quality Planning Tools


5266





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


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


52948.1.3.3 Quality Metrics


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



53228.1.3.4 Quality Checklists


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



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



53728.2.1.2 Process Improvement Plan






53788.2.1.4 Quality Control Measurements


53818.2.1.5 Project Documents


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



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



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


55088.2.2.2 Quality Audits


55118.2.2.3 Process Analysis


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









5530Additional considerations include the following.5531



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



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





56068.3.1.3 Quality Checklists






56158.3.1.6 Deliverables




5620



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



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



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


57328.3.2.2 Statistical Sampling


57358.3.2.3 Inspection


57388.3.2.4 Approved Change Requests Review


57418.3.3 Control Software Project Quality: Outputs



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


57658.3.3.2 Validated Changes


57688.3.3.3 Verified Deliverables






5776







5786



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




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











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


58689.1.2.2 Networking


58719.1.2.3 Organizational Theory






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




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








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


59599.2.2.2 Negotiation


59629.2.2.3 Acquisition


59659.2.2.4 Virtual Teams


5967

59689.2.2.5 Multi-Criteria Decision Analysis


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



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







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









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


60459.3.2.2 Training


60489.3.2.3 Team-Building Activities


60519.3.2.4 Ground Rules


60549.3.2.5 Colocation


60579.3.2.6 Recognition and Rewards


60609.3.2.7 Personnel Assessment Tools


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



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



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


61529.3.3.2 Enterprise Environmental Factors Updates


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



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






61729.4.1.3 Team Performance Assessments


61759.4.1.4 Issue Log






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


61929.4.2.2 Project Performance Appraisals


61959.4.2.3 Conflict Management




62019.4.3 Manage Software Project Team: Outputs

6202The outputs from managing a project team in the PMBOK® Guide are applicable to managing a








62149.4.3.4 Enterprise Environmental Factors Updates




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



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




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



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









637010.1.2 Plan Software Project Communications: Tools and Techniques


6372 software project communications.6373

637410.1.2.1 Communication Requirements Analysis




637710.1.2.2 Communication Technology


638010.1.2.3 Communication Models


638310.1.2.4 Communication Methods


6385

638610.1.2.5 Meetings


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




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



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









646910.2.1.5 Release and Iteration Plans



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


6488

648910.2.2.2 Communication Models




649510.2.2.4 Information Management Systems


6497

649810.2.2.5 Performance Reporting


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



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






6553 10.2.3.3 Project Documents Updates




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

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





662210.3.1.2 Project Communications


662510.3.1.3 Issue Log






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



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


6657 10.3.2.2 Expert Judgment


6660 10.3.2.3 Meetings


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













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



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


6774



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


6790 11.1.1.2 Project Charter


6793 11.1.1.3 Stakeholder Register


6796 11.1.1.4 Enterprise Environmental Factors




6799 11.1.1.5 Organizational Process Assets


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




6833See Section 11.1.2.2of the PMBOK® Guide.

6834

683511.1.2.3 Meetings


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



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























691711.2.1.11 Procurement Documents


6919





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



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



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


694811.2.2.2 Information Gathering Techniques


695111.2.2.3 Checklist Analysis


695411.2.2.4 Assumptions Analysis


695711.2.2.5 Diagramming Techniques


696011.2.2.6 SWOT Analysis




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





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











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




7030

703111.3.2.2 Probability and Impact Matrix


703411.3.2.3 Risk Data Quality Assessment


703711.3.2.4 Risk Categorization


704011.3.2.5 Risk Urgency Assessment




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



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



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


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



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















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


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



Figure 11-3. Comparative Priorities of Risk Treatment and Business Value7216

721711.4.2.2 Quantitative Risk Analysis and Modeling Techniques


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



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



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





725711.5.2 Plan Software Project Risk Responses: Tools and Techniques

7258



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


726411.5.2.2 Strategies for Positive Risks or Opportunities


726711.5.2.3 Contingent Response Strategies




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





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



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,



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









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


737011.6.2.2 Risk Audits




737311.6.2.3 Variance and Trend Analysis


737611.6.2.4 Technical Performance Measurement




738211.6.2.6 Meetings


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



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











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



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




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



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.



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



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



















767212.1.2 Plan Software Project Procurement Management: Tools and Techniques




7674 software procurement management.7675

767612.1.2.1 Make-or-Buy Analysis




768212.1.2.3 Market Research


768512.1.2.4 Meetings


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


769512.1.3.2 Procurement Statement of Work




770112.1.3.4 Source Selection Criteria


770412.1.3.5 Make-or-Buy Decisions








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




774812.2.1.3 Source Selection Criteria


775112.2.1.4 Seller Proposals




775712.2.1.6 Make-or-Buy Decisions




776012.2.1.7 Procurement Statement of Work




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


777312.2.2.2 Proposal Evaluation Techniques


777612.2.2.3 Independent Estimates




778212.2.2.5 Advertising




778812.2.2.7 Procurement Negotiations


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














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




7828













784412.3.2 Control Software Procurements: Tools and Techniques


7846 controlling software procurements.7847

784812.3.2.1 Contract Change Control System


785112.3.2.2 Procurement Performance Reviews


785412.3.2.3 Inspections and Audits


785712.3.2.4 Performance Reporting


786012.3.2.5 Payment Systems


786312.3.2.6 Claims Administration


786612.3.2.7 Records Management System


786912.3.3 Control Software Project Procurements: Outputs

7870The outputs in Section 12.3.3 of the PMBOK® Guide are applicable for controlling software










7881





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






791012.4.2 Close Software Project Procurements: Tools and Techniques


7912 controlling software procurements.7913

791412.4.2.1 Procurement Audits




791712.4.2.2 Procurement Negotiations


792012.4.2.3 Records Management System


792312.4.3 Close Software Project Procurements: Outputs

7924The outputs in Section 12.4.3 of the PMBOK® Guide are applicable for closing software


792712.4.3.1 Closed Procurements




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




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



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


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











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




800813.1.2.3 Meetings


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



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



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





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



8074predictive software project life cycle to manage a software project.

8075



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



809413.2.2.2 Meetings




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





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



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





814613.3.1.3 Change Log




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



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





817113.3.2.3 Management Skills


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












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



824613.4.1.2 Issue Log




8251



8252



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




826513.4.2.3 Meetings


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











8287

8288Footnotes:

8289 () The boldface numbers in parentheses refer to a list of references at the end of this

8290 standard.



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



©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

exposuredraft - software extension to the pmbok guide fifth edition

Documents

software projects

software project managers

new41 software

software medium

existing software

the6 pmbok guide

pmbok guide are21 applicable

pmbok guide28