Discussion 1 post responses.Please respond to the following.docx

Discussion 1 post responses.
Please respond to the following:
LG’s post states the following:Top of Form
"When Problem Decomposition is not Easy"
Consider the development of a simple mobile application that
displays personal financial management video clips selected
from a central repository. Discuss how you would
systematically analyze the requirements of this application and
identify its problem components.
Using a spiral process of stakeholder engagement which
includes understanding the business objectives or needs the
application is to provide. Next, looking at the requirements
gathering process, whereby sitting with the stakeholders and
customers to define those needs, understanding the assumptions
and constraints, expectations, and coming up with a conceptual
model both from a business and system design. Using the
model as a base, the requirements will be developed into a high-
level requirement set, where they are broken into the logical
grouping, such as business, user, functional, non-functional, and
transitional segments. Next, the requirements will be viewed
with the stakeholders and customers, to address priority, need
vs. want, and addressing any ambiguous requirements to gain
clarity for completeness.
Explain how software engineering would help you identify the
components and their interconnections.
Software engineering helps identify the components and their
interconnections because the approach requires identification of
components such as hardware, software, users, tasks, and
databases, amongst other pieces to be determined and

understand how each will interact with the others. Some
boundaries must be known that similar to the scope of a project
to help provide a context on what is in or out. It includes things
like the activities that will be performed and the entities
associated with the activities. Understanding these provide the
developers in the design and development process. For
example, the above mention contextual design or model can be
used or provide a reference to things like architectural design,
displaying these components and interconnections on paper (or
visual drawing) to help articulate the boundaries, activities, and
entities for the system.
Phleeger, S. L., Atlee, J. M. (2009-02-01). Software
Engineering: Theory and Practice, 4th Edition [VitalSource
Bookshelf version]. Retrieved from vbk://9781323089309
Pochimcherla, A., Pochimcherlahttp, A., & Pochimcherla, A.
(2018, January 26). Computer science basics - Decomposition -
break a problem into smaller. Retrieved
from http://steamism.com/compsci-decomposition/.
SP’s post states the following:Top of Form
"When Problem Decomposition is not Easy" Please respond to
the following: Consider the development of a simple mobile
application that displays personal financial management video
clips selected from a central repository. Discuss how you would
systematically analyze the requirements of this application and
identify its problem components.
In some cases, customers prefer to have an automated system
rather than one that is manual. Taking this route would be good
for production since this is one less task that they are required
to do.
Another circumstance may be that a customer prefers a system
to do something that is unique that will tailor to their own

needs. Regardless of the function, the system will have a
purpose with a goal in mind (Pfleefer & Atlee, 2010).
The requirement is what is desired by the customer (Pfleefer &
Atlee, 2010). Since the requirements deal directly with objects
and entities, functions are created to change the state of the
characteristics (Pfleefer & Atlee, 2010).
Since the mobile application displays financial management
video clips selected from a repository, one of the ideal
requirements would be how often the videos are pulled from the
central repository. Another questionable requirement would be
what time of day are the videos delivered. Also, what storage
space would need to be identified since many videos will be
available. How long should the videos be available? Would
these videos be available on the internet or would it only be
available on the intranet?
All of these concerns are specific functions that are required to
meet the goal of the system.
Key entities would place limitations and define relations among
users (Pfleefer & Atlee, 2010). For instance, one individual (or
several individuals), may be authorized for uploading the initial
videos, whereas other individuals may be limited to viewing the
videos.
Explain how software engineering would help you identify the
components and their interconnections.
Software engineering would help identify the components and
their interconnections by identifying characteristics that the
software solution must carry. Characteristics such as high
reliability, maintenance, fast response time, and design
constraints. Design constraints could hinder a solution and this
would need to be identified.
Another hindrance is process constraint, which could also limit

the methods and resources that can be used to meet the end goal
of the product (Pfleefer & Atlee, 2010).
Reference:
Pfleeger, S. L., & Atlee, J. M. (2012). Software Engineering
Theory and Practice. Johanneshov: TPB.
Discussion 2 post responses.
Please respond to the following:
LG’s post states the following:Top of Form
Commercial off the Shelf (COTS)" Please respond to the
following:
From the e-Activity, describe at least two COTS packages that
you identified through your research. Explain their purposes,
the components they contain, and the kind of applications that
could be developed using these COTS packages.
There are several COTS packages on the market for both small
businesses, large corporations, and government. These
packages have been widely used for the availability of standard
processes that have built-in functionality and capabilities that
can be integrated into the business for use. Many COTS
packages are used for financial, data or office processing or
computer utilities.. Two examples of COTS packages are:
1. Microsoft Office is a COTS product that is intended as a
solution for businesses. It comes with a variety of applications,
such as WORD for word processing, EXCEL for spreadsheets,s,
and PowerPoint for presentation. The Office product is similar
to Office365; however, Office365 is commonly referred to as a
cloud solution or Software as a Service, which is different from
a COTS product.
2. SAP [Systems Applications and Products in Data Processing]
is another COTS product. SAP is a financial and business
solution used for Enterprise Resource Planning (ERP) and data

management that helps businesses manage financial, logistics,
and HR.
Consider a situation where you are working in the gaming
industry as a software engineer and your company is pushing
toward utilizing COTS software components. Your supervisor
has asked you to develop a counter proposal outlining the
reasons why all software development should stay in-house.
Explain how you would justify using an in-house software
development strategy over using COTS commercial components.
COTS solutions are useful resources for businesses to leverage
a package that can perform routine tasks without having to
develop an in-house solution for transactions that are common
for most organizations. However, all COTS solutions are not
'turn-key' where everything works as soon as its installed and
turned on. COTS solutions may have interstices that may not
work with the existing in-house systems; therefore, they will
require additional work, such as interfaces or a manual
workaround, to be considered for optimal performance. In
addition to the development of one or more interfaces, or
resulting in manual workarounds, other reasons to consider for
using in-house software development strategy include:
· Cost for the license for a specific period of use
· Cost per user
· Potential of the vendor going out of business or transfer
ownership to another entity, e.g., overseas, more significant
volume vendor or vendor outside the market of the solution
· Customization (which can be costly)
· Site installation, including maintenance or subscription cost
· Additional support desk cost (people, training, resources)
· Training (staff, customers)
· Change in requirements
· Delivery time
· Control of resources
· Infrastructure and Integration, i.e., legacy systems

· Security
References:
Custom Development vs. "Off the Shelf" COTS Software. (n.d.).
Retrieved from https://www.winshuttle.com/blog/custom-
development-vs-shelf-cots-software-2/.
Security Considerations in Managing COTS Software. (n.d.).
Retrieved from https://www.us-cert.gov/bsi/articles/best-
practices/legacy-systems/security-considerations-in-managing-
cots-software.
NM’s post states the following:Top of Form
From the e-Activity, describe at least two COTS packages that
you identified through your research. Explain their purposes,
the components they contain, and the kind of applications that
could be developed using these COTS packages.
Commercial-off-the-shelf (COTS) is computer software
products that are ready-made and are readily available for
purchase in the commercial market (ResQSoft, n.d.). This
includes antivirus (i.e. Norton Antivirus, McAfee) or computer
utilities (i.e.word processor, database manager) it is designed to
be used by users across the globe and very reliable.
Consider a situation where you are working in the gaming
industry as a software engineer and your company is pushing
toward utilizing COTS software components. Your supervisor
has asked you to develop a counter-proposal outlining the
reasons why all software development should stay in-house.
Explain how you would justify using an in-house software
development strategy over using COTS commercial
components.
Working with in-house products, the company will have more
control in the gaming product. The requirement for the gaming
product is defined, analyzed, programmed, maintained, and

developed using the firm’s resources. The Off-the-shelf
products can be purchased at a retail store, and the customer has
to work with the package as it comes out of the box (Clydebuilt,
2012).
ResQSoft. (n.d.). The Basic of COTS Commercial-off-the-Shelf
Software. Retrieved from https://www.resqsoft.com/basics-cots-
%e2%80%93-commercial-off-the-shelf-software.html
Clydebuilt Business
Solution
s, Ltd. (2012). In-house vs. Off-the-Shelf. Retrieved
from https://Inhouse-VS-Off-the-Shelf-May.pdf
AGuidetothePROJECT
MANAGEMENTBODYOF
KNOWLEDGE
(PMBOK®GUIDE)
SixthEdition

LibraryofCongressCataloging-in-PublicationData
Names:ProjectManagementInstitute,publisher.
Title:Aguidetotheprojectmanagementbodyofknowledge(PMBOK
guide)/ProjectManagement
Institute.
Othertitles:PMBOKguide
Description:Sixthedition.|NewtownSquare,PA:ProjectManageme
ntInstitute,2017.|Series:
PMBOKguide|Includesbibliographicalreferencesandindex.
Identifiers:LCCN2017032505(print)|LCCN2017035597(ebook)|I
SBN9781628253900(ePUP)|
ISBN9781628253917(kindle)|ISBN9781628253924(WebPDF)|IS
BN9781628251845
(paperback)
Subjects:LCSH:Projectmanagement.|BISAC:BUSINESS&ECON
OMICS/ProjectManagement.
Classification:LCCHD69.P75(ebook)|LCCHD69.P75G8452017(
print)|DDC658.4/04—dc23

LCrecordavailableathttps://lccn.loc.gov/2017032505
ISBN:978-1-62825-184-5
Publishedby:
ProjectManagementInstitute,Inc.
14CampusBoulevard
NewtownSquare,Pennsylvania19073-3299USA
Phone:+1610-356-4600
Fax:+1610-356-4647
Email:[email protected]
Website:www.PMI.org
©2017ProjectManagementInstitute,Inc.Allrightsreserved.
ProjectManagementInstitute,Inc.contentiscopyrightprotectedbyU
.S.intellectualpropertylawthat
isrecognizedbymostcountries.TorepublishorreproducePMI’scont
ent,youmustobtainour
permission.Pleasegotohttp://www.pmi.org/permissionsfordetails
.
ToplaceaTradeOrderorforpricinginformation,pleasecontactIndep

endentPublishersGroup:
IndependentPublishersGroup
OrderDepartment
814NorthFranklinStreet
Chicago,IL60610USA
Phone:+1800-888-4741
Fax:+1312-337-5985
Email:[email protected](Forordersonly)
Forallotherinquiries,pleasecontactthePMIBookServiceCenter.
PMIBookServiceCenter
P.O.Box932683,Atlanta,GA31193-2683USA
Phone:1-866-276-4764(withintheU.S.orCanada)or+1-770-280-
4129(globally)
Fax:+1-770-280-4113
Email:[email protected]
https://lccn.loc.gov/2017032505
mailto:[email protected]
http://www.PMI.org

http://www.pmi.org/permissions
PrintedintheUnitedStatesofAmerica.Nopartofthisworkmayberepr
oducedortransmittedinany
formorbyanymeans,electronic,manual,photocopying,recording,or
byanyinformationstorageand
retrievalsystem,withoutpriorwrittenpermissionofthepublisher.
ThepaperusedinthisbookcomplieswiththePermanentPaperStandar
dissuedbytheNational
InformationStandardsOrganization(Z39.48—1984).
PMI,thePMIlogo,PMBOK,OPM3,PMP,CAPM,PgMP,PfMP,PMI-
RMP,PMI-SP,PMI-ACP,PMI-
PBA,PROJECTMANAGEMENTJOURNAL,PMNETWORK,PMI
TODAY,PULSEOFTHE
PROFESSIONandthesloganMAKINGPROJECTMANAGEMENT
INDISPENSABLEFOR
BUSINESSRESULTS.areallmarksofProjectManagementInstitute
,Inc.Foracomprehensivelistof
PMItrademarks,contactthePMILegalDepartment.Allothertradema
rks,servicemarks,tradenames,
tradedress,productnamesandlogosappearinghereinaretheproperty

oftheirrespectiveowners.Any
rightsnotexpresslygrantedhereinarereserved.
10987654321
NOTICE
The Project Management Institute, Inc. (PMI) standards and
guideline
publications, ofwhich thedocument containedherein isone,
aredeveloped
throughavoluntaryconsensus
standardsdevelopmentprocess.Thisprocess
bringstogethervolunteersand/orseeksouttheviewsofpersonswhoha
vean
interest in the topiccoveredby
thispublication.WhilePMIadministers the
process and establishes rules to promote fairness in the
development of
consensus,itdoesnotwritethedocumentanditdoesnotindependently
test,
evaluate, or verify the accuracy or completeness of any
information or the

soundness of any judgments contained in its standards and
guideline
publications.
PMIdisclaimsliabilityforanypersonalinjury,propertyorotherdama
ges
of any nature whatsoever, whether special, indirect,
consequential or
compensatory, directly or indirectly resulting from the
publication, use of
application, or reliance on this document. PMI disclaims and
makes no
guaranty or warranty, expressed or implied, as to the accuracy
or
completenessofanyinformationpublishedherein,anddisclaimsand
makes
no warranty that the information in this document will fulfill
any of your
particular purposes or needs. PMI does not undertake to
guarantee the
performanceof any individualmanufacturer or seller’s products
or services
byvirtueofthisstandardorguide.
Inpublishingandmakingthisdocumentavailable,PMIisnotundertak

ing
to render professional or other services for or on behalf of any
person or
entity, nor is PMI undertaking to perform any duty owed by any
person or
entitytosomeoneelse.Anyoneusingthisdocumentshouldrelyonhiso
rher
ownindependentjudgmentor,asappropriate,seektheadviceofacom
petent
professional in determining the exercise of reasonable care in
any given
circumstances. Informationandotherstandardson the
topiccoveredby this
publicationmaybeavailablefromothersources,whichtheusermaywi
shto
consultforadditionalviewsorinformationnotcoveredbythispublica
tion.
PMIhasnopower,nordoes itundertake
topoliceorenforcecompliance
with the contents of this document. PMI does not certify, test,
or inspect
products, designs, or installations for safety or health purposes.
Any
certification or other statement of compliance with any health or

safety-
related information in thisdocument shallnotbeattributable
toPMIand is
solelytheresponsibilityofthecertifierormakerofthestatement.
TABLEOFCONTENTS
PART1.
AGUIDETOTHEPROJECTMANAGEMENTBODYOF
KNOWLEDGE(PMBOK®Guide)
1.INTRODUCTION
1.1OverviewandPurposeofthisGuide
1.1.1TheStandardforProjectManagement
1.1.2CommonVocabulary
1.1.3CodeofEthicsandProfessionalConduct
1.2FoundationalElements

1.2.1Projects
1.2.2TheImportanceofProjectManagement
1.2.3RelationshipofProject,Program,Portfolio,and
OperationsManagement
1.2.4ComponentsoftheGuide
1.2.5Tailoring
1.2.6ProjectManagementBusinessDocuments
2.THEENVIRONMENTINWHICHPROJECTSOPERATE
2.1Overview
2.2EnterpriseEnvironmentalFactors
2.2.1EEFsInternaltotheOrganization
2.2.2EEFsExternaltotheOrganization
2.3OrganizationalProcessAssets

2.3.1Processes,Policies,andProcedures
2.3.2OrganizationalKnowledgeRepositories
2.4OrganizationalSystems
2.4.1Overview
2.4.2OrganizationalGovernanceFrameworks
2.4.3ManagementElements
2.4.4OrganizationalStructureTypes
3.THEROLEOFTHEPROJECTMANAGER
3.1Overview
3.2DefinitionofaProjectManager
3.3TheProjectManager’sSphereofInfluence
3.3.1Overview

3.3.2TheProject
3.3.3TheOrganization
3.3.4TheIndustry
3.3.5ProfessionalDiscipline
3.3.6AcrossDisciplines
3.4ProjectManagerCompetences
3.4.1Overview
3.4.2TechnicalProjectManagementSkills
3.4.3StrategicandBusinessManagementSkills
3.4.4LeadershipSkills
3.4.5ComparisonofLeadershipandManagement
3.5PerformingIntegration

3.5.1PerformingIntegrationattheProcessLevel
3.5.2IntegrationattheCognitiveLevel
3.5.3IntegrationattheContextLevel
3.5.4IntegrationandComplexity
4.PROJECTINTEGRATIONMANAGEMENT
4.1DevelopProjectCharter
4.1.1DevelopProjectCharter:Inputs
4.1.2DevelopProjectCharter:ToolsandTechniques
4.1.3DevelopProjectCharter:Outputs
4.2DevelopProjectManagementPlan
4.2.1DevelopProjectManagementPlan:Inputs
4.2.2DevelopProjectManagementPlan:Toolsand

Techniques
4.2.3DevelopProjectManagementPlan:Outputs
4.3DirectandManageProjectWork
4.3.1DirectandManageProjectWork:Inputs
4.3.2DirectandManageProjectWork:Toolsand
Techniques
4.3.3DirectandManageProjectWork:Outputs
4.4ManageProjectKnowledge
4.4.1ManageProjectKnowledge:Inputs
4.4.2ManageProjectKnowledge:ToolsandTechniques
4.4.3ManageProjectKnowledge:Outputs
4.5MonitorandControlProjectWork
4.5.1MonitorandControlProjectWork:Inputs

4.5.2MonitorandControlProjectWork:Toolsand
Techniques
4.5.3MonitorandControlProjectWork:Outputs
4.6PerformIntegratedChangeControl
4.6.1PerformIntegratedChangeControl:Inputs
4.6.2PerformIntegratedChangeControl:Toolsand
Techniques
4.6.3PerformIntegratedChangeControl:Outputs
4.7CloseProjectorPhase
4.7.1CloseProjectorPhase:Inputs
4.7.2CloseProjectorPhase:ToolsandTechniques
4.7.3CloseProjectorPhase:Outputs
5.PROJECTSCOPEMANAGEMENT

5.1PlanScopeManagement
5.1.1PlanScopeManagement:Inputs
5.1.2PlanScopeManagement:ToolsandTechniques
5.1.3PlanScopeManagement:Outputs
5.2CollectRequirements
5.2.1CollectRequirements:Inputs
5.2.2CollectRequirements:ToolsandTechniques
5.2.3CollectRequirements:Outputs
5.3DefineScope
5.3.1DefineScope:Inputs
5.3.2DefineScope:ToolsandTechniques
5.3.3DefineScope:Outputs

5.4CreateWBS
5.4.1CreateWBS:Inputs
5.4.2CreateWBS:ToolsandTechniques
5.4.3CreateWBS:Outputs
5.5ValidateScope
5.5.1ValidateScope:Inputs
5.5.2ValidateScope:ToolsandTechniques
5.5.3ValidateScope:Outputs
5.6ControlScope
5.6.1ControlScope:Inputs
5.6.2ControlScope:ToolsandTechniques
5.6.3ControlScope:Outputs

6.PROJECTSCHEDULEMANAGEMENT
6.1PlanScheduleManagement
6.1.1PlanScheduleManagement:Inputs
6.1.2PlanScheduleManagement:ToolsandTechniques
6.1.3PlanScheduleManagement:Outputs
6.2DefineActivities
6.2.1DefineActivities:Inputs
6.2.2DefineActivities:ToolsandTechniques
6.2.3DefineActivities:Outputs
6.3SequenceActivities
6.3.1SequenceActivities:Inputs
6.3.2SequenceActivities:ToolsandTechniques

6.3.3SequenceActivities:Outputs
6.4EstimateActivityDurations
6.4.1EstimateActivityDurations:Inputs
6.4.2EstimateActivityDurations:ToolsandTechniques
6.4.3EstimateActivityDurations:Outputs
6.5DevelopSchedule
6.5.1DevelopSchedule:Inputs
6.5.2DevelopSchedule:ToolsandTechniques
6.5.3DevelopSchedule:Outputs
6.6ControlSchedule
6.6.1ControlSchedule:Inputs
6.6.2ControlSchedule:ToolsandTechniques

6.6.3ControlSchedule:Outputs
7.PROJECTCOSTMANAGEMENT
7.1PlanCostManagement
7.1.1PlanCostManagement:Inputs
7.1.2PlanCostManagement:ToolsandTechniques
7.1.3PlanCostManagement:Outputs
7.2EstimateCosts
7.2.1EstimateCosts:Inputs
7.2.2EstimateCosts:ToolsandTechniques
7.2.3EstimateCosts:Outputs
7.3DetermineBudget
7.3.1DetermineBudget:Inputs

7.3.2DetermineBudget:ToolsandTechniques
7.3.3DetermineBudget:Outputs
7.4ControlCosts
7.4.1ControlCosts:Inputs
7.4.2ControlCosts:ToolsandTechniques
7.4.3ControlCosts:Outputs
8.PROJECTQUALITYMANAGEMENT
8.1PlanQualityManagement
8.1.1PlanQualityManagement:Inputs
8.1.2PlanQualityManagement:ToolsandTechniques
8.1.3PlanQualityManagement:Outputs
8.2ManageQuality

8.2.1ManageQuality:Inputs
8.2.2ManageQuality:ToolsandTechniques
8.2.3ManageQuality:Outputs
8.3ControlQuality
8.3.1ControlQuality:Inputs
8.3.2ControlQuality:ToolsandTechniques
8.3.3ControlQuality:Outputs
9.PROJECTRESOURCEMANAGEMENT
9.1PlanResourceManagement
9.1.1PlanResourceManagement:Inputs
9.1.2PlanResourceManagement:ToolsandTechniques
9.1.3PlanResourceManagement:Outputs

9.2EstimateActivityResources
9.2.1EstimateActivityResources:Inputs
9.2.2EstimateActivityResources:ToolsandTechniques
9.2.3EstimateActivityResources:Outputs
9.3AcquireResources
9.3.1AcquireResources:Inputs
9.3.2AcquireResources:ToolsandTechniques
9.3.3AcquireResources:Outputs
9.4DevelopTeam
9.4.1DevelopTeam:Inputs
9.4.2DevelopTeam:ToolsandTechniques
9.4.3DevelopTeam:Outputs

9.5ManageTeam
9.5.1ManageTeam:Inputs
9.5.2ManageTeam:ToolsandTechniques
9.5.3ManageTeam:Outputs
9.6ControlResources
9.6.1ControlResources:Inputs
9.6.2ControlResources:ToolsandTechniques
9.6.3ControlResources:Outputs
10.PROJECTCOMMUNICATIONSMANAGEMENT
10.1PlanCommunicationsManagement
10.1.1PlanCommunicationsManagement:Inputs
10.1.2PlanCommunicationsManagement:Toolsand
Techniques

10.1.3PlanCommunicationsManagement:Outputs
10.2ManageCommunications
10.2.1ManageCommunications:Inputs
10.2.2ManageCommunications:ToolsandTechniques
10.2.3ManageCommunications:Outputs
10.3MonitorCommunications
10.3.1MonitorCommunications:Inputs
10.3.2MonitorCommunications:ToolsandTechniques
10.3.3MonitorCommunications:Outputs
11.PROJECTRISKMANAGEMENT
11.1PlanRiskManagement

11.1.1PlanRiskManagement:Inputs
11.1.2PlanRiskManagement:ToolsandTechniques
11.1.3PlanRiskManagement:Outputs
11.2IdentifyRisks
11.2.1IdentifyRisks:Inputs
11.2.2IdentifyRisks:ToolsandTechniques
11.2.3IdentifyRisks:Outputs
11.3PerformQualitativeRiskAnalysis
11.3.1PerformQualitativeRiskAnalysis:Inputs
11.3.2PerformQualitativeRiskAnalysis:Toolsand
Techniques
11.3.3PerformQualitativeRiskAnalysis:Outputs
11.4PerformQuantitativeRiskAnalysis

11.4.1PerformQuantitativeRiskAnalysis:Inputs
11.4.2PerformQuantitativeRiskAnalysis:Toolsand
Techniques
11.4.3PerformQuantitativeRiskAnalysis:Outputs
11.5PlanRiskResponses
11.5.1PlanRiskResponses:Inputs
11.5.2PlanRiskResponses:ToolsandTechniques
11.5.3PlanRiskResponses:Outputs
11.6ImplementRiskResponses
11.6.1ImplementRiskResponses:Inputs
11.6.2ImplementRiskResponses:ToolsandTechniques
11.6.3ImplementRiskResponses:Outputs

11.7MonitorRisks
11.7.1MonitorRisks:Inputs
11.7.2MonitorRisks:ToolsandTechniques
11.7.3MonitorRisks:Outputs
12.PROJECTPROCUREMENTMANAGEMENT
12.1PlanProcurementManagement
12.1.1PlanProcurementManagement:Inputs
12.1.2PlanProcurementManagement:Toolsand
Techniques
12.1.3PlanProcurementManagement:Outputs
12.2ConductProcurements
12.2.1ConductProcurements:Inputs
12.2.2ConductProcurements:ToolsandTechniques

12.2.3ConductProcurements:Outputs
12.3ControlProcurements
12.3.1ControlProcurements:Inputs
12.3.2ControlProcurements:ToolsandTechniques
12.3.3ControlProcurements:Outputs
13.PROJECTSTAKEHOLDERMANAGEMENT
13.1IdentifyStakeholders
13.1.1IdentifyStakeholders:Inputs
13.1.2IdentifyStakeholders:ToolsandTechniques
13.1.3IdentifyStakeholders:Outputs
13.2PlanStakeholderEngagement
13.2.1PlanStakeholderEngagement:Inputs

13.2.2PlanStakeholderEngagement:Toolsand
Techniques
13.2.3PlanStakeholderEngagement:Outputs
13.3ManageStakeholderEngagement
13.3.1ManageStakeholderEngagement:Inputs
13.3.2ManageStakeholderEngagement:Toolsand
Techniques
13.3.3ManageStakeholderEngagement:Outputs
13.4MonitorStakeholderEngagement
13.4.1MonitorStakeholderEngagement:Inputs
13.4.2MonitorStakeholderEngagement:Toolsand
Techniques
13.4.3MonitorStakeholderEngagement:Outputs
REFERENCES

PART2.
THESTANDARDFORPROJECTMANAGEMENT
1.INTRODUCTION
1.1ProjectsandProjectManagement
1.2RelationshipsAmongPortfolios,Programs,andProjects
1.3LinkingOrganizationalGovernanceandProject
Governance
1.4ProjectSuccessandBenefitsManagement
1.5TheProjectLifeCycle
1.6ProjectStakeholders
1.7RoleoftheProjectManager
1.8ProjectManagementKnowledgeAreas

1.9ProjectManagementProcessGroups
1.10EnterpriseEnvironmentalFactorsandOrganizational
ProcessAssets
1.11TailoringtheProjectArtifacts
2.INITIATINGPROCESSGROUP
2.1DevelopProjectCharter
2.2IdentifyStakeholders
2.2.1ProjectManagementPlanComponents
2.2.2ProjectDocumentsExamples
2.2.3ProjectManagementPlanUpdates
2.2.4ProjectDocumentsUpdates
3.PLANNINGPROCESSGROUP
3.1DevelopProjectManagementPlan

3.2PlanScopeManagement
3.3CollectRequirements
3.4DefineScope
3.5CreateWBS

3.6PlanScheduleManagement
3.7DefineActivities
3.8SequenceActivities
3.9EstimateActivityDurations

3.10DevelopSchedule
3.11PlanCostManagement
3.12EstimateCosts

3.13DetermineBudget
3.14PlanQualityManagement
3.15PlanResourceManagement

3.15.2ProjectDocuments
3.16EstimateActivityResources
3.17PlanCommunicationsManagement
3.18PlanRiskManagement

3.19IdentifyRisks
3.20PerformQualitativeRiskAnalysis
3.21PerformQuantitativeRiskAnalysis

3.22PlanRiskResponses
3.23PlanProcurementManagement
3.24PlanStakeholderEngagement

4.EXECUTINGPROCESSGROUP
4.1DirectandManageProjectWork
4.2ManageProjectKnowledge
4.2.2ProjectDocuments

4.3ManageQuality
4.4AcquireResources
4.5DevelopTeam

4.6ManageTeam
4.7ManageCommunications
4.7.2ProjectDocumentsExample

4.8ImplementRiskResponses
4.9ConductProcurements
4.10ManageStakeholderEngagement

5.MONITORINGANDCONTROLLINGPROCESSGROUP
5.1MonitorandControlProjectWork
5.2PerformIntegratedChangeControl

5.3ValidateScope
5.4ControlScope
5.5ControlSchedule

5.6ControlCosts
5.7ControlQuality

5.8ControlResources
5.9MonitorCommunications
5.10MonitorRisks

5.11ControlProcurements
5.12MonitorStakeholderEngagement

6.CLOSINGPROCESSGROUP
6.1CloseProjectorPhase
PART3.
APPENDICES,GLOSSARY,ANDINDEX
APPENDIXX1
SIXTHEDITIONCHANGES
APPENDIXX2
CONTRIBUTORSANDREVIEWERSOFTHEPMBOK®
GUIDE—SIXTHEDITION

APPENDIXX3
AGILE,ITERATIVE,ADAPTIVE,ANDHYBRIDPROJECT
ENVIRONMENTS
APPENDIXX4
SUMMARYOFKEYCONCEPTSFORKNOWLEDGE
AREAS
APPENDIXX5
SUMMARYOFTAILORINGCONSIDERATIONSFOR
KNOWLEDGEAREAS
APPENDIXX6
TOOLSANDTECHNIQUES
GLOSSARY
LISTOFTABLESANDFIGURES

PART1.
AGUIDETOTHEPROJECTMANAGEMENTBODYOF
KNOWLEDGE(PMBOK®Guide)
Figure1-1. OrganizationalStateTransitionviaaProject
Figure1-2. ProjectInitiationContext
Figure1-3. Portfolio,Programs,Projects,andOperations
Figure1-4. OrganizationalProjectManagement
Figure1-5. InterrelationshipofPMBOK®GuideKey
ComponentsinProjects
Figure1-6. ExampleProcess:Inputs,Tools&Techniques,
andOutputs
Figure1-7. ProjectData,Information,andReportFlow
Figure1-8. InterrelationshipofNeedsAssessmentand
CriticalBusiness/ProjectDocuments
Figure2-1. ProjectInfluences
Figure3-1. ExampleofProjectManager’sSphereof
Influence
Figure3-2. ThePMITalentTriangle®
Figure4-1. ProjectIntegrationManagementOverview
Figure4-2. DevelopProjectCharter:Inputs,Tools&

Techniques,andOutputs
Figure4-3. DevelopProjectCharter:DataFlowDiagram
Figure4-4. DevelopProjectManagementPlan:Inputs,Tools
&Techniques,andOutputs
Figure4-5. DevelopProjectManagementPlan:DataFlow
Diagram
Figure4-6. DirectandManageProjectWork:Inputs,Tools&
Figure4-7. DirectandManageProjectWork:DataFlow
Diagram
Figure4-8. ManageProjectKnowledge:Inputs,Tools&
Figure4-9. ManageProjectKnowledge:DataFlowDiagram
Figure4-10. MonitorandControlProjectWork:Inputs,Tools

Figure4-11. MonitorandControlProjectWork:DataFlow
Diagram
Figure4-12. PerformIntegratedChangeControl:Inputs,
Tools&Techniques,andOutputs
Figure4-13. PerformIntegratedChangeControl:DataFlow
Diagram
Figure4-14. CloseProjectorPhase:Inputs,Tools&
Figure4-15. CloseProjectorPhase:DataFlowDiagram
Figure5-1. ProjectScopeManagementOverview
Figure5-2. PlanScopeManagement:Inputs,Tools&
Figure5-3. PlanScopeManagement:DataFlowDiagram
Figure5-4. CollectRequirements:Inputs,Tools&
Figure5-5. CollectRequirements:DataFlowDiagram
Figure5-6. ContextDiagram
Figure5-7. ExampleofaRequirementsTraceabilityMatrix

Figure5-8. DefineScope:Inputs,Tools&Techniques,and
Outputs
Figure5-9. DefineScope:DataFlowDiagram
Figure5-10. CreateWBS:Inputs,Tools&Techniques,and
Outputs
Figure5-11. CreateWBS:DataFlowDiagram
Figure5-12. SampleWBSDecomposedDownThroughWork
Packages
Figure5-13. SampleWBSOrganizedbyPhase
Figure5-14. SampleWBSwithMajorDeliverables
Figure5-15. ValidateScope:Inputs,Tools&Techniques,and
Outputs
Figure5-16. ValidateScope:DataFlowDiagram
Figure5-17. ControlScope:Inputs,Tools&Techniques,and
Outputs
Figure5-18. ControlScope:DataFlowDiagram
Figure6-1. ProjectScheduleManagementOverview

Figure6-2. SchedulingOverview
Figure6-3. PlanScheduleManagement:Inputs,Tools&
Figure6-4. PlanScheduleManagement:DataFlowDiagram
Figure6-5. DefineActivities:Inputs,Tools&Techniques,and
Outputs
Figure6-6. DefineActivities:DataFlowDiagram
Figure6-7. SequenceActivities:Inputs,Tools&Techniques,
andOutputs
Figure6-8. SequenceActivities:DataFlowDiagram
Figure6-9. PrecedenceDiagrammingMethod(PDM)
RelationshipTypes
Figure6-10. ExamplesofLeadandLag
Figure6-11. ProjectScheduleNetworkDiagram
Figure6-12. EstimateActivityDurations:Inputs,Tools&
Figure6-13. EstimateActivityDurations:DataFlowDiagram
Figure6-14. DevelopSchedule:Inputs,Tools&Techniques,

andOutputs
Figure6-15. DevelopSchedule:DataFlowDiagram
Figure6-16. ExampleofCriticalPathMethod
Figure6-17. ResourceLeveling
Figure6-18. ExampleProbabilityDistributionofaTarget
Milestone
Figure6-19. ScheduleCompressionComparison
Figure6-20. RelationshipBetweenProductVision,Release
Planning,andIterationPlanning
Figure6-21. ProjectSchedulePresentations—Examples
Figure6-22. ControlSchedule:Inputs,Tools&Techniques,
andOutputs
Figure6-23. ControlSchedule:DataFlowDiagram
Figure6-24. IterationBurndownChart
Figure7-1. ProjectCostManagementOverview
Figure7-2. PlanCostManagement:Inputs,Tools&

Figure7-3. PlanCostManagement:DataFlowDiagram
Figure7-4. EstimateCosts:Inputs,Tools&Techniques,and
Outputs
Figure7-5. EstimateCosts:DataFlowDiagram
Figure7-6. DetermineBudget:Inputs,Tools&Techniques,
andOutputs
Figure7-7. DetermineBudget:DataFlowDiagram
Figure7-8. ProjectBudgetComponents
Figure7-9. CostBaseline,Expenditures,andFunding
Requirements
Figure7-10. ControlCosts:Inputs,Tools&Techniques,and
Outputs
Figure7-11. ControlCosts:DataFlowDiagram
Figure7-12. EarnedValue,PlannedValue,andActualCosts
Figure7-13. To-CompletePerformanceIndex(TCPI)
Figure8-1. ProjectQualityManagementOverview
Figure8-2. MajorProjectQualityManagementProcess
Interrelations

Figure8-3. PlanQualityManagement:Inputs,Tools&
Figure8-4. PlanQualityManagement:DataFlowDiagram
Figure8-5. CostofQuality
Figure8-6. TheSIPOCModel
Figure8-7. ManageQuality:Inputs,Tools&Techniques,and
Outputs
Figure8-8. ManageQuality:DataFlowDiagram
Figure8-9. Cause-and-EffectDiagram
Figure8-10. ControlQuality:Inputs,Tools&Techniques,and
Outputs
Figure8-11. ControlQuality:DataFlowDiagram
Figure8-12. CheckSheets
Figure9-1. ProjectResourceManagementOverview
Figure9-2. PlanResourceManagement:Inputs,Tools&
Figure9-3. PlanResourceManagement:DataFlowDiagram
Figure9-4. SampleRACIChart
Figure9-5. EstimateActivityResources:Inputs,Tools&

Figure9-6. EstimateActivityResources:DataFlowDiagram
Figure9-7. SampleResourceBreakdownStructure
Figure9-8. AcquireResources:Inputs,Tools&Techniques,
andOutputs
Figure9-9. AcquireResources:DataFlowDiagram
Figure9-10. DevelopTeam:Inputs,Tools&Techniques,and
Outputs
Figure9-11. DevelopTeam:DataFlowDiagram
Figure9-12. ManageTeam:Inputs,Tools&Techniques,and
Outputs
Figure9-13. ManageTeam:DataFlowDiagram
Figure9-14. ControlResources:Inputs,Tools&Techniques,
andOutputs
Figure9-15. ControlResources:DataFlowDiagram
Figure10-1. ProjectCommunicationsOverview

Figure10-2. PlanCommunicationsManagement:Inputs,Tools
Figure10-3. PlanCommunicationsManagement:DataFlow
Diagram
Figure10-4. CommunicationModelforCross-Cultural
Communication
Figure10-5. ManageCommunications:Inputs,Tools&
Figure10-6. ManageCommunications:DataFlowDiagram
Figure10-7. MonitorCommunications:Inputs,Tools&
Figure10-8. MonitorCommunications:DataFlowDiagram
Figure11-1. ProjectRiskManagementOverview
Figure11-2. PlanRiskManagement:Inputs,Tools&
Figure11-3. PlanRiskManagement:DataFlowDiagram
Figure11-4. ExtractfromSampleRiskBreakdownStructure

(RBS)
Figure11-5. ExampleProbabilityandImpactMatrixwith
ScoringScheme
Figure11-6. IdentifyRisks:Inputs,Tools&Techniques,and
Outputs
Figure11-7. IdentifyRisks:DataFlowDiagram
Figure11-8. PerformQualitativeRiskAnalysis:Inputs,Tools
Figure11-9. PerformQualitativeRiskAnalysis:DataFlow
Diagram
Figure11-
10.
ExampleBubbleChartShowingDetectability,
Proximity,andImpactValue
Figure11-
11.

PerformQuantitativeRiskAnalysis:Inputs,Tools
Figure11-
12.
PerformQuantitativeRiskAnalysis:DataFlow
Diagram
Figure11-
13.
ExampleS-CurvefromQuantitativeCostRisk
Analysis
Figure11-
14.
ExampleTornadoDiagram
Figure11-
15.
ExampleDecisionTree

Figure11-
16.
PlanRiskResponses:Inputs,Tools&Techniques,
andOutputs
Figure11-
17.
PlanRiskResponses:DataFlowDiagram
Figure11-
18.
ImplementRiskResponses:Inputs,Tools&
Figure11-
19.
ImplementRiskResponses:DataFlowDiagram
Figure11-
20.

MonitorRisks:Inputs,Tools&Techniques,and
Outputs
Figure11-
21.
MonitorRisks:DataFlowDiagram
Figure12-1. ProjectProcurementManagementOverview
Figure12-2. PlanProcurementManagement:Inputs,Tools&
Figure12-3. PlanProcurementManagement:DataFlow
Diagram
Figure12-4. ConductProcurements:Inputs,Tools&
Figure12-5. ConductProcurements:DataFlowDiagram
Figure12-6. ControlProcurements:Inputs,Tools&

Figure12-7. ControlProcurements:DataFlowDiagram
Figure13-1. ProjectStakeholderManagementOverview
Figure13-2. IdentifyStakeholders:Inputs,Tools&
Figure13-3. IdentifyStakeholders:DataFlowDiagram
Figure13-4. PlanStakeholderEngagement:Inputs,Tools&
Figure13-5. PlanStakeholderEngagement:DataFlow
Diagram
Figure13-6. StakeholderEngagementAssessmentMatrix
Figure13-7. ManageStakeholderEngagement:Inputs,Tools
Figure13-8. ManageStakeholderEngagement:DataFlow
Diagram
Figure13-9. MonitorStakeholderEngagement:Inputs,Tools

Figure13-
10.
MonitorStakeholderEngagement:DataFlow
Diagram
Table1-1. ExamplesofFactorsthatLeadtotheCreationof
aProject
Table1-2. ComparativeOverviewofPortfolios,Programs,
andProjects
Table1-3. DescriptionofPMBOK®GuideKeyComponents
Table1-4. ProjectManagementProcessGroupand
KnowledgeAreaMapping
Table1-5. ProjectBusinessDocuments
Table2-1. InfluencesofOrganizationalStructureson
Projects
Table3-1. TeamManagementandTeamLeadership

Compared
Table4-1. ProjectManagementPlanandProjectDocuments
Table5-1. ElementsoftheProjectCharterandProject
ScopeStatement
Table7-1. EarnedValueCalculationsSummaryTable
Table11-1. ExampleofDefinitionsforProbabilityand
Impacts
Table12-1. ComparisonofProcurementDocumentation
PART2.
TheStandardForProjectManagement
Figure1-1. ExampleofPortfolio,Program,andProject
ManagementInterfaces
Figure1-2. GenericDepictionofaProjectLifeCycle
Figure1-3. ImpactofVariablesOverTime
Figure1-4. ExamplesofProjectStakeholders
Figure1-5. ExampleofProcessGroupInteractionsWithina

ProjectorPhase
Figure2-1. ProjectBoundaries
Figure2-2. InitiatingProcessGroup
Figure2-3. DevelopProjectCharter:InputsandOutputs
Figure2-4. IdentifyStakeholders:InputsandOutputs
Figure3-1. PlanningProcessGroup
Figure3-2. DevelopProjectManagementPlan:Inputsand
Outputs
Figure3-3. PlanScopeManagement:InputsandOutputs
Figure3-4. CollectRequirements:InputsandOutputs
Figure3-5. DefineScope:InputsandOutputs
Figure3-6. CreateWBS:InputsandOutputs
Figure3-7. PlanScheduleManagement:InputsandOutputs
Figure3-8. DefineActivities:InputsandOutputs
Figure3-9. SequenceActivities:InputsandOutputs
Figure3-10. EstimateActivityDurations:InputsandOutputs
Figure3-11. DevelopSchedule:InputsandOutputs
Figure3-12. PlanCostManagement:InputsandOutputs
Figure3-13. EstimateCosts:InputsandOutputs
Figure3-14. DetermineBudget:InputsandOutputs

Figure3-15. PlanQualityManagement:InputsandOutputs
Figure3-16. PlanResourceManagement:InputsandOutputs
Figure3-17. EstimateActivityResources:InputsandOutputs
Figure3-18. PlanCommunicationsManagement:Inputsand
Outputs
Figure3-19. PlanRiskManagement:InputsandOutputs
Figure3-20. IdentifyRisks:InputsandOutputs
Figure3-21. PerformQualitativeRiskAnalysis:Inputsand
Outputs
Figure3-22. PerformQuantitativeRiskAnalysis:Inputsand
Outputs
Figure3-23. PlanRiskResponses:InputsandOutputs
Figure3-24. PlanProcurementManagement:Inputsand
Outputs
Figure3-25. PlanStakeholderEngagement:Inputsand
Outputs
Figure4-1. ExecutingProcessGroup
Figure4-2. DirectandManageProjectWork:Inputsand
Outputs

Figure4-3. ManageProjectKnowledge:InputsandOutputs
Figure4-4. ManageQuality:InputsandOutputs
Figure4-5. AcquireResources:InputsandOutputs
Figure4-6. DevelopTeam:InputsandOutputs
Figure4-7. ManageTeam:InputsandOutputs
Figure4-8. ManageCommunications:InputsandOutputs
Figure4-9. ImplementRiskResponses:InputsandOutputs
Figure4-10. ConductProcurements:InputsandOutputs
Figure4-11. ManageStakeholderEngagement:Inputsand
Outputs
Figure5-1. MonitoringandControllingProcessGroup
Figure5-2. MonitorandControlProjectWork:Inputsand
Outputs
Figure5-3. PerformIntegratedChangeControl:Inputsand
Outputs
Figure5-4. ValidateScope:InputsandOutputs
Figure5-5. ControlScope:InputsandOutputs
Figure5-6. ControlSchedule:InputsandOutputs

Figure5-7. ControlCosts:InputsandOutputs
Figure5-8. ControlQuality:InputsandOutputs
Figure5-9. ControlResources:InputsandOutputs
Figure5-10. MonitorCommunications:InputsandOutputs
Figure5-11. MonitorRisks:InputsandOutputs
Figure5-12. ControlProcurements:InputsandOutputs
Figure5-13. MonitorStakeholderEngagement:Inputsand
Outputs
Figure6-1. ClosingProcessGroup
Figure6-2. CloseProjectorPhase:InputsandOutputs
Table1-1. ProjectManagementProcessGroupand
KnowledgeAreaMapping
Table1-2. ProjectManagementPlanandProjectDocuments
PART3.
APPENDICES,GLOSSARY,ANDINDEX
FigureX3-
1.
TheContinuumofProjectLifeCycles

FigureX3-
2.
LevelofEffortforProcessGroupsacross
IterationCycles
FigureX3-
3.
RelationshipofProcessGroupsinContinuous
Phases
TableX1-1. Section4Changes
TableX6-1. CategorizationandIndexofToolsandTechniques

Part1
AGuidetotheProjectManagement
BodyofKnowledge
(PMBOK®GUIDE)
TheinformationcontainedinthispartisnotanAmericanNationalStan
dard(ANS)andhasnotbeen
processedinaccordancewithANSI’srequirementsforanANS.Assuc
h,theinformationinthispart
maycontainmaterialthathasnotbeensubjectedtopublicrevieworaco
nsensusprocess.Inaddition,it
doesnotcontainrequirementsnecessaryforconformancetoanANSst
andard.
1
INTRODUCTION
1.1OVERVIEWANDPURPOSEOFTHISGUIDE

Projectmanagement isnotnew. Ithasbeen inuse
forhundredsofyears.
Examplesofprojectoutcomesinclude:
PyramidsofGiza,
Olympicgames,
GreatWallofChina,
TajMahal,
Publicationofachildren’sbook,
PanamaCanal,
Developmentofcommercialjetairplanes,
Poliovaccine,
Humanbeingslandingonthemoon,
Commercialsoftwareapplications,
Portabledevicestousetheglobalpositioningsystem(GPS),and
PlacementoftheInternationalSpaceStationintoEarth’sorbit.
The outcomes of these projects were the result of leaders
andmanagers
applying project management practices, principles, processes,
tools, and
techniques to theirwork. Themanagers of these projects used a
set of key
skills and applied knowledge to satisfy their customers and

other people
involved in and affected by the project. By the mid-20th
century, project
managersbegantheworkofseekingrecognitionforprojectmanageme
ntasa
profession. One aspect of this work involved obtaining
agreement on the
content of the body of knowledge (BOK) called
projectmanagement. This
BOK became known as the Project Management Body of
Knowledge
(PMBOK).TheProjectManagement Institute
(PMI)producedabaselineof
chartsandglossariesforthePMBOK.Projectmanagerssoonrealizedt
hatno
singlebookcouldcontaintheentirePMBOK.Therefore,PMIdevelop
edand
published A Guide to the Project Management Body of
Knowledge
(PMBOK®Guide).
PMI defines the projectmanagement body of knowledge

(PMBOK) as a
term that describes the knowledge within the profession of
project
management. The projectmanagement body of knowledge
includes proven
traditional practices that are widely applied as well as
innovative practices
thatareemergingintheprofession.
The body of knowledge (BOK) includes both published and
unpublished
materials. This body of knowledge is constantly evolving. This
PMBOK®
Guideidentifiesasubsetoftheprojectmanagementbodyofknowledg
ethat
isgenerallyrecognizedasgoodpractice.
Generallyrecognizedmeanstheknowledgeandpracticesdescribed
are applicable to most projects most of the time, and there is
consensusabouttheirvalueandusefulness.
Goodpracticemeansthereisgeneralagreementthattheapplication
of the knowledge, skills, tools, and techniques to project
management processes can enhance the chance of success over
many projects in delivering the expected business values and
results.

Theprojectmanagerworkswiththeprojectteamandotherstakeholder
sto
determine and use the appropriate generally recognized good
practices for
each project.Determining the appropriate combination of
processes, inputs,
tools,techniques,outputsandlifecyclephasestomanageaprojectisre
ferred
toas“tailoring”theapplicationoftheknowledgedescribedinthisguid
e.
ThisPMBOK®Guideisdifferentfromamethodology.Amethodolog
yisa
system of practices, techniques, procedures, and rules used by
those who
work in a discipline. This PMBOK® Guide is a foundation upon
which
organizationscanbuildmethodologies,policies,procedures, rules,
toolsand
techniques,andlifecyclephasesneededtopracticeprojectmanageme
nt.
1.1.1THESTANDARDFORPROJECTMANAGEMENT
This guide is based on The Standard for Project Management

[1]. A
standardisadocumentestablishedbyanauthority,custom,orgeneral
consent
asamodelorexample.AsanAmericanNationalStandardsInstitute(A
NSI)
standard, The Standard for Project Management was developed
using a
process based on the concepts of consensus, openness, due
process, and
balance.TheStandardforProjectManagementisafoundationalrefer
encefor
PMI’s project management professional development programs
and the
practice of project management. Because project management
needs to be
tailored to fit the needs of the project, the standard and the
guide are both
basedondescriptive practices, rather thanprescriptive practices.
Therefore,
the standard identifies the processes that are considered good
practices on

most projects,most of the time.The standard also identifies the
inputs and
outputs that are usually associatedwith those processes. The
standard does
notrequirethatanyparticularprocessorpracticebeperformed.TheSt
andard
for Project Management is included as Part II of A Guide to the
Project
ManagementBodyofKnowledge(PMBOK®Guide).
ThePMBOK®Guide providesmoredetail aboutkeyconcepts,
emerging
trends, considerations for tailoring the project management
processes, and
information on how tools and techniques are applied to projects.
Project
managers may use one or more methodologies to implement the
project
managementprocessesoutlinedinthestandard.
Thescopeofthisguideislimitedtothedisciplineofprojectmanageme
nt,
ratherthanthefullspectrumofportfolios,programs,andprojects.Port
folios
andprogramswillbeaddressedonlytothedegreetheyinteractwithpro

jects.
PMIpublishestwootherstandardsthataddressthemanagementofpor
tfolios
andprograms:
TheStandardforPortfolioManagement[2],and
TheStandardforProgramManagement[3].
1.1.2COMMONVOCABULARY
Acommonvocabularyisanessentialelementofaprofessionaldiscipli
ne.
ThePMILexiconofProjectManagementTerms[4]providesthefound
ational
professional vocabulary that can be consistently used by
organizations,
portfolio,program,andprojectmanagersandotherprojectstakeholde
rs.The
Lexiconwillcontinuetoevolveovertime.Theglossarytothisguidein
cludes
thevocabularyintheLexiconalongwithadditionaldefinitions.There
maybe
other industry-specific terms used in projects that are defined
by that
industry’sliterature.

1.1.3CODEOFETHICSANDPROFESSIONALCONDUCT
PMIpublishes theCodeofEthicsandProfessionalConduct [5] to
instill
confidenceintheprojectmanagementprofessionandtohelpanindivi
dualin
makingwisedecisions,particularlywhenfacedwithdifficultsituatio
nswhere
theindividualmaybeaskedtocompromisehisorherintegrityorvalues
.The
values that the global project management community defined
as most
important were responsibility, respect, fairness, and honesty.
The Code of
EthicsandProfessionalConductaffirmsthesefourvaluesasitsfounda
tion.
TheCode of Ethics and Professional Conduct includes both
aspirational
standards andmandatory standards. The aspirational standards
describe the
conduct

thatpractitioners,whoarealsoPMImembers,certificationholders,
or volunteers, strive to uphold. Although adherence to the
aspirational
standards is not easily measured, conduct in accordance with
these is an
expectationfor thosewhoconsider themselvestobeprofessionals—
it isnot
optional.Themandatorystandardsestablish firmrequirementsand,
insome
cases,
limitorprohibitpractitionerbehavior.PractitionerswhoarealsoPMI
members, certification holders, or volunteers and who do not
conduct
themselvesinaccordancewiththesestandardswillbesubjecttodiscip
linary
proceduresbeforePMI’sEthicsReviewCommittee.
1.2FOUNDATIONALELEMENTS
Thissectiondescribesfoundationalelementsnecessaryforworkingi
nand
understandingthedisciplineofprojectmanagement.
1.2.1PROJECTS
Aproject isa temporaryendeavorundertaken

tocreateauniqueproduct,
service,orresult.
Unique product, service, or result. Projects are undertaken to
fulfillobjectivesbyproducingdeliverables.Anobjectiveisdefined
as an outcome toward which work is to be directed, a strategic
position to be attained, a purpose to be achieved, a result to be
obtained,aproducttobeproduced,oraservicetobeperformed.A
deliverable isdefinedasanyuniqueandverifiableproduct, result,
orcapabilitytoperformaservicethatisrequiredtobeproducedto
completeaprocess,phase,orproject.Deliverablesmaybetangible
orintangible.
Fulfillment of project objectives may produce one or more of
the
followingdeliverables:
Auniqueproductthatcanbeeitheracomponentofanotheritem,
an enhancement or correction to an item, or a new end item in
itself(e.g.,thecorrectionofadefectinanenditem);
A unique service or a capability to perform a service (e.g., a
businessfunctionthatsupportsproductionordistribution);
Auniqueresult,suchasanoutcomeordocument(e.g.,aresearch
project that develops knowledge that can be used to determine

whetheratrendexistsoranewprocesswillbenefitsociety);and
Auniquecombinationofoneormoreproducts,services,orresults
(e.g., a software application, its associated documentation, and
helpdeskservices).
Repetitive elements may be present in some project deliverables
and
activities. This repetition does not change the fundamental and
unique
characteristicsoftheprojectwork.Forexample,officebuildingscanb
e
constructed with the same or similar materials and by the same
or
different teams.However, eachbuildingproject remains unique in
key
characteristics (e.g., location, design, environment, situation,
people
involved).
Projectsareundertakenatallorganizationallevels.Aprojectcaninvol
ve
a single individual or a group. A project can involve a single

organizational unit or multiple organizational units from
multiple
organizations.
Examplesofprojectsincludebutarenotlimitedto:
Developinganewpharmaceuticalcompoundformarket,
Expandingatourguideservice,
Mergingtwoorganizations,
Improvingabusinessprocesswithinanorganization,
Acquiringandinstallinganewcomputerhardwaresystemforuse
inanorganization,
Exploringforoilinaregion,
Modifyingacomputersoftwareprogramusedinanorganization,
Conductingresearchtodevelopanewmanufacturingprocess,and
Constructingabuilding.
Temporaryendeavor. The temporary nature of projects indicates
thataprojecthasadefinitebeginningandend.Temporarydoesnot
necessarily mean a project has a short duration. The end of the
projectisreachedwhenoneormoreofthefollowingistrue:
Theproject’sobjectiveshavebeenachieved;
Theobjectiveswillnotorcannotbemet;
Funding is exhaustedor no longer available for allocation to the

project;
The need for the project no longer exists (e.g., the customer no
longerwantstheprojectcompleted,achangeinstrategyorpriority
ends the project, the organizational management provides
directiontoendtheproject);
Thehumanorphysicalresourcesarenolongeravailable;or
Theprojectisterminatedforlegalcauseorconvenience.
Projectsare temporary,but
theirdeliverablesmayexistbeyondtheend
oftheproject.Projectsmayproducedeliverablesofasocial,economic
,
material, or environmental nature. For example, a project to
build a
national monument will create a deliverable expected to last for
centuries.
Projects drive change. Projects drive change in organizations.
From a business perspective, a project is aimed at moving an
organization from one state to another state in order to achieve
a
specific objective (see Figure 1-1). Before the project begins,

the
organization iscommonlyreferred toasbeing in thecurrentstate.
Thedesiredresultof thechangedrivenbytheproject isdescribed
asthefuturestate.
Forsomeprojects,thismayinvolvecreatingatransitionstatewhere
multiple steps are made along a continuum to achieve the future
state. The successful completion of a project results in the
organizationmoving to the future state and achieving the
specific
objective. For more information on project management and
change,seeManagingChangeinOrganizations:APracticeGuide
[6].
Projects enable business value creation. PMI defines business
value as the net quantifiable benefit derived from a business
endeavor. The benefit may be tangible, intangible, or both. In
business analysis, business value is considered the return, in the
form of elements such as time, money, goods, or intangibles in
return for something exchanged (see Business Analysis for
Practitioners:APracticeGuide,p.185[7]).
Business value in projects refers to the benefit that the results

of a
specific project provide to its stakeholders. The benefit from
projects
maybetangible,intangible,orboth.
Examplesoftangibleelementsinclude:
Monetaryassets,
Stockholderequity,
Utility,
Fixtures,
Tools,and
Marketshare.
Examplesofintangibleelementsinclude:
Goodwill,
Brandrecognition,
Publicbenefit,
Trademarks,
Strategicalignment,and
Reputation.
ProjectInitiationContext.Organizationalleadersinitiateprojects
in response to factors acting upon their organizations. There are

four fundamental categories for these factors, which illustrate
the
contextofaproject(seeFigure1-2):
Meetregulatory,legal,orsocialrequirements;
Satisfystakeholderrequestsorneeds;
Implementorchangebusinessortechnologicalstrategies;and
Create,improve,orfixproducts,processes,orservices.
Thesefactorsinfluenceanorganization’songoingoperationsandbus
iness
strategies.Leadersrespondtothesefactorsinordertokeeptheorganiz
ation
viable.Projectsprovidethemeansfororganizationstosuccessfullym
akethe
changesnecessarytodealwiththesefactors.Thesefactorsultimatelys
hould
link to thestrategicobjectivesof theorganizationand
thebusinessvalueof
eachproject.

1.2.2THEIMPORTANCEOFPROJECTMANAGEMENT
Project management is the application of knowledge, skills,
tools, and
techniques to project activities to meet the project requirements.
Project
management is accomplished through the appropriate
application and
integration of the project management processes identified for
the project.
Projectmanagementenablesorganizationstoexecuteprojectseffecti
velyand
efficiently.
Effective project management helps individuals, groups, and
public and
privateorganizationsto:
Meetbusinessobjectives;
Satisfystakeholderexpectations;
Bemorepredictable;
Increasechancesofsuccess;

Delivertherightproductsattherighttime;
Resolveproblemsandissues;
Respondtorisksinatimelymanner;
Optimizetheuseoforganizationalresources;
Identify,recover,orterminatefailingprojects;
Manageconstraints(e.g.,scope,quality,schedule,costs,resources);
Balance the influenceofconstraintson theproject (e.g., increased
scopemayincreasecostorschedule);and
Managechangeinabettermanner.
Poorly managed projects or the absence of project management
may
resultin:
Misseddeadlines,
Costoverruns,
Poorquality,
Rework,
Uncontrolledexpansionoftheproject,
Lossofreputationfortheorganization,
Unsatisfiedstakeholders,and
Failure in achieving the objectives for which the project was
undertaken.
Projects are a key way to create value and benefits in

organizations. In
today’s business environment, organizational leaders need to be
able to
manage with tighter budgets, shorter timelines, scarcity of
resources, and
rapidly changing technology.Thebusiness environment is
dynamicwith an
accelerating rate of change. To remain competitive in the world
economy,
companiesareembracingprojectmanagementtoconsistentlydeliver
business
value.
Effectiveandefficientprojectmanagementshouldbeconsideredastr
ategic
competencywithinorganizations.Itenablesorganizationsto:
Tieprojectresultstobusinessgoals,
Competemoreeffectivelyintheirmarkets,
Sustaintheorganization,and
Respondtotheimpactofbusinessenvironmentchangesonprojects
by appropriately adjusting projectmanagement plans (see

Section
4.2).
1.2.3RELATIONSHIPOFPROJECT,PROGRAM,PORTFOLIO,
ANDOPERATIONSMANAGEMENT
1.2.3.1OVERVIEW
Usingprojectmanagementprocesses,tools,andtechniquesputsinpla
cea
sound foundation for organizations to achieve their goals and
objectives.A
projectmaybemanagedinthreeseparatescenarios:asastand-
aloneproject
(outsideofaportfolioorprogram),withinaprogram,orwithinaportfo
lio.
Project managers interact with portfolio and program managers
when a
projectiswithinaprogramorportfolio.Forexample,multipleprojects
may
beneededtoaccomplishasetofgoalsandobjectivesforanorganizatio
n.In
thosesituations,projectsmaybegroupedtogetherintoaprogram.Apr
ogram
isdefined as a groupof relatedprojects, subsidiaryprograms,
andprogram

activitiesmanaged in a coordinatedmanner to obtain benefits not
available
frommanaging them individually. Programs are not large
projects. A very
large project may be referred to as a megaproject. As a
guideline,
megaprojectscostUS$1billionormore,affect1millionormorepeopl
e,and
runforyears.
Someorganizationsmayemploytheuseofaprojectportfoliotoeffecti
vely
managemultipleprogramsandprojectsthatareunderwayatanygiven
time.
A portfolio is defined as projects, programs, subsidiary
portfolios, and
operations managed as a group to achieve strategic objectives.
Figure 1-3
illustrates an exampleofhowportfolios, programs, projects,
andoperations
arerelatedinaspecificsituation.
Program management and portfolio management differ from
project
management in their life cycles, activities, objectives, focus,

and benefits.
However,portfolios,programs,projects,andoperationsoftenengage
withthe
samestakeholdersandmayneedtousethesameresources(seeFigure1
-3),
whichmay result in a conflict in the organization. This type of a
situation
increasestheneedforcoordinationwithintheorganizationthroughth
euseof
portfolio,program,andprojectmanagementtoachieveaworkablebal
ancein
theorganization.
Figure1-3 illustrates a sample portfolio structure indicating
relationships
between the programs, projects, shared resources, and
stakeholders. The
portfoliocomponentsaregroupedtogetherinordertofacilitatetheeff
ective
governanceandmanagementoftheworkthathelpstoachieveorganiza
tional
strategies and priorities. Organizational and portfolio planning
impact the
components by means of prioritization based on risk, funding,
and other

considerations. The portfolio view allows organizations to see
how the
strategicgoalsarereflectedintheportfolio.Thisportfolioviewalsoen
ables
the implementation and coordination of appropriate portfolio,
program, and
projectgovernance.Thiscoordinatedgovernanceallowsauthorizeda
llocation
ofhuman, financial, andphysical resourcesbasedon
expectedperformance
andbenefits.
Looking at project, program, and portfolio management from an
organizationalperspective:
Program and project management focus on doing programs and
projectsthe“right”way;and
Portfoliomanagement focuses on doing the “right” programs and
projects.
Table 1-2 gives a comparative overview of portfolios, programs,
and

projects.
1.2.3.2PROGRAMMANAGEMENT
Programmanagement is defined as the application of knowledge,
skills,
andprinciples
toaprogramtoachievetheprogramobjectivesandtoobtain
benefits and control not available by managing program
components
individually. A program component refers to projects and other
programs
withinaprogram.Projectmanagementfocusesoninterdependencies
withina
projecttodeterminetheoptimalapproachformanagingtheproject.Pr
ogram
managementfocusesontheinterdependenciesbetweenprojectsandb
etween
projects and the program level to determine the optimal
approach for
managing them. Actions related to these program and project-
level
interdependenciesmayinclude:

Aligningwith the organizational or strategic direction that
affects
programandprojectgoalsandobjectives;
Allocatingtheprogramscopeintoprogramcomponents;
Managinginterdependenciesamongthecomponentsoftheprogram
tobestservetheprogram;
Managing program risks thatmay impactmultiple projects in the
program;
Resolving constraints and conflicts that affect multiple projects
withintheprogram;
Resolving issues between component projects and the program
level;
Managingchangerequestswithinasharedgovernanceframework;
Allocatingbudgetsacrossmultipleprojectswithintheprogram;and
Assuring benefits realization from the program and component
projects.
Anexampleof aprogram is anewcommunications satellite
systemwith
projects for the design and construction of the satellite and the
ground

stations,thelaunchofthesatellite,andtheintegrationofthesystem.
For more information on program management, see The
Standard for
ProgramManagement[3].
1.2.3.3PORTFOLIOMANAGEMENT
A portfolio is defined as projects, programs, subsidiary
portfolios, and
operationsmanagedasagrouptoachievestrategicobjectives.
Portfoliomanagementisdefinedasthecentralizedmanagementofon
eor
moreportfolios to achieve
strategicobjectives.Theprogramsorprojectsof
theportfoliomaynotnecessarilybeinterdependentordirectlyrelated
.
Theaimofportfoliomanagementisto:
Guideorganizationalinvestmentdecisions.
Select theoptimalmixof programs andprojects tomeet strategic
objectives.
Providedecision-makingtransparency.

Prioritizeteamandphysicalresourceallocation.
Increasethelikelihoodofrealizingthedesiredreturnoninvestment.
Centralize the management of the aggregate risk profile of all
components.
Portfolio management also confirms that the portfolio is
consistent with
andalignedwithorganizationalstrategies.
Maximizing thevalueof theportfolio
requirescarefulexaminationof the
components that comprise the portfolio. Components are
prioritized so that
thosecontributingthemosttotheorganization’sstrategicobjectivesh
avethe
requiredfinancial,team,andphysicalresources.
Forexample,aninfrastructureorganizationthathasthestrategicobje
ctive
ofmaximizingthereturnonitsinvestmentsmayputtogetheraportfoli
othat
includes a mix of projects in oil and gas, power, water, roads,

rail, and
airports. From this mix, the organization may choose to manage
related
projectsasoneportfolio.Allofthepowerprojectsmaybegroupedtoge
ther
as a power portfolio. Similarly, all of the water projects may be
grouped
togetherasawaterportfolio.However,whentheorganizationhasproj
ectsin
designingandconstructingapowerplantandthenoperatesthepowerp
lantto
generateenergy,thoserelatedprojectscanbegroupedinoneprogram.
Thus,
thepowerprogramandsimilarwaterprogrambecomeintegralcompo
nentsof
theportfoliooftheinfrastructureorganization.
For more information on portfolio management, see The
Standard for
PortfolioManagement[2].
1.2.3.4OPERATIONSMANAGEMENT
Operations management is an area that is outside the scope of
formal

projectmanagementasdescribedinthisguide.
Operationsmanagementisconcernedwiththeongoingproductionofg
oods
and/or services. It ensures that business operations continue
efficiently by
using the optimal resources needed to meet customer demands.
It is
concerned with managing processes that transform inputs (e.g.,
materials,
components, energy, and labor) into outputs (e.g., products,
goods, and/or
services).
1.2.3.5OPERATIONSANDPROJECTMANAGEMENT
Changes in business or organizational operations may be the
focus of a
project—
especiallywhentherearesubstantialchangestobusinessoperations
as a result of a new product or service delivery. Ongoing
operations are
outsideofthescopeofaproject;however,thereareintersectingpoints
where
thetwoareascross.

Projectscanintersectwithoperationsatvariouspointsduringtheprod
uct
lifecycle,suchas;
Whendevelopinganewproduct,upgradingaproduct,orexpanding
outputs;
Whileimprovingoperationsortheproductdevelopmentprocess;
Attheendoftheproductlifecycle;and
Ateachcloseoutphase.
At each point, deliverables and knowledge are transferred
between the
project and operations for implementation of the delivered
work. This
implementationoccurs througha transferofproject
resourcesorknowledge
tooperationsorthroughatransferofoperationalresourcestotheproje
ct.
1.2.3.6ORGANIZATIONALPROJECTMANAGEMENT(OPM)A
ND
STRATEGIES

Portfolios, programs, and projects are aligned with or driven by
organizational strategies and differ in the way each contributes
to the
achievementofstrategicgoals:
Portfolio management aligns portfolios with organizational
strategies by selecting the right programs or projects,
prioritizing
thework,andprovidingtheneededresources.
Program management harmonizes its program components and
controlsinterdependenciesinordertorealizespecifiedbenefits.
Project management enables the achievement of organizational
goalsandobjectives.
Within portfolios or programs, projects are a means of
achieving
organizationalgoalsandobjectives.Thisisoftenaccomplishedinthe
context
ofastrategicplanthat is
theprimaryfactorguidinginvestmentsinprojects.
Alignmentwith the organization’s strategic business goals can
be achieved
through the systematic management of portfolios, programs, and
projects

through theapplicationoforganizationalprojectmanagement
(OPM).OPM
is defined as a framework in which portfolio, program, and
project
management are integratedwith organizational enablers in order
to achieve
strategicobjectives.
ThepurposeofOPMistoensurethattheorganizationundertakestheri
ght
projects and allocates critical resources appropriately. OPM
also helps to
ensure that all levels in theorganizationunderstand the
strategicvision, the
initiativesthatsupportthevision,theobjectives,andthedeliverables.
Figure
1-4 shows the organizational environment where strategy,
portfolio,
programs,projects,andoperationsinteract.
For more information on OPM, refer to Implementing
Organizational
ProjectManagement:APracticeGuide[8].

1.2.4COMPONENTSOFTHEGUIDE
Projectscompriseseveralkeycomponentsthat,wheneffectivelyman
aged,
resultintheirsuccessfulcompletion.Thisguideidentifiesandexplain
sthese
components. The various components interrelate to one another
during the
managementofaproject.
ThekeycomponentsaredescribedbrieflyinTable1-
3.Thesecomponents
aremorefullyexplainedinthesectionsthatfollowthetable.
Table1-3.DescriptionofPMBOK®GuideKeyComponents
PMBOK®GuideKeyComponent BriefDescription
Projectlifecycle(Section1.2.4.1)
Theseriesofphasesthataprojectpassesthroughfromits
starttoitscompletion.
Projectphase(Section1.2.4.2)
Acollectionoflogicallyrelatedprojectactivitiesthat

culminatesinthecompletionofoneormoredeliverables.
Phasegate(Section1.2.4.3)
Areviewattheendofaphaseinwhichadecisionis
madetocontinuetothenextphase,tocontinuewith
modification,ortoendaprogramorproject.
Projectmanagementprocesses
(Section1.2.4.4)
Asystematicseriesofactivitiesdirectedtowardcausing
anendresultwhereoneormoreinputswillbeactedupon
tocreateoneormoreoutputs.
ProjectManagementProcessGroup
(Section1.2.4.5)
Alogicalgroupingofprojectmanagementinputs,tools
andtechniques,andoutputs.TheProjectManagement
ProcessGroupsincludeInitiating,Planning,Executing,
MonitoringandControlling,andClosing.Project
ManagementProcessGroupsarenotprojectphases.

ProjectManagementKnowledge
Area(Section1.2.4.6)
Anidentifiedareaofprojectmanagementdefinedbyits
knowledgerequirementsanddescribedintermsofits
componentprocesses,practices,inputs,outputs,tools,
andtechniques.
1.2.4.1PROJECTANDDEVELOPMENTLIFECYCLES
A project life cycle is the series of phases that a project passes
through
fromitsstarttoitscompletion.Itprovidesthebasicframeworkforman
aging
the project. This basic framework applies regardless of the
specific project
work involved.Thephasesmaybe sequential, iterative,
oroverlapping.All
projectscanbemappedtothegenericlifecycleshowninFigure1-5.
Projectlifecyclescanbepredictiveoradaptive.Withinaprojectlifecy
cle,
there are generally one or more phases that are associated with
the
developmentoftheproduct,service,orresult.Thesearecalledadevel

opment
life cycle.Development life cycles canbepredictive, iterative,
incremental,
adaptive,orahybridmodel:
In a predictive life cycle, the project scope, time, and cost are
determinedintheearlyphasesofthelifecycle.Anychangestothe
scope are carefully managed. Predictive life cycles may also be
referredtoaswaterfalllifecycles.
Inan iterative lifecycle, theprojectscopeisgenerallydetermined
early in the project life cycle, but time and cost estimates are
routinely modified as the project team’s understanding of the
productincreases.Iterationsdeveloptheproductthroughaseriesof
repeated cycles, while increments successively add to the
functionalityoftheproduct.
Inan incremental lifecycle, thedeliverable isproduced througha
series of iterations that successively add functionality within a
predetermined time frame. The deliverable contains the
necessary
and sufficient capability to be considered complete only after
the
finaliteration.
Adaptivelifecyclesareagile,iterative,orincremental.Thedetailed

scope is defined and approved before the start of an iteration.
Adaptive life cycles are also referred to as agile or change-
driven
lifecycles.SeeAppendixX3.
Ahybridlifecycleisacombinationofapredictiveandanadaptive
life cycle. Those elements of the project that are well known or
havefixedrequirementsfollowapredictivedevelopmentlifecycle,
and those elements that are still evolving follow an adaptive
developmentlifecycle.
Itisuptotheprojectmanagementteamtodeterminethebestlifecyclefo
r
eachproject.Theproject lifecycleneeds
tobeflexibleenoughtodealwith
the variety of factors included in the project. Life cycle
flexibilitymay be
accomplishedby:
Identifyingtheprocessorprocessesneededtobeperformedineach
phase,
Performing the process or processes identified in the
appropriate
phase,
Adjusting the various attributes of a phase (e.g., name, duration,
exitcriteria,andentrancecriteria).

Project life cycles are independent of product life cycles,
whichmay be
produced by a project. A product life cycle is the series of
phases that
represent theevolutionofaproduct,fromconcept
throughdelivery,growth,
maturity,andtoretirement.
1.2.4.2PROJECTPHASE
A project phase is a collection of logically related project
activities that
culminatesinthecompletionofoneormoredeliverables.Thephasesin
alife
cycle can be described by a variety of attributes. Attributes may
be
measurableanduniquetoaspecificphase.Attributesmayincludebuta
renot
limitedto:
Name(e.g.,PhaseA,PhaseB,Phase1,Phase2,proposalphase),
Number(e.g.,threephasesintheproject,fivephasesintheproject),

Duration(e.g.,1week,1month,1quarter),
Resourcerequirements(e.g.,people,buildings,equipment),
Entrance criteria for a project to move into that phase (e.g.,
specified approvals documented, specified documents
completed),
and
Exit criteria for a project to complete a phase (e.g., documented
approvals,completeddocuments,completeddeliverables).
Projects may be separated into distinct phases or
subcomponents. These
phasesorsubcomponentsaregenerallygivennamesthatindicatethet
ypeof
workdoneinthatphase.Examplesofphasenamesincludebutarenotli
mited
to:
Conceptdevelopment,
Feasibilitystudy,
Customerrequirements,

Discussion 1 post responses.Please respond to the following.docx

Recomendados

Recomendados

Más contenido relacionado

Similar a Discussion 1 post responses.Please respond to the following.docx

Similar a Discussion 1 post responses.Please respond to the following.docx (19)

Más de cuddietheresa

Más de cuddietheresa (20)

Último

Último (20)

Discussion 1 post responses.Please respond to the following.docx