The first step in project scope man

The first step in project scope management is planning how the scope will be managed
throughout the life of the project. After reviewing the project management plan, project
charter, enterprise environmental factors, and organizational process assets, the project
team uses expert judgment and meetings to develop two important outputs: the scope
management plan and the requirements management plan.
The scope management plan is a subsidiary part of the project management plan, as
described in Chapter 4, Project Integration Management. It can be informal and broad or
formal and detailed, based on the needs of the project. In fact, small projects may not need a
written scope management plan, but large projects or highly technical projects often benefit
from one. In general, a scope management plan includes the following information:
• How to prepare a detailed project scope statement: For example, are there
templates or guidelines to follow? How much detail is needed to describe each
deliverable?
• How to create a WBS: It is often difficult to create a good WBS. This section
of the scope management plan would provide suggestions, samples, and
resources for creating a WBS.
• How to maintain and approve the WBS: The initial WBS often changes,
and project team members disagree on what should be included. The scope
management plan describes guidelines for maintaining the WBS and getting
approval for it.
• How to obtain formal acceptance of the completed project deliverables: It is
extremely important to understand the process for obtaining formal acceptance
of completed deliverables, especially for projects in which payments
are based on formal acceptance.
• How to control requests for changes to the project scope: This process is
related to performing integrated change control, as described in Chapter 4.
Organizations often have guidelines for submitting, evaluating, and approving
changes to scope, and this section of the scope management plan would
specify how to handle change requests for the project.
Another important output of planning scope management is the requirements
management plan. Before you learn about the contents of this document, it is important to
understand what requirements are. The 1990 IEEE Standard Glossary of Software
Engineering Terminology defines a requirement as follows:
“1. A condition or capability needed by a user to solve a problem or achieve an
objective.
2. A condition or capability that must be met or possessed by a
system or system component to satisfy a contract, standard, specification, or
other formally imposed document.
3. A documented representation of a condition or capability as in 1 or 2.”1
The PMBOK® Guide, Fifth Edition, describes requirements as “conditions or capabilities
that must be met by the project or present in the product, service, or result to satisfy
an agreement or other formally imposed specification.” It further explains that requirements
“include the quantified and documented needs and expectations of the sponsor,
Copyright 2016 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.Project Scope Management
187
customer, and other stakeholders. These requirements need to be elicited, analyzed, and
recorded in enough detail to be included in the scope baseline and be measured once project
execution begins.”
For example, the chapter’s opening case describes a project for upgrading IT assets to
meet corporate standards. These standards specify the minimum requirements for each
laptop, such as the type of processor, amount of memory, and hard disk size. The documented
requirements for this project, therefore, might state that all laptops include an
Intel processor, at least 16 GB of memory, and a 2-TB hard drive.
For some IT projects, it is helpful to divide requirements development into categories
called elicitation, analysis, specification, and validation. These categories include all the
activities involved in gathering, evaluating, and documenting requirements for a software
or software-containing product. It is also important to use an iterative approach to defining
requirements because they are often unclear early in a project.
The requirements management plan documents how project requirements will be
analyzed, documented, and managed. A requirements management plan can include the
following information:
• How to plan, track, and report requirements activities
• How to perform configuration management activities
• How to prioritize requirements
• How to use product metrics
• How to trace and capture attributes of requirements
What Went R ight?
Several studie

Kết quả (Việt) 1:

Bước đầu tiên trong quản lý phạm vi dự án đang có kế hoạch làm thế nào phạm vi sẽ được quản lýtrong suốt cuộc đời của dự án. Sau khi xem xét các kế hoạch quản lý dự án, dự ánđiều lệ, yếu tố môi trường doanh nghiệp và tổ chức quá trình tài sản, các dự ánđội sử dụng bản án chuyên gia và các cuộc họp để phát triển hai kết quả đầu ra quan trọng: phạm vikế hoạch quản lý và kế hoạch quản lý yêu cầu.Kế hoạch quản lý phạm vi là một phần công ty con của kế hoạch quản lý dự án, nhưđược mô tả trong chương 4, quản lý dự án tích hợp. Nó có thể không chính thức và rộng hoặcchính thức và chi tiết, dựa trên nhu cầu của dự án. Trong thực tế, các dự án nhỏ có thể không cần mộtvăn phạm vi kế hoạch quản lý, nhưng dự án lớn hoặc kỹ thuật cao các dự án thường hưởng lợitừ một. Nói chung, một kế hoạch quản lý phạm vi bao gồm các thông tin sau:• Làm thế nào để chuẩn bị một tuyên bố dự án chi tiết phạm vi: ví dụ: cómẫu hoặc hướng dẫn để làm theo? Chi tiết bao nhiêu là cần thiết để mô tả mỗideliverable?• Làm thế nào để tạo một WBS: nó thường là khó khăn để tạo ra một WBS tốt. Phần nàytrong phạm vi kế hoạch quản lý sẽ cung cấp gợi ý, mẫu, vàtài nguyên cho việc tạo ra một WBS.• Làm thế nào để duy trì và chấp thuận WBS: WBS ban đầu thường thay đổi,và các thành viên nhóm dự án không đồng ý về những gì nên được bao gồm. Phạm vikế hoạch quản lý mô tả hướng dẫn cho việc duy trì WBS và nhận đượcphê duyệt nó.• Làm thế nào để có được chính thức chấp nhận phân phôi dự án hoàn thành: đó làvô cùng quan trọng để hiểu quá trình để đạt được chính thức chấp nhậnsố phân phôi đã hoàn thành, đặc biệt là cho các dự án trong đó thanh toánDựa trên sự chấp nhận chính thức.• Làm thế nào để kiểm soát các yêu cầu cho các thay đổi đối với phạm vi dự án: quá trình này làliên quan đến thực hiện kiểm soát tích hợp sự thay đổi, như được diễn tả trong chương 4.Tổ chức thường có hướng dẫn đối với đệ trình, đánh giá và phê duyệtthay đổi đối với phạm vi, và phần này của kế hoạch quản lý phạm vi nàochỉ định làm thế nào để xử lý yêu cầu thay đổi đối với các dự án.Một quan trọng ra kế hoạch quản lý phạm vi là các yêu cầukế hoạch quản lý. Trước khi bạn tìm hiểu về nội dung của tài liệu này, điều quan trọng làhiểu những gì đang có yêu cầu. Bảng thuật ngữ phần mềm tiêu chuẩn IEEE năm 1990Kỹ thuật ngữ định nghĩa một yêu cầu như sau:"1. điều kiện hoặc khả năng cần thiết của một người sử dụng để giải quyết một vấn đề hoặc đạt được mộtmục tiêu. 2. một điều kiện hoặc khả năng mà phải được đáp ứng hoặc được sở hữu bởi mộtHệ thống hoặc các thành phần hệ thống để đáp ứng hợp đồng, tiêu chuẩn, đặc điểm kỹ thuật, hoặctài liệu chính thức áp đặt. 3. một đại diện tài liệu của một điều kiện hoặc các khả năng như trong 1 hoặc 2." 1The PMBOK® Guide, phiên bản thứ 5, mô tả các yêu cầu như là "điều kiện hoặc khả năngđiều đó phải được đáp ứng bởi dự án hoặc trình bày trong sản phẩm, Dịch vụ hoặc các kết quả đáp ứngmột thỏa thuận hoặc đặc điểm kỹ thuật chính thức áp đặt." Nó giải thích thêm rằng yêu cầu"bao gồm các tài liệu định lượng và nhu cầu và mong đợi của các nhà tài trợ,Bản quyền năm 2016 Cengage học. Tất cả các quyền. Có thể không được sao chép, quét hoặc trùng lặp, toàn bộ hoặc một phần. Do quyền điện tử, một số nội dung bên thứ ba có thể được bị đàn áp từ eBook và/hoặc eChapter(s).Biên tập review đã coi là rằng bất kỳ nội dung bị đàn áp không vật chất ảnh hưởng đến tổng thể kinh nghiệm học tập. Cengage học có quyền loại bỏ nội dung bổ sung bất kỳ lúc nào nếu tiếp theo quyền hạn chế yêu cầu nó. Quản lý phạm vi dự án187khách hàng, và các bên liên quan khác. Những yêu cầu cần phải được elicited, phân tích, vàghi lại chi tiết đủ để được bao gồm trong phạm vi cơ sở và đo một lần dự ánthực hiện bắt đầu."Ví dụ, các chương mở trường hợp mô tả một dự án nâng cấp nó tài sản đểđáp ứng các tiêu chuẩn công ty. Các tiêu chuẩn này xác định các yêu cầu tối thiểu cho mỗimáy tính xách tay, chẳng hạn như các loại bộ vi xử lý, số lượng bộ nhớ, và kích thước đĩa cứng. Các tài liệuyêu cầu đối với các dự án này, do đó, có thể nhà nước rằng tất cả các máy tính xách tay bao gồm mộtBộ xử lý Intel, ít nhất 16 GB bộ nhớ và ổ cứng 2 TB.Đối với một số dự án CNTT, nó là hữu ích để chia yêu cầu phát triển thành các loạiđược gọi là elicitation, phân tích, kỹ thuật và xác nhận. Các danh mục này bao gồm tất cả cácCác hoạt động liên quan đến việc thu thập, đánh giá và tài liệu về các yêu cầu cho một phần mềmhoặc phần mềm có chứa sản phẩm. Nó cũng quan trọng là phải sử dụng một cách tiếp cận lặp đi lặp lại để xác địnhyêu cầu bởi vì họ thường không rõ ràng sớm trong một dự án.Kế hoạch quản lý yêu cầu về tài liệu làm thế nào yêu cầu dự án sẽphân tích, tài liệu và quản lý. Một kế hoạch quản lý yêu cầu có thể bao gồm cácthông tin sau:• Làm thế nào để lên kế hoạch, theo dõi và báo cáo các hoạt động yêu cầu• Làm thế nào để thực hiện hoạt động quản lý cấu hình• Làm thế nào để ưu tiên các yêu cầu• Làm thế nào để sử dụng số liệu sản phẩm• Làm thế nào để theo dõi và nắm bắt các thuộc tính của yêu cầuNhững gì đã đi R ight?Một số studie

Kết quả (Việt) 2:

Bước đầu tiên trong phạm vi quản lý dự án được lên kế hoạch như thế nào phạm vi sẽ được quản lý
trong suốt thời gian của dự án. Sau khi xem xét các kế hoạch quản lý dự án, dự án
điều lệ, các yếu tố môi trường doanh nghiệp, và các tài sản quá trình tổ chức, các dự án
nhóm sử dụng phán đoán chuyên gia và các cuộc họp để phát triển hai đầu ra quan trọng: phạm vi
. Kế hoạch quản lý và kế hoạch quản lý các yêu cầu
kế hoạch quản lý phạm vi là một công ty con một phần của kế hoạch quản lý dự án, như
được mô tả trong Chương 4, quản lý dự án tích hợp. Nó có thể là không chính thức và rộng hoặc
chính thức và chi tiết, dựa trên nhu cầu của dự án. Trong thực tế, các dự án nhỏ có thể không cần một
kế hoạch quản lý phạm vi văn bản, nhưng các dự án lớn, dự án kỹ thuật cao thường được hưởng lợi
từ một. Nói chung, một kế hoạch phạm vi quản lý bao gồm các thông tin sau:
• Làm thế nào để chuẩn bị một tuyên bố phạm vi dự án chi tiết: Ví dụ, đang có
các mẫu hoặc hướng dẫn để làm theo? Làm thế nào nhiều chi tiết là cần thiết để mô tả từng
chuyển giao?
• Làm thế nào để tạo ra một WBS: Thường rất khó để tạo ra một WBS tốt. Phần này
của kế hoạch phạm vi quản lý sẽ cung cấp gợi ý, các mẫu, và
các nguồn lực để tạo ra một WBS.
• Làm thế nào để duy trì và phê duyệt WBS: Các WBS ban đầu thường xuyên thay đổi,
và các thành viên nhóm dự án không đồng ý về những gì nên được bao gồm. Phạm vi
kế hoạch quản lý mô tả các hướng dẫn cho việc duy trì WBS và nhận được
sự chấp thuận cho nó.
• Làm thế nào để có được chấp nhận chính thức của các phân phôi dự án hoàn thành: Nó là
vô cùng quan trọng để hiểu được quá trình để có được chấp nhận chính thức
của phân phôi hoàn thành, đặc biệt là cho các dự án, trong đó thanh toán
được dựa trên sự chấp nhận chính thức.
• làm thế nào để kiểm soát các yêu cầu thay đổi đối với quy mô dự án: quá trình này
liên quan đến việc thực hiện kiểm soát thay đổi tích hợp, như mô tả trong Chương 4.
Tổ chức thường có hướng dẫn cho trình, thẩm định, phê duyệt và
thay đổi phạm vi, và phần này của kế hoạch quản lý phạm vi sẽ
xác định làm thế nào để xử lý các yêu cầu thay đổi cho dự án.
Một kết quả quan trọng của kế hoạch quản lý phạm vi là các yêu cầu
kế hoạch quản lý. Trước khi bạn tìm hiểu về các nội dung của tài liệu này, điều quan trọng là phải
hiểu được những yêu cầu gì đang có. Năm 1990 chuẩn IEEE Tự điển của phần mềm
Kỹ thuật ngữ định nghĩa một yêu cầu như sau:
"1. Một điều kiện, năng lực cần thiết của một người sử dụng để giải quyết một vấn đề hoặc đạt được một
mục tiêu.
2. Một điều kiện, năng lực phải được đáp ứng hay chiếm hữu bởi một
hệ thống hay thành phần hệ thống để đáp ứng một hợp đồng, tiêu chuẩn, đặc điểm kỹ thuật, hoặc
tài liệu chính thức áp đặt khác.
3. Một đại diện ghi chép của một điều kiện, năng lực như trong 1 hoặc 2. "1
Các PMBOK® Guide, Fifth Edition, mô tả các yêu cầu là" điều kiện hay khả năng
đó phải được đáp ứng bởi các dự án hoặc hiện diện trong sản phẩm, dịch vụ, hoặc kết quả để đáp ứng
thoả thuận hoặc đặc điểm kỹ thuật chính thức áp đặt khác. "Nó tiếp tục giải thích rằng các yêu cầu
" bao gồm các nhu cầu và mong đợi của các nhà tài trợ, định lượng và ghi
Copyright 2016 Cengage Learning. Tất cả các quyền. Có thể không được sao chép, scan, hoặc trùng lặp, toàn bộ hoặc một phần. Do quyền điện tử, một số nội dung của bên thứ ba có thể bị ức chế từ sách điện tử và / hoặc eChapter (s).
Tổng biên tập đã coi rằng bất kỳ nội dung bí không vật chất ảnh hưởng đến học tập kinh nghiệm tổng thể. Cengage Learning có quyền loại bỏ nội dung bổ sung bất cứ lúc nào nếu hạn chế quyền tiếp theo yêu cầu it.Project Quản lý Phạm vi
187
khách hàng và các bên liên quan khác. Những yêu cầu này cần phải được gợi ra, phân tích và
ghi lại trong đủ chi tiết để được bao gồm trong đường cơ sở phạm vi và được đo khi dự án
thực hiện bắt đầu. "
Ví dụ, trường hợp mở đầu của chương mô tả một dự án nâng cấp tài sản CNTT để
đáp ứng các tiêu chuẩn của công ty. Những tiêu chuẩn xác định các yêu cầu tối thiểu cho mỗi
máy tính xách tay, chẳng hạn như các loại vi xử lý, dung lượng bộ nhớ và dung lượng đĩa cứng. Các tài liệu
yêu cầu cho dự án này, do đó, có thể nói rằng tất cả các máy tính xách tay bao gồm một
bộ xử lý Intel, ít nhất 16 GB bộ nhớ và ổ cứng 2 TB.
Đối với một số dự án CNTT, nó là hữu ích để phân chia các yêu cầu phát triển thành các loại
gọi là gợi mở , phân tích, đặc điểm kỹ thuật, và xác nhận. Các loại này bao gồm tất cả các
hoạt động liên quan đến việc thu thập, đánh giá và ghi lại các yêu cầu cho một phần mềm
hoặc sản phẩm phần mềm có chứa. Nó cũng quan trọng để sử dụng một cách tiếp cận lặp để xác định
các yêu cầu vì họ thường không rõ ràng trong giai đoạn đầu của dự án.
Các tài liệu kế hoạch quản lý các yêu cầu như thế nào yêu cầu của dự án sẽ được
phân tích, tài liệu, và quản lý. Một kế hoạch quản lý các yêu cầu có thể bao gồm các
thông tin sau:
• Làm thế nào để lập kế hoạch, theo dõi, và yêu cầu báo cáo các hoạt động
• Làm thế nào để thực hiện các hoạt động quản lý cấu hình
• Làm thế nào để ưu tiên các yêu cầu
• Làm thế nào để sử dụng các số liệu sản phẩm
• Làm thế nào để theo dõi và chụp hình các thuộc tính của các yêu cầu
gì Went R ight?
Một số Studie