© Augustus Cicala Jr 2020
G. CicalaThe Project Managers Guide to Microsoft Project 2019 https://doi.org/10.1007/978-1-4842-5635-0_4

4. Understanding Project Definition

Gus Cicala1 
(1)
Wilmington, DE, USA
 
  • Defining Your Project and Understanding the Definition Process

  • Initiating a Project

  • Planning the Scope of a Project

  • Scope Definition

  • Scope Verification

../images/492971_1_En_4_Chapter/492971_1_En_4_Figa_HTML.jpgLearning Objectives for This Chapter

At the end of the chapter, the reader should be able to:
  • Understand the basic principles of the project definition

  • Describe the process for initiating a project

  • Define the key components of the project scope document

  • Recognize the concepts of scope definition and scope verification

4.1 Defining Your Project and Understanding the Definition Process

The typical questions addressed in project definition documents are: Why are we doing this project? How many people are required and what types of skill will they need? How much will it cost? What are the deliverables? When will it be done? How will you do it?

Defining a Project Definition Document

Different organizations use different names for their definition documents. Some of the more common names are
  • Business plan  – Often used to gain support and approval for internal company projects.

  • Proposal  – Used between two separate firms, such as a manufacturer and a consulting company, to sell a project to a company.

  • Statement of work (SOW) – The formal attachment or appendix to the standard terms and conditions of a contract that describes the detailed approach for performing the project; sometimes part of a proposal.

  • Scope of work  – Another term used for a statement of work.

  • Project charter  – Like a business plan, it is often used to gain support and approval for internal company projects.

The Anatomy of a Definition Document

The most important and difficult part of the project is its beginning.... If done carefully, the project has a chance of success. If done carelessly, or not at all, the project is doomed to failure.

—Wysocki, Beck and Crane

Effective Project Management

In order to ensure that the project is properly defined, the project manager must meet with the key sponsor and stakeholders to develop a mutually agreed-upon definition for the project. Ideally, this step is completed before the project is funded and scheduled, but it may be necessary to fine-tune it once you are sure the project is approved. As mentioned at the beginning of this chapter, a thorough definition document will consider a number of key questions. To answer these questions, the document will usually consist of the following sections:
  • Executive summary  – A brief summary of the entire document

  • Objectives  – Clear, measurable statements defining the purpose of the project

  • Assumptions  – Documented answers to open key unknowns

  • Approach  – A plan of action for building the deliverables

  • Deliverables guidelines  – Outline of the project deliverables list

  • Business investment – Estimated project cost

  • Estimated schedule – Summary of the project work plan

  • Completion criteria  – How you’ll know when each major phase and the overall project are done

Defining What “Done” Means

One of the keys to avoiding scope creep is to know exactly when you’re done. The definition process is the project manager’s first and most critical opportunity to limit the project scope through clearly articulated exit or completion criteria for the major project deliverables and for the overall project.

The project definition document provides an opportunity for the project manager to define this completion criteria. A solid completion statement will tie the deliverables and their acceptance together in a logical way.

A sample completion statement might look like the following:
  • The design task will be complete when the project manager provides the design report, as outlined in the deliverables guidelines section, and it is accepted by the project sponsor according to the acceptance procedure in Appendix C.

Statements like this should not only be included in the completion criteria section of the definition document but also in the approach section to help clear up any doubts as to exactly what “done” means.

The most difficult part of writing a definition document is setting limits—that is, defining up front what the project does include, as well as what it does not include.

For example, a project charter that says “The goal of this project is to network all facilities in Maryland” leaves the project manager vulnerable to the dreaded, “While you’re at it, why don’t you include the facilities in Virginia?” On the other hand, a project charter that says “The goal of this project is to network all facilities in Maryland. Facilities in Virginia will be networked in a separate project during the next fiscal year” provides some defense when people ask for out-of-scope modifications.

Backing into Project End Dates

All too often, the project manager is assigned to a project after the project finish date, budget, and resources have been defined. If the project manager (or someone with similar skills) has not been involved in the initial definition of these important parameters, a work plan and schedule may not yet exist. The only way to achieve any degree of certainty in these figures is to lay out a schedule that demonstrates whether or not there is enough money, the right number and kind of people, and enough time to produce the expected deliverables.

Project managers affectionately call the process of forcing a project plan to fit into a predetermined project scope, schedule, and set of resources as backing into the schedule . Most project managers would prefer to build the plan before they commit to any kind of project completion date. The painfulness of this process highlights the importance of involving the project manager early in the definition of a project.

In the event that the schedule cannot support the key parameters, it is important that the project manager communicate this issue to the project sponsors as quickly as possible.

In the later modules on the subject of planning, we’ll take a look at what the project manager can do to build a plan against a fixed end date, budget, and number of resources.

4.2 Initiating a Project

The PMBOK Guide identifies four processes involved in the overall project definition process: project initiation, scope planning, scope definition, and scope verification.

Initiation involves formally recognizing that a new project exists or that an existing project should continue into its next phase. In some organizations, a project is not formally initiated until after completion of a feasibility study, a preliminary plan, or some other form of analysis. Some types of projects—especially internal service projects and new product development projects—are initiated informally, and a limited amount of work may be done to get the approvals needed for formal initiation.

Inputs to Initiation

Each aspect of the initiation process has its key components, as outlined here:
  • 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.

  • Strategic plan – Plan projects should be supportive of the performing organization’s strategic goals. As such, the strategic plan of the performing organization should be considered as a factor in project selection decisions.

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

  • Historical information – Historical information about the results of previous project selection decisions and previous project performance should be considered to the extent it is available. When initiation involves approval for the next phase of a project, information about the results of previous phases is often critical.

Tools and Techniques for Initiation

Project selection methods – Project selection methods generally fall into one of two broad categories:
  • 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) as well as specialized ones (analytic hierarchy process, logical framework analysis).

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.

Outputs from Initiation

Project charter – A project charter is a document that formally recognizes the existence of 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

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.

Identification of project manager – 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 and preferably before much project planning has been done.

Constraints – Constraints are factors that will limit the project management team’s options. For example, a predefined budget is a constraint that will limit the team’s options regarding scope, staffing, and schedule.

Assumptions – Assumptions are factors that, for planning purposes, will be presumed to be true, real, or certain. For example, if the date that a key person will become available is uncertain, the team may assume a specific start date. Assumptions generally involve a degree of risk.

4.3 Planning the Scope of a Project

Scope planning is the process of developing a written scope statement to serve as the basis for future project decisions. In particular, the scope statement will influence whether or not the project or phase has been completed successfully. The scope statement forms the basis for an agreement between the project team and the project customer by identifying both the project objectives and the major project deliverables. Under some circumstances, particularly if the major deliverables and project objectives have been identified, this process may involve little more than creating the written document.

Inputs to Scope Planning

  • Product description

  • Project charter

  • Constraints

  • Assumptions

Tools and Techniques for Scope Planning

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

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

Alternatives identification – This is a catchall term for any technique used to generate different approaches to the project. There are a variety of general management techniques used here, the most common of which are brainstorming and lateral thinking.

Expert judgment – Expert judgment was described in Section 4.2, “Initiating a Project.”

Outputs from Scope Planning

Scope statement – The scope statement provides a documented basis for making future project decisions and for confirming or developing a common understanding of project scope among the stakeholders. As the project progresses, the scope statement may need to be revised or refined to reflect 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.

  • Project product – A brief summary of the product description.

  • Project deliverables – A list of the summary-level sub-products 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; must include at least cost, schedule, and quality measures. Project objectives should have an attribute (cost), a yardstick (US dollars), and an absolute or relative value (less than 1.5 million). Un-quantified objectives (customer satisfaction) entail high risk.

Supporting detail – Supporting detail for the scope statement should be documented and organized for easy use and should always include all identified assumptions and constraints.

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—that is, 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, depending on the needs of the project. It is a part of the overall project plan.

4.4 Scope Definition

Scope definition involves subdividing the major project deliverables identified in the scope statement into smaller, more manageable components to
  • Improve the accuracy of cost, time, and resource estimates

  • Define a baseline for performance measurement and control

  • Facilitate clear responsibility assignments

Proper scope definition is critical to project success. Poor scope definition leads to higher costs because of the inevitable changes (scope creep), which disrupt project efficiency, increase project time, and lower the productivity and morale of the project team.

Inputs to Scope Definition

Scope Statement
  • Constraints – When a project is done under contract, the constraints defined by contractual provisions are often important considerations during scope definition.

Assumptions
  • Other planning outputs – The outputs of the processes in other knowledge areas should be reviewed for possible impact on project scope definition.

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

Tools and Techniques for Scope Definition

Work breakdown structure templates – A work breakdown structure (WBS) from a previous project can often be used as a template for a new project. Although each project is unique, WBSs can often be re-used since most projects will resemble previous projects within a given organization with similar project lifecycles and similar deliverables required from each phase.

Decomposition – Decomposition involves subdividing the major project deliverables into smaller, more manageable components until the deliverables are defined in sufficient detail to support future project activities (planning, executing, controlling, and closing). Decomposition involves the following major steps:
  1. 1.

    Identify the major elements of the project – In general, the major elements will be the project deliverables and project management. However, the major elements should always be defined in terms of how the project will actually be managed.

     
  2. 2.

    Decide if adequate cost and duration estimates can be developed at this level of detail for each element – 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 element, proceed to Step 4 if there is adequate detail and to Step 3 if there is not, as different elements may have differing levels of decomposition.

     
  3. 3.

    Identify constituent elements of the deliverable – Constituent elements should be described in terms of tangible, verifiable results in order to facilitate performance measurements. As with the major elements, the constituent elements should be defined in terms of how the work of the project will actually be accomplished. Tangible, verifiable results can include services as well as products. For example, status reporting could be described as weekly status reports. Repeat Step 2 on each constituent element.

     
  4. 4.
    Verify the correctness of the decomposition:
    • Are the lower-level items both necessary and sufficient for completion of the item decomposed? If not, the constituent elements 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 team or person who will accept responsibility for satisfactory completion of the item? If not, revisions are needed to provide adequate management control.

     

Outputs from Scope Definition

Work breakdown structure – A work breakdown structure (WBS) is a deliverable-oriented grouping of project elements 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 elements.

A WBS is normally presented in chart form. 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 are often known collectively as the code of accounts . The items at the lowest level of the WBS are often referred to as work packages. These work packages may be further broken down in the activity definition process.

4.5 Scope Verification

Scope verification is the process of formalizing acceptance of the project scope by the stakeholders (sponsor, client, customer, etc.). It requires reviewing work products and 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 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.

Inputs to Scope Verification

Work results – Assessments such as which deliverables have been fully or partially completed and what costs have been incurred or committed; work results are an output of project plan execution.

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.

Tools and Techniques for Scope Verification

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.

Outputs from Scope Verification

Formal acceptance – A documentation that the client or sponsor has accepted the product of the project or phase must be prepared and distributed.

../images/492971_1_En_4_Chapter/492971_1_En_4_Figb_HTML.jpg End of Chapter Quiz Questions

  •    1–5.   Match the project definition document name listed in the left column of the following table to the correct description from the right column by entering the letter that the name corresponds to in the blank line. Note: One answer applies to two of the questions.

1. Business plan ____

A. Used between two separate firms, such as a manufacturer and a consulting company, to sell a project to a company

2. Proposal ____

 

3. Statement of work ___

B. Another term used for a statement of work

4. Scope of work ____

C. Often used to gain support and approval for internal company projects

5. Project charter ____

D. The formal attachment or appendix to the standard terms and conditions of a contract that describes the detailed approach for performing the project

  1. 6.

    What sections does a project definition document usually contain?

    ../images/492971_1_En_4_Chapter/492971_1_En_4_Figc_HTML.gif

     
  2. 7.

    Define the term “project objectives.”

     
  • ___________________________________________________________ ___________________________________________________________

  1. 8.
    Which of the following are clear, measurable statements defining the purpose of the project?
    1. A.

      Executive summary

       
    2. B.

      Objectives

       
    3. C.

      Assumptions

       
    4. D.

      None of the above

       
     
  2. 9.

    What are deliverables guidelines?

     
  • ______________________________________________________________________________________________________________________

  1. 10.

    Fill in the blank: The summary of the project work plan is the ___________________________________________________________.

     
  2. 11.

    Which section of the project definition document can you tell when each major phase is done?

     
  • ______________________________________________________________________________________________________________________

  1. 12.

    Fill in the blank: A solid completion statement will tie the ________ and their ________ together in a logical way.

     
  2. 13.

    A project charter says “The goal of this project is to network all facilities in Delaware.” What is a potential issue with this charter, and how can it be improved?

     
  • ___________________________________________________________ ___________________________________________________________

  1. 14.

    Describe what is meant by “backing into the schedule.”

     
  • ___________________________________________________________ ___________________________________________________________

  1. 15.

    What are the four processes involved in the overall project definition as identified by the PMBOK Guide?

     
  • ___________________________________________________________ ___________________________________________________________

  1. 16.

    True or False: Some types of projects are initiated informally, and a limited amount of work may be done to get the approvals needed for formal initiation.

     
  • 17–28. Fill in the Inputs, Tools and Techniques, and Outputs for each of the following phases:

  • Initiation

  • Inputs: ____________________________________________________

  • Tools and Techniques:________________________________________________

  • Outputs: ___________________________________________________

  • Scope Planning

  • Inputs: ____________________________________________________

  • Tools and Techniques:________________________________________________

  • Outputs: ___________________________________________________

  • Scope Definition

  • Inputs: ____________________________________________________

  • Tools and Techniques:________________________________________________

  • Outputs: ___________________________________________________

  • Scope Verification

  • Inputs: ____________________________________________________

  • Tools and Techniques:________________________________________________

  • Outputs: ___________________________________________________

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.14.27.68