Project+/Planning

REQUIREMENTS ANALYSISEdit

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.

ProductEdit

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 StatementEdit

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 it's environment
  • JAD (Joint Application Design)
  • UML (Unified Modeling Language)
    • management tool for object oriented software design

Project Description DocumentEdit

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 - OTNEdit

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

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

Types Of RequirementsEdit

  • business
  • functional
  • technical

TraceabilityEdit

  • track a requirement to documented need

Configuration ManagementEdit

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

REFINE SCOPEEdit

  • 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

WBS key conceptsEdit

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

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

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

PhaseEdit

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

  • 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

  • "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 practicesEdit

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

hierarchy format e.g.Edit

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

DeliverableEdit

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

IssuesEdit

  • Contract Labor
  • Outsourcing

Recruit The Best CandidatesEdit

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

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

Resource Capabilities And Resource AvailabilityEdit

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

RESPONSIBILITY ASSIGNMENT MATRIXEdit

Maps Work To PeopleEdit

Authority Structure?Edit

ESTIMATION TECHNIQUESEdit

Top DownEdit

  • 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

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

ParametricEdit

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

AnalogousEdit

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

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

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

FTE = Full Time EquivalentEdit

SCHEDULEEdit

Process For Creating ScheduleEdit

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

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

Items Needed To Justify The ScheduleEdit

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

Sequencing TasksEdit

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

Dependencies: Types OfEdit

  • 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

MilestonesEdit

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

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

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

LeadEdit

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

LagEdit

  • waiting time between two tasks

Gantt ChartEdit

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

  • 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

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

ScheduleEdit

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

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

BUDGETEdit

Process For Creating - Bottom UpEdit

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

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

Budget BaselineEdit

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

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

Cost BudgetingEdit

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

  • compensation
  • benefits
  • overtime
  • etc

COMMUNICATIONS PLANEdit

Communication PoliciesEdit

  • 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

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

Information Needs Of End-User ManagementEdit

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

QUALITY PLANEdit

Quality PlanEdit

  • create operation definitions for performance, and reliability

Project Review ProcessEdit

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

Quality Testing (Types Of)Edit

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

Quality Assurance (QA)Edit

  • 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

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

RISK MANAGEMENT PLANEdit

RiskEdit

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

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

Choices To Handle RiskEdit

  • accept
  • avoid
  • mitigate

Qualitative Risk AnalysisEdit

  • assess likelihood and impact of identified risks

Identify Potential RisksEdit

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

Risk AssessmentEdit

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

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

Risk Response ControlEdit

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

Risk Response DevelopmentEdit

  • 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

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

PROJECT PLANEdit

Project Plan - Key ConceptsEdit

  • 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 it's 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 ForEdit

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

Project Plan - Included In Project PlanEdit

  • 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

  • (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 PlanEdit

  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
Last modified on 15 October 2010, at 15:45