mind map bab 5 manajemen bidang proyek

Chapter 5 Project Scope Management

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 (1). It is primarily concerned with defining and control-
ling what is or is not included in the project.  Figure 5-1  provides an overview
of the major project scope management processes:
5.1
Initiation
—authorizing the project or phase.
5.2
Scope Planning
—developing a written scope statement as the basis for future
project decisions.
5.3
Scope Definition
—subdividing the major project deliverables into smaller, more
manageable components.
5.4
Scope Verification
—formalizing acceptance of the project scope.
5.5
Scope Change Control
—controlling changes to project scope.
These processes interact with each other and with the processes in the other
knowledge areas as well. Each process may involve effort from one or more indi-
viduals or groups of individuals, based on the needs of the project. Each process
generally occurs at least once in every project phase.
Although the processes are presented here as discrete components with well-
defined interfaces, in practice they may overlap and interact in ways not detailed
here. Process interactions are discussed in detail in Chapter 3.
In the project context, the term  scope  may refer to:
ٱ
Product scope—the features and functions that characterize a product or service.
ٱ
Project scope—the work that must be done to deliver a product with the spec-
ified features and functions.
The processes, tools, and techniques used to manage  project  scope are the
focus of this chapter. The processes, tools, and techniques used to manage
product  scope vary by application area and are usually defined as part of the
project life cycle (the project life cycle is discussed in Section 2.1).
A project generally results in a single product, but that product may include
subsidiary components, each with its own separate but interdependent product
scopes. For example, a new telephone system would generally include four sub-
sidiary components—hardware, software, training, and implementation.
Completion of the project scope is measured against the project plan, but com-
pletion of the product scope is measured against the product requirements. Both
types of scope management must be well integrated to ensure that the work of
the project will result in delivery of the specified product.

5.1 INITIATION
Initiation is the process of formally authorizing a new project or that an existing
project should continue into its next phase (see Section 2.1 for a more detailed
discussion of project phases). This formal initiation links the project to the
ongoing work of the performing organization. In some organizations, a project is
not formally initiated until after completion of a needs assessment, a feasibility
study, a preliminary plan, or some other equivalent form of analysis that was itself
separately initiated. Some types of projects, especially internal service projects and
new product development projects, are initiated informally, and some limited
amount of work is done to secure the approvals needed for formal initiation. Proj-
ects are typically authorized as a result of one or more of the following:
ٱ
A market demand (e.g., a car company authorizes a project to build more fuel-
efficient cars in response to gasoline shortages).
ٱ
A business need (e.g., a training company authorizes a project to create a new
course to increase its revenues).
ٱ
A customer request (e.g., an electric utility authorizes a project to build a new
substation to serve a new industrial park).
ٱ
A technological advance (e.g., an electronics firm authorizes a new project to
develop a video game player after advances in computer memory).
ٱ
A legal requirement (e.g., a paint manufacturer authorizes a project to estab-
lish guidelines for the handling of toxic materials).
ٱ
A social need (e.g., a nongovernmental organization in a developing country
authorizes a project to provide potable water systems, latrines, and sanitation
education to low-income communities suffering from high rates of cholera).
These stimuli may also be called problems, opportunities, or business require-
ments. The central theme of all these terms is that management generally must
make a decision about how to respond.
5.1.1 Inputs to Initiation

1.Product description.
The product description documents the characteristics of the
product or service that the project was undertaken to create. The product
description will generally have less detail in early phases and more detail in later
ones as the product characteristics are progressively elaborated.
The product description should also document the relationship between the
product or service being created and the business need or other stimulus that
gave rise to the project (see the list in Section 5.1). While the form and substance
of the product description will vary, it should always be detailed enough to sup-
port later project planning.        

Many projects involve one organization (the seller) doing work under contract
to another (the buyer). In such circumstances, the initial product description is
usually provided by the buyer.

2.Strategic plan.
All projects should be supportive of the performing organization’s
strategic goals—the strategic plan of the performing organization should be con-
sidered as a factor in project selection decisions.

3.Project selection criteria.
Project selection criteria are typically defined in terms
of the merits of the product of the project and can cover the full range of possible
management concerns (financial return, market share, public perceptions, etc.).

4.Historical information.
Historical information about both the results of previous
project selection decisions and previous project performance should be considered
to the extent that it is available. When initiation involves approval for the next
phase of a project, information about the results of previous phases is often critical.
5.1.2  Tools and Techniques for Initiation

1.Project selection methods.
Project selection methods involve measuring value or
attractiveness to the project owner. Project selection methods include considering
the decision criterion (multiple criteria, if used, should be combined into a single
value function) and a means to calculate value under uncertainty. These are
known as the  decision model  and  calculation method . Project selection also applies
to choosing the alternative ways of doing the project. Optimization tools can be
used to search for the optimal combination of decision variables. Project selec-
tion methods generally fall into one of two broad categories (2):
ٱ
Benefit measurement methods—comparative approaches, scoring models,
benefit contribution, or economic models.
ٱ
Constrained optimization methods—mathematical models using linear, non-
linear, dynamic, integer, and multi-objective programming algorithms.
These methods are often referred to as  decision models . Decision models
include generalized techniques (Decision Trees, Forced Choice, and others), as
well as specialized ones (Analytic Hierarchy Process, Logical Framework
Analysis, and others). Applying complex project selection criteria in a sophisti-
cated model is often treated as a separate project phase.
.
2.Expert judgment.
Expert judgment will often be required to assess the inputs to
this process. Such expertise may be provided by any group or individual with spe-
cialized knowledge or training, and is available from many sources, including:
ٱ
Other units within the performing organization.
ٱ
Consultants.
ٱ
Stakeholders, including customers.
ٱ
Professional and technical associations.
ٱ
Industry groups.
5.1.3  Outputs from Initiation

1.Project charter.
A project charter is a document that formally authorizes a
project. It should include, either directly or by reference to other documents:
ٱ
The business need that the project was undertaken to address.
ٱ
The product description (described in Section 5.1.1.1).
The project charter should be issued by a manager external to the project, and
at a level appropriate to the needs of the project. It provides the project manager
with the authority to apply organizational resources to project activities.


When a project is performed under contract, the signed contract will generally
serve as the project charter for the seller.

2.Project manager identified/assigned.
In general, the project manager should be
identified and assigned as early in the project as is feasible. The project manager
should always be assigned prior to the start of project plan execution (described
in Section 4.2) and preferably before much project planning has been done (the
project planning processes are described in Section 3.3.2).
.
3.Constraints.
Constraints are factors that will limit the project management team’s
options. For example, a predefined budget is a constraint that is highly likely to
limit the team’s options regarding scope, staffing, and schedule.
When a project is performed under contract, contractual provisions will gen-
erally be constraints. Another example is a requirement that the product of the
project be socially, economically, and environmentally sustainable, which will also
have an effect on the project’s scope, staffing, and schedule.
4.Assumptions.
See Section 4.1.1.5.

5.2 SCOPE PLANNING
Scope planning is the process of progressively elaborating and documenting the
project work (project scope) that produces the product of the project. Project
scope planning starts with the initial inputs of product description, the project
charter, and the initial definition of constraints and assumptions. Note that the
product description incorporates product requirements that reflect agreed-upon
customer needs and the product design that meets the product requirements. The
outputs of scope planning are the scope statement and scope management plan,
with the supporting detail. The scope statement forms the basis for an agreement
between the project and the project customer by identifying both the project
objectives and the project deliverables. Project teams develop multiple scope
statements that are appropriate for the level of project work decomposition.
5.2.1  Inputs to Scope Planning

1.Product description.
The product description is discussed in Section 5.1.1.1.

2.Project charter.
The project charter is described in Section 5.1.3.1.

3.Constraints.
Constraints are described in Section 5.1.3.3.

4.Assumptions.
Assumptions are described in Section 4.1.1.5.        

5.2.2  Tools and Techniques for Scope Planning

1.Product analysis.
Product analysis involves developing a better understanding of
the product of the project. It includes techniques such as product breakdown
analysis systems engineering, value engineering, value analysis, function analysis,
and quality function deployment.

2.Benefit/cost analysis.
Benefit/cost analysis involves estimating tangible and
intangible costs (outlays) and benefits (returns) of various project and product
alternatives, and then using financial measures, such as return on investment or
payback period, to assess the relative desirability of the identified alternatives.

3
Alternatives identification.
This is a general term for any technique used to gen-
erate different approaches to the project. There is a variety of general manage-
ment techniques often used here, the most common of which are brainstorming
and lateral thinking.

4
Expert judgment.
Expert judgment is described in Section 5.1.2.2.
5.2.3  Outputs from Scope Planning
.
1
Scope statement.
The scope statement provides a documented basis for making
future project decisions and for confirming or developing common understanding
of project scope among the stakeholders. As the project progresses, the scope
statement may need to be revised or refined to reflect approved changes to the
scope of the project. The scope statement should include, either directly or by ref-
erence to other documents:
ٱ
Project justification—the business need that the project was undertaken to
address. The project justification provides the basis for evaluating future
tradeoffs.
ٱ
Project’s product—a brief summary of the product description (the product
description is discussed in Section 5.1.1.1).
ٱ
Project deliverables—a list of the summary-level subproducts whose full and sat-
isfactory delivery marks completion of the project. For example, the major deliv-
erables for a software development project might include the working computer
code, a user manual, and an interactive tutorial. When known, exclusions
should be identified, but anything not explicitly included is implicitly excluded.
ٱ
Project objectives—the quantifiable criteria that must be met for the project
to be considered successful. Project objectives must include at least cost,
schedule, and quality measures. Project objectives should have an attribute
(e.g., cost), a metric (e.g., United States [U.S.] dollars), and an absolute or
relative value (e.g., less than 1.5 million). Unquantified objectives (e.g., “cus-
tomer satisfaction”) entail high risk to successful accomplishment.
.
2
Supporting detail.
Supporting detail for the scope statement should be docu-
mented and organized as needed to facilitate its use by other project management
processes. Supporting detail should always include documentation of all identi-
fied assumptions and constraints. The amount of additional detail may vary by
application area.
.
3
Scope management plan.
This document describes how project scope will be
managed and how scope changes will be integrated into the project. It should
also include an assessment of the expected stability of the project scope (i.e., how
likely is it to change, how frequently, and by how much). The scope management
plan should also include a clear description of how scope changes will be iden-
tified and classified. (This is particularly difficult—and therefore absolutely
essential—when the product characteristics are still being elaborated.)
A Guide to the Project Management Body of Knowledge (PMBOK
®
Guide)
2000 Edition
©2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapter 5—Project Scope Management
56
5.2.2
|
5.3.2.1
 


A scope management plan may be formal or informal, highly detailed or
broadly framed, based on the needs of the project. It is a subsidiary component
of the project plan (described in Section 4.1.3.1).
5.3 SCOPE DEFINITION
Scope definition involves subdividing the major project deliverables (as identi-
fied in the scope statement as defined in Section 5.2.3.1) into smaller, more man-
ageable components to:
ٱ
Improve the accuracy of cost, duration, and resource estimates.
ٱ
Define a baseline for performance measurement and control.
ٱ
Facilitate clear responsibility assignments.
Proper scope definition is critical to project success. “When there is poor scope
definition, final project costs can be expected to be higher because of the
inevitable changes which disrupt project rhythm, cause rework, increase project
time, and lower the productivity and morale of the workforce” (3).
5.3.1  Inputs to Scope Definition
.
1
Scope statement.
The scope statement is described in Section 5.2.3.1.
.
2
Constraints.
Constraints are described in Section 5.1.3.3. When a project is done
under contract, the constraints defined by contractual provisions are often impor-
tant considerations during scope definition.
.
3
Assumptions.
Assumptions are described in Section 4.1.1.5.
.
4
Other planning outputs.
The outputs of the processes in other knowledge areas
should be reviewed for possible impact on project scope definition.
.
5
Historical information.
Historical information about previous projects should be
considered during scope definition. Information about errors and omissions on
previous projects should be especially useful.
5.3.2  Tools and Techniques for Scope Definition
.
1
Work breakdown structure templates.
A WBS (described in Section 5.3.3.1) from
a previous project can often be used as a template for a new project. Although
each project is unique, WBSs can often be “reused” since most projects will
resemble another project to some extent. For example, most projects within a
given organization will have the same or similar project life cycles, and will thus
have the same or similar deliverables required from each phase.        


Many application areas or performing organizations have standard or semi-
standard WBSs that can be used as templates. For example, the U.S. Department
of Defense has recommended standards WBSs for Defense Material Items (MIL-
HDBK-881). A portion of one of these templates is shown as  Figure 5-2 .
.
2
Decomposition.
Decomposition involves subdividing the major project deliver-
ables or subdeliverables into smaller, more manageable components until the
deliverables are defined in sufficient detail to support development of project
activities (planning, executing, controlling, and closing). Decomposition involves
the following major steps:
(1) Identify the major deliverables of the project, including project manage-
ment. The major deliverables should always be defined in terms of how the
project will actually be organized. For example:
ٱ
The phases of the project life cycle may be used as the first level of decompo-
sition with the project deliverables repeated at the second level, as illustrated
in  Figure 5-3 .
ٱ
The organizing principle within each branch of the WBS may vary, as illus-
trated in  Figure 5-4 .
(2) Decide if adequate cost and duration estimates can be developed at this
level of detail for each deliverable. The meaning of  adequate  may change over the
course of the project—decomposition of a deliverable that will be produced far
in the future may not be possible. For each deliverable, proceed to Step 4 if there
is adequate detail, to Step 3 if there is not—this means that different deliverables
may have differing levels of decomposition.
(3) Identify constituent components of the deliverable. Constituent components
should be described in terms of tangible, verifiable results to facilitate performance
measurement. As with the major components, the constituent components should
be defined in terms of how the work of the project will actually be organized and
the work of the project accomplished. Tangible, verifiable results can include ser-
vices as well as products (e.g.,  status reporting  could be described as  weekly status
reports ; for a manufactured item, constituent components might include several
individual components plus  final assembly ). Repeat Step 2 on each constituent
component.
(4) Verify the correctness of the decomposition:
ٱ
Are the lower-level items both necessary and sufficient for completion of the
decomposed item? If not, the constituent components must be modified
(added to, deleted from, or redefined).
ٱ
Is each item clearly and completely defined? If not, the descriptions must be
revised or expanded.
ٱ
Can each item be appropriately scheduled? Budgeted? Assigned to a specific
organizational unit (e.g., department, team, or person) who will accept
responsibility for satisfactory completion of the item? If not, revisions are
needed to provide adequate management control.
5.3.3  Outputs from Scope Definition
.
1
Work breakdown structure.
A WBS is a deliverable-oriented grouping of project
components that organizes and defines the total scope of the project; work not

This WBS is illustrative only. It is not intended to represent the full project scope of any specific project,
nor to imply that this is the only way to organize a WBS on this type of project.
 

in the WBS is outside the scope of the project. As with the scope statement, the
WBS is often used to develop or confirm a common understanding of project
scope. Each descending level represents an increasingly detailed description of
the project deliverables. Section 5.3.2.2 describes the most common approach for
developing a WBS. A WBS is normally presented in chart form, as illustrated in
Figures 5-2 ,  5-3 , and  5-4 ; however, the WBS should not be confused with the
method of presentation—drawing an unstructured activity list in chart form does
not make it a WBS.
Each item in the WBS is generally assigned a unique identifier; these identifiers
can provide a structure for a hierarchical summation of costs and resources. The
items at the lowest level of the WBS may be referred to as  work packages , espe-
cially in organizations that follow earned value management practices. These
work packages may in turn be further decomposed in a subproject work break-
down structure. Generally, this type of approach is used when the project manager
is assigning a scope of work to another organization, and this other organization
must plan and manage the scope of work at a more detailed level than the project
manager in the main project. These work packages may be further decomposed in
the project plan and schedule, as described in Sections 5.3.2.2 and 6.1.2.1.
Work component descriptions are often collected in a  WBS dictionary . A WBS
dictionary will typically include work package descriptions, as well as other plan-
ning information such as schedule dates, cost budgets, and staff assignments.
The WBS should not be confused with other kinds of “breakdown” structures
used to present project information. Other structures commonly used in some
application areas include:
ٱ
Contractual WBS (CWBS), which is used to define the level of reporting that
the seller will provide the buyer. The CWBS generally includes less detail than
the WBS used by the seller to manage the seller’s work.
ٱ
Organizational breakdown structure (OBS), which is used to show which
work components have been assigned to which organizational units.
ٱ
Resource breakdown structure (RBS), which is a variation of the OBS and is
typically used when work components are assigned to individuals.
ٱ
Bill of materials (BOM), which presents a hierarchical view of the physical
assemblies, subassemblies, and components needed to fabricate a manufac-
tured product.
ٱ
Project breakdown structure (PBS), which is fundamentally the same as a
properly done WBS. The term  PBS  is widely used in application areas where
the term  WBS  is incorrectly used to refer to a BOM.
.
2
Scope statement updates.
Include any modification of the contents of the scope
statement (described in Section 5.2.3.1). Appropriate stakeholders must be noti-
fied as needed.
5.4 SCOPE VERIFICATION
Scope verification is the process of obtaining formal acceptance of the project
scope by the stakeholders (sponsor, client, customer, etc.). It requires reviewing
deliverables and work results to ensure that all were completed correctly and sat-
isfactorily. If the project is terminated early, the scope verification process should
establish and document the level and extent of completion. Scope verification dif-
fers from quality control (described in Section 8.3) in that it is primarily con-
cerned with  acceptance  of the work results while quality control is primarily
concerned with the  correctness  of the work results. These processes are generally
performed in parallel to ensure both correctness and acceptance.        


5.4.1  Inputs to Scope Verification
.
1
Work results.
Work results—which deliverables have been fully or partially com-
pleted—are an output of project plan execution (discussed in Section 4.2).
.
2
Product documentation.
Documents produced to describe the project’s products
must be available for review. The terms used to describe this documentation
(plans, specifications, technical documentation, drawings, etc.) vary by applica-
tion area.
.
3
Work breakdown structure.
The WBS aids in definition of the scope, and should
be used to verify the work of the project (see Section 5.3.3.1).
.
4
Scope statement.
The scope statement defines the scope in some detail and
should be verified (see Section 5.2.3.1).
.
5
Project plan.
The project plan is described in Section 4.1.3.1.
5.4.2  Tools and Techniques for Scope Verification
.
1
Inspection.
Inspection includes activities such as measuring, examining, and
testing undertaken to determine whether results conform to requirements.
Inspections are variously called reviews, product reviews, audits, and walk-
throughs; in some application areas, these different terms have narrow and spe-
cific meanings.
5.4.3  Outputs from Scope Verification
.
1
Formal acceptance.
Documentation that the client or sponsor has accepted the
product of the project phase or major deliverable(s) must be prepared and dis-
tributed. Such acceptance may be conditional, especially at the end of a phase.

5.5  SCOPE CHANGE CONTROL
Scope change control is concerned with a) influencing the factors that create
scope changes to ensure that changes are agreed upon, b) determining that a
scope change has occurred, and c) managing the actual changes when and if they
occur. Scope change control must be thoroughly integrated with the other con-
trol processes (schedule control, cost control, quality control, and others, as dis-
cussed in Section 4.3).        

5.5.1  Inputs to Scope Change Control

1
Work breakdown structure.
The WBS is described in Section 5.3.3.1. It defines the
project’s scope baseline.
.
2
Performance reports.
Performance reports, discussed in Section 10.3.3.1, provide
information on scope performance, such as which interim deliverables have been
completed and which have not. Performance reports may also alert the project
team to issues that may cause problems in the future.
.
3
Change requests.
Change requests may occur in many forms—oral or written,
direct or indirect, externally or internally initiated, and legally mandated or
optional. Changes may require expanding the scope or may allow shrinking it.
Most change requests are the result of:
ٱ
An external event (e.g., a change in a government regulation).
ٱ
An error or omission in defining the scope of the product (e.g., failure to
include a required feature in the design of a telecommunications system).
ٱ
An error or omission in defining the scope of the project (e.g., using a BOM
instead of a WBS).
ٱ
A value-adding change (e.g., an environmental remediation project is able to
reduce costs by taking advantage of technology that was not available when
the scope was originally defined).
ٱ
Implementing a contingency plan or workaround plan to respond to a risk, as
described in Section 11.6.3.3.
.
4
Scope management plan.
The scope management plan is described in Section5.2.3.3.
5.5.2  Tools and Techniques for Scope Change Control
.
1
Scope change control.
A scope change control defines the procedures by which
the project scope may be changed. It includes the paperwork, tracking systems,
and approval levels necessary for authorizing changes. The scope change control
should be integrated with the integrated change control described in Section 4.3
and, in particular, with any system or systems in place to control product scope.
When the project is done under contract, the scope change control must also
comply with all relevant contractual provisions.
.
2
Performance measurement.
Performance measurement techniques, described in
Section 10.3.2, help to assess the magnitude of any variations that do occur. Deter-
mining what is causing the variance relative to the baseline and deciding if the
variance requires corrective action are important parts of scope change control.
.
3
Additional planning.
Few projects run exactly according to plan. Prospective
scope changes may require modifications to the WBS or analysis of alternative
approaches (see Sections 5.3.3.1 and 5.2.2.3, respectively).
5.5.3  Outputs from Scope Change Control
.
1
Scope changes.
A scope change is any modification to the agreed-upon project
scope as defined by the approved WBS. Scope changes often require adjustments
to cost, time, quality, or other project objectives.
Project scope changes are fed back through the planning process, technical
and planning documents are updated as needed, and stakeholders are notified as
appropriate.
When a project is performed under contract, the signed contract will generally
serve as the project charter for the seller.
.
2
Project manager identified/assigned.
In general, the project manager should be
identified and assigned as early in the project as is feasible. The project manager
should always be assigned prior to the start of project plan execution (described
in Section 4.2) and preferably before much project planning has been done (the
project planning processes are described in Section 3.3.2).
.
3
Constraints.
Constraints are factors that will limit the project management team’s
options. For example, a predefined budget is a constraint that is highly likely to
limit the team’s options regarding scope, staffing, and schedule.
When a project is performed under contract, contractual provisions will gen-
erally be constraints. Another example is a requirement that the product of the
project be socially, economically, and environmentally sustainable, which will also
have an effect on the project’s scope, staffing, and schedule.
.
4
Assumptions.
See Section 4.1.1.5.

Rangkuman Bab 5 – Manajemen Lingkup Proyek

5.1. Inisiasi
Inisiasi adalah proses pemberian kuasa/hak secara formal untuk pembuatan proyek baru atau proyek yang sedang berkelanjutan kedalam fase selanjutnya.

Input
1. Deskripsi Produk
Deskripsi produk merupakan mendokumentasikan karakteristik produk atau jasa proyek yang melakukan pembuatan. Deskripsi produk umumnya akan memiliki lebih sedikit detail dalam tahap awal.

2. Rencana Strategis
Semua proyek harus mendukung strategis organisasi.

3. Kriteria Pemilihan Proyek
Kriteria pemilihan proyek biasanya didefinisikan dalam istilah manfaat dari produk proyek.

4. Informasi Historis
Informasi sejarah tentang kedua hasil proyek seleksi keputusan sebelumnya dan kinerja proyek sebelumnya harus dipertimbangkan secara luas jika tersedia.

Alat dan teknik
1. Metode Seleksi Proyek
Metode seleksi proyek melibatkan mengukur nilai atau daya tarik kepada pemilik proyek.

2. Penilaian Ahli
Penilaian ahli akan sering diminta untuk menilai masukan untuk proses ini.

Output
1. Penghargaan Proyek
Adalah dokumen yang secara resmi menjadi wewenang sebuah proyek.

2. Identifikasi Manajer Proyek
Secara umum, manajer proyek harus diidentifikasi dan ditugaskan sebagai awal dalam proyek sebagai layak
3. Kendala
Kendala adalah faktor yang akan membatasi pilihan tim manajemen proyek.

4. Asumsi


5.2. Perencanaan Bidang / Perencanaan Lapangan
Perencanaan ruang lingkup adalah proses progresif menguraikan dan mendokumentasikan pekerjaan proyek (lingkup proyek) yang menghasilkan produk dari proyek. Perencanaan lingkup proyek dimulai dengan input awal deskripsi produk, piagam proyek, dan definisi awal kendala dan asumsi.

Input
1. Deskripsi Produk

2. Penghargaan Proyek

3. Kendala

4. Asumsi

Alat dan Teknik
1. Analisis Produk
Analisis produk melibatkan mengembangkan pemahaman yang lebih baik dari produk proyek. Ini mencakup teknik seperti produk pemecahan analisis sistem rekayasa, rekayasa nilai, analisis nilai, analisis fungsi, dan quality function deployment.

2. Analisis Manfaat / Biaya
Analisis manfaat / biaya melibatkan estimasi berwujud dan tidak berwujud biaya (pengeluaran) dan manfaat (keuntungan) dari berbagai proyek dan alternatif produk, dan kemudian menggunakan ukuran finansial.

3. Identifikasi Alternatif
Ini adalah istilah umum untuk setiap teknik yang digunakan untuk menghasilkan pendekatan yang berbeda untuk proyek.

4. Penilaian Ahli


Output
1. Pernyataan Lingkup
Pernyataan lingkup memberikan dasar didokumentasikan untuk membuat keputusan proyek masa depan dan untuk mengkonfirmasikan atau mengembangkan pemahaman umum tentang ruang lingkup proyek antara para pemangku kepentingan. Sebagai proyek berlangsung, pernyataan ruang lingkup mungkin perlu direvisi atau disempurnakan untuk mencerminkan perubahan yang disetujui pada lingkup proyek.

2. Mendukung Detail
Mendukung detail untuk pernyataan ruang lingkup harus didokumentasikan dan terorganisir yang diperlukan untuk memfasilitasi penggunaannya oleh proses manajemen proyek lainnya.

3. Lingkup Rencana Pengelolaan
Dokumen ini menjelaskan bagaimana ruang lingkup proyek akan dikelola dan bagaimana perubahan lingkup akan diintegrasikan ke dalam proyek. Hal ini juga harus mencakup penilaian terhadap stabilitas yang diharapkan dari lingkup proyek (yaitu, bagaimana mungkin itu berubah, seberapa sering, dan seberapa banyak).


5.3. Definisi Bidang / Lingkup
Definisi Lingkup melibatkan pengelompokan proyek besar penyampaian menjadi lebih kecil.

Input
1. Pernyataan Lingkup

2. Kendala
Ketika sebuah proyek dilakukan di bawah kontrak, kendala didefinisikan oleh ketentuan kontrak sering pertimbangan penting selama ruang lingkup definisi.

3. Asumsi

4. Output Perencanaan Lain
Output dari proses dalam bidang pengetahuan lainnya harus ditinjau untuk dampak yang mungkin pada definisi lingkup proyek.

5. Informasi Historis
Informasi sejarah tentang proyek-proyek sebelumnya harus dipertimbangkan selama ruang lingkup definisi.

Alat dan Teknik
1. Bekerja Pada Kerusakan Pola Struktur
Sebuah WBS (Work Breakdown Structure) dari proyek sebelumnya sering dapat digunakan sebagai template untuk sebuah proyek baru. Meskipun setiap proyek adalah unik, WBS sering bisa " kembali " karena sebagian besar proyek akan menyerupai proyek lain sampai batas tertentu.

2. Penguraian
Dekomposisi melibatkan pengelompokan proyek besar penyampaian atau subdeliverable menjadi lebih kecil, komponen lebih mudah ditangani sampai kiriman didefinisikan secara cukup rinci.

Output
1. Strukur Rincian Kerja
Sebuah WBS adalah pengelompokan berorientasi deliverable komponen proyek yang mengatur dan mendefinisikan total lingkup proyek, bekerja tidak di WBS berada di luar lingkup proyek.

2. Memperbarui Pernyataan Lingkup
Pemangku kepentingan yang tepat harus diberitahu sesuai kebutuhan.


5.4. Verifikasi Bidang /  Lingkup

Input
1. Hasil Kerja
Hasil kerja yang pengirimannya telah sepenuhnya atau sebagian selesai adalah output rencana pelaksanaan proyek.

2. Dokumentasi Produk
Dokumen yang dihasilkan untuk menggambarkan produk proyek harus tersedia untuk dapat diperiksa. Istilah yang digunakan untuk menggambarkan dokumentasi ini (rencana, spesifikasi, dokumentasi teknis, gambar, dll) bervariasi berdasarkan wilayah aplikasi.


3. Struktur Rincian Kerja
WBS membantu dalam definisi ruang lingkup, dan harus digunakan untuk memverifikasi pekerjaan proyek.

4. Pernyataan Lingkup
Pernyataan lingkup mendefinisikan ruang lingkup dengan detail dan harus diverifikasi.

5. Rencana Proyek


Alat dan Teknik
1. Inspeksi
Pemeriksaan meliputi kegiatan seperti mengukur, memeriksa, dan pengujian dilakukan untuk menentukan apakah hasil memenuhi persyaratan.

Output
1. Penerimaan Formal
Dokumentasi bahwa klien atau sponsor telah menerima produk dari fase proyek atau penyampaian utama harus disiapkan dan didistribusikan. Penerimaan tersebut mungkin bersyarat, terutama pada akhir fase.


5.5. Pengawasan Perubahan Bidang / Lingkup
Pengendalian perubahan lingkup yang bersangkutan dengan :
a) mempengaruhi faktor-faktor yang menciptakan perubahan ruang lingkup untuk memastikan bahwa perubahan yang disepakati
b) menentukan bahwa perubahan lingkup telah terjadi
c) mengelola perubahan yang sebenarnya ketika terjadi perubahan. Pengendalian perubahan lingkup harus benar-benar terintegrasi dengan proses kontrol lainnya.

Input
1. Struktur Rincian Kerja

2. Laporan Kinerja
Laporan kinerja, memberikan informasi tentang kinerja lingkup, seperti yang kiriman sementara telah selesai dan yang belum.



3. Perubahaan Permintaan
Perubahan permintaan dapat terjadi dalam berbagai bentuk, yaitu bisa dalam bentuk lisan atau tertulis, langsung atau tidak langsung, eksternal atau internal dimulai, dan mandat hukum atau opsional.

4. Lingkup Rencana Pengelola

Proses
1. Pengendalian Perubahan Lingkup
Sebuah pengendalian perubahan lingkup mendefinisikan prosedur dimana lingkup proyek dapat diubah.

2. Pengukuran Kinerja
Teknik pengukuran kinerja, membantu untuk menilai besarnya setiap variasi yang memang terjadi.

3. Perencanaan Tambahan
Beberapa proyek berjalan tepat sesuai rencana, yang membuat perubahan lingkup mungkin memerlukan modifikasi WBS atau analisis alternatif pendekatan.

Output
1. Perubahan Lingkup
Perubahan lingkup adalah setiap modifikasi yang disepakati lingkup proyek seperti yang didefinisikan oleh WBS disetujui.

2. Tindakan Korektif
Tindakan korektif adalah segala sesuatu yang dilakukan untuk membawa harapan kinerja proyek pada masa depan sejalan dengan rencana proyek.

3. Pelajaran yang Dipetik
Penyebab penyimpangan, alasan di balik tindakan korektif yang dipilih, dan jenis-jenis pelajaran dari pengendalian perubahan lingkup harus didokumentasikan, sehingga informasi ini menjadi bagian dari database historis untuk kedua proyek ini dan proyek lain dari organisasi pertunjukan.

4. Dasar yang Disesuaikan
Tergantung pada sifat perubahan, dokumen dasar yang sesuai dapat direvisi dan diterbitkan kembali untuk mencerminkan perubahan disetujui dan membentuk dasar baru untuk perubahan masa depan.

BAB 5 - manajemen bidang proyek

5.1 Inisiasi (Permulaan)
Inisiasi adalah proses pemberian kuasa/hak secara formal untuk pembuatan proyek baru atau proyek yang sedang berkelanjutan kedalam fase selanjutnya. Permulaan formal ini menghubungkan proyek pada pekerjaan yang sedang berjalan untuk menunjukkan organisasi tersebut. Pada beberapa organisasi, proyek mengalami inisiasi secara formal sampai selesainya kebutuhan penaksiran, studi kelayakan, rencana awal, atau hal-hal yang bentuknya setara dari analisa itu sendiri yang inisiasinya terpisah. Beberapa tipe proyek, terutama proyek pelayanan internal dan proyek baru yang berkembang, terinisiasi secara tidak formal, dan beberapa jumlah kerja yang terbatas sudah selesai untuk mengamankan kebutuhan persetujuan inisiasi yang formal. Secara khas tipikal proyek adalah sebagai berikut :
• Permintaan pasar
• Kebutuhan bisnis
• Permintaan pelanggan
• Manfaat teknologi
• Persyaratan hukum
• Kebutuhan sosial
Tipikal di atas bisa dikatakan sebagai rangsangan, kesempatan, atau keperluan bisnis. Inti dari semua persyaratan adalah bahwa manajemen secara umum harus membuat keputusan tentang bagaimana untuk memberi respon / tanggapan.

5.1.1 Input ke Inisiasi
1. Deskripsi produk
Deskripsi produk mendokumentasikan karakteristik produk atau jasa proyek yang melakukan pembuatan. Deskripsi produk umumnya akan memiliki lebih sedikit detail dalam tahap awal dan lebih rinci dalam yang kemudian sebagai karakteristik produk secara progresif diuraikan.
Deskripsi produk juga harus mendokumentasikan hubungan antara produk atau jasa yang dibuat dan kebutuhan bisnis atau stimulus lain yang memunculkan proyek. Sementara bentuk dan substansi deskripsi produk akan bervariasi , selalu harus cukup rinci untuk mendukung perencanaan proyek nanti.
Banyak proyek melibatkan satu organisasi (penjual) melakukan pekerjaan berdasarkan kontrak yang lain (pembeli). Dalam keadaan seperti itu , deskripsi produk awal biasanya diberikan oleh pembeli .

2. Rencana strategis
Semua proyek harus mendukung strategis organisasi melakukan itu tujuan rencana strategis organisasi melakukan harus dianggap sebagai faktor dalam keputusan seleksi proyek.

3. Kriteria pemilihan proyek
Kriteria pemilihan proyek biasanya didefinisikan dalam istilah manfaat dari produk proyek dan dapat mencakup rentang penuh keprihatinan manajemen mungkin (pengembalian keuangan , pembagian pasar ,persepsi publik , dll).

4. Informasi historis
Informasi sejarah tentang kedua hasil proyek seleksi keputusan sebelumnya dan kinerja proyek sebelumnya harus dipertimbangkan secara luas jika tersedia . Ketika inisiasi melibatkan persetujuan untuk tahap berikutnya dari proyek, informasi tentang hasil tahap sebelumnya sering kali kritis.

5.1.2 Alat dan Teknik untuk Inisiasi

1. Metode seleksi proyek
Metode seleksi proyek melibatkan mengukur nilai atau daya tarik kepada pemilik proyek. Metode seleksi proyek meliputi mempertimbangkan kriteria keputusan (beberapa kriteria , jika digunakan, harus dikombinasikan menjadi fungsi nilai tunggal) dan sarana untuk menghitung nilai di bawah ketidakpastian. Ini dikenal sebagai model keputusan dan metode perhitungan. Pemilihan proyek juga berlaku untuk memilih cara-cara alternatif untuk melakukan proyek. Alat optimasi dapat digunakan untuk mencari kombinasi optimal variabel keputusan. Metode seleksi proyek umumnya jatuh ke dalam salah satu dari dua kategori besar :
ٱ Manfaat pengukuran pendekatan metode komparatif, model penilaian, manfaat kontribusi, atau model ekonomi.
ٱModel optimasi,terkendala metode matematika menggunakan linear, nonlinear, dinamis, integer, dan multi-tujuan algoritma pemrograman. Metode ini sering disebut sebagai model keputusan. Model keputusan termasuk teknik umum (Pohon Keputusan, Keputusan Paksa, dan lain-lain), serta yang khusus (Analitik Hirarki Proses, Analisis Logical Framework, dan lain-lain). Menerapkan kriteria seleksi proyek yang kompleks dalam model canggih sering dianggap sebagai fase proyek terpisah.

2. Penilaian ahli
Penilaian ahli akan sering diminta untuk menilai masukan untuk proses ini. Keahlian tersebut dapat diberikan oleh setiap kelompok atau individu dengan pengetahuan atau pelatihan khusus, dan tersedia dari berbagai sumber, termasuk :
ٱ Unit lain dalam organisasi melakukan.
ٱ Konsultan.
ٱ Kepentingan, termasuk pelanggan.
ٱ Profesional dan teknis asosiasi.
ٱ Kelompok Industri.

5.1.3 Keluaran dari Inisiasi

1. Proyek charter
Sebuah project charter adalah dokumen yang secara resmi wewenang sebuah proyek. Ini harus mencakup, baik secara langsung atau dengan referensi ke dokumen lain :
• Kebutuhan bisnis yang proyek ini dilakukan untuk mengatasi.
• Deskripsi produk.
Piagam proyek harus dikeluarkan oleh seorang manajer eksternal untuk proyek, dan pada tingkat yang sesuai dengan kebutuhan proyek. Ini menyediakan manajer proyek dengan otoritas untuk menerapkan sumber daya organisasi untuk kegiatan proyek. Ketika sebuah proyek dilakukan di bawah kontrak, kontrak yang ditandatangani pada umumnya akan berfungsi sebagai piagam proyek untuk penjual.

2. Pengidentifikasian / Penugasan Manajer Proyek
Secara umum, manajer proyek harus diidentifikasi dan ditugaskan sebagai awal dalam proyek sebagai layak. Manajer proyek harus selalu ditugaskan sebelum dimulainya rencana pelaksanaan proyek dan sebaiknya sebelum perencanaan proyek banyak yang telah dilakukan.

3. Kendala
Kendala adalah faktor yang akan membatasi pilihan tim manajemen proyek. Misalnya, anggaran yang telah ditetapkan merupakan kendala yang sangat mungkin untuk membatasi pilihan tim mengenai ruang lingkup, staf, dan jadwal. Ketika sebuah proyek dilakukan di bawah kontrak, ketentuan kontrak umumnya akan kendala. Contoh lain adalah persyaratan bahwa produk proyek secara sosial, ekonomi, dan lingkungan yang berkelanjutan, yang juga akan berpengaruh pada lingkup proyek, staf, dan jadwal.

4. Asumsi


5.2 Perencanaan Bidang / Perencanaan Lapangan
Perencanaan ruang lingkup adalah proses progresif menguraikan dan mendokumentasikan pekerjaan proyek (lingkup proyek) yang menghasilkan produk dari proyek. Perencanaan lingkup proyek dimulai dengan input awal deskripsi produk, piagam proyek, dan definisi awal kendala dan asumsi. Perhatikan bahwa deskripsi produk menggabungkan persyaratan produk yang mencerminkan kesepakatan kebutuhan pelanggan dan desain produk yang memenuhi persyaratan produk. Output dari perencanaan lingkup adalah pernyataan lingkup dan rencana manajemen ruang lingkup, dengan detail pendukung. Pernyataan lingkup membentuk dasar bagi kesepakatan antara proyek dan pelanggan proyek dengan mengidentifikasi kedua tujuan proyek dan deliverable proyek. Tim proyek mengembangkan beberapa pernyataan lingkup yang sesuai untuk tingkat proyek dekomposisi kerja.

5.2.1 Masukan untuk Perencanaan ruang lingkup

1. Deskripsi produk
2. Proyek charter
3. Kendala
4. Asumsi

5.2.2 Alat dan Teknik Perencanaan Lingkup

1. Analisis produk
Analisis produk melibatkan mengembangkan pemahaman yang lebih baik dari produk proyek. Ini mencakup teknik seperti produk pemecahan analisis sistem rekayasa, rekayasa nilai, analisis nilai, analisis fungsi, dan quality function deployment.

2. Analisis manfaat / biaya
Analisis manfaat / biaya melibatkan estimasi berwujud dan tidak berwujud biaya (pengeluaran) dan manfaat (keuntungan) dari berbagai proyek dan alternatif produk, dan kemudian menggunakan ukuran finansial, seperti pengembalian investasi atau payback period, untuk menilai keinginan relatif dari alternatif diidentifikasi.

3. Identifikasi alternatif
Ini adalah istilah umum untuk setiap teknik yang digunakan untuk menghasilkan pendekatan yang berbeda untuk proyek. Ada berbagai teknik manajemen umum yang sering digunakan di sini, yang paling umum di antaranya adalah brainstorming dan berpikir lateral.
4. Penilaian ahli

5.2.3 Keluaran dari Perencanaan Lingkup

1. Pernyataan lingkup
Pernyataan lingkup memberikan dasar didokumentasikan untuk membuat keputusan proyek masa depan dan untuk mengkonfirmasikan atau mengembangkan pemahaman umum tentang ruang lingkup proyek antara para pemangku kepentingan. Sebagai proyek berlangsung, pernyataan ruang lingkup mungkin perlu direvisi atau disempurnakan untuk mencerminkan perubahan yang disetujui pada lingkup proyek. Pernyataan lingkup harus mencakup, baik secara langsung atau dengan referensi ke dokumen lain :
ٱ Pembenaran - Proyek bisnis perlu bahwa proyek ini dilakukan untuk mengatasi. Pembenaran proyek memberikan dasar untuk mengevaluasi pengorbanan masa depan.
ٱ Proyek produk - ringkasan singkat tentang deskripsi produk.
ٱ Proyek kiriman - daftar dari subproducts ringkasan tingkat yang pengiriman penuh dan memuaskan menandai penyelesaian proyek. Misalnya, point utama untuk proyek pengembangan perangkat lunak mungkin termasuk kode kerja komputer, user manual, dan tutorial interaktif. Ketika diketahui, pengecualian harus diidentifikasi, tapi apa pun tidak secara eksplisit dimasukkan secara implisit dikecualikan.
ٱ Tujuan - Proyek kriteria kuantitatif yang harus dipenuhi untuk proyek agar dianggap berhasil. Tujuan proyek harus menyertakan setidaknya biaya, jadwal, dan kualitas tindakan. Tujuan Proyek harus memiliki sebuah atribut (misalnya, biaya), metrik (misalnya, dolar Amerika Serikat), dan nilai mutlak atau relatif (misalnya, kurang dari 1,5 juta). Tujuan unquantified (misalnya, " kepuasan pelanggan ") memerlukan berisiko tinggi untuk keberhasilannya.

2. Mendukung detail
Mendukung detail untuk pernyataan ruang lingkup harus didokumentasikan dan terorganisir yang diperlukan untuk memfasilitasi penggunaannya oleh proses manajemen proyek lainnya. Mendukung rinci harus selalu menyertakan dokumentasi semua asumsi diidentifikasi dan kendala. Jumlah detail tambahan dapat bervariasi berdasarkan wilayah aplikasi.

3. Lingkup rencana pengelolaan
Dokumen ini menjelaskan bagaimana ruang lingkup proyek akan dikelola dan bagaimana perubahan lingkup akan diintegrasikan ke dalam proyek. Hal ini juga harus mencakup penilaian terhadap stabilitas yang diharapkan dari lingkup proyek (yaitu, bagaimana mungkin itu berubah, seberapa sering, dan seberapa banyak). Rencana pengelolaan lingkup juga harus mencakup gambaran yang jelas tentang bagaimana perubahan lingkup akan diidentifikasi dan diklasifikasikan. (Hal ini sangat sulit dan karena itu benar-benar penting - ketika karakteristik produk masih sedang diuraikan.)
Sebuah rencana manajemen ruang lingkup mungkin formal atau informal, sangat rinci atau dibingkai luas, berdasarkan pada kebutuhan proyek. Ini adalah komponen anak perusahaan dari rencana proyek.

5.3 Definisi Bidang / Lapangan
Definisi Lingkup melibatkan pengelompokan proyek besar penyampaian menjadi lebih kecil, komponen lebih mudah dikelola ke:
ٱ Meningkatkan akurasi biaya, durasi, dan sumber daya estimasi.
ٱ Tentukan dasar untuk pengukuran kinerja dan kontrol.
ٱ Memfasilitasi tugas tanggung jawab yang jelas.
Ruang lingkup definisi tepat sangat penting untuk keberhasilan proyek. "Ketika ada definisi lingkup miskin, biaya proyek akhir dapat diharapkan akan lebih tinggi karena perubahan tak terelakkan yang mengganggu irama proyek, menyebabkan pengerjaan ulang, meningkatkan waktu proyek, dan menurunkan produktivitas dan moral tenaga kerja".

5.3.1 Masukan untuk Lingkup Definisi

1. Pernyataan lingkup

2 . Kendala
Ketika sebuah proyek dilakukan di bawah kontrak, kendala didefinisikan oleh ketentuan kontrak sering pertimbangan penting selama ruang lingkup definisi.

3. Asumsi

4. Output perencanaan lainnya
Output dari proses dalam bidang pengetahuan lainnya harus ditinjau untuk dampak yang mungkin pada definisi lingkup proyek.

5. Informasi historis
Informasi sejarah tentang proyek-proyek sebelumnya harus dipertimbangkan selama ruang lingkup definisi. Informasi tentang kesalahan dan kelalaian pada proyek-proyek sebelumnya harus sangat berguna.

5.3.2 Alat dan Teknik untuk Lingkup Definisi

1. Bekerja kerusakan struktur template
Sebuah WBS (Work Breakdown Structure) dari proyek sebelumnya sering dapat digunakan sebagai template untuk sebuah proyek baru. Meskipun setiap proyek adalah unik, WBS sering bisa " kembali " karena sebagian besar proyek akan menyerupai proyek lain sampai batas tertentu. Sebagai contoh, sebagian besar proyek dalam suatu organisasi akan memiliki siklus hidup proyek yang sama atau serupa, dan dengan demikian akan memiliki kiriman yang sama atau serupa yang diperlukan dari setiap tahap.

Banyak daerah aplikasi atau organisasi yang melakukan WBSs memiliki standar atau semistandard yang dapat digunakan sebagai template. Misalnya, Departemen Pertahanan AS telah merekomendasikan standar WBSs Pertahanan Produk Bahan (MIL - HDBK - 881).

2. Penguraian
Dekomposisi melibatkan pengelompokan proyek besar penyampaian atau subdeliverable menjadi lebih kecil, komponen lebih mudah ditangani sampai kiriman didefinisikan secara cukup rinci untuk mendukung pengembangan kegiatan proyek (perencanaan, pelaksanaan, pengendalian, dan penutupan). Dekomposisi melibatkan langkah-langkah utama berikut :
(1) Mengidentifikasi penyerahan utama proyek, termasuk manajemen proyek. Point utama harus selalu didefinisikan dalam hal bagaimana proyek benar-benar akan diselenggarakan. Sebagai contoh:
ٱ Para fase siklus hidup proyek dapat digunakan sebagai tingkat pertama dari dekomposisi dengan deliverable proyek diulangi pada tingkat kedua.
ٱ Prinsip pengorganisasian dalam setiap cabang WBS dapat bervariasi.

(2) Putuskan apakah biaya yang memadai dan perkiraan durasi dapat dikembangkan pada tingkat detail untuk setiap deliverable. Arti dari memadai dapat berubah selama proyek - dekomposisi dari deliverable yang akan diproduksi jauh di masa depan mungkin tidak dapat dilakukan. Untuk setiap deliverable, lanjutkan ke Langkah 4 jika ada detail yang memadai, ke Langkah 3 jika tidak ada - ini berarti bahwa kiriman yang berbeda mungkin telah tingkat dekomposisi berbeda.

(3) Mengidentifikasi komponen konstituen dari deliverable. Komponen-komponen penyusun harus dijelaskan dalam hal yang nyata, hasil diverifikasi untuk memudahkan pengukuran kinerja. Seperti dengan komponen utama, komponen-komponen penyusun harus didefinisikan dalam hal bagaimana pekerjaan proyek benar-benar akan diselenggarakan dan pekerjaan proyek dilakukan. Nyata, hasil diverifikasi dapat mencakup layanan serta produk (misalnya, pelaporan statusnya bisa digambarkan sebagai laporan status mingguan, untuk item diproduksi, komponen konstituen mungkin termasuk beberapa komponen individual ditambah perakitan akhir). Ulangi Langkah 2 pada setiap komponen penyusunnya.
(4) Verifikasi kebenaran dekomposisi :
ٱ Apakah item - tingkat yang lebih rendah perlu dan cukup untuk menyelesaikan item membusuk? Jika tidak, komponen-komponen penyusun harus dimodifikasi (ditambahkan, dihapus dari, atau didefinisikan ulang).
ٱ Apakah setiap item jelas dan lengkap didefinisikan? Jika tidak, deskripsi harus direvisi atau diperluas.
ٱ Dapatkah setiap item secara tepat dijadwalkan? Anggaran? Ditugaskan ke unit organisasi tertentu (misalnya, departemen, tim, atau orang) yang akan menerima tanggung jawab untuk penyelesaian yang memuaskan dari barang? Jika tidak, revisi diperlukan untuk memberikan kontrol manajemen yang memadai.

5.3.3 Keluaran dari Lingkup Definisi

1. Struktur rincian kerja
Sebuah WBS adalah pengelompokan berorientasi deliverable komponen proyek yang mengatur dan mendefinisikan total lingkup proyek, bekerja tidak di WBS berada di luar lingkup proyek. Seperti pernyataan ruang lingkup, WBS sering digunakan untuk mengembangkan atau mengkonfirmasi pemahaman umum tentang ruang lingkup proyek. Setiap tingkat turun mewakili deskripsi semakin rinci deliverable proyek. Bagian 5.3.2.2 menggambarkan pendekatan yang paling umum untuk mengembangkan WBS. Sebuah WBS biasanya disajikan dalam bentuk grafik, seperti digambarkan pada Gambar 5-2, 5-3, dan 5-4, namun WBS tidak harus bingung dengan metode presentasi - menggambar daftar kegiatan terstruktur dalam bentuk grafik tidak membuat WBS.
Setiap item dalam WBS umumnya diberi pengenal unik, pengidentifikasi ini dapat memberikan struktur untuk penjumlahan hirarkis biaya dan sumber daya. Item pada tingkat terendah dari WBS dapat disebut sebagai paket pekerjaan, terutama dalam organisasi yang mengikuti praktek-praktek manajemen nilai yang diterima. Paket-paket pekerjaan pada gilirannya akan lebih terurai dalam struktur rincian kerja proyek. Umumnya, jenis pendekatan yang digunakan ketika manajer proyek menetapkan lingkup pekerjaan ke organisasi lain, dan organisasi lainnya harus merencanakan dan mengelola ruang lingkup kerja di tingkat yang lebih rinci dibandingkan dengan manajer proyek dalam proyek utama. Paket-paket pekerjaan selanjutnya dapat didekomposisi dalam rencana proyek dan jadwal, seperti yang dijelaskan dalam Bagian 5.3.2.2 dan 6.1.2.1.
Deskripsi komponen kerja sering dikumpulkan dalam WBS kamus. Sebuah WBS kamus biasanya akan mencakup deskripsi paket pekerjaan, serta informasi perencanaan lain seperti tanggal jadwal, anggaran biaya, dan tugas staf. WBS tidak harus bingung dengan jenis lain dari "gangguan" struktur yang digunakan untuk menyajikan informasi proyek. Struktur lain yang umum digunakan di beberapa area aplikasi meliputi:
ٱ Kontrak WBS (CWBS), yang digunakan untuk menentukan tingkat melaporkan bahwa penjual akan memberikan pembeli. Para CWBS umumnya termasuk kurang detail dibandingkan WBS digunakan oleh penjual untuk mengelola pekerjaan penjual.
ٱ struktur rincian Organisasi (OBS), yang digunakan untuk menunjukkan komponen kerja telah ditetapkan ke unit organisasi.
ٱ Sumberdaya struktur rincian (RBS), yang merupakan variasi dari OBS dan biasanya digunakan ketika komponen pekerjaan yang ditugaskan untuk individu.
ٱ Bill of material (BOM), yang menyajikan pandangan hirarkis dari majelis fisik, subassemblies, dan komponen yang dibutuhkan untuk membuat sebuah produk manufaktur.
ٱ struktur rincian proyek (PBS), yang pada dasarnya sama dengan WBS dilakukan dengan benar. Istilah PBS banyak digunakan dalam area aplikasi mana WBS istilah salah digunakan untuk merujuk kepada BOM.

2. Update pernyataan lingkup
Sertakan modifikasi dari isi pernyataan ruang lingkup (dijelaskan dalam Bagian 5.2.3.1). Pemangku kepentingan yang tepat harus diberitahu sesuai kebutuhan.


5.4 Verifikasi Bidang / Lapangan
Verifikasi Lingkup adalah proses mendapatkan penerimaan formal dari ruang lingkup proyek oleh para pemegang jabatan penting (sponsor, klien, pelanggan, dll). Hal ini membutuhkan peninjauan pengiriman dan hasil kerja untuk memastikan bahwa semua telah dilakukan dengan benar dan memuaskan. Jika proyek ini dihentikan lebih awal, proses verifikasi lingkup harus menetapkan dan mendokumentasikan tingkat dan tingkat penyelesaian. Lingkup verifikasi berbeda dari kontrol kualitas terutama berkaitan dengan penerimaan hasil kerja sementara kontrol kualitas terutama berkaitan dengan kebenaran hasil kerja. Proses ini umumnya dilakukan secara paralel untuk memastikan baik kebenaran dan penerimaan.

5.4.1 Masukan untuk Lingkup Verifikasi

1. Hasil kerja
Hasil kerja yang pengirimannya telah sepenuhnya atau sebagian selesai adalah output rencana pelaksanaan proyek.
2. Dokumentasi produk
Dokumen yang dihasilkan untuk menggambarkan produk proyek harus tersedia untuk dapat diperiksa. Istilah yang digunakan untuk menggambarkan dokumentasi ini (rencana, spesifikasi, dokumentasi teknis, gambar, dll) bervariasi berdasarkan wilayah aplikasi.

3. Struktur rincian kerja
WBS membantu dalam definisi ruang lingkup, dan harus digunakan untuk memverifikasi pekerjaan proyek.
4. Pernyataan lingkup
Pernyataan lingkup mendefinisikan ruang lingkup dengan detail dan harus diverifikasi.
5. Rencana proyek
Rencana proyek dijelaskan pada Bagian 4.1.3.1.

5.4.2 Alat dan Teknik untuk Lingkup Verifikasi

1. Inspeksi
Pemeriksaan meliputi kegiatan seperti mengukur, memeriksa, dan pengujian dilakukan untuk menentukan apakah hasil memenuhi persyaratan. Ada istilah lain dari inspeksi yaitu : ulasan, review produk, audit, dan penelusuran, dalam beberapa area aplikasi, istilah-istilah yang berbeda memiliki arti yang sempit dan spesifik.

5.4.3 Keluaran dari Lingkup Verifikasi

1. Penerimaan formal
Dokumentasi bahwa klien atau sponsor telah menerima produk dari fase proyek atau penyampaian utama harus disiapkan dan didistribusikan. Penerimaan tersebut mungkin bersyarat, terutama pada akhir fase.


5.5 Pengawasan Perubahan Bidang / Lapangan
Pengendalian perubahan lingkup yang bersangkutan dengan :
a) mempengaruhi faktor-faktor yang menciptakan perubahan ruang lingkup untuk memastikan bahwa perubahan yang disepakati
b) menentukan bahwa perubahan lingkup telah terjadi
c) mengelola perubahan yang sebenarnya ketika terjadi perubahan. Pengendalian perubahan lingkup harus benar-benar terintegrasi dengan proses kontrol lainnya.

5.5.1 Masukan untuk Pengendalian Perubahan Lingkup

1. Struktur rincian kerja

2. Laporan kinerja
Laporan kinerja, memberikan informasi tentang kinerja lingkup, seperti yang kiriman sementara telah selesai dan yang belum. Laporan kinerja juga dapat mengingatkan tim proyek untuk menjegah masalah  yang dapat menyebabkan masalah di masa depan.

3. Perubahan permintaan
Perubahan permintaan dapat terjadi dalam berbagai bentuk, yaitu bisa dalam bentuk lisan atau tertulis, langsung atau tidak langsung, eksternal atau internal dimulai, dan mandat hukum atau opsional. Perubahan mungkin memerlukan perluasan lingkup atau memungkinkan menyusut itu.

Kebanyakan permintaan perubahan adalah hasil dari :
ٱ Peristiwa eksternal (misalnya, perubahan dalam peraturan pemerintah).
ٱ Suatu kesalahan atau kelalaian dalam mendefinisikan ruang lingkup produk (misalnya, kegagalan untuk menyertakan fitur yang diperlukan dalam desain sistem telekomunikasi).
ٱ Sebuah kesalahan atau kelalaian dalam mendefinisikan lingkup proyek (misalnya, menggunakan BOM bukan sebuah WBS).
ٱ Sebuah nilai tambah perubahan (misalnya, sebuah proyek rehabilitasi lingkungan dapat mengurangi biaya dengan memanfaatkan teknologi yang tidak tersedia ketika lingkup awalnya didefinisikan).
ٱ Mengimplementasikan rencana kontingensi atau rencana solusi untuk menanggapi risiko.

4 . Lingkup rencana pengelolaan


5.5.2 Alat dan Teknik untuk Pengendalian Perubahan Lingkup

1. Pengendalian perubahan lingkup
Sebuah pengendalian perubahan lingkup mendefinisikan prosedur dimana lingkup proyek dapat diubah. Ini termasuk dokumen, sistem pelacakan, dan tingkat persetujuan yang diperlukan untuk perubahan kekuasaan. Kontrol lingkup perubahan harus diintegrasikan dengan kontrol perubahan yang terintegrasi dan khususnya dengan sistem atau sistem untuk mengontrol lingkup produk. Ketika proyek ini dilakukan di bawah kontrak, pengendalian perubahan lingkup juga harus mematuhi semua ketentuan kontrak yang relevan.

2. Pengukuran kinerja
Teknik pengukuran kinerja, membantu untuk menilai besarnya setiap variasi yang memang terjadi. Menentukan apa yang menyebabkan varians relatif terhadap baseline dan memutuskan apakah varians membutuhkan tindakan korektif adalah bagian penting dari pengendalian perubahan lingkup.

3. Perencanaan tambahan
Beberapa proyek berjalan tepat sesuai rencana, yang membuat perubahan lingkup mungkin memerlukan modifikasi WBS atau analisis alternatif pendekatan.


5.5.3 Output dari Lingkup Pengendalian Perubahan

1. Perubahan lingkup
Perubahan lingkup adalah setiap modifikasi yang disepakati lingkup proyek seperti yang didefinisikan oleh WBS disetujui. Perubahan lingkup sering membutuhkan penyesuaian biaya, waktu, kualitas, atau tujuan proyek lainnya. Perubahan lingkup proyek diumpankan kembali melalui proses perencanaan, teknis dan dokumen perencanaan diperbarui sesuai kebutuhan, dan pemangku kepentingan akan diberitahu sesuai.

2. Tindakan korektif
Tindakan korektif adalah segala sesuatu yang dilakukan untuk membawa harapan kinerja proyek pada masa depan sejalan dengan rencana proyek.

3. Pelajaran yang dipetik
Penyebab penyimpangan, alasan di balik tindakan korektif yang dipilih, dan jenis-jenis pelajaran dari pengendalian perubahan lingkup harus didokumentasikan, sehingga informasi ini menjadi bagian dari database historis untuk kedua proyek ini dan proyek lain dari organisasi pertunjukan.

4. Dasar yang disesuaikan
Tergantung pada sifat perubahan, dokumen dasar yang sesuai dapat direvisi dan diterbitkan kembali untuk mencerminkan perubahan disetujui dan membentuk dasar baru untuk perubahan masa depan.