Project+/Printable version

From Wikibooks, open books for an open world
Jump to navigation Jump to search


Project+

The current, editable version of this book is available in Wikibooks, the open-content textbooks collection, at
https://en.wikibooks.org/wiki/Project%2B

Permission is granted to copy, distribute, and/or modify this document under the terms of the Creative Commons Attribution-ShareAlike 3.0 License.


Initiating

IDENTIFY PROJECT PURPOSE[edit | edit source]

Key Points[edit | edit source]

  • identify business objective i.e. stated goal of the project
  • define the opportunity/problem

Goal[edit | edit source]

  • desired end result
  • often synonymous with objective
  • may be a high-level objective that has less-than-complete definition

Objective[edit | edit source]

  • something to be achieved
  • desired outcomes of the project or any part of the project
  • measued in in terms of concrete deliverables and behavioral outcomes
  • it has to be visualisez before

EVALUATE BUSINESS JUSTIFICATION[edit | edit source]

Key Points[edit | edit source]

  • Identify high-level business-related requirements, outcomes, and criteria for success
  • identify low-level needs and expectations
  • establish boundaries for project budget, duration, and risk

Triple Constraints[edit | edit source]

  • scope
  • schedule
  • budget

Business Case[edit | edit source]

  • the information that describes the justification for the project
  • project is justified if expected benefits outweigh estimated costs and risks
  • often complex
  • may require
    • Financial Analysis
    • technical analysis
    • organization impact analysis
    • feasibility study

Request for Proposal (RFP) AKA Request for Quote (RFQ).[edit | edit source]

  • describes
    • need for products and/or services
    • conditions under which product/services are to be provided
  • purpose
    • solicit bids or proposals from prospective suppliers

IDENTIFY MAJOR STAKEHOLDERS & THEIR ROLES[edit | edit source]

Project Manager[edit | edit source]

  • key stakeholder
  • responsible and accountable for managing a project's planning and performance
  • single point of accountability for a project

Customer or Client[edit | edit source]

  • key stakeholder
  • person or organization that is the principle beneficiary of the project
  • Generally has a significant authority regarding
    • scope definition
    • whether the project should be initiated and/or continued.

Performing Organization[edit | edit source]

  • key stakeholder
  • company or group doing the work

[edit | edit source]

  • key stakeholder
  • builds and maintains executive commitment
  • allocates organization resources (capital, human, etc.)
  • provides direction
  • has authority to settle disputes between project staff & functional staff

Champion[edit | edit source]

  • senior exec who promotes and defends the project

Project Steering Committee[edit | edit source]

  • execs from functional areas that provide
    • guidance
    • strategic input and direction
    • enlist cooperation from their functional group
    • high level project approval

Project Team (decide later? In planning phase?)[edit | edit source]

  • anybody who is doing work on the project
  • includes contractors and consultants

Authority[edit | edit source]

  • ability to get other people to act based on your decisions
  • based on perception that a person has been officially empowered to issue binding orders

Power[edit | edit source]

  • ability to influence the actions of others
  • may come from
    • formal delegation of authority
      • charter gives PM this
    • reference power
      • personality
    • subject matter expertise
      • respect earned from skills
    • ability to influence rewards and penalties
      • rewarded or coercive authority
    • other sources.

Stakeholder[edit | edit source]

  • anybody and everybody with a stake in the project
    • clients
    • sponsors
    • performers
    • general public
    • family and friends of direct participants
    • others?

Managerial Structures[edit | edit source]

  • functional
  • project
  • matrix

Matrix Organization[edit | edit source]

  • business structure in which people are assigned to
    • functional group
      • departments, disciplines, etc
    • projects or processes
      • cut across the organization
      • require resources from multiple functional groups.

DEFINE THE SCOPE OR THE PROJECT[edit | edit source]

Scope Components[edit | edit source]

  • function
  • performance

Five (scope?) Constants[edit | edit source]

  • project end date
  • project ownership
  • completion criteria
  • rigorous change control procedure
  • "best practices" life cycle for this type of project

Statement of Scope AKA Statement of Work (SOW)[edit | edit source]

  • description of the scope of a project
  • centered on the major deliverables and constraints
  • develops and confirms an understanding of project scope
  • typically requires more time to create than WBS or charter
  • review of the scope documents held before proceeding to project planning phase
  • complete after the PM and the sponsor agree that objectives will be met
  • establishes procedure to request changes to a project scope
  • end-users representative approves technical changes

SOW-PROCS (mnemonic)[edit | edit source]

  • (P) - Policies and Procedures
  • (R) - Requirements
  • (O) - Overview
  • (C) - Criteria for Vendor Purchase
  • (S) - Specifications

Scope: three dimensions[edit | edit source]

  • product
    • full set of features and functions
  • project
    • work that has to be done to deliver the product
  • impact
    • involvement by performing and client organizations.
    • effect on performing and client organizations.

Scope Change[edit | edit source]

  • any change in the definition of the project scope
  • can result from:
    • changes in client needs
    • discovery of defects or omissions
    • regulatory changes
    • other

Scope Change Control AKA Scope Change Management[edit | edit source]

  • process of making sure that changes to the scope are consciously evaluated
  • making sure that implications are considered in making a decision to
    • make the change
    • postpone it
    • reject it

Scope Creep[edit | edit source]

  • changes in scope over the life of a project
  • unconscious growth of the project scope
  • results from uncontrolled changes to requirements
  • managed by implementing a rigid change control process

Scope Definition[edit | edit source]

  • breaks down major deliverables into more manageable components
  • makes verification, development, and project control, easier
  • may be part of requirements definition and/or design

Scope Planning[edit | edit source]

  • development of a statement of project's
    • principle deliverables
    • justification (business case)
    • objectives
  • part of requirements definition

Scope Verification[edit | edit source]

  • process to ensure that all project deliverables have been completed satisfactorily
  • associated with acceptance of the product by clients and sponsors.

BUILD CONSENSUS AND OBTAIN WRITTEN APPROVAL (objectives)[edit | edit source]

Secure Written Confirmation Of[edit | edit source]

  • customer expectations
  • problem/opportunity
  • deliverables
  • strategy
  • completion date
  • Budget
  • risks
  • priority
  • sponsor
  • resources
  • resources availability

- all the above documented in the charter?

Methods to build consensus[edit | edit source]

  • negotiating
  • interviewing
  • meetings
  • memos

Strategies To build And Maintain Senior Management Support[edit | edit source]

  • involve mgmt in defining project concept
  • involve mgmt in defining scope
  • involve mgmt in reviewing and approving deliverables
  • provide role for mgmt as spokesperson/advocate

Consensus[edit | edit source]

  • unanimous agreement among the decision-makers
  • requires conviction that the decision will adequately achieve objectives
  • if one person is not in agreement then there is no consensus



Planning

REQUIREMENTS ANALYSIS[edit | edit source]

Requirements analysis is the phase of the project where the requirements of a project are carefully defined. A requirement is a documented need or a description of what a system must accomplish. It is a statement that identifies a necessary attribute, capability, characteristic, or quality of the product of a project.

Product[edit | edit source]

The project's material outcome is its product. The product may be a service, event or a material object. It includes all necessary aspects of the deliverable including training, documentation, etc. Requirements focus on the product itself rather than the ways of achieving the product, leaving the implementation details for later. Requirements that focus on how the product is achieved are said to have implementation bias.

Requirements Statement[edit | edit source]

A requirements statement is a detailed accounting of project objectives. It describes the features, functions and performance constraints of the product. It provide the basis for accepting the product, or describes what must be accomplished for the product to be accepted.

The following are some useful techniques to understand user requirements:

  • Prototyping
    • Pilot
  • Use Case Modeling
    • describes relationship of a software product and its environment
  • JAD (Joint Application Design)
  • UML (Unified Modeling Language)
    • management tool for object oriented software design

Project Description Document[edit | edit source]

The Project Description Document and the Project Requirements are used to identify:

  • the high-level value of the project to the sponsor and users
  • gaps in the requirements when compared to the project scope
  • whether the list of requirements is complete and valid enough to move on to next phase

Project Requirements Document - OTN[edit | edit source]

  • all system inputs are defined
  • all system outputs are defined
  • requirements are validated with sponsors and users
  • business rules, special logic, and calculations are defined
  • gaps between the requirements and the scope are identified and filled

Requirement Characteristics[edit | edit source]

  • necessary range of inputs
  • carefully evaluated to be within the project scope
  • complete, accurate, and valid

Types Of Requirements[edit | edit source]

  • business
  • functional
  • technical

Traceability[edit | edit source]

  • track a requirement to documented need

Configuration Management[edit | edit source]

  • ensure descriptions of projects products are correct and complete
  • document physical and functional design characteristics

REFINE SCOPE[edit | edit source]

  • Scope statement will be included in the project plan
  • Scope of a project is usually defined during the initiation phase of a project but the scope can change as needed as more analysis is done

WBS (work breakdown structure)[edit | edit source]

WBS key concepts[edit | edit source]

  • hierarchical task list
  • decomposition of project into a collection of work units
  • use to determine the project work effort
  • basis for planning, schedule, budget
  • used to estimate resource requirements, activity durations, and costs
  • required to create a Gantt chart
  • will be included in the project plan statement
  • Phase = highest level element of the WBS
  • Work Package = lowest level element of the WBS
  • one person responsible for each item, although many may work on that item
  • formal approval should be obtained for each deliverable
  • authority to sign off should be clearly defined
  • depicted as
    • tree diagram (or hierarchy chart)
    • list in outline form with detailed items subordinated to higher-level items.
  • schedule and budget contained in WBS?

Activity or Task[edit | edit source]

  • may be of any size (a project is a very large activity or task)
  • sometimes the terms are synonymous
  • sometimes the terms are used to denote a piece of work at a particular level in WBS
    • e.g. a phase is broken into activities, and an activity into tasks
  • defined in each activity or task
    • duration
    • cost
    • resources
    • deliverables

SMART: activities or tasks should be[edit | edit source]

  • Specific
  • Measurable
  • Assignable
  • Realistic
  • Time-framed

Phase[edit | edit source]

  • highest level element of the WBS
  • grouping of activities in a project
  • meets a major milestone by providing a significant deliverable
    • e.g. requirements definition or product design document
  • a project is broken down into a set of phases for control purposes
  • phase is usually the highest level of breakdown of a project in the WBS.

Work Package[edit | edit source]

  • lowest level of the WBS at which project accounting is performed
  • usually a week or so in duration and performed by an individual or small work group

"Work Package" v "Task" v "Work Unit" v "Activity"[edit | edit source]

  • "task" or "work unit" or "activity" = all ambiguous
  • task could be high level, mid-level, or low level, i.e. summary task, sub-task
  • work package lowest level for which accounting is performed - unambiguous

best practices[edit | edit source]

  • keep work unit duration as short as possible
  • work teams should be small

hierarchy format e.g.[edit | edit source]

  • 1.0 Main task 1
    • 1.1 Subtask 1
    • 1.2. Subtask 2
  • 2.0 Main task 2
  • 3.0 Main task 3

Deliverable[edit | edit source]

  • any item produced as the outcome of a project or any part of a project
  • project deliverable is differentiated from interim deliverables
  • interim deliverables result from activities within the project
  • deliverable must be tangible and verifiable
  • every element of the WBS (activity or task) must have one or more deliverables.

BUILD TEAM[edit | edit source]

Issues[edit | edit source]

  • Contract Labor
  • Outsourcing

Recruit The Best Candidates[edit | edit source]

  • ask mainly open questions
  • develop the interview questions
  • develop a mechanism to score responses
  • develop a comprehensive job specification
  • identify skills, knowledge, and attitudes required for the position

Attributes To Look For In A Candidate[edit | edit source]

  • a positive, team-player attitude
  • a goal oriented, Can do disposition
  • a knowledge of systems and user documentation

Resource Capabilities And Resource Availability[edit | edit source]

  • have the greatest impact on the actual duration of project tasks
  • have the greatest impact on the estimated per unit labor cost

RESPONSIBILITY ASSIGNMENT MATRIX[edit | edit source]

Maps Work To People[edit | edit source]

Authority Structure?[edit | edit source]

ESTIMATION TECHNIQUES[edit | edit source]

Top Down[edit | edit source]

  • estimate effort/cost/duration/risk of project or phase
  • looking at the project as a whole
  • comparing project to previously performed similar projects
  • methods of comparison
    • analogous estimating
    • direct comparison
    • parametric estimating
    • using an algorithm
    • experts
    • estimating from memory

ROM (Rough Order of Magnitude)[edit | edit source]

  • estimate effort/cost/duration/risk of project or phase
  • done early in a projects to get a ball park figure
  • about the same as top down.

Parametric[edit | edit source]

  • estimate effort/cost/duration or project or phase
  • using an algorithm
  • parameters that represent attributes of the project used to calculate
  • used in top-down estimating.

Analogous[edit | edit source]

  • estimate effort/cost/duration/risk of project or phase
  • estimating using similar projects or activities as a basis for determining
  • used in top-down estimating

Bottom Up[edit | edit source]

  • estimate effort/cost/duration or project or phase
  • breaking down into activities, tasks and sub-tasks
  • estimating the effort, duration and cost of each task and sub-task
  • combine all component estimates to determine the full estimate
  • determining duration through a bottom-up approach requires
    • sequencing and resource leveling to be done as part of the scheduling process.

Cost and Time Estimating Issues[edit | edit source]

  • scope
  • task requirements
  • resource availability
  • resource expense
  • original estimations vs actuals

FTE = Full Time Equivalent[edit | edit source]

SCHEDULE[edit | edit source]

Process For Creating Schedule[edit | edit source]

  • estimate time and resources for each work unit
    • historical data
    • expert judgment
  • determine dependencies between work units
  • level the resources
  • create checklists for each work unit
  • understand dependency relations between work units
    • FF, SS, FS, SF

Five Lists Required To Generate Schedule[edit | edit source]

  • deliverables
  • project tasks
  • required skills
  • available skills
  • time and resources per task

Items Needed To Justify The Schedule[edit | edit source]

  • the project critical path
  • actions you have taken
  • the tasks with time requirements

Sequencing Tasks[edit | edit source]

  • part of the scheduling process
  • tasks are positioned serially or parallel based on dependencies between them
  • sequencing results in a task network.

Dependencies: Types Of[edit | edit source]

  • mandatory
    • inherent in the nature of the work
    • often involve physical limitations
    • hard logic
  • discretionary
    • defined by project management team
    • soft logic
  • external
    • relationship between project and non-project activities

Milestones[edit | edit source]

  • points in time when a deliverable or set of deliverables is available
  • denote a significant event such as the completion of a phase
  • SMART criteria = Specific, Measurable, Assignable, Realistic, Time-framed
  • on gantt chart represented by black diamonds
  • on tracking gantt chart, slipped milestones represented by white diamond
  • an event: no duration or effort
  • must be preceded by one or more tasks
    • even the beginning of a project is preceded by a set of tasks, may be implied

Critical Path[edit | edit source]

  • path(s) in a project network that has the longest duration
  • series of activities that determines the earliest completion of the project
  • may be more than one critical path
  • critical path(s) may change during the project.

Float Or Slack[edit | edit source]

  • amount of time available for a task to slip before it delays the project end date
  • It is the difference between the task's early and late start dates.

Lead[edit | edit source]

  • minimum lapse of time between start of activity and start of overlapping activity

Lag[edit | edit source]

  • waiting time between two tasks

Gantt Chart[edit | edit source]

  • bar chart that depicts a schedule of activities and milestones
  • activities are listed along the left side of the chart
  • time line is listed along the top or bottom of the chart
  • activities are shown as horizontal bars
  • length of activity bars are equivalent to the duration of the activity
  • may be annotated with dependency relationships and other schedule-related information.

Network Diagram[edit | edit source]

  • graphic tool for depicting the sequence and relationships between tasks
  • forms of network diagrams
    • PERT Diagram
    • Critical Path Diagram
    • Arrow Diagram
    • Precedence Diagram

Pert (Program Evaluation And Review Technique)[edit | edit source]

  • scheduling technique that makes use of
    • dependency analysis and critical path to determine the duration of a project
    • slack to determine priorities of tasks
  • task durations are computed as (Optimistic + 4x Most likely + Pessimistic estimates) / 6)

Schedule[edit | edit source]

  • project time-line
  • identifies dates (absolute or relative to a start date) that
    • project tasks will be started and completed
    • resources will be required
    • milestones will be reached.

Sequencing Tasks[edit | edit source]

  • tasks are positioned serially or parallel based on dependencies between them
  • sequencing results in a task network.

BUDGET[edit | edit source]

Process For Creating - Bottom Up[edit | edit source]

  • determine cost of resources for each work unit
  • determine when those resources will be required
  • should have written approval from the project sponsor

Uses For Top Down Budget[edit | edit source]

  • confirm the customer's expected cost
  • validate detailed (bottom-up) budget when it is created

Budget Baseline[edit | edit source]

  • need budget and schedule to develop
  • show when the budget for each work unit will be spent
  • basis for budgets cash flow
  • basis for PV (BCWS) and EV (BCWP) (new terms?)

Management Reserve[edit | edit source]

  • funding for price changes that occur over the project life cycle due to -inflation- ?

Cost Budgeting[edit | edit source]

  • allocate cost estimates over time
  • four inputs to cost budgeting
    • cost estimates
    • WBS
    • project schedule
    • risk management plan
  • one output from cost budgeting
    • cost baseline
      • time phased budget

Fully Loaded Amounts For Hr Include[edit | edit source]

  • compensation
  • benefits
  • overtime
  • etc

COMMUNICATIONS PLAN[edit | edit source]

Communication Policies[edit | edit source]

  • There should be no arguments in front of the customer
  • Consultants should not discuss other clients while on-site

Communications Plan Should Include Communication:[edit | edit source]

  • purpose
  • senders
  • recipients
  • frequency
  • type
  • method
  • description

Information Needs Of End-User Management[edit | edit source]

  • main systems functionality
  • user involvement requirements
  • main deliverables planned delivery times

QUALITY PLAN[edit | edit source]

Quality Plan[edit | edit source]

  • create operation definitions for performance, and reliability

Project Review Process[edit | edit source]

  • provides a quality assurance measure for project performance
  • provides an independent evaluation of project performance/documentation

Quality Testing (Types Of)[edit | edit source]

  • unit test
    • component level
  • integration test
    • functionally grouped components
  • system test
    • the entire system as one entity
  • user acceptance test
    • should prove that the system operates to the specified requirements.
  • verification
    • alpha testing
    • simulated environment and simulated data
  • validation
    • beta testing
    • live environment and real data
  • audit testing
    • certifies system is ready for operation

Quality Checkpoints[edit | edit source]

Quality Assurance (QA)[edit | edit source]

  • making sure standards and procedures are effective and complied with
  • in some organizations QA is used to refer to the quality control function
  • satisfy standards
  • promote continual improvements

Quality Control (QC)[edit | edit source]

  • making sure deliverables comply with acceptance criteria
  • includes testing and reviews.

RISK MANAGEMENT PLAN[edit | edit source]

Risk[edit | edit source]

  • likelihood of the occurrence of an event
  • generally, the event is a negative one like project failure
  • event may also be a positive event, like the early completion of a task
  • price for opportunity

Risk Categories[edit | edit source]

  • technology risk
  • schedule risk
    • program evaluation and review technique (PERT)
    • Monte Carlo
  • financial risk

Choices To Handle Risk[edit | edit source]

  • accept
  • avoid
  • mitigate

Qualitative Risk Analysis[edit | edit source]

  • assess likelihood and impact of identified risks

Identify Potential Risks[edit | edit source]

  • historical information
  • nature of product and project
  • information gathering

Risk Assessment[edit | edit source]

  • part of risk management
  • planners identify potential risks and describe them
  • risks usually identified in terms of
    • symptoms
    • causes
    • probability of occurrence
    • potential impact

Risk Response[edit | edit source]

  • action that can be taken to address the occurrence of a risk event
  • Contingency Plans are collections of risk responses

Risk Response Control[edit | edit source]

  • responding to risk event occurrences throughout the project life cycle
  • taking corrective action is an aspect of risk response control

Risk Response Development[edit | edit source]

  • part of risk management
  • planners identify and define actions to be taken in case a risk occurs
    • such risk may be positive or negative

Six Processes Within The Area Of Risk Management:[edit | edit source]

  • Risk Management Planning
  • Risk Identification
  • Qualitative Risk Analysis
  • Quantitative Risk Analysis
  • Risk Response Planning
  • Risk Monitoring and Control

PROJECT PLAN[edit | edit source]

Project Plan – Key Concepts[edit | edit source]

  • other documents, such as WBS and SOW are fed into the project plan
  • very detailed and contains all the information about the project
  • a living document in that its contents can change over the life of the project
  • needs to be base-lined and all changes tracked
  • closes out the planning phase

Project Plan - Methods For Generating Support For[edit | edit source]

  • requesting input from stakeholders during planning process
  • clearly illustrating how the project relates to the company's objectives

Project Plan - Included In Project Plan[edit | edit source]

  • project scope
  • project definition
  • project objectives
  • project scope analysis (inclusion and exclusions)
  • project deliverables
  • project assumptions
  • project success criteria
  • project requirements
  • methodology description
  • project approach
  • work breakdown structure (WBS)
  • project estimates
  • project risk assessments
  • project resources (skills set needed, etc)

Project Plan : PP-TOSTR-SEE-BIST (mnemonic)[edit | edit source]

  • (T) - Table of Contents
  • (O) - Overview
  • (S) - Sponsors
  • (T) - Team Members
  • (R)- Requirements
  • (S) - Scheduled Tasks (WBS)
  • (E) - Expected Resources
  • (E) - Environmental Issues
  • (B) - Business Requirements
  • (I) - Implementation Plans
  • (S) - Support Plans
  • (T) - Training Plans - Nine Knowledge Areas, each = report, except integration (dummies pmp)
    1. Integration
    2. Scope
    3. Time
    4. Cost
    5. Quality
    6. Human Resources
    7. Communication
    8. Procurement
    9. Risk
    • mnemonic: Rapper Ice-T seeks the HR department to take a CPR class
      • Ice-T - IST - integration, scope, time
      • seeks HR - CQ HR - cost, quality, HR
      • CPR - communication, procurement, risk

Project Plan - Steps To Creating A Project Plan[edit | edit source]

  1. assemble all project planning elements
  2. create an outline or table of contents
  3. review outline with key stakeholders
  4. adjust the plan according stakeholder feedback
  5. write the comprehensive project plan
  6. obtain formal approval



Executing

KICK OFF MEETING[edit | edit source]

  • meet with sponsor to review the output
  • a meeting at the beginning of the project or major phase of the project
  • align peoples' understanding of project objectives, procedures, and plans
  • begin the team-building and bonding process.

WEEKLY TASKS[edit | edit source]

  • check scope
  • check evolution and status deliverables
  • check schedule
  • analyze variances, compare estimates to actuals
  • handle scope changes
  • list, track, try to resolve open issues
  • report project status
  • push for activity close-out and deliverable sign-off
  • decide if it's necessary to kill project

EVM (Earned Value Management)[edit | edit source]

EVM (Earned Value Management)[edit | edit source]

  • a method for integrating scope, schedule and resources
  • used for measuring project performance
  • compares
    • amount of work that was planned (PV)
    • what was actually earned (EV)
    • what was actually spent (AC)
  • determines if cost and schedule performance are as planned.

EVA (Earned Value Analysis)[edit | edit source]

  • most commonly used method of performance measurement
  • integrates scope, cost and schedule measures
  • assesses project performance
  • used to identify any divergence from planned outcomes

EV (Earned Value)[edit | edit source]

  • EV = PV * % complete (from course prep)
  • formerly BCWP (Budgeted Cost Work Performed)
  • value of work actually completed

PV (Planned Value)[edit | edit source]

  • formerly BCWS (Budgeted Cost Work Scheduled)
  • portion of approved cost estimate planned to be spent on activity during given period.
  • physical work scheduled to be performed

AC (Actual Cost)[edit | edit source]

  • formerly ACWP (Actual Cost Work Performed)
  • total costs incurred in accomplishing work during given period.
  • occurred to accomplish earned value

BAC (Budget at Completion)[edit | edit source]

  • the original total budget allocated to a project.
  • sum of all budgets allocated to a project

EAC (Estimate at Completion)[edit | edit source]

  • 3 formulas to calculate EAC
    • EAC = AC + ETC
    • EAC = AC + BAC - EV (variances are atypical)
    • EAC = BAC/CPI (from course prep) (variances are expected to occur again at same rate).
  • value expressed as either dollars or hours
  • represents the projected final costs of work when completed
  • actual costs incurred plus estimated cost of remaining work.

CPI (Cost Performance Index)[edit | edit source]

  • CPI=EV/AC
  • ratio of worth to cost
  • measure of cost-efficiency or efficiency of the budget
  • CPI < 1.0 means that the task is over budget

CV (Cost Variance)[edit | edit source]

  • CV=EV-AC
  • difference between worth and cost of completed work
  • identifies the area where spending more than budgeted
  • CV < 0 means the task is over budget

ETC (Estimate to Complete)[edit | edit source]

  • ETC=BAC-EV
  • expected additional cost needed to complete an activity or project

SV (Schedule Variance)[edit | edit source]

  • SV=EV-PV
  • difference between worth and supposed-to-be worth of completed work
  • identify schedule problems
  • measure of schedule efficiency
  • SV < 0 means the task is behind schedule

SPI (Schedule Performance Index)[edit | edit source]

  • SPI=EV/PV
  • schedule efficiency ratio of earned value accomplished against the planned value
  • describes what portion of the planned schedule was actually accomplished.
  • SPI < 1.0 means the task is behind schedule

TCPI (To Complete Performance Index)[edit | edit source]

  • Two possible formula:

TCPI = (BAC – EV)/(BAC – AC); based on BAC (original BAC only money available)

TCPI = (BAC – EV)/(EAC – AC); based on EAC (new revised EAC approved)

  • ratio of remaining work to remaining budget
  • efficiency that must be achieved to complete remaining work with remaining money
  • TCPI>1 = must increase performance to stay within budget

CAPS (Control Account Plans)[edit | edit source]

  • management control unit in which earned value performance measurement takes place
  • formerly called Cost Account Plan
  • EVM CAPs continuously measure project performance by relating 3 independent variables
    • Planned Value
    • Earned Value
    • Actual Costs

Formulas Summary:[edit | edit source]

  • CV=EV-AC
  • EAC (Estimate at Completion):
    • EAC = AC + ETC
    • EAC = AC + BAC - EV
    • EAC = BAC/CPI (from course prep)
  • CPI=EV/AC
  • SV=EV-PV
  • SPI=EV/PV
  • TCPI=(BAC-EV)/(BAC-AC)
  • Funds Remaining (BAC or EAC - AC)
  • EV=PV*%complete (from course prep)

Formula Mnemonics For Basic Formulas (CV,SV,CPI,SPI)[edit | edit source]

  • "V" in left-most means variance which means subtract
  • "I" in left-most means index which means divide
  • "EV" on left side of equation after "="
  • if cost "AC" is right-most, otherwise "PV"
  • CV=EV-AC
  • SV=EV-PV
  • CPI=EV/AC
  • SPI=EV/PV

Formula Mnemonics For TCPI[edit | edit source]

  • Two possible formula:

TCPI = (BAC – EV)/(BAC – AC); BAC based

TCPI = (BAC – EV)/(EAC – AC); EAC based

  • remember both num and denom start with BAC-
  • no PV
  • "I" in left-most means index which means divide
  • "EV" on left side of equation after "="

- baseline

  • original project plan plus approved changes. Must have to use EVA.

CHANGE CONTROL[edit | edit source]

Use The Established Procedures Outlined In The Statement Of Work[edit | edit source]

Two Methods Used To Monitor Scope Changes[edit | edit source]

  • track number of scope changes
  • track dollar value of extra work performed

Before Approval From The Stakeholders On A Project Scope Modification[edit | edit source]

  • analyze budget issues and their impact on "common problems"
  • analyze project plan issues and their impact
  • research alternatives for the proposed scope change

Value Engineering[edit | edit source]

  • used to evaluate proposed changes

When Change Occurs, PMS Must[edit | edit source]

  • identify cause
  • write a status report to document change
  • determine how scope change will impact cost and/or schedule
  • quantify alternative solutions
  • ask users to distinguish between mandatory and optional scope changes
  • determine whether to inform the sponsor
  • gain stakeholder approval

Objectives Of Change Control Process[edit | edit source]

  • insure that changes are beneficial
  • know when change has occurred
  • manage changes as they occur

Preventing Scope Creep[edit | edit source]

  • scope is well documented and verified in the planning phase
  • team well informed of products and quality procedures
  • develop and follow a requirements management process

LARGE & MULTI-LOCATION PROJECT STRATEGIES[edit | edit source]

What May Be Needed[edit | edit source]

  • communication standards
  • work standards
  • sub-teams
  • focus on milestones

TEAM MANAGEMENT[edit | edit source]

Best Practices[edit | edit source]

  • Shared Challenge
  • Team Identity
  • Balanced Task Assignment
  • Team Support
  • Trust Your Team
  • Earn Respect
  • Be a Team Player
  • Leadership Principles

Conflict Handling Modes[edit | edit source]

  • confrontation mode
    • problem solving approach
    • allows parties to work through their differences
    • usually most effective
  • smoothing mode
    • de-emphasize areas of differences
    • emphasize areas of agreement
    • often used when personalities clash
  • forcing mode
    • win-lose approach
    • favored by the autocratic
  • withdrawal mode
    • little gets accomplished

Task Related Conflict[edit | edit source]

  • often healthy
  • different approaches to create deliverables discussed
  • better solutions can be achieved

Emotional Conflicts[edit | edit source]

  • develop group ground rules to avoid

Common Causes Of Performance Problems Include[edit | edit source]

  • team is unfocused or pulling in different directions
  • team is fragmented into special interest or social groups

EXECUTIVE SUPPORT[edit | edit source]

Re-enforce by[edit | edit source]

  • identify source of doubts
  • use interpersonal skills
  • act without creating negative impact
  • use allies and influence

RESOURCE MANAGEMENT[edit | edit source]

Issues[edit | edit source]

  • Contract Labor
  • Outsourcing
  • Material Resources and Suppliers
  • Resource Leveling

PROJECT DELAYS[edit | edit source]

Issues Related To Extending Schedule[edit | edit source]

  • impact on other project goals
  • impact on the rest of the organization
  • impact on the project team
  • impact on the vendors

INTERIM PROJECT REQUIREMENT REVIEWS[edit | edit source]

INTERIM PROJECT REQUIREMENT REVIEWS - Process[edit | edit source]

  • held with the sponsors and users
  • held after the initial requirements are completed
  • held after requested changes to the scope are defined
  • most reviews are face-to-face with affected stakeholders
  • may be held on a periodic basis or as needed
  • Reasons To Hold Non-Periodic Reviews
    • organizational changes
    • misunderstandings arise
    • quality problems
    • budget problems

INTERIM PROJECT REQUIREMENT REVIEWS - Reasons for[edit | edit source]

  • provides a quality assurance measure for project performance
  • provides an independent evaluation of project performance/documentation
  • examines the overall health of the project
  • recommends actions to address any significant problems
  • Emphasize Important Project Goals
    • main goals understood?
    • are products being delivered on time?
    • quality okay?
    • budget okay?

INTERIM PROJECT REQUIREMENT REVIEWS - Acceptable Outcomes[edit | edit source]

  • approve requirements list as is
  • agree on revisions then resubmit for review and approval
  • agree on revisions then move forward with the planning phase

TURNOVER PHASE[edit | edit source]

Transition Work[edit | edit source]

  • user docs
  • user training
  • help-desk training

REFERENCES[edit | edit source]



Closing

Project Close Out Phase[edit | edit source]

Closing[edit | edit source]

  • process of gaining formal acceptance for the results of a project or phase.
  • bringing project or phase to an orderly end.
  • archiving of project information and post-project review.

Output[edit | edit source]

  • project archives
  • formal acceptance documentation
  • project review
  • team member evaluations
  • lessons learned report = last deliverable

Formal Acceptance Of The Project By The Customers[edit | edit source]

  • first step in close out phase
  • a goals of the close out phase?
  • formal acceptance documentation should be prepared
  • PM should document customer acceptance

Project Review[edit | edit source]

  • necessary task in preparation of the Close Out phase
  • asses and evaluate each phases of the project
  • asses and evaluate the overall project performance
  • a way to learn from the experience and continuously improve project performance

Project Archives[edit | edit source]

  • leave clear and complete documentation of the project

Ongoing Maintenance Should Be Discussed In A Project Close Out Meeting[edit | edit source]

Executive Sponsor Is Responsible For Authorizing Closure Of The Project[edit | edit source]

All Contract Files Must Be Closed Out[edit | edit source]

Lessons Learned Report[edit | edit source]

  • PM may need to study from previous projects

Project Audit[edit | edit source]

  • formal review of project progress and results
  • did project achieve benefits as planned
  • was work accomplished according to plan