JS

Wednesday, June 30, 2021

PROJECT SCOPE MANAGEMENT | FAQ | PMBOK GUIDE 6th Edition | 2021

FAQ 

Frequently Asked Question 


PMBOK GUIDE 6th Edition: 

Chapter 05 PROJECT SCOPE MANAGEMENT


Pertanyaan (silahkan dijawab dan masing2nya merujuk ke halaman berapa di PMBOK):


1. Apakah objective dari Project Scope Management? Jelaskan perbedaan antara Product Scope dengan Project Scope.  

Objective: 

Project Scope Management includes the processes required to ensure that the project includes all the work required,

and only the work required, to complete the project successfully. Managing the project scope is primarily concerned with

defining and controlling what is and is not included in the project.

 

Page 129 


Differences Product Scope vs Project Scope:

  • Product scope. The features and functions that characterize a product, service, or result.

  • Project scope. The work performed to deliver a product, service, or result with the specified features and functions. The term “project scope” is sometimes viewed as including product scope.

Page 131

 


 

2. Sebutkan perbedaan dalam Scope Management, antara lifecycle project Predictive dengan Adaptive/Agile. Faktor apa saja yang perlu dipertimbangkan sehingga metode Agile dapat diterapkan? 

 

The difference in Scope Management; Life cycle project predictive vs Adaptive/Agile Project Life Cycle:

The project life cycle determines the series of phases that a project passes through from its inception to the end of the project. 

 

Project life cycles can range along a continuum from predictive approaches at one end to adaptive or agile approaches

at the other. 

  • In a predictive life cycle, the project deliverables are defined at the beginning of the project and any changes to the scope are progressively managed. 

  • In an adaptive or agile life cycle, the deliverables are developed over multiple iterations where a detailed scope is defined and approved for each iteration when it begins.

 page.131

 

3. Apakah pengertian dari Requirement? Apa bedanya Product Requirement dengan Project Scope? 

 

Requirement. A condition or capability that is necessary to be present in a product, service, or result to satisfy a business need.

Page 719.


Product requirement vs project scope :

Scope : The scope management plan contains information on how the project scope will be defined and developed

Requirement : The requirements management plan has information on how project requirements will be collected, analyzed, and documented

Page. 140

 

4. Apakah pengertian product Backlog? Apa bedanya dengan requirement? 

Product Backlog. An ordered list of user-centric requirements that a team maintains for a product

Page 153


Requirement. A condition or capability that is necessary to be present in a product, service, or result to satisfy a business need.

Page 719.


 

5. Bagian apa dari Project Charter dan Project Management Plan yang dapat membantu proses Plan Scope Management? Mengapa? 


Bagian dari project charter yang dapat membantu plan scope management:

The project charter documents the project purpose, high-level project description,

assumptions, constraints, and high-level requirements that the project is intended to satisfy.

Page.145


Bagian dari project management plan yang dapat membantu plan scope management:

  • Quality management plan. Described in Section 8.1.3.1. The way the project and product scope will be managed can be influenced by how the organization’s quality policy, methodologies, and standards are implemented on the project.

  • Project life cycle description. The project life cycle determines the series of phases that a project passes through from its inception to the end of the project.

  • Development approach. The development approach defines whether waterfall, iterative, adaptive, agile, or a hybrid development approach will be used.

 Page.135


Karena List tersebut sebagai inputs dari plan scope management

6. Apa bedanya Scope Management Plan dengan Requirement Management Plan? 

Scope Management plan :

The scope management plan is a component of the project management plan that describes how the scope will be defined, developed, monitored, controlled, and validated. The components of a scope management plan include:

  • Process for preparing a project scope statement;

  • Process that enables the creation of the WBS from the detailed project scope statement;

  • Process that establishes how the scope baseline will be approved and maintained; and

  • Process that specifies how formal acceptance of the completed project deliverables will be obtained.

The scope management plan can be formal or informal, broadly framed or highly detailed, based on the needs of the project.

 Page 137


Requirement Management Plan :

The requirements management plan is a component of the project management plan that describes how project and product requirements will be analyzed, documented, and managed. According to Business Analysis for Practitioners: A Practice Guide [7], some organizations refer to it as a business analysis plan. Components of the requirements management plan can include but are not limited to:

  • How requirements activities will be planned, tracked, and reported;

  • Configuration management activities such as: how changes will be initiated; how impacts will be analyzed; how they will be traced, tracked, and reported; as well as the authorization levels required to approve these changes;

  • Requirements prioritization process;

  • Metrics that will be used and the rationale for using them; and

  • Traceability structure that reflects the requirement attributes captured on the traceability matrix.


Page.137


7. Apakah objective dari proses Collect Requirements? Bagaimana input-input Collect Requirements dapat membantu proses tersebut? 

Collect Requirements is the process of determining, documenting, and managing stakeholder needs and requirements to meet objectives. The key benefit of this process is that it provides the basis for defining the product scope and project scope. This process is performed once or at predefined points in the project.


Objective = The key benefit 

Provides the basis for defining the product scope and project scope


Page.138


Bagaimana input dapat membantu proses nya:

These requirements need to be elicited, analyzed, and recorded in enough detail to be included in the

scope baseline and to be measured once project execution begins. Requirements become the foundation of the WBS. Cost, schedule, quality planning, and procurement are all based on these requirements.


8. Sebutkan dan jelaskan teknik-teknik Decision Making. Dalam menentukan keputusan berdasarkan Voting, terdapat istilah Majority dan Plurarity, apa bedanya? 


Teknik decision making:

  • Voting. Voting is a collective decision-making technique and an assessment process having multiple alternatives with an expected outcome in the form of future actions. These techniques can be used to generate, classify, and prioritize product requirements. Examples of voting techniques include:

    • Unanimity. A decision that is reached whereby everyone agrees on a single course of action.

    • Majority. A decision that is reached with support obtained from more than 50% of the members of the group. Having a group size with an uneven number of participants can ensure that a decision will be reached, rather than resulting in a tie.

    • Plurality. A decision that is reached whereby the largest block in a group decides, even if a majority is not achieved. This method is generally used when the number of options nominated is more than two.

  • Autocratic decision making. In this method, one individual takes responsibility for making the decision for the group.

  • Multicriteria decision analysis. A technique that uses a decision matrix to provide a systematic analytical approach for establishing criteria, such as risk levels, uncertainty, and valuation, to evaluate and rank many ideas.


Majority vs Plurarity :

  • Majority. A decision that is reached with support obtained from more than 50% of the members of the group. Having a group size with an uneven number of participants can ensure that a decision will be reached, rather than resulting in a tie.

  • Plurality. A decision that is reached whereby the largest block in a group decides, even if a majority is not achieved. This method is generally used when the number of options nominated is more than two.

Perbedaanya di reached support, see above description.

Page.144


9. Bagimana mengaplikasikan Tools di bawah ini dalam proses Collect Requirements? 

a. Affinity Diagrams 

Affinity diagrams allow large numbers of ideas to be classified into groups for review and analysis.

b. Mind Mapping 

Mind mapping consolidates ideas created through individual brainstorming sessions into a

single map to reflect commonality and differences in understanding and to generate new ideas.

c. Nominal Group Technique 

The nominal group technique enhances brainstorming with a voting process used

to rank the most useful ideas for further brainstorming or for prioritization. The nominal group technique is a structured form of brainstorming consisting of four steps:

  • A question or problem is posed to the group. Each person silently generates and writes down their ideas.

  • The moderator writes down the ideas on a flip chart until all ideas are recorded.

  • Each recorded idea is discussed until all group members have a clear understanding.

  • Individuals vote privately to prioritize the ideas, usually using a scale of 1 – 5, with 1 being the lowest and 5 being the highest. Voting may take place in many rounds to reduce and focus in on ideas. After each round, the votes are tallied and the highest scoring ideas are selected.


d. Job Shadowing 

It is usually done externally by an observer viewing a business expert performing a job.

e. Participant Observer 

Who actually performs a process or procedure to experience how it is done to uncover hidden requirements.


Cara mengaplikasikannya dengan menyesuaikan keadaan dan kondisi sesuai dengan project dengan menggunakan salah satu dari tools tersebut.


Page.144-145


10. Apa perbedaan Requirements Documentation dengan Requirements Traceability Matrix? 

Requirements Documentation

Describes how individual requirements meet the business need for the project. Requirements may start out at a high level and become progressively more detailed as more information about the requirements is known. Before being baselined, requirements need to be unambiguous (measurable and testable), traceable, complete, consistent, and acceptable to key stakeholders. The format of the requirements document may range from a simple document listing all the requirements categorized by stakeholder and priority, to more elaborate forms containing an executive summary, detailed descriptions, and attachments.


Requirements Traceability Matrix

Is a grid that links product requirements from their origin to the deliverables that satisfy them. The implementation of a requirements traceability matrix helps ensure that each requirement adds

business value by linking it to the business and project objectives. It provides a means to track requirements throughout the project life cycle, helping to ensure that requirements approved in the requirements documentation are delivered at the end of the project. Finally, it provides a structure for managing changes to the product scope.


Page.148


11. Apakah pengertian Scope Baseline? Apa saja isi dari Scope Baseline? 

The scope baseline is the approved version of a scope statement, WBS, and its associated WBS dictionary, which can be changed only through formal change control procedures and is used as a basis for comparison. It is a component of the project management plan.


Components of the scope baseline include:

  • Project scope statement. The project scope statement includes the description of the project scope, major deliverables, assumptions, and constraints (Section 5.3.3.1).

  • WBS. The WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. Each descending level of the WBS represents an increasingly detailed definition of the project work.

  • Work package. The lowest level of the WBS is a work package with a unique identifier. These identifiers provide a structure for hierarchical summation of costs, schedule, and resource information and form a code of accounts. Each work package is part of a control account. A control account is a management control point where scope, budget, and schedule are integrated and compared to the earned value for performance measurement. A control account has two or more work packages, though each work package is associated with a single control account.

  • Planning package. A control account may include one or more planning packages. A planning package is a work breakdown structure component below the control account and above the work package with known work content but without detailed schedule activities.

Page.161


12. Apakah perbedaan Project Scope Statement yang dihasilkan Define Scope dengan yang dihasilkan Create WBS dalam Scope Baseline? 

Project Scope Statement (Define Scope) vs Create WBS(Scope Baseline)

The project scope statement 

Is the description of the project scope, major deliverables, assumptions, and constraints. The project scope statement documents the entire scope, including project and product scope. It describes the project’s deliverables in detail. It also provides a common understanding of the project scope among project stakeholders. It may contain explicit scope exclusions that can assist in managing stakeholder expectations. It enables the project team to perform more detailed planning, guides the project team’s work during execution, and provides the baseline for evaluating whether requests for changes or additional work are contained within or outside the project’s boundaries.


Create WBS 

The WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. Each descending level of the WBS represents an increasingly detailed definition of the project work.


Perbedaanya: project’s deliverables in detail vs detailed definition of the project work


Page.154-161


13. Apakah pengertian dari WBS Dictionary? Perlukah WBS dictionary dibuat jika WBS sudah ada, mengapa? 

WBS dictionary. The WBS dictionary is a document that provides detailed deliverable, activity, and scheduling information about each component in the WBS. The WBS dictionary is a document that supports the WBS. Most of the information included in the WBS dictionary is created by other processes and added to this document at a later stage. Information in the WBS dictionary may include but is not limited to:

  • Code of account identifier,

  • Description of work,

  • Assumptions and constraints,

  • Responsible organization,

  • Schedule milestones,

  • Associated schedule activities,

  • Resources required,

  • Cost estimates,

  • Quality requirements,

  • Acceptance criteria,

  • Technical references, and

  • Agreement information.


Perlunya WBS dictionary meski WBS ada:

The WBS dictionary is a document that supports the WBS. Most of the information included in the WBS dictionary is created by other processes and added to this document at a later stage. 


Tanpa WBS dictionary, tidak ada yang support WBS.


Page.162


14. Apakah objective dari proses Validate Scope? Mengapa WPD masuk sebagai input Validate Scope? 

Validate Scope is the process of formalizing acceptance of the completed project deliverables. The key benefit of this process is that it brings objectivity to the acceptance process and increases the probability of final product, service, or result acceptance by validating each deliverable. This process is performed periodically throughout the project as needed.


Objective proses validate scope: Formalizing acceptance of the completed project deliverables


Mengapa WPD masuk sebagai input validate scope:

Cause WPD includes the degree of compliance with requirements, number

of nonconformities, the severity of the nonconformities, or the number of validation cycles performed in a period of time. That needed by Validate Scope.


Page.163-165


15. Apakah ada hubungan urutan antara Validate Scope dengan Control Scope? Jika ada, mana yang lebih dulu? 

Secara proses validate scope lebih dahulu dibanding control karena:


  • Validate Scope is the process of formalizing acceptance of the completed project deliverables

  • Control Scope is the process of monitoring the status of the project and product scope and managing changes to the scope baseline


Namun kedua proses ini saling berhubungan dan saling cross check satu sama lain, untuk completed project deliverable yang lebih bak sesuai plan.


Page 163 dan 167


16. Apakah perbedaan Verified Deliverables dengan Accepted Deliverables? 

Verified deliverables: Are project deliverables that are completed and checked for correctness through the Control Quality process.

Accepted Deliverables: Deliverables that meet the acceptance criteria are formally signed off and approved by the customer or sponsor.


Page.165-166


17. Gambarkan storyline Scope dan Storyline Requirement.





No comments:

Post a Comment