Download - PM Processes - REV03 - ScopeNawzad.doc
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
1/30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
2/30
Project Management Processes Scope
Table of Contents
Course Syllabus
1. Course Title: Project Management Processes / Project ScopeManagement
2. Course Level: Competency
Page 2of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
3/30
Project Management Processes Scope
3. Course Description:This course requires all participants tobe familiar with basic Project Management theory andmethodologies. This course is designed to proide participants
with s!ills" !nowledge" tools and techniques that are utili#ed inthe Project Management. $t focuses on practical s!ills andmethodologies.
4. Contact Hours: % &ours ' ( day )
5. Course Prerequisites: Participants* should be members inproject management departments / units or their wor! isreleant to project management applications.
6. Course Dates: T+,
. Class Ti!es: -rom : am to 0: pm.
". Course Location:T+,
#. $nstructor: Tarabot / PM 1nit trainers
1%. &equire' Te(t an' )t*er Learnin+ &esources:
Class handouts
11. Course )vervie,: Proide participants the opportunity to
improe and/or acquire the necessary !nowledge ands!ill2set in Project Management and to transform this!nowledge to actions that would benefit public serices.
Proide a set of learning materialscoering range of topics in Project Management.
Proide the participants with selectedadanced leel material in Project Management"standards and best practices.
12. Course )b-ectives: 1pon completion of this course"
students should be able to: 3earn Project Scope Management process" tools"
techniques and s!ills. 3earn to apply a ariety of Project Scope Management
practices and planning tools as means of administering"directing and coordinating projects.
13. Course Policies: Students are e4pected to attend the
full course period and must be present for all actiitiesand e4ams to receie credit. $f a student has a special
circumstance that will preent him/her from attending a
Page 3of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
4/30
Project Management Processes Scope
schedule e4am" a ma!e2up e4am can be rescheduled atthe conenience of the instructor.
5ll assignments are due as specified
by the instructor. Student can miss a ma4imum of one
day of training.
14. et*o'olo+/: The trainer will proide a comprehensiemanual to the participants. 3ecturing will be conducted usingpower point presentations. 5 participatory approach will beused to facilitate learning of the participants. 64amples" casestudies and practical questions/actiities will be used.
$ntro'uction
Page 4of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
5/30
Project Management Processes Scope
T*e pro-ect life c/cle
5 project life cycle is collection of general sequential and sometimes
oerlapping project phases whose name and number are determinedby the management and control needs of the organi#ation ororgani#ations inoled in the project" the nature of the project itself"and its area of application. 5 life cycle can be documented with amethodology. The project life cycle can be determined or shaped bythe unique aspects of the organi#ation" industry or technologyemployed. 7hile eery project has a definite start and a definite end"the specific delierables and actiities that ta!e place in between willary widely with the project. The life cycle proides the basicframewor! for managing the project" regardless of the specific wor!inoled.
Pro-ect ana+e!ent Processes for a Pro-ect
Project management is the application of !nowledge" s!ills" tools"and techniques to project actiities to meet project requirements.This application of !nowledge requires the effectie management of
appropriate processes.
$n this framewor!" the fie Project Management Process 8roups thatrequired for any project are clearly identified and described. Thesefie process groups hae clear dependencies and are typicallyperformed in the same sequence on each project. They areindependent of application areas or industry focus. $ndiidual processgroups* indiidual constituent processes are often iterated prior tocompleting the project. The constituent processes can haeinteractions within a process group and among process group. The
nature of these interactions aries from project to project and may ormay not be performed in a particular order.
Page 5of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
6/30
Project Management Processes Scope
5 process group includes the constituent project managementprocesses that are lin!ed by the respectie inputs and outputs where
the result or outcome of one process becomes the input to another.
5 process is a set of interrelated actions and actiities performed toachiee a pre2specific product" result" or serice. 6ach process ischaracteri#ed by its inputs" the tools and techniques that can beapplied" and the resulting outputs. The project manager mustconsider organi#ational process assets and enterprise enironmentalfactors. These must be ta!en into account for eery process" een ifthey are not e4plicitly listed as inputs in the process specification.9rgani#ational process assets proide guidelines and criteria fortailoring the organi#ation*s processes to the specific needs of the
project. 6nterprise enironmental factors may constrain the projectmanagement options.
$n order for a project to be successful" the project team must: Select appropriate processes required to meet the project
delierables. 1se a defined approach that can be adopted to meet
requirements. Comply with requirements to meet sta!eholder needs and
e4pectations. +alance the competing demands of scope" cost" quality"
resources" and ris! to produce the specific product" serice" orresult.
Project management processes apply globally and across industrygroups. 8ood practice means there is general agreement that theapplication of project management processes has been shown toenhance the chances of success oer a wide range of products.
This framewor! describes the nature of project managementprocesses in terms of the integration between the processes" their
interactions" and the purposes they sere. Project managementprocesses are grouped into fie categories !nown as ProjectManagement Process 8roups:
$nitiatin+ Process 0roup: Those processes performed todefine a new project or a new phase of an e4isting project byobtaining authori#ation to start the project or phase.
Plannin+ Process 0roup: Those processes required toestablish the scope of the project" refine the objecties" anddefine the course of action required to attain the objecties thatthe project was underta!en to achiee.
Page 6of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
7/30
Project Management Processes Scope
(ecutin+ Process 0roup: Those processes performed tocomplete the wor! defined in the project management plan tosatisfy the project specification.
onitorin+ an' Controllin+ Process 0roup: Thoseprocesses required to trac!" reiew" and regulate the progressand performance of the project identify any areas in whichchanges to the plan are required and initiate the correspondingchanges.
Closin+ Process 0roup: Those Processes performed tofinali#e all actiities across all Process 8roups to formally closethe project or phase.
Knowledge
Area
Project Management Process Groups
InitiatingProcessGroup
PlanningProcessGroup
ExecutingProcessGroup
Monitoring&
ControllingProcessGroup
ClosingProcessGroup
ProjectIntegration
management
4.1 DevelopProjectCharter.
4.2 Developproject Mgmt.Plan
4.3 Directand ManageProject work,
4.4 Monitorand ControlProjectWork., 4.5Perormintegrated
changecontrol.
4.! Clo"eProject orPha"e.
Project Scopemanagement
5.1 Plan#copeMgmt.,5.2 Collectre$%irement",5.3 Deine#cope and5.4 CreateW.
5.5 'alidate#cope.5.! Control#cope.
Page 7of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
8/30
Project Management Processes Scope
Project Timemanagement
!.1 Plan#ched%leMgmt.,!.2 Deine
(ctivitie".!.3#e$%ence(ctivitie".,!.4 )"timate(ctivit*+e"o%rce".,!.5 )"timate(ctivit*D%ration"and !.!Develop#ched%le.
!. Control#ched%le.
Project Costmanagement
.1 Plan Co"tMgmt.,.2 )"timateCo"t" and.3Determine&%dget.
.4 ControlCo"t".
Project Qualitymanagement
-.1 Plan%alit*Mgmt.
-.2 Perorm%alit*(""%rance.
-.3 Control%alit*.
ProjectHumanResource
management
/.1 Plan 0+Mgmt.
/.2 (c$%ireProjecteam., /.3DevelopProjecteam. and/.4 ManageProjecteam.
ProjectCommunication
management
1.1 PlanComm%n.Mgmt.
1.2 ManageComm%n.
1.3 ControlComm%n.
Project Riskmanagement
11.1 Plan+i"k Mgmt.,
11.2 denti*+i"k".,11.3 Perorm%alitative+i"k(nal*"i".,11.4 Perorm%antitative+i"k anal*"i"and11.5 Plan+i"k+e"pon"e".
11.! Control+i"k".
Page 8of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
9/30
Project Management Processes Scope
ProjectProcurementmanagement
12.1 PlanProc%rementMgmt.
12.2 Cond%ctProc%rement.
12.3 ControlProc%rement.
12.4 Clo"eProc%rement.
Project
Stakeholermanagement
13.1 denti*#takeholder".
13.2 Plan
#takeholder"Mgmt.
13.3 Manage
#takeholder)ngagement.
13.4 Control
#takeholder")ngagement.
The aboe table reflects the mapping of the 0; project managementprocess into fie Project Management Process 8roups and the tenProject Management is! Management are to increase theprobability and impact of positie eents" and decrease theprobability and impact of negatie eents in the project.
Pro-ect Procure!ent ana+e!ent: $t includes theprocesses necessary to purchase or acquire products" serices"or results needed from outside the project team.
Page 9of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
10/30
Project Management Processes Scope
Pro-ect tae*ol'ers ana+e!ent: Project Sta!eholderManagement includes the processes required to identify thepeople" groups" or organi#ations that could impact or be
impacted by the project" to analy#e sta!eholder e4pectationsand their impact on the project" and to deelop appropriatemanagement strategies for effectiely engaging sta!eholders inproject decisions and e4ecution.
Co!!on Pro-ect ana+e!ent Process $nteractions
The project management processes are presented as discreteelements with well2defined interfaces. &oweer" in practice theyoerlap and interact in ways that are not completely detailed here.Most e4perienced project management practitioners recogni#e there
is more than one way to manage a project. The required Process8roup and their constituent processes are guides for applyingappropriate project management !nowledge and s!ills during theproject. The application of the project management processes isiteratie" and many processes are repeated during the project. Theinteractie nature of project management requires the Monitoringand Controlling Process 8roup to interact with the other Process8roups.
$n addition" since management of a project is a finite effort" the
$nitiating Process 8roup begins the project" and the Closing Process8roup ends it. Project Management Process 8roups are lin!ed by theoutputs they produce. The Process 8roups are seldom either discreteor on2time eents they are oerlapping actiities that occurthroughout the project. The output of one process generally becomesan input to another process or is a delierable of the project. ThePlanning Process 8roup proides the 64ecution Process 8roup withthe Project Management plan and project documents" and" as theproject progresses" it often entails updates to the projectmanagement plan and the project documents.
Page 10of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
11/30
Project Management Processes Scope
Pro-ect ana+e!ent Process 0roups an' no,le'+ereas appin+
Knowledge
Area
Project Management Process Groups
InitiatingProcessGroup
PlanningProcessGroup
ExecutingProcessGroup
Monitoring&
ControllingProcessGroup
ClosingProcessGroup
ProjectIntegration
management
4.1 DevelopProject
Charter.
4.2 Developproject Mgmt.
Plan
4.3 Directand Manage
Project work,
4.4 Monitorand ControlProjectWork., 4.5
Perormintegratedchangecontrol.
4.! Clo"eProject or
Pha"e.
Project Scopemanagement
5.1 Plan#copeMgmt.,5.2 Collectre$%irement",5.3 Deine#cope and5.4 Create
W.
5.5 'alidate#cope.5.! Control#cope.
Page 11of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
12/30
Project Management Processes Scope
cope 7 Plannin+: Collect &equire!ents
Collect requirements is the process of defining and documentingsta!eholders* needs to meet the project objecties. The projectsuccess is directly influenced by the care ta!en in capturing andmanaging project and product requirements.>equirements include the quantified and documented needs ande4pectations of the sponsor" customer" and other sta!eholders.
These requirements need to be elicited" analy#ed" and recorded inenough detail to be measured once project e4ecution begins.Collecting requirements is defining and managing customere4pectations. >equirements become the foundation of the 7+S.Cost" Schedule" and quality planning are all built upon theserequirements. The deelopment of the requirements begins with ananalysis of the information contained in the project charter and thesta!eholder register. Many organi#ations categori#e requirementsinto project requirements and product requirements. Projectrequirements can include business requirements" projectmanagement requirements" deliery requirements" etc. Product
requirements can include information on technical requirements"security requirements" performance requirements" etc.
$nputs:
1. cope ana+e!ent Plan: The scope management planproides clarity as to how project teams will determine which type ofrequirements need to be collected for the project.
2. &equire!ents ana+e!ent Plan: The requirementsmanagement plan proides the processes that will be usedthroughout the Collect >equirements process to define and
Page 12of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
13/30
Project Management Processes Scope
document the sta!eholder needs.
3. tae*ol'er ana+e!ent Plan:The sta!eholder managementplan is used to understand sta!eholder communication requirements
and the leel of sta!eholder engagement in order to assess andadapt to the leel of sta!eholder participation in requirementsactiities.
4. Pro-ect C*arter:The project charter is used to proide
the high2leel description of the product" serice" or result of
the project so that detailed requirements can be deeloped.
5. tae*ol'er &e+ister: The sta!eholder register is used toidentify sta!eholders who can proide information on the
requirements. The sta!eholder register also captures majorrequirements and main e4pectations sta!eholders may hae for theproject.
Tools 8 Tec*niques:
1. $ntervie,s: 5n interiew is a formal or informal approach toelicit information from sta!eholders by tal!ing to them directly.$t is typically performed by as!ing prepared and spontaneous
questions and recording the responses. $nteriews are oftenconducted on an indiidual basis between an interiewer andan interiewee" but may inole multiple interiewers and/ormultiple interiewees. $nteriewing e4perienced projectparticipants" sponsors and other e4ecuties" and subjectmatter e4perts can aid in identifying and defining the featuresand functions of the desired product delierables. $nteriewsare also useful for obtaining confidential information.
2. 9ocus 0roups:
-ocus groups bring together prequalified sta!eholders and subjectmatter e4perts to learn about their e4pectations and attitudes about
a proposed product" serice" or result. 5 trained moderator guides
the group through an interactie discussion" designed to be more
conersational than a one2on2one interiew.
3. 9acilitate' ors*ops:
-acilitated wor!shops are focused sessions that bring !ey
sta!eholders together to define product requirements. 7or!shops
are considered a primary technique for quic!ly defining cross2
Page 13of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
14/30
Project Management Processes Scope
functional requirements and reconciling sta!eholder differences.
+ecause of their interactie group nature" well2facilitated sessions
can build trust" foster relationships" and improe communication
among the participants" which can lead to increased sta!eholderconsensus. $n addition" issues can be discoered earlier and resoled
more quic!ly than in indiidual sessions.
-or e4ample" facilitated wor!shops called joint application
design/deelopment '?5,) sessions are used in the software
deelopment industry. These facilitated sessions focus on bringing
business subject matter e4perts and the deelopment team together
to improe the software deelopment process. $n the manufacturing
industry" quality function deployment '@-,) is another e4ample of a
facilitated wor!shop technique that helps determine criticalcharacteristics for new product deelopment. @-, starts by
collecting customer needs" also !nown as oice of the customer
'A9C). These needs are then objectiely sorted and prioriti#ed" and
goals are set for achieing them. 1ser stories" which are short"
te4tual descriptions of required functionality" are often deeloped
during a requirements wor!shop. 1ser stories describe the
sta!eholder who benefits from the feature 'role)" what the
sta!eholder needs to accomplish 'goal)" and the benefit to the
sta!eholder 'motiation). 1ser stories are widely used with agile
methods.
4. 0roup Creativit/ Tec*niques
Seeral group actiities can be organi#ed to identify project and
product requirements. Some of the group creatiity techniques that
can be used are:
;rainstor!in+. 5 technique used to generate and
collect multiple ideas related to project and product
requirements. 5lthough brainstorming by itself does notinclude oting or prioriti#ation" it is often used with other
group creatiity techniques that do.
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
15/30
Project Management Processes Scope
ffinit/ 'ia+ra!. 5 technique that allows large numbers
of ideas to be classified into groups for reiew and analysis.
ulti7criteria 'ecision anal/sis. 5 technique that utili#es
a decision matri4 to proide a systematic analytical approachfor establishing criteria" such as ris! leels" uncertainty" and
aluation" to ealuate and ran! many ideas.
5. 0roup Decision7ain+ Tec*niques
5 group decision2ma!ing technique is an assessment process
haing multiple alternaties with an e4pected outcome in the form
of future actions. These techniques can be used to generate"
classify" and prioriti#e product requirements.
There are arious methods of reaching a group decision" such as: =nani!it/. 5 decision that is reached whereby
eeryone agrees on a single course of action. 9ne way
to reach unanimity is the ,elphi technique" in which a
selected group of e4perts answers questionnaires and
proides feedbac! regarding the responses from each
round of requirements gathering. The responses are only
aailable to the facilitator to maintain anonymity.
a-orit/. 5 decision that is reached with support
obtained from more than B of the members of the
group. &aing a group si#e with an uneen number of
participants can ensure that a decision will be reached"
rather than resulting in a tie.
Pluralit/. 5 decision that is reached whereby the
largest bloc! in a group decides" een if a majority is not
achieed. This method is generally used when the
number of options nominated is more than two.
Dictators*ip. $n this method" one indiidual ma!es the
decision for the group.
5ll of these group decision2ma!ing techniques can be applied to thegroup creatiity techniques used in the Collect >equirements process.
6. uestionnaires an' urve/s
@uestionnaires and sureys are written sets of questions designed to
quic!ly accumulate information from a large number of respondents.
@uestionnaires and/or sureys are most appropriate with aried
audiences" when a quic! turnaround is needed" when respondents are
geographically dispersed" and where statistical analysis is appropriate.
Page 15of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
16/30
Project Management Processes Scope
. )bservations
9bserations proide a direct way of iewing indiiduals in their
enironment and how they perform their jobs or tas!s and carry out
processes. $t is particularly helpful for detailed processes when the
people that use the product hae difficulty or are reluctant to articulate
their requirements. 9bseration is also !nown as Djob shadowing.E $t is
usually done e4ternally by an obserer iewing a business e4pert
performing a job. $t can also be done by a Dparticipant obsererE who
actually performs a process or procedure to e4perience how it is done to
uncoer hidden requirements.
". Protot/pes
Prototyping is a method of obtaining early feedbac! on requirements
by proiding a wor!ing model of the e4pected product before actually
building it. Since a prototype is tangible" it allows sta!eholders to
e4periment with a model of the final product rather than being limited
to discussing abstract representations of their requirements. Prototypes
support the concept of progressie elaboration in iteratie cycles of
moc!2up creation" user e4perimentation" feedbac! generation" and
prototype reision. 7hen enough feedbac! cycles hae been performed"
the requirements obtained from the prototype are sufficiently complete
to moe to a design or build phase. Storyboarding is a prototyping
technique showing sequence or naigation through a series of images or
illustrations. Storyboards are used on a ariety of projects in a ariety of
industries" such as film" adertising" instructional design" and on agile
and other software deelopment projects. $n software deelopment"
storyboards use moc!2ups to show naigation paths through 7ebPages"
screens" or other user interfaces.
#. ;enc*!arin+
+enchmar!ing inoles comparing actual or planned practices" such
as processes and operations" to those of comparable organi#ations to
identify best practices" generate ideas for improement" and proide a
basis for measuring performance. The organi#ations compared during
benchmar!ing can be internal or e4ternal.1%. Conte(t Dia+ra!s
The conte4t diagram is an e4ample of a scope model. Conte4t
diagrams isually depict the product scope by showing a business
system 'process" equipment" computer system" etc.)" and how people
and other systems 'actors) interact with it. Conte4t diagrams show
inputs to the business system" the actor's) proiding the input" the
Page 16of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
17/30
Project Management Processes Scope
outputs from the business system" and the actor's) receiing the output.
11. Docu!ent nal/sis
,ocument analysis is used to elicit requirements by analy#ing
e4isting documentation and identifying information releant to the
requirements. There are a wide range of documents that may be
analy#ed to help elicit releant requirements. 64amples of documents
that may be analy#ed include" but are not limited to: business plans"
mar!eting literature" agreements" requests for proposal" current process
Fows" logical data models" business rules repositories" application
software documentation" business process or interface documentation"
use cases" other requirements documentation" problem/issue logs"
policies" procedures" and regulatory documentation such as laws" codes"or ordinances" etc.
)utputs:1. &equire!ents Docu!entation
>equirements documentation describes how indiidual
requirements meet the business need for the project.
>equirements may start out at a high leel and become
progressiely more detailed as more about the requirements is
!nown. +efore being baselined" requirements need to beunambiguous 'measurable and testable)" traceable" complete"
consistent" and acceptable to !ey sta!eholders. The format of a
requirements document may range from a simple document
listing all the requirements categori#ed by sta!eholder and
priority" to more elaborate forms containing an e4ecutie
summary" detailed descriptions" and attachments.
Components of requirements documentation can include" but" are not
limited to:
+usiness requirements" including:
o +usiness and project objecties for traceability
o +usiness rules for the performing organi#ation and
o 8uiding principles of the organi#ation.
Sta!eholder requirements" including:
o $mpacts to other organi#ational areas
o $mpacts to other entities inside or outside the
performing organi#ation ando Sta!eholder communication and reporting
requirements.
Page 17of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
18/30
Project Management Processes Scope
Solution requirements" including:
o -unctional and nonfunctional requirements
o Technology and standard compliance requirements
o Support and training requirementso @uality requirements and
o >eporting requirements" etc. 'solution requirements
can be documented te4tually" in models" or both).
Project requirements" such as:
o 3eels of serice" performance" safety" compliance"etc. and
o 5cceptance criteria.
Transition requirements. >equirements assumptions" dependencies" and
constraints.
2. &equire!ents Traceabilit/ atri(
The requirements traceability matri4 is a grid that lin!s product
requirements from their origin to the delierables that satisfy them. The
implementation of a requirements traceability matri4 helps ensure that
each requirement adds business alue by lin!ing it to the business and
project objecties. $t proides a means to trac! requirementsthroughout the project life cycle" helping to ensure that requirements
approed in the requirements documentation are deliered at the end
of the project. -inally" it proides a structure for managing changes to
the product scope.
Tracing includes" but is not limited to" tracing requirements for the
following:
+usiness needs" opportunities" goals" and objecties
Project objecties
Project scope/7+S delierables
Product design
Product deelopment
Test strategy and test scenarios and
&igh2leel requirements to more detailed requirements.
Page 18of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
19/30
Project Management Processes Scope
5ttributes associated with each requirement can be recorded in therequirements traceability matri4. These attributes help to define !eyinformation about the requirement. Typical attributes used in therequirements traceability matri4 may include: a unique identifier" ate4tual description of the requirement" the rationale for inclusion"owner" source" priority" ersion" current status 'such as actie"cancelled" deferred" added" approed" assigned" completed)" and statusdate. 5dditional attributes to ensure that the requirement has metsta!eholders* satisfaction may include stability" comple4ity" andacceptance criteria.
This figure is a sample of a requirements traceability matrix with itsassociated attributes.
cope 7 Plannin+: Define cope
$t is the process of deeloping a detailed description of the projectand product. The preparation of a detailed project scope statement iscritical to project success and builds upon the major delierables"assumptions and constraints that are documented during projectinitiation. ,uring planning" the project scope is defined and describedwith greater specificity as more information about the project is
!nown. 64isting ris!s" assumption" and constraints are analy#ed for
Page 19of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
20/30
Project Management Processes Scope
completeness additional ris!s" assumption" and constraints areadded as necessary.
$nputs:
(. cope ana+e!ent Plan: $t is acomponent of the project management plan that establishes
the actiities for deeloping" monitoring" and controlling the
project scope.
G. Pro-ect C*arter: The project charterproides the high2leel project description and product
characteristics. $t also contains project approal
requirements. $f a project charter is not used in theperforming organi#ation" then comparable information needs
to be acquired or deeloped" and used as a basis for the
detailed project scope statement.
3. &equire!ents Docu!entation
4. )r+ani>ational Process ssets:
Policies" procedures" and templates for a project scopestatement.Project files from preious projects.3essons learned from preious phases or projects.
Tools 8 Tec*niques:
1. (pert ?u'+!ent:64pert judgment is often used to analy#e the informationneeded to deelop the project" scope statement. Such
judgment and e4pertise is applied to any technical details.Such e4pertise is proided by any group or indiidual withspeciali#ed !nowledge or training" and is aailable from manysources" including:
9ther units within the organi#ation. Consultants. Sta!eholders" including customers or sponsors. Professional and technical associations. $ndustry groups Subject matter e4perts
2. Pro'uct nal/sis:
Page 20of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
21/30
Project Management Processes Scope
-or projects that hae a product as delierable" as opposed toa serice or result" product analysis can be an effectie tool.6ach application area has one or more generally accepted
methods for translating high2leel product descriptions intotangible delierables. Product analysis includes techniquessuch as product brea!down" systems analysis" requirementsanalysis" system engineering" alue engineering" and alueengineering.
3. lternatives 0eneration:$t is a technique used to generate different approaches toe4ecute and perform the wor! of the project. 5 ariety ofgeneral management techniques can be used such asbrainstorming lateral thin!ing" pair wise comparison" etc.
4. 9acilitate' ors*ops.
)utputs:
1. Pro-ect cope tate!ent:The project scope statement describes" in details" the project*sdelierables and the wor! required to create those delierables.The project scope statement also proides a commonunderstanding of the project scope among project sta!eholder
e4pectations. $t enables the project team to perform moredetailed planning" guides the project team*s wor! duringe4ecution" and proides the baseline for ealuation whetherrequests for changes or additional wor! are contained within oroutside the project*s boundaries.The degree and leel of detail to which the project scopestatement defines the wor! that will be performed and the wor!that e4cluded can determine how well the project managementteam can control the oerall project scope. The detailed projectscope statement includes" either directly" or by reference toother documents" the following:
Product scope description: Progressiely elaborates thecharacteristics of the product" serice" or result describedin the project charter and requirements documentation.
Product acceptance criteria: ,efine the process andcriteria for accepting completed products" serices" orresults.
Project delierables ,elierables include both the outputs that comprise the
product or serice of the project" as well as ancillaryresults" such as project management reports and
Page 21of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
22/30
Project Management Processes Scope
documentation. The delierables may be described at asummary leel or in great detail.
Project e4clusions: generally identifies what is e4cluded
as from the project. 64plicitly stating what is out of scopefor the project helps to manage sta!eholders*e4pectations.
Project constraints: lists and describes the specificproject constraints associated with the project scope thatlimits the team*s options. 7hen a project is performedunder contract" contractual proisions will generally beconstraints. $nformation constraints may be listed in theproject scope statement or in a separate log.
Project assumptions: lists and describes the specificproject assumptions associated with the project scope
and the potential impact of those assumptions if theyproe to be false. Project teams frequently identify"document" and alidate assumptions as part of theirplanning process. $nformation on assumptions may belisted in the project scope statement or in a separate log.
2. Pro-ect Docu!ent =p'ates: Project documents that may be updated include:
Sta!eholder register. >equirements documentation >equirements traceability matri4.
cope 7 Plannin+: Create or ;rea'o,n tructure@;A
$t is the process of subdiiding project delierables and project wor!into smaller" more manageable component.The wor! brea!down structure '7+S) is a delierable2orientedhierarchical decomposition of the wor! to be e4ecuted by the projectteam to accomplish the project objecties and create the requireddelierables" with each descending leel of the 7+S representing anincreasing by detailed definition of the project wor!. The 7+Sorgani#es and defines the total scope of the project" and represents
Page 22of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
23/30
Project Management Processes Scope
the wor! specified in the current approed project scope statement.The planned wor! is contained within the lowest leel 7+Scomponents" which are called wor! pac!ages. 5 wor! pac!age can
scheduled" cost estimated" monitored" and controlled. $n the conte4tof the 7+S" wor! refers to wor! products or delierables that are theresult of efforts and not to the effort itself.
$nputs:
1. cope ana+e!ent Plan$t specifies how to create the 7+S from the detailed project
scope statement and how the 7+S will be maintained and
approed.
2. Pro-ect cope tate!ent$t describes the wor! that will be performed and the wor!
that is e4cluded. $t also lists and describes the specific
internal or e4ternal restrictions or limitations that may affect
the e4ecution of the project.
3. &equire!ents Docu!entation,etailed requirements documentation is essential for
understanding what needs to be produced as the result of the
project and what needs to be done to delier the project andits final products.
4. nterprise nviron!ental 9actors$ndustry2specific 7+S standards" releant to the nature of
the project" may sere as e4ternal reference sources for
creation of the 7+S. -or e4ample" engineering projects may
reference $S9/$6C (BGHH on Systems 6ngineering I System
3ife Cycle Processes J%K" to create a 7+S for a new project.
5. )r+ani>ational Process ssets: The organi#ational process assets that can influence thecreate 7+S include:
Policies" procedures" and templates for the 7+S Project files from preious projects. 3essons learned from preious projects.
Tools 8 Tec*niques:
1. Deco!position:
Page 23of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
24/30
Project Management Processes Scope
$t is the subdiision of project delierables into smaller" moremanageable components until the wor! and delierables are definedto the wor! pac!age leel. The wor! pac!age leel is lowest leel in
the 7+S" and is the point at which the cost and actiity durations forthe wor! can be reliably estimated and managed. The leel of detailfor wor! pac!ages will ary with the si#e and comple4ity of theproject.,ecomposition of the total project wor! into wor! pac!ages generallyinoles the following actiities:
$dentifying and analy#ing the delierables and relatedwor!
Structuring and organi#ing the 7+S ,ecomposing the upper 7+S leel into lower leel
detailed component
,eeloping and assigning identification codes to the 7+Scomponents
Aerifying that the degree of decomposition of the wor! isnecessary and sufficient.
The 7+S structure can be created in a number of forms" such as: 1sing phases of the project life cycle as the first leel of
decomposition" with the product and project delierablesinserted at the second leel.
1sing major delierables as the fist leel ofdecomposition.
1sing subprojects which may be deeloped byorgani#ations outside the project team" such ascontracted wor!. The seller then deelops the supportingcontract wor! brea!down structure as part of thecontracted wor!.
The 7+S can be structured as an outline" and organi#ational chart" afishbone diagram" or other method. Aerifying the correctness of thedecomposition requires determining that the lower2leel 7+Scomponents are those that are necessary and sufficient for
completion of the corresponding higher leel delierables. 5s thewor! is decomposed to greater leel of details" the ability to plan"manage" and control the wor! is enhanced. &oweer" e4cessiedecomposition can lead to non2productie management efforts"inefficient use of resources" and decreased efficiency in performingthe wor!.,ecomposition may not be possible for a delierable or subprojectthat will be accomplished far into future. The project managementteam usually waits until the delierable or subproject is clarified sothe details of the 7+S can be deeloped. This technique issometimes referred to as rolling wae planning.
2. (pert ?u'+!ent
Page 24of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
25/30
Project Management Processes Scope
64pert judgment is often used to analy#e the information needed to
decompose the project delierables down into smaller component parts
in order to create an effectie 7+S. Such judgment and e4pertise is
applied to technical details of the project*s scope and used to reconciledifferences in opinion on how to best brea! down the oerall scope of
the project. This leel of e4pertise is proided by any group or indiidual
with releant training" !nowledge" or e4perience with similar projects or
business areas. 64pert judgment can also come in the form of
predefined templates that proide guidance on how to effectiely brea!
down common delierables. Such templates may be industry or
discipline specific or may come from e4perience gained in similar
projects. The project manager" in collaboration with the project team"
then determines the final decomposition of the project scope into the
discrete wor! pac!ages that will be used to effectiely manage the wor!of the project.
)utputs:
1. cope ;aseline: $t is a component of the project management plan" and itincludes:
Project scope statement: it includes the product scope
description" the project delierables and defines theproduct user acceptance criteria. 7+S 7+S dictionary
2. Pro-ect Docu!ent =p'ates:Project document that may be updated: >equirements,ocumentation. $f approed change requests result from theCreate 7+S process" then the requirements documentationmay need to be updated to include approed changes.
cope 7 onitor B Control: ali'ate cope:
Page 25of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
26/30
Project Management Processes Scope
$t is the process of formali#ing acceptance of the completed projectdelierables. Aerifying scope includes reiewing delierables with thecustomer or sponsor to ensure that they are competed satisfactorilyand obtaining formal acceptance of delierables by customer or
sponsor.Scope erification differs from quality control in that scopeerification is primarily concerned with acceptance of thedelierables" while quality control is primarily concerned withcorrectness of the delierables and meeting the quality requirementsspecified for the delierables. @uality control is generally performedbefore scope erification" but these two processes can be performedin parallel.
$nputs:
1. Pro-ect ana+e!ent PlanThe project management plan contains the scope baseline.Components of the scope baseline include:
Project scope statement 7+S 7+S dictionary
2. &equire!ents Docu!entationThe requirements documentation lists all the project" product"
technical" and other types of requirements that must bepresent for the project and product" along with theiracceptance criteria.
3. &equire!ents Traceabilit/ atri($t lin!s requirements to their origin and trac!s themthroughout the project life cycle.
4. ali'ate' @verifie'A DeliverablesAalidated delierables hae been completed and chec!ed forcorrectness by the Perform @uality Control process.
5. or Perfor!ance Data
Page 26of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
27/30
Project Management Processes Scope
$t includes the degree of compliance with requirements" number ofnonconformities" seerity of the nonconformities" or the number ofalidation cycles performed in a period of time.
Tools 8 Tec*niques:
1. $nspection:$t includes actiities such as measuring" e4amining" and erifying todetermine whether wor! and delierables meet requirements andproduct acceptance criteria. $nspections are sometimes calledreiews" product reiews" audits" and wal!throughs. $n someapplication areas" these different terms hae narrow and specificmeaning.
2. 0roup Decision7ain+ Tec*niquesThese techniques are used to reach a conclusion when the
alidation is performed by the project team and other
sta!eholders.
)utputs:
1. ccepte' Deliverables
,elierables that meet the acceptance criteria are formallysigned off and approed by the customer or sponsor. -ormallydocumentation receied from the customer or sponsorac!nowledging formal sta!eholder acceptance of the project*sdelierables is forwarded for the Close Project or Phaseprocess.
2. C*an+e &equestsThose completed delierables that hae not been formallyaccepted are documented" along with the reasons for non2acceptance. Those delierables may require a change request
for defect repair. The change request are processed fro reiewand disposition through the Perform $ntegrated Change Controlprocess.
3. or Perfor!ance $nfor!ation7or! performance information includes information about project
progress" such as which delierables hae started" their progress"
which delierables hae finished" or which hae been accepted.
4. Pro-ect Docu!ent =p'ates
Page 27of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
28/30
Project Management Processes Scope
Project documents that may be updated as a result of theAerify Scope process include any documents that define theproduct or report status on product completion.
cope 7 onitor B Control: Control cope
$t is the process of monitoring the status of the project and productscope and managing changes to the scope baseline. Controlling theproject scope ensures all requested changes and recommendedcorrectie or preentie actions are processed through the Perform$ntegrated Change Control process.Project scope control is also used to manage the actual changeswhen they occur and is integrated with the other control processes.1ncontrolled changes are often referred to as project scope creep.
Change is ineitable" thereby mandating some type of changecontrol process.
$nputs:
1. Pro-ect ana+e!ent Plan: $t contains the following information that is used to controlscope:
Scope baseline$t is compared to actual results to determine if a change"correctie action" preentie action is necessary.
Scope management plan$t describes how the project scope will be managed andcontrolled.
Change management plan$t defines the process for managing change on theproject.
Configuration management plan$t defines those items that are configurable" those itemsthat require formal change control" and the process forcontrolling changes to such items.
>equirements management plan
Page 28of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
29/30
Project Management Processes Scope
$t can include how requirements actiities will beplanned" trac!ed" and reported and how changes to theproduct" serice" or result requirements will be initiated.
$t also describes how impacts will be analy#ed and theauthority leels required approing those changes.
2. or Perfor!ance $nfor!ation$nformation about project progress" such as which delierableshae started" their progress and which delierables haefinished.
3. &equire!ents Docu!entation
4. &equire!ents Traceabilit/ atri(
5. )r+ani>ational Process ssetsThe organi#ational process assets that can influence theControl Scope process include:
64isting formal and informal scope control2relatedpolicies" procedures" and guidelines.
Monitoring and reporting methods to be used.
Tools 8 Tec*niques:
ariance nal/sisProject performance measurements are used to assess themagnitude of ariation from the original scope baseline. $mportantaspects of project scope control include determining the cause anddegree of ariance relatie to the scope baseline and decidingwhether correctie or preentie action is required.
)utputs:
1. or Perfor!ance easure!entsMeasurements can include planned s. actual technicalperformance or other scope performance measurements. Thisinformation is documented and communicated to sta!eholders.
2. )r+ani>ational Process ssets =p'ates 9rgani#ational process assets that may be updated include:
Causes of ariances Correctie action chosen and the reasons 9ther types of lessons learned from project scope
control.
Page 29of 30
-
7/27/2019 PM Processes - REV03 - ScopeNawzad.doc
30/30
Project Management Processes Scope
3. C*an+e &equests5nalysis of scope performance can result in a change requestto the scope baseline or other components of the project
management plan. Change requests can include preentie orcorrectie actions or defect repairs. Change requests areprocessed for reiew and disposition according to the Perform$ntegrated Change Control process.
4. Pro-ect ana+e!ent Plan =p'ates Scope +aseline 1pdates $f the approed change requests hae an effect upon the
project scope" then the scope statement" the 7+S
dictionary are reised and reissued to reflect theapproed changes.
9ther +aseline 1pdates $f the approed change requests hae an effect on the
project scope" then the corresponding cost baseline andschedule baselines are reised and reissued to reflect theapproed changes.
5. Pro-ect Docu!ent =p'ates Project documents that may be updated include:
>equirements documentation >equirements traceability matri4