Chapter 5 Project Scope Management

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 controlling
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 individuals
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 welldefined
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 specified
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 subsidiary
components—hardware, software, training, and implementation.
          Completion of the project scope is measured against the project plan, but completion
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. Projects

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 fuelefficient

     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 establish

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

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 support

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 considered

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 selection

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, nonlinear,

      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 sophisticated

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 specialized

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 generally

   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 generate

   different approaches to the project. There is a variety of general management

   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 reference

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 satisfactory

delivery marks completion of the project. For example, the major deliverables

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., “customer

satisfaction”) entail high risk to successful accomplishment.

.2 Supporting detail. Supporting detail for the scope statement should be documented

  and organized as needed to facilitate its use by other project management

   processes. Supporting detail should always include documentation of all identified

   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 identified

   and classified. (This is particularly difficult—and therefore absolutely

   essential—when the product characteristics are still being elaborated.)

             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 identified
      in the scope statement as defined in Section 5.2.3.1) into smaller, more manageable
      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).


Inputs
.1 Scope statement
.2 Constraints
.3 Assumptions
.4 Other planning outputs
.5 Historical information
.
Tools & Tecniques
.1 Work breakdown structure
  templates
.2 Decomposition
.
Outputs
.1 Work breakdown structure
.2 cope statement updates


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 important
    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 semistandard

    WBSs that can be used as templates. For example, the U.S. Department

    of Defense has recommended standards WBSs for Defense Material Items (MILHDBK-

    881). A portion of one of these templates is shown as Figure 5-2.

.2 Decomposition. Decomposition involves subdividing the major project deliverables

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

    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 decomposition

          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 illustrated

         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 services

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

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, especially

in organizations that follow earned value management practices. These

work packages may in turn be further decomposed in a subproject work breakdown

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 planning

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 manufactured

   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 notified

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

      If the project is terminated early, the scope verification process should

      establish and document the level and extent of completion. Scope verification differs

      from quality control (described in Section 8.3) in that it is primarily concerned

      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 completed—

          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 application

         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 walkthroughs;

in some application areas, these different terms have narrow and specific

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

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 control

processes (schedule control, cost control, quality control, and others, as discussed

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 Section

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

.2 Corrective action. Corrective action is anything done to bring expected future
project performance in line with the project plan.
.3 Lessons learned. The causes of variances, the reasoning behind the corrective
action chosen, and other types of lessons learned from scope change control
should be documented, so that this information becomes part of the historical
database for both this project and other projects of the performing organization.
.4 Adjusted baseline. Depending upon the nature of the change, the corresponding
baseline document may be revised and reissued to reflect the approved change
and form the new baseline for future changes.
A

Chapter 5 Manajemen dalam Lingkup Proyek

Bab 5      

Manajemen dalam Lingkup Proyek

Manajemen lingkup proyek mencakup proses-proses yang diperlukan untuk memastikan bahwa proyek tersebut mencakup semua pekerjaan yang diperlukan, dan hanya pekerjaan yang diperlukan, untuk menyelesaikan proyek dengan sukses. itu terutama berkaitan dengan mendefinisikan dan mengendalikan apa atau tidak termasuk dalam project.figure 5-1 memberikan gambaran proses manajemen proyek lingkup besar.

5.1       inisiasi mengesahkan proyek atau fase.
5.2       lingkup perencanaan-mengembangkan tertulis lingkup pernyataan sebagai  dasar untuk keputusan proyek masa depan.
5.3       Definisi-pengelompokan lingkup deliverable proyek besar menjadi lebih kecil,            komponen lebih managaeble.
5.4       lingkup verifikasi-meresmikan penerimaan lingkup proyek.
5.5       perubahan lingkup kontrol pengendali perubahan lingkup proyek.

proses berinteraksi satu sama lain dan dengan proses di bidang pengetahuan lain juga. setiap proses mungkin melibatkan usaha dari satu atau lebih individu atau kelompok individu, berdasarkan kebutuhan proyek. setiap proses umumnya terjadi setidaknya sekali dalam setiap tahapan proyek.
meskipun proses disajikan di sini sebagai komponen diskrit dengan baik didefinisikan antarmuka, dalam praktiknya mereka mungkin tumpang tindih dan berinteraksi dengan cara yang tidak rinci di sini. Proses interaksi dibahas secara rinci dalam Bab 3.
dalam konteks proyek, ruang lingkup panjang mungkin merujuk kepada:

§  lingkup-Produk fitur dan fungsi yang menjadi ciri suatu produk atau jasa.

§  Proyek lingkup-pekerjaan yang harus dilakukan untuk memberikan produk dengan specfitur- ified dan fungsi. Proses, peralatan, dan teknik yang digunakan untuk mengelola lingkup. fokus dari bab ini. Proses, peralatan, dan teknik yang digunakan untuk mengelola lingkup produk bervariasi berdasarkan wilayah aplikasi dan biasanya didefinisikan sebagai bagian dari siklus hidup proyek (siklus hidup proyek dibahas dalam Bagian 2.1).
Sebuah proyek umumnya menghasilkan satu produk, tapi produk yang dapat mencakupanak perusahaan komponen, masing-masing dengan produk sendiri terpisah namun saling cakupan. Sebagai contoh, sistem telepon baru umumnya akan mencakup empat sub-sidiary komponen-hardware, software, pelatihan, dan implementasi.
Penyelesaian ruang lingkup proyek diukur terhadap rencana proyek, namun com-
pletion lingkup produk diukur terhadap persyaratan produk. keduanya
jenis manajemen lingkup harus terintegrasi dengan baik untuk memastikan bahwa pekerjaanproyek ini akan mengakibatkan pengiriman produk tertentu.

5.1 Inisiasi
Inisiasi adalah proses formal otorisasi sebuah proyek baru atau bahwa ada
proyek harus berlanjut ke tahap berikutnya (lihat Bagian 2.1 untuk lebih rinci
diskusi tahapan proyek). Ini inisiasi resmi menghubungkan proyek ke
berkelanjutan bekerjanya organisasi melakukan. Dalam beberapa organisasi, proyek ini
tidak secara resmi dimulai sampai setelah selesai penilaian kebutuhan, kelayakan suatu
studi, rencana awal, atau bentuk lainnya yang dipersamakan analisis yang sendiri
secara terpisah dimulai. Beberapa jenis proyek, proyek pelayanan terutama internal dan
proyek pengembangan produk baru, yang dimulai secara informal, dan beberapa terbatas
jumlah pekerjaan yang dilakukan untuk mengamankan persetujuan yang dibutuhkan untuk inisiasi formal. proyek biasanya berwenang sebagai akibat dari satu atau lebih dari berikut ini:

§     >Sebuah permintaan pasar (misalnya, sebuah perusahaan mobil kewenangan sebuah proyek untuk membangun lebih hemat bahan bakar mobil dalam menanggapi kekurangan bensin).

§    >Sebuah kebutuhan bisnis (misalnya, sebuah perusahaan pelatihan kewenangan sebuah proyek untuk membuat yang baru
Tentu saja untuk meningkatkan pendapatan).

§   > Sebuah permintaan pelanggan (misalnya, sebuah utilitas listrik mengotorisasi sebuah proyek untuk membangun baru
gardu untuk melayani kawasan industri baru).

§    >Sebuah kemajuan teknologi (misalnya, sebuah perusahaan elektronik mengotorisasi sebuah proyek baru untuk
mengembangkan pemutar video game setelah kemajuan dalam memori komputer).

§    >Suatu persyaratan hukum (misalnya, produsen cat kewenangan proyek untuk pem-
lish pedoman untuk penanganan bahan beracun).

§    >Sebuah kebutuhan sosial (misalnya, sebuah organisasi non-pemerintah di negara berkembang wewenang proyek untuk menyediakan sistem air minum, kakus, dan sanitasipendidikan untuk masyarakat berpenghasilan rendah menderita tingkat tinggi kolera). Rangsangan ini juga dapat disebut masalah, peluang, atau bisnis memerlukan kasih. Tema sentral dari semua ketentuan ini manajemen yang umumnya harus
membuat keputusan tentang bagaimana menanggapi.

Input Output Peralatan & Teknik

.1 Deskripsi produk .2 Rencana strategis .3 Proyek kriteria seleksi .4 Sejarah informasi

.1 Proyek metode seleksi  .2 Ahli penghakiman

.1 Project charter .2Project manager .3 identified/assigned .4 Constraints .5 Assumptions

5.1.1 Masukan ke Inisiasi
.1 Uraian produk. Deskripsi produk mendokumentasikan karakteristik
produk atau jasa yang proyek dilakukan untuk menciptakan. produk
deskripsi umumnya akan memiliki detail kurang dalam fase awal dan lebih rinci di kemudian
yang 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 (lihat daftar di Bagian 5.1). Sementara bentuk dan substansi
dari deskripsi produk akan bervariasi, selalu harus cukup rinci untuk mendukung
Port perencanaan proyek selanjutnya.

Banyak proyek yang melibatkan satu organisasi (penjual) melakukan pekerjaan di bawah kontrak kepada yang lain (pembeli). Dalam keadaan tersebut, keterangan produknya adalah biasanya disediakan oleh si pembeli.

.2            Rencana Strategis. Semua proyek harus menjadi pendukung bagi hasil strategis organisasi pertunjukan---rencana strategis dari organisasi pertunjukan harus dipertimbangkan sebagai sebauh factor dalam pemutusan pemilihan proyek.

.3            Kriteria pemilihan proyek. Criteria pemilihan proyek biasanya didefinisikan  dalam jangka waktu kelebihan dari produk sebuah proyek dan bisa menutupi seluruh batas dari kemungkinan manajemen masalah (pengembalian keuangan, pembagiann pemasaran, pemikiran public, dll.).

.4            Informasi Sejarah. Informasi sejarah tentang hasil dari keputusan pemilihan proyek sebelumnya dan penampilan proyek sebelumnya harusnya disadari untuk perluasan yangtersedia. Ketika inisiasi melibatkan persetujuan untuk proyek di fase selanjutnya, informasi tentang hasil dari fase sebelumnya sering kritis.

5.1.2      Peralatan dan Teknis untuk Inisiasi

.1            Metode pemilihan proyek. Metode pemilihan proyek meliputi mengukur nilai atau ketertarikan terhadap pemilik proyek. Metode pemilihan proyek termasuk mempertimbagkan kriteria keputusan (bermacam kriteria, bila digunakan, harus dikombinasikan kepada fungsi nilai tunggal) dan artinya menghitung nilai di bawah ketidaktentuan. Itu semua dikenal sebagai model keputusan dan metode penghitungan. Pemilihan proyek juga berlaku untuk memilih cara alternative untuk melakukan proyek. Alat optimalisasi dapat digunakan untuk mencari sebuah kombinasi optimal dari suatu variable keputusan. Metode pemilihan proyek secara umum berada dalam salah satu dari dua (2) kategori yang luas:

·         Metode pengukuran keuntungan----kemunculan perbandingan, model-model penilaian, kontribusi kuntungan, atau model-model ekonimis.

·         Metode optimisasi terpaksa----model-model matematika menggunakan linier, non-linier, dinamis, integer, dan algoritma pemrograman multi-objektif.Metode-metode ini sering mengacu sebagai model-model keputusan. Model-model keputusan termasuk teknis umum (Pohon Keputusan, Pilihan Mendesak, dan lainnya), sama bagusnya dengan yang khusus (Proses analisis heirarki, analisis kerangka logis, dan lainnya). Mengaplikasikan criteria pemilihan proyek secara kompleks dalam suatu model yang mutakhir sering diperlakukan sebagai pemisah fase proyek.

.2                    Keputusan Ahli. Keputusan ahli akan sering dibutuhkan untuk menilai input untuk proses ini. Seperti keahlian yang disediakan oleh grup manapun atau individual dengan pengetahuan khusus atau latihan, dan juga tersedia dari banyak sumber, termasuk:

·         Unit lainnya dalam organisasi pertunjukan.

·         Konsultan

·         Pemangku kepentingan, termasuk pelanggan.

·         Tenaga ahli dan asosiasi teknik

·         Grup Industri

5.1.3      Keluaran dari Inisiasi

.1            Piagam proyek. Sebuah piagam proyek adalah berkas yang secara resmi mengotorisasi sebuah proyek. Itupun akan termasuk, salah satu yang secara langsung ataupun melalui referensi untuk berkas lain:

·         Suatu bisnis perlu bahwa suatu proyek sudah dilakukan kepada alamat

·         Penjelasan produk (Dijelaskan dalam bagian 5.1.1.1).

Piagam proyek seharusnya dikeluarkan oleh menejer eksternal ke proyek, dan saat level sesuai untuk kebutuhan proyek. Itupun menyediakan pengelolaan proyek dengan otoritas untuk menggunakan sumber organisasional untuk aktifitas proyek.

Ketika sebuah proyek dipertunjukkan dibawah kontrak, yang menandatangani kontrak umumnya akan melayani sebagai piagam proyek untuk penjual.

.2                    Pengelolaan proyek yang teridentifikas/ditugaskan. Umumnya, pengelolaan proyek seharusnya teridentifikasi dan ditugaskan terlebih dulu dalam proyek yang layak. Pengelolaan proyek seharusnya selalu ditugaskan sebelum perencanaan proyek dimulai (dijelaskan dalam Bag. 4.2) dan lebih disukai sebelum banyak perencanaan proyek selesai (proses perencanaan proyek tersebut dijelaskan dalam Bagian 3.3.2). 

                 .3             Kendala adalah faktor yang akan membatasi tim manajemen proyek itu pilihan. Misalnya,

                                   anggaran yang telah ditetapkan merupakan kendala yang sangat mungkin membatasi 

                                   pilihan tim mengenai ruang lingkup, staf, dan jadwal. Ketika sebuah proyek dilakukan di

                                  bawah kontrak, ketentuan kontrak umumnya akan 

            menjadi kendala. Contoh lain adalah persyaratan bahwa produk dari proyek secara sosial, ekonomi, dan lingkungan yang berkelanjutan, yang juga akan memiliki efek pada ruang lingkup proyek, staf, dan jadwal.

4                      Asumsi. Lihat Bagian 4.1.1.5.

5.2 LINGKUP PERENCANAAN

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

5.2.1      Masukan untuk Perencanaan Ruang Lingkup

.1                Uraian produk. Deskripsi produk dibahas dalam Bagian 5.1.1.1.

.2                Proyek charter. Piagam proyek dijelaskan dalam Bagian 5.1.3.1.

.3.               Kendala. Kendala yang dijelaskan dalam Bagian 5.1.3.3.

.4                Asumsi. Asumsi dijelaskan dalam Bagian 4.1.1.5.

5.2.2  Alat dan Teknik Perencanaan Ruang Lingkup

.1    Produk analisis. Analisis produk melibatkan mengembangkan pemahaman yang lebih baik

        produk dari proyek. Ini mencakup teknik seperti kerusakan produk

        analisis sistem rekayasa, rekayasa nilai, analisis nilai, analisis fungsi,

        dan kualitas penyebaran fungsi.

.2     Manfaat / analisis biaya. Manfaat / analisis biaya melibatkan estimasi nyata dan

        berwujud biaya (pengeluaran) dan manfaat (keuntungan) dari berbagai proyek dan produk

        alternatif, dan kemudian menggunakan ukuran finansial, seperti pengembalian investasi atau

        payback period, untuk menilai keinginan relatif dari alternatif diidentifikasi.

.3    Alternatif identifikasi. Ini adalah istilah umum untuk teknik yang digunakan untuk setiap gen-

       erate pendekatan yang berbeda untuk proyek. Ada berbagai umum pengelolaan

       teknik pemerintah sering digunakan di sini, yang paling umum yang curah pendapat

       dan berpikir lateral.

.4   Ahli penghakiman. Penilaian ahli dijelaskan dalam Bagian 5.1.2.2.

5.2.3 Keluaran dari Perencanaan Lingkup

.1    Lingkup pernyataan. Pernyataan lingkup memberikan dasar didokumentasikan untuk membuat

       masa depan proyek keputusan dan untuk konfirmasi atau mengembangkan pemahaman bersama

       dari lingkup proyek antara para pemangku kepentingan. Sebagai proyek berlangsung, ruang lingkup

       Pernyataan mungkin perlu direvisi atau disempurnakan untuk mencerminkan perubahan disetujui   

       lingkup proyek. Pernyataan lingkup harus mencakup, baik secara langsung atau melalui ref-

       erence ke dokumen lain:

∆         Proyek pembenaran-kebutuhan bisnis yang proyek ini dilakukan untuk

           address. Pembenaran proyek memberikan dasar untuk mengevaluasi masa depan

           pengorbanan.

∆         Proyek produk-ringkasan singkat dari deskripsi produk (produk

           deskripsi dibahas dalam Bagian 5.1.1.1).

∆        Project kiriman-daftar ringkasan tingkat subproducts yang penuh dan duduk-

           pengiriman isfactory menandai selesainya proyek. Misalnya, utama deliv-

           Erables untuk proyek pengembangan perangkat lunak mungkin termasuk komputer kerja

           kode, panduan pengguna, dan tutorial interaktif. Ketika diketahui, pengecualian

           harus diidentifikasi, tapi apa pun tidak secara eksplisit dimasukkan secara implisit dikecualikan.

∆         Project tujuan-kriteria kuantitatif yang harus dipenuhi untuk proyek

           agar dianggap berhasil. Tujuan Proyek harus menyertakan setidaknya biaya,

          jadwal, dan kualitas tindakan. Tujuan Proyek harus memiliki atribut

          (Misalnya, biaya), metrik (misalnya, Amerika Serikat [AS] dolar), dan mutlak atau

           relatif nilai (misalnya, kurang dari 1,5 juta). Unquantified tujuan (misalnya, "cus-

           Tomer kepuasan ") memerlukan berisiko tinggi pemenuhan sukses.

.2    Mendukung detail. Mendukung detail untuk pernyataan ruang lingkup harus dokumen-

       mented dan diatur sesuai kebutuhan untuk memudahkan penggunaannya oleh manajemen proyek      lainnya

proses. Mendukung rinci harus selalu menyertakan dokumentasi dari semua identi-

      fied asumsi dan kendala. Jumlah detail tambahan dapat bervariasi tergantung

      aplikasi daerah.

.3   Lingkup rencana pengelolaan. Dokumen ini menjelaskan bagaimana ruang lingkup proyek akan

      Dikelola dan bagaimana perubahan ruang lingkup akan diintegrasikan ke dalam proyek. Seharusnya

      juga mencakup penilaian stabilitas diharapkan dari ruang lingkup proyek (yaitu, bagaimana

      mungkin adalah untuk mengubah, seberapa sering, dan seberapa banyak). Manajemen lingkup

      Rencana juga harus mencakup gambaran yang jelas tentang bagaimana perubahan lingkup akan               I     iden-tified 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

luas dibingkai, berdasarkan pada kebutuhan proyek. Ini adalah komponen anak

dari rencana proyek (dijelaskan pada Bagian 4.1.3.1).

5.3  DEFINISI LINGKUP

        Definisi lingkup melibatkan pengelompokan deliverable proyek utama (seperti identifikasi-

        fied dalam laporan lingkup sebagaimana didefinisikan dalam Bagian 5.2.3.1) menjadi lebih kecil,                          lebih mankomponen agéable ke:

∆  Meningkatkan akurasi perkiraan biaya, durasi, dan sumber daya.

∆  Tentukan dasar untuk pengukuran kinerja dan kontrol.

∆  Memfasilitasi tugas tanggung jawab yang jelas.

Definisi lingkup yang tepat sangat penting bagi keberhasilan proyek. "Ketika ada ruang lingkup yang                  buruk Definisi, biaya tugas akhir dapat diharapkan akan lebih tinggi karena

tak terelakkan perubahan yang mengganggu ritme proyek, pengerjaan ulang penyebab, proyek        [         peningkatan.waktu, dan menurunkan produktivitas dan moral tenaga kerja "(3).

Inputs	Alat & Teknik	Output
.1Scope pernyataan .2Constraints .3Assumptions .4Semua perencanaan output .5History informasi	.1 Kerja kerusakan struktur template .2 Dekomposisi	.1 Kerja kerusakan struktur .2 Lingkup Pernyataan update

5.3.1  Masukan ke Definition Lingkup

.1        Lingkup pernyataan. Pernyataan lingkup dijelaskan dalam Bagian 5.2.3.1. Kendala

.2.      Kendala yang dijelaskan dalam Bagian 5.1.3.3. Ketika sebuah proyek dilakukan

           di bawah kontrak, kendala didefinisikan oleh ketentuan kontrak sering impor-

           tant pertimbangan selama definisi lingkup.

.3.      Asumsi dijelaskan dalam Bagian 4.1.1.5.

.4       Output perencanaan lainnya. Output dari proses dalam bidang pengetahuan lainnya

          harus ditinjau ulang untuk kemungkinan dampak pada lingkup definisi proyek.

.5       Historical informasi. Informasi sejarah tentang proyek-proyek sebelumnya harus

          dipertimbangkan selama definisi lingkup. Informasi tentang kesalahan dan kelalaian

          proyek-proyek sebelumnya harus sangat berguna.

5.3.2  Alat dan Teknik untuk Definisi Lingkup

.1        Template kerusakan struktur Kerja. Sebuah WBS (dijelaskan dalam Bagian 5.3.3.1) dari

           proyek sebelumnya sering dapat digunakan sebagai template untuk sebuah proyek baru.meskipun

           setiap proyek adalah unik, WBSs sering dapat "kembali" karena sebagian besar proyek akan

           menyerupai proyek lain sampai batas tertentu. Sebagai contoh, sebagian besar proyek dalam

           organisasi tertentu akan memiliki siklus hidup proyek yang sama atau serupa, dan demikian akan

           memiliki kiriman yang sama atau serupa yang diperlukan dari setiap tahap.

WBS ini adalah ilustrasi. Hal ini tidak dimaksudkan untuk mewakili lingkup proyek penuh dari setiap proyek tertentu, atau untuk menyiratkan bahwa ini adalah satu-satunya cara untuk mengatur WBS pada jenis proyek.

Gambar 5-2.         Contoh Kerja Struktur Breakdown untuk Produk Bahan Pertahanan

Banyak area aplikasi atau organisasi yang melakukan WBS memiliki standar atau semi-standar yang dapat digunakan sebagai contoh. Sebagai contoh, U.S.Department Pertahanan telah merekomendasikan standar WBS untuk Produk Bahan Pertahanan (MIL-HDBK-881). Sebagian dari salah satu contoh yang ditampilkan sebagai Gambar 5-2.

2.  Penguraian. Penguraian melibatkan pengelompokan kiriman  proyek besar atau sub kiriman menjadi lebih kecil, komponen lebih mudah ditangani sampai kiriman didefinisikan secara rinci cukup untuk mendukung pengembangan kegiatan proyek (perencanaan, pelaksanaan, pengendalian, dan penutupan). Dekomposisi melibatkan langkah-langkah utama berikut:

     1.  Mengidentifikasi point utama dari proyek, termasuk manajemen proyek. Point utama harus selalu didefinisikan dalam hal bagaimana proyek akan benar-benar terorganisir. Sebagai contoh:

·         Fase-fase siklus hidup proyek dapat digunakan sebagai tingkat pertama dari dekomposisi dengan deliverable proyek diulang pada tingkat kedua, seperti yang diilustrasikan pada Gambar 5-3.

·         Prinsip pengorganisasian dalam setiap cabang WBS dapat bervariasi, seperti digambarkan pada Gambar 5-4.

          2.  Memutuskan apakah biaya yang memadai dan perkiraan durasi dapat dikembangkan pada tingkat detail untuk setiap pengiriman. Arti dari memadai dapat berubah selama proyek, penguraian dari pengiriman yang akan diproduksi jauh di masa depan mungkin tidak dapat dilakukan. Untuk setiap pengiriman, lanjutkan ke Langkah 4 jika ada rincian yang memadai, ke Langkah 3 jika tidak ada, ini berarti bahwa kiriman yang berbeda mungkin memiliki tingkat yang berbeda dari penguraian.

3.  Mengidentifikasi adalah komponen dari pengiriman. Komponen harus dijelaskan dalam hal nyata, hasil diverifikasi untuk memfasilitasi pengukuran kinerja. Seperti dengan komponen utama,komponen harus didefinisikan dalam hal proyek dicapai. Jelas, hasil diverifikasi dapat mencakup layanan serta produk (misalnya, pelaporan status dapat digambarkan sebagai laporan status mingguan, untuk item diproduksi, komponen mungkin termasuk komponen individu beberapa ditambah perakitan akhir). Ulangi Langkah 2 pada setiap komponen penyusunnya.

4.  Memverifikasi kebenaran dekomposisi :

·         Apakah tingkat rendah item penting dan cukup untuk penyelesaian membusuk item? Jika tidak, komponen harus dimodifikasi (ditambahkan ke, 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? Dianggarkan? Ditugaskan ke spesifik unit organisasi (misalnya, departemen, tim, atau orang) yang akan menerima tanggung jawab untuk penyelesaian yang memuaskan dari item? Jika tidak, revisi yang diperlukan untuk memberikan kontrol manajemen yang memadai.

5.3.3 Output dari Definisi Lingkup

Fase awal                                                                                                                                                Fase selanjutnya WBS ini ilustrasi. Hal ini tidak dimaksudkan untuk mewakili lingkup proyek penuh dari setiap proyek tertentu, atau untuk menyiratkan bahwa ini adalah satu-satunya cara untuk mengatur WBS pada jenis proyek.

Rencana pengolahan air limbah

Perancangan

Gambar sipil

Gambar bangunan

Gambar susunan

Gambar Mekanis/tiruan

Gambar HVAC

Gambar pipa ledeng

Gambar Instrumensasi

Gambar Listrik

Kerja Otak

Penganginan lembah

Stasiun Pompa Limbah

Kendali udara bangunan

Lumpur bangunan

Pembangunan

          1.  Bekerja struktur rincian. Sebuah WBS adalah pengelompokan penyampaian  berorientasi proyek komponen yang mengatur dan menentukan ruang lingkup total proyek; bekerja tidak

Di wbs berada di luar lingkup dari proyek. Seperti dengan lingkup pernyataan, wbs yang sering digunakan untuk mengembangkan atau mengkonfirmasi umum pemahaman dari proyek lingkup. Setiap menurun tingkat mewakili yang semakin terperinci proyek deliverables. Bagian 5.3.2.2 menjelaskan pendekatan yang paling umum untuk mengembangkan sebuah wbs. Sebuah wbs itu biasanya disajikan dalam grafik yang membentuk, seperti yang digambarkan dalam angka 5-2, 5-3, dan 5-4; namun, yang wbs jangan bingung dengan metode presentasi menggambar sebuah kegiatan tidak terstruktur daftar dalam grafik yang membentuk tidak membuat sebuah wbs. Setiap item di wbs ini umumnya ditugaskan yang unik identifier; ini pengidentifikasi dapat menyediakan sebuah struktur untuk sebuah hirarkis penjumlahan dari biaya dan sumberdaya. Item pada tingkat terendah dari wbs dapat disebut sebagai bekerja paket, terutama di organisasi yang mengikuti diperoleh nilai praktek manajemen. Paket pekerjaan ini mungkin pada akhirnya menjadi lebih lanjut decomposed dalam sebuah subproject bekerja kerusakan struktur. Umumnya, pendekatan jenis ini digunakan ketika project manager menetapkan sebuah ruang lingkup bekerja untuk organisasi lain, dan organisasi lain Harus merencanakan dan mengelola lingkup pekerjaan di tingkat yang lebih rinci dari proyek manajer di utama proyek. Paket pekerjaan ini mungkin lebih lanjut decomposed dalam rencana proyek dan jadwal, seperti yang dijelaskan di bagian 5.3.2.2 dan 6.1.2.1. Deskripsi pekerjaan komponen yang sering dikumpulkan dalam sebuah wbs kamus. Sebuah wbs kamus akan biasanya termasuk deskripsi pekerjaan paket, serta perencanaan lain informasi seperti jadwal tanggal, biaya anggaran, dan staf tugas. Yang wbs jangan bingung dengan jenis lain dari “kerusakan struktur”  digunakan untuk menyajikan project information. Struktur lainnya yang umum digunakan dalam beberapa aplikasi daerah termasuk:

Contractual WBS (CWBS),, yang digunakan untuk menentukan tingkat pelaporan Penjual akan memberikan pembeli. CWBS umumnya termasuk kurang detail daripada WBS digunakan oleh penjual untuk mengelola penjual yang bekerja.

Organizational breakdown structure (OBS), yang digunakan untuk menunjukkan mana pekerjaan komponen telah ditugaskan untuk yang organisasi unit.

Resource breakdown structure (RBS), yang adalah variasi dari OBS dan biasanya digunakan ketika pekerjaan komponen yang ditugaskan untuk individu.

Bill of material (BOM), yang menyajikan pemandangan hirarkis fisik Majelis, subassemblies, dan komponen yang diperlukan untuk membuat produk yang diproduksi.

Project breakdown structure (PBS), yang pada dasarnya sama dengan WBS dilakukan dengan benar. PBS istilah secara luas digunakan dalam bidang aplikasi mana WBS salah istilah ini untuk merujuk kepada BOM.

2 Scope statement updates.Termasuk apapun modifikasi dari isi pernyataan lingkup (dijelaskan dalam Bagian 5.2.3.1). Stakeholder yang sesuai harus diberitahu yang diperlukan.

5.4 SCOPE VERIFICATION

Lingkup verifikasi adalah proses mendapatkan penerimaan formal lingkup proyek oleh stakeholder (sponsor, klien, pelanggan, dll). Hal ini membutuhkan meninjau hasil penyerahan dan bekerja untuk

memastikan bahwa semua diselesaikan dengan benar dan memuaskan. Jika proyek dihentikan awal, proses verifikasi lingkup harus menetapkan dan dokumen tingkat dan sejauh penyelesaian. Lingkup verifikasi berbeda dari kontrol kualitas (dijelaskan dalam bagian 8.3) terutama berkaitan dengan penerimaan hasil kerja sementara kontrol kualitas ini berkaitan dengan kebenaran dari hasil kerja. Proses ini umumnya dilakukan secara paralel untuk memastikan ketepatan dan penerimaan 

5.4.1 input untuk cakupan verifikasi

                1. hasil kerja. Hasil kerja adalah kiriman yang telah sepenuhnya atau sebagian diselesaikan merupakan output dari pelaksanaan rencana proyek (dibahas dalam bagian 4.2).

                2. dokumentasi produk. Dokumentasi produk adalah untuk menggambarkan produk proyek harus tersedia untuk diperiksa. Istilah yang digunakan untuk menggambarkan dokumentasi ini (rencana,spesifikasi,dokumentasi teknis, gambar,dll) bervariasi berdasarkan area(wilayah) aplikasinya.

                3. work breakdown structure. WBS membantu dalam mendefinisikan ruang lingkup dan harus digunakan untuk memverifikasi proyek pekerjaan (lihat bagian 5.3.3.1).

                4. scope statement. Scope statement mendefinisikan ruang lingkup dalam beberapa detail dan harus diverifikasi (lihat bagian 5.2.3.1).

                5. project plan. Project plan di jelaskan dalam bagian 4.1.3.1.

5.4.2 peralatan dan teknik untuk cakupan verifikasi.

                1. inspection. Inspection meliputi kegiatan seperti mengukur memeriksa, dan pengujian dilakukan untuk menentukan apakah hasil sesuai dengan persyaratan.berbagai inspeksi disebut ulasan, review produk, audit, dan penelusuran, dalam beberapa area aplikasi, istilah-istilah yang berbeda memiliki arti yang sempit dan spesifik.

5.4.3 output dari cakupan verifikasi

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

5.5 scope change control

                scope change control 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, dan c) mengelola perubahan yang sebenarnya ketika dan jika mereka terjadi. Lingkup perubahan kontrol harus benar-benar terintegrasi dengan proses kontrol lainnya (jadwal kontrol, pengendalian biaya, kontrol kualitas, dan lain-lain, seperti dibahas dalam Bagian 4.3).

INPUT	PERALATAN DAN TEKNIK	OUTPUT
1.       Work breakdown structure 2.       Performance report 3.       Change request 4.       Scope management plan	1.       Scope change control 2.       Performance meansurement 3.       Additional planning	1.       Scope changes 2.       Corrective action 3.       Lessons learned 4.       Adjusted baseline

5.5.1 input to scope change control

                1. work breakdown structure. WBS dijelaskan di bagian 5.2.2.1. Ini mendefinisikan dasar ruang lingkup proyek.

                2.perfomance reports. Laporan kinerja, dibahas dalam Bagian 10.3.3.1, memberikan informasi tentang kinerja lingkup, seperti yang penyerahan sementara telah selesai dan yang belum. Laporan kinerja juga dapat mengingatkan tim proyek untuk isu-isu yang dapat menyebabkan masalah di masa depan.

                3 change request. Permintaan perubahan dapat terjadi dalam banyak bentuk-lisan atau tertulis,langsung atau tidak langsung, eksternal atau internal dimulai, dan secara hukum wajib atau opsional. Perubahan mungkin memerlukan perluasan ruang lingkup atau memungkinkan menyusutkannya. Permintaan perubahan Kebanyakan adalah hasil dari:

                * Suatu peristiwa eksternal (misalnya, perubahan dalam peraturan pemerintah).

* Kesalahan atau kelalaian dalam mendefinisikan lingkup produksi (misalnya, kegagalan untuk memasukkan fitur yang dibutuhkan dalam desain sistem telekomunikasi)

* Kesalahan atau kelalaian dalam mendefinisikan lingkup proyek (misalnya, menggunakan BOM bukannya WBS)

* Sebuah nilai tambah perubahan (misalnya, sebuah proyek rehabilitasi lingkungan dapat mengurangi biaya dengan mengambil keuntungan dari teknologi yang tidak tersedia ketika lingkup awalnya didefinisikan)

* Menerapkan rencana darurat atau rencana solusi untuk menanggapi risiko, seperti yang dijelaskan dalam bagian 11.6.3.3.

4. scope management plan. Rencana pengelolaan lingkup dijelaskan dalam bagian 5.2.3.3.

5.5.2 peralatan dan teknik untuk scope change control

                1. scope changes. Suatu pengendalian perubahan lingkup mendefinisikan prosedur dimana lingkup proyek dapat diubah. Ini mencakup dokumen, sistem pelacakan, dan tingkat persetujuan yang diperlukan untuk perubahan otorisasi. Kontrol perubahan lingkup harus diintegrasikan dengan kontrol perubahan terpadu dijelaskan dalam bagian 4.2 dan, khususnya, dengan sistem di lingkup tempat kontrol produk. Ketika proyek ini dilakukan di bawah kontrak, pengendalian perubahan lingkup juga harus mematuhi semua ketentuan kontrak yang relevan.

                2. performance meansurement. kinerja measurement.Performance, dijelaskan dalam Bagian 10.3.2, 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 kontrol lingkup perubahan.

                3. additional planning. Beberapa proyek berjalan tepat sesuai rencana. Perubahan lingkup Calon mungkin memerlukan modifikasi WBS atau analisis pendekatan alternatif (lihat Bagian 5.3.3.1 dan 5.2.2.3, masing-masing).

5.5.3 output dari scope change control

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

                2.corrective action. Tindakan korektif adalah segala sesuatu dilakukan untuk membawa masa depan yang diharapkankinerja proyek sesuai dengan rencana proyek.

                3. lesson learned. Penyebab varians, alasan di balik korektif tindakan yang dipilih, dan jenis-jenis pelajaran dari kontrol lingkup perubahan harus didokumentasikan, sehingga informasi ini menjadi bagian dari sejarah database untuk kedua proyek ini dan proyek lain dari organisasi yang melakukan.

                4. adjusted baseline. Tergantung pada sifat dari perubahan, yang sesuai Dokumen dasar dapat direvisi dan diterbitkan kembali untuk mencerminkan perubahan disetujui dan membentuk dasar baru untuk perubahan masa depan.