• Shuffle
    Toggle On
    Toggle Off
  • Alphabetize
    Toggle On
    Toggle Off
  • Front First
    Toggle On
    Toggle Off
  • Both Sides
    Toggle On
    Toggle Off
  • Read
    Toggle On
    Toggle Off
Reading...
Front

Card Range To Study

through

image

Play button

image

Play button

image

Progress

1/163

Click to flip

Use LEFT and RIGHT arrow keys to navigate between flashcards;

Use UP and DOWN arrow keys to flip the card;

H to show hint;

A reads text to speech;

163 Cards in this Set

  • Front
  • Back
  • 3rd side (hint)
SCOPE
.
.
.
.
.
.
Project Scope Management
.
.
The process required to ensure that the project includes all the work required, and only the work required, to complete the project successfully.
.
.
Product Scope
.
.
Describes the product to be delivered. Completion of the product scope is measured against the requirements.
.
.
Project Scope
.
.
Describes the work required to deliver the product. Completion of the project scope is measured against the project plan.
.
.
.
.
Project Scope Management (5)
.
.
1.      Initiation
.
.
Process of formally recognizing that a new project exists or that an existing project should continue into the its next period
.
.
2.      Scope Planning
.
.
Process of developing a written scope statement as the basis for future project decisions including, in particular, the criteria used to determine if the project or phase has been completed successfully.
.
.
3.      Scope Definition
.
.
Involves subdividing the major project deliverables into smaller, more manageable components.
.
.
4.      Scope Verification
.
.
Process of formalizing acceptance of the project scope by the stakeholders. It requires reviewing work products and results to ensure that all were completed correctly and satisfactorily.
.
.
5.      Scope Change Control
.
.
Is concerned with a) influencing the factors which create scope changes to ensure that changes are beneficial, b) determining that a scope change has occurred, and c) managing the actual changes when and if they occur.
.
.
Scope Initiation (5.1)
.
.
1.      Inputs
.
.
a.      Product description
.
.
Documents the characteristics of the product or service that the project was undertaken to create. Less detail in the early phases.
.
.
b.      Strategic plan
.
.
All projects should be supportive of the performing organization’s strategic goal
.
.
c.       Project selection criteria
.
.
Typically defined in terms of the product of the project. Should cover the full range of possible management concerns.
.
.
d.      Historical information
.
.
Results of previous project selection decision and previous project performance should be considered.
.
.
2.      Tools and Techniques
.
.
a.      Project selection methods
.
.
1)      Decision Models
.
.
a)      Benefit measurement methods – Comparative approaches, scoring models. Benefit contribution or economic models
.
.
b)      Constrained optimization methods – Mathematical models using linear, non-linear and other techniques
.
.
b.      Expert judgment
.
.
Often required to assess the inputs to his process
.
.
3.      Outputs
.
.
a.      Project charter
.
.
A document the formally recognizes the existence of a project. Issued by a manager external to the project and at a level appropriate to the needs of the project. It is the deliverable for the concept phase of the project. At a minimum, it should describe the responsibilities and authority of the project and functional managers.
.
.
b.      Project manager identified/assigned
.
.
Project manager should be identified and assigned as early as is feasible.
.
.
c.       Constraints
.
.
Factors that limit the project management team’s options.
.
.
d.      Assumptions
.
.
Factors that, for planning purposes, will be considered to be true, real or certain.
.
.
Scope Planning (5.2)
.
.
1.      Inputs
.
.
a.      Product description
.
.
Documents the characteristics of the product or service that the project was undertaken to create. Less detail in the early phases.
.
.
b.      Project charter
.
.
A document the formally recognizes the existence of a project. Issued by a manager external to the project and at a level appropriate to the needs of the project
.
.
c.       Constraints
.
.
Factors that limit the project management team’s options.
.
.
d.      Assumptions
.
.
Factors that, for planning purposes, will be considered to be true, real or certain.
.
.
2.      Tools and Techniques
.
.
a.       Product analysis
.
.
Involves developing a better understanding of the product of the project.
.
.
b.      Benefit/cost analysis
.
.
Involves estimating tangible and intangible costs (outlays) and benefits (returns) of various project alternatives and then using financial measures to assess the relative desirability of the identified alternatives.
.
.
c.       Alternatives identification
.
.
Catchall term for any technique used to generate different approaches to the project. (i.e. brainstorming)
.
.
d.      Expert judgment
.
.
3.      Outputs
.
.
a.      Scope statement
.
.
Provides a documented basis for making future project decisions and for confirming or developing common understanding of project scope among the stakeholders. Statement must include what is not going to be done. Four major sections are:
.
.
1)      Project justification – Describes the business need why this project was undertaken.
.
.
2)      Project product – Brief product description
.
.
3)      Project deliverables – A list of the summary level sub-projects
.
.
4)      Project objectives – Quantifiable criteria that must be met to be considered successful. Must include following measures:
.
.
a)      Cost
.
.
b)      Schedule
.
.
c)      Quality
.
.
b.      Supporting details
.
.
Should be documented and organized as needed to facilitate its use by other PM processes.
.
.
c.       Scope management plan
.
.
Describes how project scope will be managed and how scope changes will be integrated into the project. It must also include an assessment of the expected stability of the project scope.
.
.
Scope Definition (5.3)
.
.
1.      Inputs
.
.
a.      Scope statement
.
.
b.      Constraints
.
.
c.       Assumptions
.
.
d.      Other planning outputs
.
.
e.       Historical information
.
.
2.      Tools and Techniques
.
.
a.       Work breakdown structure templates
.
.
A WBS from a previous project can be used as a template for a new project.
.
.
b.      Decomposition
.
.
Involves estimating tangible and intangible costs (outlays) and benefits (returns) of various project alternatives and then using financial measures to assess the relative desirability of the identified alternatives.
.
.
1)      Identify the major elements of the project
.
.
2)      Estimate elements
.
.
3)      Identify constituent elements of the deliverables
.
.
4)      Verify the correctness of the decomposition
.
.
3.      Outputs
.
.
a.      Work breakdown structure
.
.
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. Items at the lowest level of the WBS are work packages.
.
.
Scope Verification (5.4)
.
.
1.      Inputs
.
.
a.      Work results
.
.
Which deliverables have been fully or partially completed, what costs have been incurred or committed.
.
.
b.      Product documentation
.
.
Documents produced to describe the project’s products must be available for review.
.
.
2.      Tools and Techniques
.
.
a.       Inspection
.
.
Includes activities such as measuring, examining and testing undertaken to determine whether results conform to requirements. Purpose is to specifically identify deficiencies, gaps and errors against the project documentation.
.
.
3.      Outputs
.
.
a.      Formal acceptance
.
.
Documentation that the client or sponsor has accepted the product of the project or phase must be prepared and distributed.
.
.
Scope Change Control (5.5)
.
.
1.      Inputs
.
.
a.      Work breakdown structure
.
.
Defines the project’s scope baseline; Basis for measuring and reporting scope performance.
.
.
b.      Performance reports
.
.
Provide information on scope performance such as which interim products have been completed and which have not.
.
.
c.       Change requests
.
.
May require expanding the scope or may allow shrinking it. Change requests are the result of one of the following:
.
.
1)      External event (governmental regulation)
.
.
2)      Error or omission in defining the scope of the product
.
.
3)      Error or omission in defining the scope of the project
.
.
4)      A value-added change
.
.
d.      Scope management plan
.
.
Describes how changes will be integrated into the project
.
.
2.      Tools and Techniques
.
.
a.       Scope change control system
.
.
Defines the procedures by which the scope project may be changed. It includes the paperwork, tracking systems and approval levels necessary for authorizing changes.
.
.
b.      Performance measurement
.
.
Techniques to help access the magnitude of any variations that occur in the performance project.
.
.
c.       Additional planning
.
.
Adjustments made to the project plan to accommodate the additions/deletions of activities
.
.
3.      Outputs
.
.
a.      Scope changes
.
.
Any modification to the authorized project scope as defined by the approved WBS. Scope changes often requirement adjustments to cost, time quality or other project objectives.
.
.
b.      Corrective action
.
.
Activity performed to bring expected future project performance into line with the project plan.
.
.
c.       Lessons learned
.
.
Causes of variances, reasoning behind corrective actions and other type of lessons learned from scope change.
.
.
.
.
.
.
.
.
.
.
a.       Assess the range of the variables being considered and determine the probability distribution most suited to each.
.
.
b.      For each variable within its specific range, select a value randomly chosen, taking account of the probability distribution for the occurrence of the variable.
.
.
c.       Run a deterministic analysis using the combination of values selected for each one of the variables.
.
.
d.      Repeat steps 2 and 3 a number of times to obtain the probability distribution of the result. Typically between 100 and 1000 iterations are required depending on the number of variables and the degree of confidence required.
.
.
6.      Decision Tree Analysis
.
.
A feature of project work is that a number of options are typically available in the course of reaching the final results. An advantage of decision tree analysis is that it forces consideration of the probability of each outcome. Thus, the likelihood of failure is quantified and some value is place on each decision. This form of risk analysis is usually applied to cost and time considerations, both in choosing between different early investment decisions, and later in considering major changes with uncertain outcomes during project implementation.
.
.
7.      Utility Theory
.
.
Utility theory endeavors to formalize management’s attitude towards risk, an approach that is appropriate to decision tree analysis for the calculation of expected values, and also for the assessment of results from sensitivity and probability analyses. However, in practical project work Utility Theory tends to be viewed as rather theoretical.
.
.
8.      Decision Theory
.
.
Is a technique for assisting in reaching decisions under uncertainty and risk. All decisions are based to some extent on uncertain forecasts. Given the criteria selected by the decision-maker, Decision Theory points to the best possible course whether or not the forecasts are accurate.
.
.
The Quality Risk
.
.
This risk can best be expressed by the question: “What if the project fails to perform as expected during its operational life?” This may well be the result of less than satisfactory quality upon project completion, and is especially true if quality is not given due attention during the project life cycle. Since the in-service life of the resulting product is typically much longer than the period required to plan and produce that product, any quality shortcomings and their effects may surface over a prolonged period of time.
.
.
Consequently, of all the project objectives, conformance to quality requirement is the one most remembered long after cost and schedule performance have faded into the past. It follows that quality management can have the most impact on the long-term actual or perceived success of the project.
.
.
Risk Perceptions
.
.
1.      People do not, in fact, demand zero risk. They take risk every day, both consciously and subconsciously, and they are willing and able to take benefit/risk decisions, as in driving and speeding.
.
.
2.      Peoples’ judgment of degrees of risk is not, however, coincident with most methodologies for measuring risk statistically. The public may greatly underestimate familiar risks (e.g. driving) while greatly overestimating unfamiliar risks (e.g. buying a home near a nuclear facility).
.
.
3.      A variety of emotional, not logical, factors control risk perceptions:
.
.
a.       Primary is the sense of personal control and the ability to mange the risk
.
.
b.      Secondary are qualities of familiarity and conversely, dread. The greater the unfamiliarity and potential for connection to gruesome, the more it is likely to be judged as highly risky and therefore unacceptable.
.
.
4.      Once established, risk perceptions are extremely hard to change. New information may be absorbed by the intellect, but it is not readily absorbed at an emotional level.
.
.
5.      Risk perceptions reside fundamentally at an emotional level.
.
.