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

10
Sample Project Charter
11
Sample Project Charter
12
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.

13
Scope planning

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

14
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

15
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

16
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

17
Scope Definition

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

18
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

19
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?

20
Project Elements

• A project has
• Functions
• Activities
• Tasks

21
Function

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

22
Activity

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

23
Task

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

24
Typical WBS
25
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

26
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

27
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

28
WBS Chart Example
29
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
30
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

31
Product WBS
32
Process WBS
33
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

34
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

35
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

36
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

37
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

38
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

39
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

40
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

41
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

42
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

43
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

44
WBS Techniques

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

45
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

46
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!)

47
WBS Basis of Many Things

• Network scheduling
• Costing
• Risk analysis
• Organizational structure
• Control
• Measurement

48
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

49
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

50
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?

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

52
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

53
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

54
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

55
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

56
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

57
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

58
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

59
Scope management and project failure

• Many IT Project suffer from scope creep and poor
  scope verification
• FoxMeyer Drug filed fro bankruptcy after scope
  creep on a SCM system
• McDonalds binned 1 billion project to link its
  operations in a real time network