Project Management Processes Scope

Table of Contents

Course Syllabus
1. Course Title: Project Management Processes / Project Scope Management 2. Course Level: Competency

Page 2 of 30

Project Management Processes Scope

3. Course Description: This course requires all participants to be familiar with basic Project Management theory and methodologies. This course is designed to pro ide participants with s!ills" !nowledge" tools and techniques that are utili#ed in the Project Management. $t focuses on practical s!ills and methodologies. 4. Contact Hours: % &ours ' ( day ) 5. Course Prerequisites: Participants* should be members in project management departments / units or their wor! is rele ant 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 Course )vervie,: Pro ide participants the opportunity to impro e and/or acquire the necessary !nowledge and s!ill2set in Project Management and to transform this !nowledge to actions that would benefit public ser ices. Pro ide a set of learning materials co ering range of topics in Project Management. Pro ide the participants with selected ad anced le el material in Project Management" standards and best practices.

11.

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 acti ities and e4ams to recei e credit. $f a student has a special circumstance that will pre ent him/her from attending a

Page 3 of 30

Project Management Processes Scope

schedule e4am" a ma!e2up e4am can be rescheduled at the con enience 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 pro ide a comprehensi e manual to the participants. 3ecturing will be conducted using power point presentations. 5 participatory approach will be used to facilitate learning of the participants. 64amples" case studies and practical questions/acti ities will be used.

$ntro'uction

Page 4 of 30

Project Management Processes Scope

T*e pro-ect life c/cle 5 project life cycle is collection of general sequential and sometimes o erlapping project phases whose name and number are determined by the management and control needs of the organi#ation or organi#ations in ol ed in the project" the nature of the project itself" and its area of application. 5 life cycle can be documented with a methodology. The project life cycle can be determined or shaped by the unique aspects of the organi#ation" industry or technology employed. 7hile e ery project has a definite start and a definite end" the specific deli erables and acti ities that ta!e place in between will ary widely with the project. The life cycle pro ides the basic framewor! for managing the project" regardless of the specific wor! in ol ed.

Pro-ect .ana+e!ent Processes for a Pro-ect Project management is the application of !nowledge" s!ills" tools" and techniques to project acti ities to meet project requirements. This application of !nowledge requires the effecti e management of appropriate processes. $n this framewor!" the fi e Project Management Process 8roups that required for any project are clearly identified and described. These fi e process groups ha e clear dependencies and are typically performed in the same sequence on each project. They are independent of application areas or industry focus. $ndi idual process groups* indi idual constituent processes are often iterated prior to completing the project. The constituent processes can ha e interactions within a process group and among process group. The nature of these interactions aries from project to project and may or may not be performed in a particular order.

Page 5 of 30

Project Management Processes Scope

5 process group includes the constituent project management processes that are lin!ed by the respecti e 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 acti ities performed to achie e a pre2specific product" result" or ser ice. 6ach process is characteri#ed by its inputs" the tools and techniques that can be applied" and the resulting outputs. The project manager must consider organi#ational process assets and enterprise en ironmental factors. These must be ta!en into account for e ery process" e en if they are not e4plicitly listed as inputs in the process specification. 9rgani#ational process assets pro ide guidelines and criteria for tailoring the organi#ation*s processes to the specific needs of the project. 6nterprise en ironmental factors may constrain the project management options. $n order for a project to be successful" the project team must: Select appropriate processes required to meet the project deli erables. 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" ser ice" or result. Project management processes apply globally and across industry groups. 8ood practice means there is general agreement that the application of project management processes has been shown to enhance the chances of success o er a wide range of products. This framewor! describes the nature of project management processes in terms of the integration between the processes" their interactions" and the purposes they ser e. Project management processes are grouped into fi e categories !nown as Project Management Process 8roups:

$nitiatin+ Process 0roup: Those processes performed to define a new project or a new phase of an e4isting project by obtaining authori#ation to start the project or phase. Plannin+ Process 0roup: Those processes required to establish the scope of the project" refine the objecti es" and define the course of action required to attain the objecti es that the project was underta!en to achie e.

Page 6 of 30

Project Management Processes Scope

1(ecutin+ Process 0roup: Those processes performed to complete the wor! defined in the project management plan to satisfy the project specification. .onitorin+ an' Controllin+ Process 0roup: Those processes required to trac!" re iew" and regulate the progress and performance of the project: identify any areas in which changes to the plan are required: and initiate the corresponding changes. Closin+ Process 0roup: Those Processes performed to finali#e all acti ities across all Process 8roups to formally close the project or phase.

Project Management Process Groups

Knowledge Area
Initiating Process Group Planning Process Group Executing Process Group Monitoring & Controlling Process Group 4.4 Monitor and Control Project Work., 4.5 Per orm integrated change control. Closing Process Group

Project Integration management

4.1 Develop Project Charter.

4.2 Develop project Mgmt. Plan

4.3 Direct and Manage Project work,

4.! Clo"e Project or Pha"e.

Project Scope management

5.1 Plan #cope Mgmt., 5.2 Collect re$%irement", 5.3 De ine #cope and 5.4 Create W&#.

5.5 'alidate #cope. 5.! Control #cope.

Page 7 of 30

Project Management Processes Scope

Project Time management

Project Cost management

Project Quality management

!.1 Plan #ched%le Mgmt., !.2 De ine (ctivitie". !.3 #e$%ence (ctivitie"., !.4 )"timate (ctivit* +e"o%rce"., !.5 )"timate (ctivit* D%ration" and !.! Develop #ched%le. ,.1 Plan Co"t Mgmt., ,.2 )"timate Co"t" and ,.3 Determine &%dget. -.1 Plan .%alit* Mgmt.

!., Control #ched%le.

,.4 Control Co"t".

Project Human Resource management

/.1 Plan 0+ Mgmt.

-.2 Per orm .%alit* (""%rance. /.2 (c$%ire Project 1eam., /.3 Develop Project 1eam. and /.4 Manage Project 1eam. 12.2 Manage Comm%n.

-.3 Control .%alit*.

Project Communication management

12.1 Plan Comm%n. Mgmt. 11.1 Plan +i"k Mgmt., 11.2 3denti * +i"k"., 11.3 Per orm .%alitative +i"k (nal*"i"., 11.4 Per orm .%antitative +i"k anal*"i" and 11.5 Plan +i"k +e"pon"e".

12.3 Control Comm%n.

Project Risk management

11.! Control +i"k".

Page 8 of 30

Project Management Processes Scope

Project Procurement management Project Stakehol er management 13.1 3denti * #takeholder".

12.1 Plan Proc%rement Mgmt. 13.2 Plan #takeholder" Mgmt.

12.2 Cond%ct Proc%rement. 13.3 Manage #takeholder )ngagement.

12.3 Control Proc%rement. 13.4 Control #takeholder" )ngagement.

12.4 Clo"e Proc%rement.

The abo e table reflects the mapping of the 0; project management process into fi e Project Management Process 8roups and the ten Project Management <nowledge 5reas: Pro-ect $nte+ration .ana+e!ent: $t includes the processes and acti ities needed to identify" define" combine" unify" and coordinate the arious processes and project management acti ities within the Project Management Process 8roup. Pro-ect 2cope .ana+e!ent: $t includes the processes required to ensure that the project includes all the wor! required" and only the wor! required" to complete the project successfully. Pro-ect Ti!e .ana+e!ent: $t includes the processes required to manage timely completion of the project. Pro-ect Cost .ana+e!ent: $t includes the processes in ol ed in estimating" budgeting" and controlling costs so that the project can be completed within the appro ed budget. Pro-ect 3ualit/ .ana+e!ent: $t includes the processes and acti ities of the performing organi#ation that determine quality policies" objecti es" and responsibilities so that the project will satisfy the needs for which it was underta!en. $t implements the quality management system through policy and procedures with continuous process impro ement acti ities conducted throughout" as appropriate. Pro-ect Hu!an &esource .ana+e!ent: $t includes the processes that organi#e" manage" and lead the project team. The project team is comprised of the people with assigned roles and responsibilities for completing the project. Pro-ect Co!!unication .ana+e!ent: $t includes the processes required to ensure timely and appropriate generation" collection" distribution" storage" retrie al" and ultimate disposition of project information. Pro-ect &is4 .ana+e!ent: $t includes the processes of conducting ris! management planning" identification" analysis" response planning" and monitoring = control on a project. The objecti es of Project >is! Management are to increase the probability and impact of positi e e ents" and decrease the probability and impact of negati e e ents in the project. Pro-ect Procure!ent .ana+e!ent: $t includes the processes necessary to purchase or acquire products" ser ices" or results needed from outside the project team.

Page 9 of 30

Project Management Processes Scope

Pro-ect 2ta4e*ol'ers .ana+e!ent: Project Sta!eholder Management includes the processes required to identify the people" groups" or organi#ations that could impact or be impacted by the project" to analy#e sta!eholder e4pectations and their impact on the project" and to de elop appropriate management strategies for effecti ely engaging sta!eholders in project decisions and e4ecution.

Co!!on Pro-ect .ana+e!ent Process $nteractions The project management processes are presented as discrete elements with well2defined interfaces. &owe er" in practice they o erlap 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 Process 8roup and their constituent processes are guides for applying appropriate project management !nowledge and s!ills during the project. The application of the project management processes is iterati e" and many processes are repeated during the project. The interacti e nature of project management requires the Monitoring and Controlling Process 8roup to interact with the other Process 8roups.

$n addition" since management of a project is a finite effort" the $nitiating Process 8roup begins the project" and the Closing Process 8roup ends it. Project Management Process 8roups are lin!ed by the outputs they produce. The Process 8roups are seldom either discrete or on2time e ents: they are o erlapping acti ities that occur throughout the project. The output of one process generally becomes an input to another process or is a deli erable of the project. The Planning Process 8roup pro ides the 64ecution Process 8roup with the Project Management plan and project documents" and" as the project progresses" it often entails updates to the project management plan and the project documents.

Page 10 of 30

Project Management Processes Scope

Pro-ect .ana+e!ent Process 0roups an' 5no,le'+e 6reas .appin+

Project Management Process Groups

Knowledge Area
Initiating Process Group Planning Process Group Executing Process Group Monitoring & Controlling Process Group 4.4 Monitor and Control Project Work., 4.5 Per orm integrated change control. Closing Process Group

Project Integration management

4.1 Develop Project Charter.

4.2 Develop project Mgmt. Plan

4.3 Direct and Manage Project work,

4.! Clo"e Project or Pha"e.

Project Scope management

5.1 Plan #cope Mgmt., 5.2 Collect re$%irement", 5.3 De ine #cope and 5.4 Create W&#.

5.5 'alidate #cope. 5.! Control #cope.

Page 11 of 30

Project Management Processes Scope

2cope 7 Plannin+: Collect &equire!ents

Collect requirements is the process of defining and documenting sta!eholders* needs to meet the project objecti es. The project success is directly influenced by the care ta!en in capturing and managing project and product requirements. >equirements include the quantified and documented needs and e4pectations of the sponsor" customer" and other sta!eholders. These requirements need to be elicited" analy#ed" and recorded in enough detail to be measured once project e4ecution begins. Collecting requirements is defining and managing customer e4pectations. >equirements become the foundation of the 7+S. Cost" Schedule" and quality planning are all built upon these requirements. The de elopment of the requirements begins with an analysis of the information contained in the project charter and the sta!eholder register. Many organi#ations categori#e requirements into project requirements and product requirements. Project requirements can include business requirements" project management requirements" deli ery requirements" etc. Product requirements can include information on technical requirements" security requirements" performance requirements" etc.

$nputs:
1. 2cope .ana+e!ent Plan: The scope management plan pro ides clarity as to how project teams will determine which type of requirements need to be collected for the project. 2. &equire!ents .ana+e!ent Plan: The requirements management plan pro ides the processes that will be used throughout the Collect >equirements process to define and

Page 12 of 30

Project Management Processes Scope

document the sta!eholder needs. 3. 2ta4e*ol'er .ana+e!ent Plan: The sta!eholder management plan is used to understand sta!eholder communication requirements and the le el of sta!eholder engagement in order to assess and adapt to the le el of sta!eholder participation in requirements acti ities. 4. Pro-ect C*arter: The project charter is used to pro ide the high2le el description of the product" ser ice" or result of the project so that detailed requirements can be de eloped. 5. 2ta4e*ol'er &e+ister: The sta!eholder register is used to identify sta!eholders who can pro ide information on the requirements. The sta!eholder register also captures major requirements and main e4pectations sta!eholders may ha e for the project.

Tools 8 Tec*niques:
1. $ntervie,s: 5n inter iew is a formal or informal approach to elicit 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. $nter iews are often conducted on an indi idual basis between an inter iewer and an inter iewee" but may in ol e multiple inter iewers and/or multiple inter iewees. $nter iewing e4perienced project participants" sponsors and other e4ecuti es" and subject matter e4perts can aid in identifying and defining the features and functions of the desired product deli erables. $nter iews are also useful for obtaining confidential information. 2. 9ocus 0roups: -ocus groups bring together prequalified sta!eholders and subject matter e4perts to learn about their e4pectations and attitudes about a proposed product" ser ice" or result. 5 trained moderator guides the group through an interacti e discussion" designed to be more con ersational than a one2on2one inter iew. 3. 9acilitate' :or4s*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 13 of 30

Project Management Processes Scope

functional requirements and reconciling sta!eholder differences. +ecause of their interacti e group nature" well2facilitated sessions can build trust" foster relationships" and impro e communication among the participants" which can lead to increased sta!eholder consensus. $n addition" issues can be disco ered earlier and resol ed more quic!ly than in indi idual sessions. -or e4ample" facilitated wor!shops called joint application design/de elopment '?5,) sessions are used in the software de elopment industry. These facilitated sessions focus on bringing business subject matter e4perts and the de elopment team together to impro e the software de elopment process. $n the manufacturing industry" quality function deployment '@-,) is another e4ample of a facilitated wor!shop technique that helps determine critical characteristics for new product de elopment. @-, starts by collecting customer needs" also !nown as oice of the customer 'A9C). These needs are then objecti ely sorted and prioriti#ed" and goals are set for achie ing them. 1ser stories" which are short" te4tual descriptions of required functionality" are often de eloped 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 'moti ation). 1ser stories are widely used with agile methods. 4. 0roup Creativit/ Tec*niques Se eral group acti ities can be organi#ed to identify project and product requirements. Some of the group creati ity 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 not include oting or prioriti#ation" it is often used with other group creati ity techniques that do. <o!inal +roup tec*nique. 5 technique that enhances brainstorming with a oting process used to ran! the most useful ideas for further brainstorming or for prioriti#ation.
$'ea8!in' !appin+. 5 technique in which ideas created through indi idual brainstorming sessions are consolidated into a single map to reflect commonality and differences in understanding" and generate new ideas.

Page 14 of 30

Project Management Processes Scope

6ffinit/ 'ia+ra!. 5 technique that allows large numbers of ideas to be classified into groups for re iew and analysis. .ulti7criteria 'ecision anal/sis. 5 technique that utili#es a decision matri4 to pro ide a systematic analytical approach for establishing criteria" such as ris! le els" uncertainty" and aluation" to e aluate and ran! many ideas.

5.

0roup Decision7.a4in+ Tec*niques

5 group decision2ma!ing technique is an assessment process ha ing multiple alternati es 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 e eryone 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 pro ides feedbac! regarding the responses from each round of requirements gathering. The responses are only a ailable to the facilitator to maintain anonymity. .a-orit/. 5 decision that is reached with support obtained from more than B/ C of the members of the group. &a ing a group si#e with an une en 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" e en if a majority is not achie ed. This method is generally used when the number of options nominated is more than two. Dictators*ip. $n this method" one indi idual ma!es the

decision for the group. 5ll of these group decision2ma!ing techniques can be applied to the group creati ity techniques used in the Collect >equirements process.

6. 3uestionnaires an' 2urve/s

@uestionnaires and sur eys are written sets of questions designed to quic!ly accumulate information from a large number of respondents. @uestionnaires and/or sur eys are most appropriate with aried audiences" when a quic! turnaround is needed" when respondents are geographically dispersed" and where statistical analysis is appropriate.

Page 15 of 30

Project Management Processes Scope

. )bservations
9bser ations pro ide a direct way of iewing indi iduals in their en ironment 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 ha e difficulty or are reluctant to articulate their requirements. 9bser ation is also !nown as Djob shadowing.E $t is usually done e4ternally by an obser er iewing a business e4pert performing a job. $t can also be done by a Dparticipant obser erE who actually performs a process or procedure to e4perience how it is done to unco er hidden requirements.

". Protot/pes
Prototyping is a method of obtaining early feedbac! on requirements by pro iding 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 progressi e elaboration in iterati e cycles of moc!2up creation" user e4perimentation" feedbac! generation" and prototype re ision. 7hen enough feedbac! cycles ha e been performed" the requirements obtained from the prototype are sufficiently complete to mo e to a design or build phase. Storyboarding is a prototyping technique showing sequence or na igation through a series of images or illustrations. Storyboards are used on a ariety of projects in a ariety of industries" such as film" ad ertising" instructional design" and on agile and other software de elopment projects. $n software de elopment" storyboards use moc!2ups to show na igation paths through 7ebPages" screens" or other user interfaces.

#. ;enc*!ar4in+
+enchmar!ing in ol es comparing actual or planned practices" such as processes and operations" to those of comparable organi#ations to identify best practices" generate ideas for impro ement" and pro ide 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) pro iding the input" the

Page 16 of 30

Project Management Processes Scope

outputs from the business system" and the actor's) recei ing the output.

11.

Docu!ent 6nal/sis

,ocument analysis is used to elicit requirements by analy#ing e4isting documentation and identifying information rele ant to the requirements. There are a wide range of documents that may be analy#ed to help elicit rele ant 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 indi idual requirements meet the business need for the project. >equirements may start out at a high le el and become progressi ely more detailed as more about the requirements is !nown. +efore being baselined" requirements need to be unambiguous '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 e4ecuti e summary" detailed descriptions" and attachments. Components of requirements documentation can include" but" are not limited to: +usiness requirements" including: o +usiness and project objecti es 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: and o Sta!eholder communication and reporting requirements.

Page 17 of 30

Project Management Processes Scope

Solution requirements" including: o -unctional and nonfunctional requirements: o Technology and standard compliance requirements: o Support and training requirements: o @uality requirements: and o >eporting requirements" etc. 'solution requirements can be documented te4tually" in models" or both). Project requirements" such as:

o 3e els of ser ice" performance" safety" compliance" etc.: and o 5cceptance criteria. Transition requirements. >equirements constraints. assumptions" dependencies" and

2. &equire!ents Traceabilit/ .atri(

The requirements traceability matri4 is a grid that lin!s product requirements from their origin to the deli erables 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 objecti es. $t pro ides a means to trac! requirements throughout the project life cycle" helping to ensure that requirements appro ed in the requirements documentation are deli ered at the end of the project. -inally" it pro ides 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 objecti es: Project objecti es: Project scope/7+S deli erables: Product design: Product de elopment: Test strategy and test scenarios: and &igh2le el requirements to more detailed requirements.

Page 18 of 30

Project Management Processes Scope

5ttributes associated with each requirement can be recorded in the requirements traceability matri4. These attributes help to define !ey information about the requirement. Typical attributes used in the requirements traceability matri4 may include: a unique identifier" a te4tual description of the requirement" the rationale for inclusion" owner" source" priority" ersion" current status 'such as acti e" cancelled" deferred" added" appro ed" assigned" completed)" and status date. 5dditional attributes to ensure that the requirement has met sta!eholders* satisfaction may include stability" comple4ity" and acceptance criteria. This figure is a sample of a requirements traceability matrix with its associated attributes.

2cope 7 Plannin+: Define 2cope

$t is the process of de eloping a detailed description of the project and product. The preparation of a detailed project scope statement is critical to project success and builds upon the major deli erables" assumptions and constraints that are documented during project initiation. ,uring planning" the project scope is defined and described with greater specificity as more information about the project is !nown. 64isting ris!s" assumption" and constraints are analy#ed for

Page 19 of 30

Project Management Processes Scope

completeness: additional ris!s" assumption" and constraints are added as necessary.

$nputs: (.
$t is a component of the project management plan that establishes the acti ities for de eloping" monitoring" and controlling the project scope. Pro-ect C*arter: The project charter pro ides the high2le el project description and product characteristics. $t also contains project appro al requirements. $f a project charter is not used in the performing organi#ation" then comparable information needs to be acquired or de eloped" and used as a basis for the detailed project scope statement.

2cope

.ana+e!ent

Plan:

G.

3. 4.

&equire!ents Docu!entation )r+ani>ational Process 6ssets:

Policies" procedures" and templates for a project scope statement. Project files from pre ious projects. 3essons learned from pre ious phases or projects.

Tools 8 Tec*niques: 1. 1(pert ?u'+!ent:

64pert judgment is often used to analy#e the information needed to de elop the project" scope statement. Such judgment and e4pertise is applied to any technical details. Such e4pertise is pro ided by any group or indi idual with speciali#ed !nowledge or training" and is a ailable from many sources" 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 6nal/sis:

Page 20 of 30

Project Management Processes Scope

-or projects that ha e a product as deli erable" as opposed to a ser ice or result" product analysis can be an effecti e tool. 6ach application area has one or more generally accepted methods for translating high2le el product descriptions into tangible deli erables. Product analysis includes techniques such as product brea!down" systems analysis" requirements analysis" system engineering" alue engineering" and alue engineering.

3. 6lternatives 0eneration:
$t is a technique used to generate different approaches to e4ecute and perform the wor! of the project. 5 ariety of general management techniques can be used such as brainstorming lateral thin!ing" pair wise comparison" etc.

4. 9acilitate' :or4s*ops. )utputs: 1. Pro-ect 2cope 2tate!ent:

The project scope statement describes" in details" the project*s deli erables and the wor! required to create those deli erables. The project scope statement also pro ides a common understanding of the project scope among project sta!eholder e4pectations. $t enables the project team to perform more detailed planning" guides the project team*s wor! during e4ecution" and pro ides the baseline for e aluation whether requests for changes or additional wor! are contained within or outside the project*s boundaries. The degree and le el of detail to which the project scope statement defines the wor! that will be performed and the wor! that e4cluded can determine how well the project management team can control the o erall project scope. The detailed project scope statement includes" either directly" or by reference to other documents" the following: Product scope description: Progressi ely elaborates the characteristics of the product" ser ice" or result described in the project charter and requirements documentation. Product acceptance criteria: ,efine the process and criteria for accepting completed products" ser ices" or results. Project deli erables ,eli erables include both the outputs that comprise the product or ser ice of the project" as well as ancillary results" such as project management reports and

Page 21 of 30

Project Management Processes Scope

documentation. The deli erables may be described at a summary le el or in great detail. Project e4clusions: generally identifies what is e4cluded as from the project. 64plicitly stating what is out of scope for the project helps to manage sta!eholders* e4pectations. Project constraints: lists and describes the specific project constraints associated with the project scope that limits the team*s options. 7hen a project is performed under contract" contractual pro isions will generally be constraints. $nformation constraints may be listed in the project scope statement or in a separate log. Project assumptions: lists and describes the specific project assumptions associated with the project scope and the potential impact of those assumptions if they pro e to be false. Project teams frequently identify" document" and alidate assumptions as part of their planning process. $nformation on assumptions may be listed 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.

2cope 7 Plannin+: Create :or4 ;rea4'o,n 2tructure @:;2A

$t is the process of subdi iding project deli erables and project wor! into smaller" more manageable component. The wor! brea!down structure '7+S) is a deli erable2oriented hierarchical decomposition of the wor! to be e4ecuted by the project team to accomplish the project objecti es and create the required deli erables" with each descending le el of the 7+S representing an increasing by detailed definition of the project wor!. The 7+S organi#es and defines the total scope of the project" and represents

Page 22 of 30

Project Management Processes Scope

the wor! specified in the current appro ed project scope statement. The planned wor! is contained within the lowest le el 7+S components" which are called wor! pac!ages. 5 wor! pac!age can scheduled" cost estimated" monitored" and controlled. $n the conte4t of the 7+S" wor! refers to wor! products or deli erables that are the result of efforts and not to the effort itself.

$nputs:
1. 2cope .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 appro ed. 2. Pro-ect 2cope 2tate!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 deli er the project and its final products. 4. 1nterprise 1nviron!ental 9actors $ndustry2specific 7+S standards" rele ant to the nature of the project" may ser e 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 6ssets:

The organi#ational process assets that can influence the create 7+S include: Policies" procedures" and templates for the 7+S Project files from pre ious projects. 3essons learned from pre ious projects.

Tools 8 Tec*niques: 1. Deco!position:

Page 23 of 30

Project Management Processes Scope

$t is the subdi ision of project deli erables into smaller" more manageable components until the wor! and deli erables are defined to the wor! pac!age le el. The wor! pac!age le el is lowest le el in the 7+S" and is the point at which the cost and acti ity durations for the wor! can be reliably estimated and managed. The le el of detail for wor! pac!ages will ary with the si#e and comple4ity of the project. ,ecomposition of the total project wor! into wor! pac!ages generally in ol es the following acti ities: $dentifying and analy#ing the deli erables and related wor! Structuring and organi#ing the 7+S ,ecomposing the upper 7+S le el into lower le el detailed component ,e eloping and assigning identification codes to the 7+S components Aerifying that the degree of decomposition of the wor! is necessary 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 le el of decomposition" with the product and project deli erables inserted at the second le el. 1sing major deli erables as the fist le el of decomposition. 1sing subprojects which may be de eloped by organi#ations outside the project team" such as contracted wor!. The seller then de elops the supporting contract wor! brea!down structure as part of the contracted wor!. The 7+S can be structured as an outline" and organi#ational chart" a fishbone diagram" or other method. Aerifying the correctness of the decomposition requires determining that the lower2le el 7+S components are those that are necessary and sufficient for completion of the corresponding higher le el deli erables. 5s the wor! is decomposed to greater le el of details" the ability to plan" manage" and control the wor! is enhanced. &owe er" e4cessi e decomposition can lead to non2producti e management efforts" inefficient use of resources" and decreased efficiency in performing the wor!. ,ecomposition may not be possible for a deli erable or subproject that will be accomplished far into future. The project management team usually waits until the deli erable or subproject is clarified so the details of the 7+S can be de eloped. This technique is sometimes referred to as rolling wa e planning.

2. 1(pert ?u'+!ent

Page 24 of 30

Project Management Processes Scope

64pert judgment is often used to analy#e the information needed to decompose the project deli erables down into smaller component parts in order to create an effecti e 7+S. Such judgment and e4pertise is applied to technical details of the project*s scope and used to reconcile differences in opinion on how to best brea! down the o erall scope of the project. This le el of e4pertise is pro ided by any group or indi idual with rele ant training" !nowledge" or e4perience with similar projects or business areas. 64pert judgment can also come in the form of predefined templates that pro ide guidance on how to effecti ely brea! down common deli erables. 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 effecti ely manage the wor! of the project.

)utputs:
1. 2cope ;aseline: $t is a component of the project management plan" and it includes: Project scope statement: it includes the product scope description" the project deli erables and defines the product user acceptance criteria. 7+S 7+S dictionary 2. Pro-ect Docu!ent =p'ates: Project document that may be updated: >equirements ,ocumentation. $f appro ed change requests result from the Create 7+S process" then the requirements documentation may need to be updated to include appro ed changes.

2cope 7 .onitor B Control: Cali'ate 2cope:

Page 25 of 30

Project Management Processes Scope

$t is the process of formali#ing acceptance of the completed project deli erables. Aerifying scope includes re iewing deli erables with the customer or sponsor to ensure that they are competed satisfactorily and obtaining formal acceptance of deli erables by customer or sponsor. Scope erification differs from quality control in that scope erification is primarily concerned with acceptance of the deli erables" while quality control is primarily concerned with correctness of the deli erables and meeting the quality requirements specified for the deli erables. @uality control is generally performed before scope erification" but these two processes can be performed in parallel.

$nputs: 1. Pro-ect .ana+e!ent Plan

The 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!entation
The requirements documentation lists all the project" product" technical" and other types of requirements that must be present for the project and product" along with their acceptance criteria.

3. &equire!ents Traceabilit/ .atri(

$t lin!s requirements to their origin and trac!s them throughout the project life cycle.

4. Cali'ate' @verifie'A Deliverables

Aalidated deli erables ha e been completed and chec!ed for correctness by the Perform @uality Control process.

5. :or4 Perfor!ance Data

Page 26 of 30

Project Management Processes Scope

$t includes the degree of compliance with requirements" number of nonconformities" se erity of the nonconformities" or the number of alidation cycles performed in a period of time.

Tools 8 Tec*niques: 1. $nspection:

$t includes acti ities such as measuring" e4amining" and erifying to determine whether wor! and deli erables meet requirements and product acceptance criteria. $nspections are sometimes called re iews" product re iews" audits" and wal!throughs. $n some application areas" these different terms ha e narrow and specific meaning.

2. 0roup Decision7.a4in+ Tec*niques

These techniques are used to reach a conclusion when the alidation is performed by the project team and other sta!eholders.

)utputs: 1. 6ccepte' Deliverables

,eli erables that meet the acceptance criteria are formally signed off and appro ed by the customer or sponsor. -ormally documentation recei ed from the customer or sponsor ac!nowledging formal sta!eholder acceptance of the project*s deli erables is forwarded for the Close Project or Phase process.

2. C*an+e &equests
Those completed deli erables that ha e not been formally accepted are documented" along with the reasons for non2 acceptance. Those deli erables may require a change request for defect repair. The change request are processed fro re iew and disposition through the Perform $ntegrated Change Control process.

3. :or4 Perfor!ance $nfor!ation

7or! performance information includes information about project progress" such as which deli erables ha e started" their progress" which deli erables ha e finished" or which ha e been accepted.

4. Pro-ect Docu!ent =p'ates

Page 27 of 30

Project Management Processes Scope

Project documents that may be updated as a result of the Aerify Scope process include any documents that define the product or report status on product completion.

2cope 7 .onitor B Control: Control 2cope

$t is the process of monitoring the status of the project and product scope and managing changes to the scope baseline. Controlling the project scope ensures all requested changes and recommended correcti e or pre enti e actions are processed through the Perform $ntegrated Change Control process. Project scope control is also used to manage the actual changes when they occur and is integrated with the other control processes. 1ncontrolled changes are often referred to as project scope creep. Change is ine itable" thereby mandating some type of change control process.

$nputs: 1. Pro-ect .ana+e!ent Plan:

$t contains the following information that is used to control scope: Scope baseline $t is compared to actual results to determine if a change" correcti e action" pre enti e action is necessary. Scope management plan $t describes how the project scope will be managed and controlled. Change management plan $t defines the process for managing change on the project. Configuration management plan $t defines those items that are configurable" those items that require formal change control" and the process for controlling changes to such items. >equirements management plan

Page 28 of 30

Project Management Processes Scope

$t can include how requirements acti ities will be planned" trac!ed" and reported and how changes to the product" ser ice" or result requirements will be initiated. $t also describes how impacts will be analy#ed and the authority le els required appro ing those changes.

2. :or4 Perfor!ance $nfor!ation

$nformation about project progress" such as which deli erables ha e started" their progress and which deli erables ha e finished.

3. &equire!ents Docu!entation 4. &equire!ents Traceabilit/ .atri( 5. )r+ani>ational Process 6ssets

The organi#ational process assets that can influence the Control Scope process include: 64isting formal and informal scope control2related policies" procedures" and guidelines. Monitoring and reporting methods to be used.

Tools 8 Tec*niques: Cariance 6nal/sis

Project performance measurements are used to assess the magnitude of ariation from the original scope baseline. $mportant aspects of project scope control include determining the cause and degree of ariance relati e to the scope baseline and deciding whether correcti e or pre enti e action is required.

)utputs: 1. :or4 Perfor!ance .easure!ents

Measurements can include planned s. actual technical performance or other scope performance measurements. This information is documented and communicated to sta!eholders.

2. )r+ani>ational Process 6ssets =p'ates

9rgani#ational process assets that may be updated include: Causes of ariances Correcti e action chosen and the reasons 9ther types of lessons learned from project scope control.

Page 29 of 30

Project Management Processes Scope

3. C*an+e &equests
5nalysis of scope performance can result in a change request to the scope baseline or other components of the project management plan. Change requests can include pre enti e or correcti e actions or defect repairs. Change requests are processed for re iew and disposition according to the Perform $ntegrated Change Control process.

4. Pro-ect .ana+e!ent Plan =p'ates

Scope +aseline 1pdates $f the appro ed change requests ha e an effect upon the project scope" then the scope statement" the 7+S dictionary are re ised and reissued to reflect the appro ed changes. 9ther +aseline 1pdates $f the appro ed change requests ha e an effect on the project scope" then the corresponding cost baseline and schedule baselines are re ised and reissued to reflect the appro ed changes.

5. Pro-ect Docu!ent =p'ates

Project documents that may be updated include: >equirements documentation >equirements traceability matri4

Page 30 of 30