Scope Management - thắc mắc và giải đáp

demigarcon

Nhà truyền đạo
Các ACE có ai giải thích dùm demi phần "decomposition" với, tiếng Việt càng dễ hiểu hơn. Đọc mà chẳng hiểu nó muốn nói gì, nếu có ví dụ để dễ tưởng tượng luôn thì càng tốt, thanks nhiều nha.
 

ductamftu

Well-known member
decomposition = "Phân hoạch"

Đây là kỹ thuật được dùng khá phổ biến để phân rã các thành phần lớn thành các thành phần nhỏ hơn tới một mức độ nào đó (có thể ước lượng được, có thể nhìn thấy được ...)

Ví dụ:


Hình vẽ là ví dụ về một dự án phần mềm, việc phân hoạch được dừng lại tới khi ra được các gói Client, Server, Documentation, Training ---> Có thể ước lượng được chi phí, thời gian hoàn thành!

Trong Scope Management, việc tạo WBS dùng kỹ thuật này sẽ chia dự án ra thành các Deliverable, Deliverable nhỏ hơn, các Sub-Project, rồi tới các Work package. Tới Work package thì có thể ước lượng được chi phí và thời gian để hoàn thành ---> End.

Hy vọng "thiển ý" của em có thể giúp bác được chút nào. Có gì khiếm khuyết thì bác chỉ giáo giúp nhé!
 

ThanhLE

Super Moderator
Decomposition: phân rã, chia nhỏ. Giải thích giống ductamftu thoai.
 

demigarcon

Nhà truyền đạo
Thanks ductamftu và ThanhLE nhiều, có tiếng Việt tự nhiên dễ hiểu hẳn ra, hehe. Vậy cái tool ở đây là phân chia WBS thành các work package nhỏ đủ để tính chi phí và thời gian hoàn thành.
 

gauto988

Well-known member
Mọi người làm ơn giải thích cho mình các thành phần trong Scope documentation này với:

Components of requirements documentation can include, but, are not limited to:
• Business requirements, including:
○○ Business and project objectives for traceability;
○○ Business rules for the performing organization; and
○○ Guiding principles of the organization.

• Stakeholder requirements, including:
○○ Impacts to other organizational areas;
○○ Impacts to other entities inside or outside the performing organization; and
○○ Stakeholder communication and reporting requirements.

• Solution requirements, including:
○○ Functional and nonfunctional requirements;
○○ Technology and standard compliance requirements;
○○ Support and training requirements;
○○ Quality requirements; and
○○ Reporting requirements, etc. (solution requirements can be documented textually, in models,
or both).

• Project requirements, such as:
○○ Levels of service, performance, safety, compliance, etc.; and
○○ Acceptance criteria.
• Transition requirements.
• Requirements assumptions, dependencies, and constraints.
 

Thuy Men

Well-known member
[MENTION=1362]gauto988[/MENTION]: Chưa hiểu rõ ý em hỏi ở đây.

Theo chị phán đoán có khả năng 1 số option sau:
- Ko hiểu tại sao chiwa theo hướng các nhóm này
- Chưa hiểu ý nghĩa từng nhóm
- Chưa hiểu 1 nhóm nào đó trong đây
- Chưa hiểu 1 nội dung cụ thể trong 1 nhóm nào đó
 

gauto988

Well-known member
Hi chị,
Em không hiểu tại sao lại chia theo các nhóm này ạ. Em hiểu là requirement documentation sẽ ghi nhận các requirement của stakeholder đến project, product, nhưng không hiểu tại sao lại chia thành các nhóm nhỏ này?
 
Sửa lần cuối:

gin

Well-known member
mình nghĩ chỉ có Business Requirement và Stakeholder requirement là 2 Requirement chính chi phối, rồi từ đó đẻ ra tất cả các requirment còn lại. họ list ra vậy mang tính chất liệt kê chứ ko có tính cấu trúc tầng lớp.
 

trieuchau

Nhà truyền đạo
[MENTION=1362]gauto988[/MENTION]: không có term "Scope documentation" trong PMBOK nhé em. Đây là các components của requirements documentation, và requirements documentation là một phần của project document. Họ phân chia ra các loại requirements documentation khác nhau như vậy để dễ phân biệt và follow up về sau. Quan trọng nhất là requirements documentation sẽ mô tả "how individual requirements meet the business need for the project" và chúng ta cần phải biết "balance stakeholders' requirements" dựa trên business case, project charter, project scope statements (if available), project constraints nếu cần prioritize competing requirements.
 

gauto988

Well-known member
Em nhầm em nhầm, vì đang đọc scope nên em bị loạn tí anh ạ. Requirement documentation ạ
 

Hai

Member
Có nhiều process/ tool có định nghĩa, chức năng na ná nhau, mà em mới học HF chưa nắm chắc structure. Cả nhà phân biệt giùm em WBS Dictionary và Scope Statement với. Xin đa tạ m(_)m .
 

Thuy Men

Well-known member
Tớ ko hiểu ý bạn [MENTION=28862]Hai[/MENTION] định hỏi chi tiết thế nào. Rõ ràng trong sách PMBok nói rất rõ bản chất của 2 tài liệu này rùi mà.

Nếu có thể bạn nói rõ nội dung chi tiết được không?
 

Hai

Member
hic, sent xong bị error bay hết trơn >_< .

hi [MENTION=25971]Thuy Men[/MENTION], Theo mình hiểu thì scope statement & WBS diary đều là describe project scope, requirement, resources, criteria, constraints..
WBS diary thì chắc là chi tiết hơn vào các work package và có account ? :( . Ví dụ 2 cái này ở HF khá giống nhau và mình thấy WBS diary không chỉ rõ ra WP nên thấy hơi thắc mắc chút.

Anw, theo mình hiểu thì Scope statement -> WBS-> WBS Diary ( không nhớ rõ input lắm, nhưng chắc order là vậy :p ) . 3 đứa này gộp lại ra Scope Baseline. Scope statement đã identify Scope , WBS diary nhắc lại và chi tiết hơn vào milestone schedule & cost, vậy cần Scope baseline nữa làm gì ta ? trong HF cũng không thấy ví dụ về Scope Baseline, nên thắc mắc tập 2 :p

Mình mới đang đọc HF thôi, chưa có đụng đến PMPBOK hiz. Định đọc xong HF rồi mới đụng đến mấy món khác, thắc mắc của newbie nên có gì mọi người thông cảm .. m(_)m
btw, Process /subsidiary plan nhiều quá mà mỗi lần có changes đi update ngược lại chắc cũng hơi bị đuối :(
 

trieuchau

Nhà truyền đạo
[MENTION=28862]Hai[/MENTION]: WBS dictionary mới đúng, không có term WBS diary

Quay lại với định nghĩa trong PMBOK sẽ chính xác nhất, các cuốn sách khác nếu khác PMBOK thì cần phải tuân theo PMBOK.

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, in detail, the project’s deliverables and the work required to create those deliverables. 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. The detailed project scope statement, either directly, or by reference to other documents, includes the following:
- Product scope description
- Acceptance criteria
- Deliverable
- Project exclusion
- Constraints
- Assumptions.


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. The WBS is finalized by assigning each work package to a control account and establishing a unique identifier for that work package from a code of accounts. These identifiers provide a structure for hierarchical summation of costs, schedule, and resource information. A control account is a management control point where scope, budget, actual cost, and schedule are integrated and compared to the earned value for performance measurement. Control accounts are placed at selected management points in the WBS. Each control account may include one or more work packages, but each of the work packages should be associated with only one control account. A control account may include one or more planning packages. A planning package is a work breakdown structure component below the control account with known work content but without detailed schedule activities.


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


Do đó, scope statement & WBS dictionary KHÔNG phải đều describe project scope, requirement, resources, criteria, constraints.... (xem định nghĩa ở trên). WBS dictionary cung cấp các chi tiết về WBS (xem định nghĩa ở trên). ...

Đọc Head First sẽ giúp bạn có cái nhìn tổng quát về PMP và dễ hình dung & tiếp thu vì Head First trình bày theo phương pháp mindmap. Các kiến thức chuyên sâu và chính xác hơn thì cần tham khảo Rita và đặc biệt là PMBOK.
 

Hai

Member
Thanks @Trieu chau , mình định nghiền thật kĩ HF trước rồi mới qua PMPBOK, nhưng kiểu này chắc phải thay đổi cách học một chút rồi
 

trieuchau

Nhà truyền đạo
[MENTION=28862]Hai[/MENTION]: cứ đọc trước HF đi, vì HF sẽ giúp mình có overview về PMP và dễ tiếp thu. Sau đó có thể đọc Rita; rồi đọc PMBOK cuối cùng. Mình cũng đang hướng dẫn cho các học viên của LIPROF theo thứ tự như vậy, và kết quả là rất tốt.
 

tegiac

Member
Theo mình hiểu thì:

Scope baseline là tên chung để gọi tổng hợp (Scope statement + WBS + WBS dictionary).

Sau khi đã collect requirement từ stakeholders xong, Project team sẽ quyết định những requirement nào của stakeholders sẽ được thực hiện, requirement nào sẽ được bỏ qua => scope statement, sau đó phân rã các scope này ra => WBS, ở WBS có các item nhỏ được gọi là work packages, tuy nhiên WBS chỉ thể hiện thông tin của work packages dưới dạng ngắn gọn(identifiers + work packages title), do đó cần có một tài liệu mô tả chi tiết hơn từng work packages(bao gồm: assumtions, constraints, milestones, success criteria...), tài liệu này là WBS dictionary.

Sau khi Project team hoàn thành Scope baseline. PM chịu trách nhiệm gửi Scope Basline này cho các stakeholders, như một tài liệu chính thống(official document) giúp PM confirm về scope của dự án từ phía stakeholders, cũng như là một căn cứ(basis) cho việc thực hiện các hoạt động dự án cũng như validate products.

Việc thay đổi đến các baselines bắt buộc phải qua một quy trình cân nhắc, đánh giá(PICC). Và lại phải được các stakeholders confirm. Chính vì sự phức tạp như vậy nên việc thay đổi baselines là lựa chọn cuối cùng khi có một thay đổi nào đó đến dự án
 
Sửa lần cuối:

trieuchau

Nhà truyền đạo
[MENTION=28847]tegiac[/MENTION]:
"Việc thay đổi đến các baselines bắt buộc phải qua một quy trình cân nhắc, đánh giá(PICC). Và lại phải được các stakeholders confirm. Chính vì sự phức tạp như vậy nên việc thay đổi baselines là lựa chọn cuối cùng khi có một thay đổi nào đó đến dự án" cần correct là:
- CCB (Change Control Board) approve hoặc reject chứ không phải stakeholders
- Không có thứ tự ưu tiên ở việc "thay đổi baselines là lựa chọn cuối cùng..." mà bất kỳ thay đổi nào cũng trải qua process PICC (Perform Integrated Change Control), nếu kết quả của process này yêu cầu thay đổi/cập nhật baselines thì thay đổi/cập nhật, nếu kết quả của process này không yêu cầu thay đổi/cập nhật baselines thì không thay đổi/cập nhật.
 

tegiac

Member
Thanks [MENTION=88]trieuchau[/MENTION], mình hiểu là CCB sẽ approve - reject change request đến các baseline, tuy nhiên cho mình hỏi CCB này gồm những ai?
Mình đặt giả định ngớ ngẩn thế này:
Một dự án đang sản xuất một sản phẩm cho thị trường, sau khi collect requirement với một key stakeholder thì tính năng A được yêu cầu có trong sản phẩm, sau khi chốt scope và có được scope baseline thì tính năng A nằm trong scope baseline. Trong quá trình thực hiện dự án, PM vì một lí do nào đó tạo CR muốn update tính năng A này thành A' và được CCB approved. Nếu Key stakeholder ban đầu nằm trong CCB và đồng ý A đổi thành A' thì không vấn đề gì, tuy nhiên nếu key stakeholder ban đầu không nằm trong CCB và ông ta cho rằng A' được update không giống với tính năng A ban đầu mà ông ta mong muốn, vậy có ảnh hưởng gì không?
 

Hai

Member
Mình nghĩ là CCB là có cả stakeholder rồi, trường hợp key stakeholder như client / sponsor không approved ( không nằm trong CCB ) thì chắc CCB đó chưa đúng.
Còn sau đó yêu cầu chuyển thì đưa vô CCB chuyển thôi
 

Agile Project Management

Agile/Scrum

IT Management Professional

Information Technology Management Professional

Facebook

VietPMP Worldwide

vietpmp worldwide counters
Top