PM Processes - REV03 - ScopeNawzad.doc

7/27/2019 PM Processes - REV03 - ScopeNawzad.doc

1/30


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


3/30


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


4/30


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


5/30


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


6/30


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/30


(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


8/30


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


9/30


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


10/30


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


11/30


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


12/30


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


13/30


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


14/30


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.


15/30


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


16/30


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


17/30


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


18/30


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


19/30


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


20/30


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


21/30


-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


22/30


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


23/30


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


24/30


$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


25/30


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


26/30


$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


27/30


$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


28/30


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


29/30


$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


30/30


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

Documents

PM Processes - REV03 - ScopeNawzad.doc