Project Management and Change Management - PowerPoint PPT Presentation

1 / 61
About This Presentation
Title:

Project Management and Change Management

Description:

Project Management and Change Management Lecture 3 Scope Management Scope Scope is the sum of the products and services to be provided as a project A concise and ... – PowerPoint PPT presentation

Number of Views:467
Avg rating:3.0/5.0
Slides: 62
Provided by: colm158
Category:

less

Transcript and Presenter's Notes

Title: Project Management and Change Management


1
Project Management and Change Management
  • Lecture 3 Scope Management

2
Scope
  • Scope is the sum of the products and services to
    be provided as a project
  • A concise and accurate description of the end
    products or deliverables of the project
  • That meet specified requirements
  • As agreed between the project stakeholders

3
Scope Management
  • Project Scope Management includes the processes
    required to
  • Ensure that the project includes all of the work
    required
  • And only the work required to complete the
    project successfully

4
Scope management consists of
  • Initiation
  • Planning
  • Definition
  • Verification
  • Change Control

5
Scope Initiation
  • The phase where the organisation commits to
    beginning a project or commits to moving to the
    next phase of the project
  • Normally occurs as managements response to the
    recognition of a problem, business need or
    opportunity

6
Scope initiation - inputs
  • Product description
  • Strategic plan
  • Project selection method
  • Historical Information

7
Scope Initiation Tools and Techniques
  • Project Selection Methods e.g. quantitative cost
    measurement, scoring models
  • Expert judgement e.g. expert panel, objective
    brain storming

8
Scope Initiation - Outputs
  • Project charter
  • Project manager identified / assigned
  • Constraints
  • Assumptions

9
Project Charter
  • After deciding what project to work on, it is
    important to formalize projects
  • A project charter is a document that formally
    recognizes the existence of a project and
    provides direction on the projects objectives
    and management
  • Key project stakeholders should sign a project
    charter to acknowledge agreement on the need and
    intent of the project
  • It obtains management approval for the work to be
    done and obtains a commitment for the resources
    to do the work

10
Project charter contents
  • Objectives What the desired outcomes are
  • Function Major features and/or processes
  • Performance Generalised specifications
  • Constraints limits of the environment
  • Scope boundaries of the project
  • Cost/benefits Rough order of magnitude estimates

11
Sample Project Charter
12
Sample Project Charter
13
Scope planning
  • Inputs include the product description, project
    charter, constraints and assumptions
  • Methods include product analysis, benefit/cost
    analysis identifying alternatives and expert
    judgment
  • Outputs include scope statement, supporting
    detail and scope management plan.

14
Scope planning
  • Involves developing a written scope statement
    that includes the project justification, the
    major deliverables and the project objectives

15
Scope Statement
  • Forms the basis for an agreement between the
    project team and the project customer by
    identifying project objectives and the major
    project deliverables
  • Normally written by project manager in
    conjunction with the project team

16
Scope statement
  • Justification business reason
  • Product description a summary of the product
    description
  • Deliverables- a summary of all deliverables whose
    full and satisfactory delivery means the project
    is complete
  • Objectives time, cost , quality

17
Scope management plan
  • A subsidiary element of the overall management
    plan
  • Describes how project scope will be managed
  • Describes how scope changes will be integrated
    into the project
  • Should also include a clear description of how
    scope changes will be identified and classified

18
Scope Definition
  • Involves decomposing the major deliverables into
    smaller, more manageable components to provide
    better control
  • WBS

19
What is WBS
  • WBS is the name given to a technique in project
    management in which the project is broken down
    into manageable chunks
  • A WBS provides a central organising concept for
    the project. That is a common framework for
    Planning, Scheduling, cost estimating, budgeting,
    configuring, monitoring and controlling the
    entire project

20
Partitioning the Project
  • You need to decompose the project into
    manageable chunks
  • ALL projects need this step
  • Divide Conquer
  • Two main causes of project failure
  • Forgetting something critical
  • Ballpark estimates become targets
  • How does partitioning help this?

21
Project Elements
  • A project has
  • Functions
  • Activities
  • Tasks

22
Function
  • Management activity
  • Often Spanning the life of the project
  • Examples Change Management, Risk Management and
    project Management

23
Activity
  • An element of work with expected duration, cost
    and resources
  • Can be subdivided into other activities or tasks

24
Task
  • Lowest level of activity on the project
  • Typically not shown on preliminary WBS ( too
    granular)
  • Smallest unit of work in the real schedule

25
Typical WBS
26
Work Breakdown Structure WBS
  • Hierarchical list of projects work activities
  • 2 Formats
  • Outline (indented format)
  • Graphical Tree (Organizational Chart)
  • Uses a decimal numbering system
  • Ex 3.1.5
  • 0 is typically top level
  • Includes
  • Development, Mgmt., and project support tasks
  • Shows is contained in relationships
  • Does not show dependencies or durations

27
WBS
  • Contract WBS (CWBS)
  • First 2 or 3 levels
  • High-level tracking
  • Project WBS (PWBS)
  • Defined by PM and team members
  • Tasks tied to deliverables
  • Lowest level tracking

28
A Full WBS Structure
  • Up to six levels (3-6 usually) such as
  • Upper 3 can be used by customer for reporting (if
    part of RFP/RFQ)
  • Different level can be applied to different uses
  • Ex Level 1 authorizations 2 budgets 3
    schedules

29
WBS Chart Example
30
WBS Outline Example
0.0 Retail Web Site 1.0 Project Management 2.0
Requirements Gathering 3.0 Analysis Design 4.0
Site Software Development 4.1 HTML Design and
Creation 4.2 Backend Software 4.2.1 Database
Implementation 4.2.2 Middleware
Development 4.2.3 Security Subsystems 4.2.4
Catalog Engine 4.2.5 Transaction
Processing 4.3 Graphics and Interface 4.4
Content Creation 5.0 Testing and Production
31
WBS Types
  • Process WBS
  • a.k.a Activity-oriented
  • Ex Requirements, Analysis, Design, Testing
  • Typically used by PM
  • Product WBS
  • a.k.a. Entity-oriented
  • Ex Financial engine, Interface system, DB
  • Typically used by engineering manager
  • Hybrid WBS both above
  • This is not unusual
  • Ex Lifecycle phases at high level with component
    or feature-specifics within phases
  • Rationale processes produce products

32
Product WBS
33
Process WBS
34
WBS Types
  • Less frequently used alternatives
  • Organizational WBS
  • Research, Product Design, Engineering, Operations
  • Can be useful for highly cross-functional
    projects
  • Geographical WBS
  • Can be useful with distributed teams
  • NYC team, San Jose team, Off-shore team

35
Ways to develop a WBS
  • By geographically separated areas whether for
    activity or product
  • By major chronological time periods
  • By structure, process, system or device
    components
  • By intermediate deliverables required in the
    production of the end deliverables
  • By separated areas of responsibility i.e.
    functional, discipline trade or service

36
Remember
  • Different people view the technique differently
  • The techniques can be applied in different ways
  • The results must reflect the project strategy
  • No single way is best for all projects

37
Work Packages
  • Generic term for discrete tasks with definable
    end results
  • Typically the leaves on the tree
  • The one-to-two rule
  • Often 1 or 2 persons for 1 or 2 weeks
  • Basis for monitoring and reporting progress
  • Can be tied to budget items (charge numbers)
  • Resources (personnel) assigned
  • Ideally shorter rather than longer
  • Longer makes in-progress estimates needed
  • These are more subjective than done
  • 2-3 weeks maximum for software projects
  • 1 day minimum (occasionally a half day)
  • Not so small as to micro-manage

38
Work Package
  • Is the lowest level in the WBS
  • Has a deliverable result
  • Should have one responsible part called the WP
    owner
  • May be considered by the WP assignee as a project
    in itself
  • May include several milestones
  • Should fit organisational procedures and culture
  • The optimal size of a WP may be expressed in
    terms of labour hours, calendar time, cost,
    report period risks

39
Contents of a work packages may include
  • Description of the work product expected --
    product to be produced
  • The staffing requirements who or how many
    people will do this activity
  • Name of responsible individual(s)- who is
    reponsible for seeing what is completed
  • The scheduled start and send dates when the
    activity is expected to start and end
  • The budget assigned the effort estimate for the
    activity
  • The acceptance criteria for the work defect
    level or other quality measure

40
WBS Dictionary
  • The labels and shape of our WBS is fine. But how
    are we to know what work is in each work package
  • On larger projects it is usual to provide what is
    known as a WBS dictionary for each package
  • This provides
  • A statement of work describing the work content
    of each package
  • And often a description of what is not included

41
WBS and WPEvolution
  • As a project progresses through its lifecycle and
    planning becomes more detailed it may be
    necessary to further subdivide existing work
    packages
  • This will push them to the next lower level

42
WBS
  • List of Activities, not Things
  • List of items can come from many sources
  • SOW, Proposal, brainstorming, stakeholders, team
  • Describe activities using bullet language
  • Meaningful but terse labels
  • All WBS paths do not have to go to the same level
  • Do not plan more detail than you can manage

43
WBS Methodology
  • PM must map activities to chosen lifecycle
  • Each lifecycle has different sets of activities
  • Integral process activities occur for all
  • Planning, configuration, testing
  • Operations and maintenance phases are not
    normally in plan (considered post-project)
  • Some models are straightened for WBS
  • Spiral and other iterative models
  • Linear sequence several times
  • Deliverables of tasks vary by methodology

44
WBS Techniques
  • Top-Down
  • Bottom-Up
  • Analogy
  • Rolling Wave
  • 1st pass go 1-3 levels deep
  • Gather more requirements or data
  • Add more detail later
  • Post-its on a wall

45
WBS Techniques
  • Top-down
  • Start at highest level
  • Systematically develop increasing level of detail
  • Best if
  • The problem is well understood
  • Technology and methodology are not new
  • This is similar to an earlier project or problem
  • But is also applied in majority of situations

46
WBS Techniques
  • Bottom-up
  • Start at lowest level tasks
  • Aggregate into summaries and higher levels
  • Cons
  • Time consuming
  • Needs more requirements complete
  • Pros
  • Detailed

47
WBS Techniques
  • Analogy
  • Base WBS upon that of a similar project
  • Use a template
  • Analogy also can be estimation basis
  • Pros
  • Based on past actual experience
  • Cons
  • Needs comparable project

48
WBS Techniques
  • Brainstorming
  • Generate all activities you can think of that
    need to be done
  • Group them into categories
  • Both Top-down and Brainstorming can be used on
    the same WBS
  • Remember to get the people who will be doing the
    work involved (buy-in matters!)

49
WBS Basis of Many Things
  • Network scheduling
  • Costing
  • Risk analysis
  • Organizational structure
  • Control
  • Measurement

50
WBS foundation of the project
  • Involve all players when using WBS
  • May be used as a project organisational chart
  • Establishes cost/schedule estimates
  • Feeds into network diagram
  • Risk appraisal tool
  • Identifies contract strategy
  • Coding structure for reporting

51
Defining Project Scope - a process perspective
  • Although scope will include organisational and
    technical components a process perspective
    provides the best and most focused definition of
    what is changing and what is not changing
  • Example Process to be redesigned begins with the
    receipt of an order and ends with the completed
    order received by the customer

52
Need to address the following questions
  • What processes are included in the scope of our
    project?
  • What processes are NOT included in the scope of
    our project? 
  • Where does each process begin and where does each
    process end?
  • What systems used in these processes are NOT
    included in the scope? 
  • What organizations involved in these processes
    are included in the scope? 
  • What organizations involved in these processes
    are NOT included in the scope?

53
Examples
  • The process includes the work processes and
    systems required to fill the order. The process
    does not include the manufacturing activities
    required to make the product, or the billing
    process.
  • Organizations involved include order processing,
    logistics and shipping. Organizations not
    involved include manufacturing and accounting
  • The current personal computers and LAN
    architecture are part of the project scope. The
    database server and database application are also
    included. The customer contact software is not
    part of the project scope.

54
Defining Project Scope Other Work
  • Preparation of training material
  • Delivery of training
  • Business Process documentation
  • Business Process Re-engineering
  • Rework
  • Project management and administration
  • Vendor management
  • Security

55
Defining Project Scope Other Work
  • Disaster recovery plans
  • Business continuity plans
  • Provision and setup of equipment
  • Software
  • Communication
  • Support after go-live
  • Recruitment of permanent or contract staff
  • Staff performance management and evaluation
  • Hardware upgrade or purchase
  • Hardware installation
  • Data preparation for transfer
  • System documentation

56
Scope definition summary
  • Represents content not execution sequence
  • Scope Baseline
  • Use of WBS ensures completeness
  • Verifies Scope
  • Validates change to scope
  • Interfaces with contracts
  • Approve prior to proceeding further
  • Basis for further decisions

57
Scope Change
  • A scope change may be defined as any change in
    the project deliverables from what was originally
    intended
  • A scope change almost always requires an
    adjustment to the project cost and schedule

58
Scope Change
  • Very few projects are executed as per the
    original design and execution plan. Need to look
    at
  • Types of change
  • Sources of change
  • Impact of changes
  • Change authorisation

59
Scope Verification
  • This is the process of obtaining formal
    acceptance of the project from the stakeholders
    (sponsor, client, customer etc. )
  • Input work results, product documentation, WBS,
    project plan, scope statement
  • Tools and techniques Inspection
  • Outputs Formal Acceptance

60
Scope Verification Typical Test program
  • List components to be tested
  • Define the test measures
  • Test location
  • Who will test
  • Test procedures
  • Test support equipment required

61
Scope management and project failure
  • Many IT Project suffer from scope creep and poor
    scope verification
  • FoxMeyer Drug filed for bankruptcy after scope
    creep on a SCM system
  • McDonalds binned 1 billion project to link its
    operations in a real time network
Write a Comment
User Comments (0)
About PowerShow.com