SE 477 Software and Systems Project Management

1
SE 477 Software and Systems Project Management

• Dennis Mumaugh, Instructor
• dmumaugh_at_cdm.depaul.edu
• Office OHare, Room 113
• Office Hours Wednesday, 430-600

2
Administrivia

• Comments and feedback
• Team Project
• Team posting on COL gt Course Documents
• Team Project assignment on COL gt Assignments
• Team Project Report template on COL gt Course
  Documents and on class web site

3
Project

• Write a Project Plan for your project
• Initial Phase Project Document (combines elements
  of Project Charter and Preliminary Project Scope
  Statement)
• Project Plan
• Goals and milestones
• Deliverables
• Schedule, tasks and activities
• Costs and estimations
• Use template provided

4
Homework

• Assignment 2 Due October 8, 2008
• Two to three page discussion and analysis on
• Benefits of planning and scheduling
• Limitations of planning and scheduling
• And the pitfalls to avoid

5
SE 477 Class 3

• Topics
• Project Planning Initial Phase
• The Project Management Plan
• Project plans
• Creating the Work Breakdown Structure (WBS)
• Reading
• PMP Study Guide Chapter 3
• Kerzner Chapter 11.8-11.16, 11.20
• Hallows Chapter 2-3
• Lewis Chapter 5
• Taylor Chapter 2, 6

6
Thought for the Day

• Planning a project takes as much effort as
  planning a war.
• Hope is not a strategy!

7
Last time

• Fundamentals
• Initial Phase
• Project Management Processes
• Developing the project charter
• Developing the preliminary project scope
  statement
• System Development Processes
• Inception phase activities
• Organizational Structures Influences
• Functional, Project, Matrix Orgs.
• Initial documents
• Statement of Work (SOW)
• Project Charter

8
Review
9
To Get to the Essence of a Project

• Why is the system being developed?
• What will be done?
• When will it be accomplished?
• Who is responsible?
• Where are they organizationally located?
• How will the job be done technically and
  managerially?
• How much of each resource (e.g., people,
  software, tools, database) will be needed?
• Barry Boehm

10
Stakeholders

• Senior managers who define the business issues
  that often have significant influence on the
  project.
• Project (technical) managers who must plan,
  motivate, organize, and control the practitioners
  who do software work.
• Practitioners who deliver the technical skills
  that are necessary to engineer a product or
  application.
• Customers who specify the requirements for the
  software to be engineered and other stakeholders
  who have a peripheral interest in the outcome.
• End-users who interact with the software once it
  is released for production use.

11
Common-Sense Approach to Projects

• Start on the right foot. This is accomplished by
  working hard (very hard) to understand the
  problem that is to be solved and then setting
  realistic objectives and expectations.
• Maintain momentum. The project manager must
  provide incentives to keep turnover of personnel
  to an absolute minimum, the team should emphasize
  quality in every task it performs, and senior
  management should do everything possible to stay
  out of the teams way.
• Track progress. For a software project, progress
  is tracked as work products (e.g., models,
  source code, sets of test cases) are produced and
  approved (using formal technical reviews) as part
  of a quality assurance activity.
• Make smart decisions. In essence, the decisions
  of the project manager and the software team
  should be to keep it simple.
• Conduct a postmortem analysis. Establish a
  consistent mechanism for extracting lessons
  learned for each project.

12
Concept Exploration

• The Why phase
• Not a mandatory formal phase
• Sometimes called the pre-project phase
• Collecting project ideas
• Then the funneling process
• Project Justification
• ROI
• Cost-benefit analysis
• Initial planning and estimates

13
Concept Exploration

• Possibly includes Procurement Management
• RFP Process
• Vendor selection
• Contract management
• Gathering the initial team
• Including PM if not already on-board
• Identify the project sponsor
• Primary contact for approval and decision making
• Potential Phase Outputs
• Concept Document, Product Description, Proposal,
  SOW, Project Charter

14
Concept Exploration

• Characteristics Issues
• Lack of full commitment and leadership
• Some frustrations
• Management only getting rough estimates from
  development
• Development not getting enough specifics from
  customer
• Finding a balanced team
• Budget sign-off may be your 1st major task
• Achieved via
• Good concept document or equivalent
• Demonstration of clear need (justification)
• Initial estimates

15
Project Planning
16
Project Planning

• Now the general who wins a battle makes many
  calculations in his temple ere the battle is
  fought. The general who loses a battle makes but
  few calculations beforehand. Thus do many
  calculations lead to victory, and few
  calculations to defeat
• Sun Tzu, The Art of War

17
Software Project Planning

• The overall goal of project planning is to
  establish a pragmatic strategy for controlling,
  tracking, and monitoring a complex technical
  project.
• Or,
• A Plan is the strategy for the successful
  completion of the project. It's a description of
  the project steps that produce increasing
  maturity of the products or processes produced by
  the project.
• Why?
• So the end result gets done on time, with quality!

18
Planning

• "You've got to be very careful if you don't know
  where you're going, because you might not get
  there.
• "If you don't know where you are going, you will
  wind up somewhere else.
• Yogi Berra
• If you don't know where you're going, any road
  will take you there.
• If you dont know where youre going, how do you
  know when you get there?

19
Project PlanningIntroduction

• Why plan?
• Consider driving a car do you drive looking
  backwards?
• Planning and control
• Planning in the iterative development model

20
Planning

• Preliminary planning starts on day one
• Even in the pre-project phase
• Should not be conducted in secret
• Need buy-in and approval
• Very important step
• Both from above and below

21
Primary Planning Steps

• Identify project scope and objectives
• Define and Record Requirements
• Identify project organizational environment
• Analyze project characteristics
• Identify Project Team and Define Roles and
  Responsibilities
• Identify project products and activities
• Create the WBS
• Estimate effort for each activity
• Allocate resources
• Schedule deliveries and milestones

22
Primary Planning Steps

• Develop Change Management Plan
• Identify Risks and Define Risk Strategies
• Review and communicate plan
• Obtain Plan Approval
• Conduct Kick-off Meeting

23
Project Planning Task Set - I

• Establish project scope
• Determine feasibility
• Define required resources
• Determine required human resources
• Define reusable software resources
• Identify environmental resources
• Estimate cost and effort
• Decompose the problem
• Develop two or more estimates using size,
  function points, process tasks or use-cases
• Reconcile the estimates

24
Project Planning Task Set - II

• Develop a project schedule
• Scheduling is considered in detail later.
• Establish a meaningful task set
• Define a task network
• Use scheduling tools to develop a timeline chart
• Define schedule tracking mechanisms
• Analyze risks
• Risk analysis is considered in detail later.

25
Project Phases
26
Potential Deliverables by Phase
27
Time Allocation by Phase

• Remember the 40-20-40 Rule
• Specification-Implementation-Test

Bennatan, E.M, On Time Within Budget
28
Time Allocation by Phase
McConnell, Steve, Rapid Development
29
Activities by of Total Effort
NASAs Managers Handbook for Software
Development
30
Software Project Survival Guide

• Documents
• Schedules
• Checklists

31
Planning

• Scoping
• What is the problem
• How much will it cost?
• Estimation
• How long will it take?
• Schedule
• Resources
• How many people will it take?
• Risk
• What might go wrong?
• Control Strategy

32
Process Issues

• You want a fairly sophisticated process without
  incurring much overhead
• Remember, projects are often larger than they
  first appear
• Easier to loosen too much process than add later

33
Plans Evolve Over Time
NASAs Managers Handbook for Software
Development
34
Software Development Plan (SDP)

• Software Project Management Plan (SPMP)
• Some consider it the most important document in
  the project (along with requirements document)
• Can be seen as an aggregation of other core
  documents
• Evolves over time as pieces come together

35
SDP / SPMP

• Fundamental Sections
• Project overview
• Deliverables
• Project organization
• Managerial processes
• Communication management plan
• Milestones
• Technical processes
• Budget
• Schedule

36
Preliminary Scope

• Project objectives
• Product description
• Objectives
• Deliverables
• Requirements (product and project)
• Exclusions (project boundary)
• Constraints

• Assumptions
• High-level risks and definitions
• Milestones
• Initial WBS
• Cost Estimate
• Configuration management requirements
• Project acceptance criteria

37
Deliverables

• List of items to be delivered
• Must be tangible items
• Sample deliverables
• The product the actual software, in the
  installable format
• Product documentation
• Reports and planning documentation
• Most projects are driven by deliverables, so you
  need several
• Project deliverables (aka documents) are included

38
Communications Management Plan

• Often a section of SPMP
• Describes information flow to all parties
• Gathering and distributing information
• Status meetings
• Monthly, Weekly, Daily?
• Status reports are vital

39
Documents

• Planning
• Product

40
Planning Documents

• Project ROI Analysis
• Business Case
• Project Charter
• Statement of Work (SOW)
• Software Project Management Plan (SPMP)
• Software Development Plan (SDP)
• Communications Management Plan
• Budget
• Responsibility Assignment Matrix (RAM)
• Risk Management Plan

41
Planning Documents

• Other documents you may want/need
• Software Quality Assurance Plan (SQAP)
• Software Process Improvement Plan
• Software Configuration Management Plan (SCMP)
• Migration Plan
• Operations Plan

42
Planning Documents

• You (the PM) need to choose which documents are
  appropriate
• Docs do not have to be lengthy
• Small Set
• Software Development Plan
• Risk Management Plan
• Software Quality Assurance Plan
• Software Configuration Management Plan

43
Product Documents

• Statement of Need
• System Interface Specification
• Software Requirements Specification
• Software Design Specification
• Software Validation Verification Plan
• User Documentation
• Support Plan
• Maintenance Documentation

44
Project Planning Tools
45
Project Planning and Tracking

• WBS - Work Breakdown Structure. Technique for
  describing all work in a project.
• PERT - Program Evaluation and Review Technique. A
  well-entrenched technique for scheduling.
• CPM - Critical Path Method. Used with PERT to
  determine problems in scheduling.
• Gantt Charts - bar chart that graphically
  displays project schedule

46
Defining Task Sets

• Determine type of project
• Assess the degree of rigor required
• Identify adaptation criteria
• Select appropriate software engineering tasks
• Task Set Refinement
• Use Work Breakdown Structure to determine tasks
• Define a Task Network
• Use a Gantt Chart and/or PERT to document

47
Work Breakdown Structure

• A Work Breakdown Structure (WBS) captures all the
  work of a project in an organized way. 
• Portrayed graphically as a hierarchical tree,
• A tabular list of "element" categories and tasks
  or the indented task list that appears in your
  Gantt chart schedule.
• Breaking Large, complex projects into
  progressively smaller pieces
• A collection of defined "work packages" that may
  include a number of tasks.
• Continue to refine work until packages are of a
  suitable size
• A work package can include design, coding,
  testing, etc.
• See notes below.

48
The Work Breakdown Structure

• The Work Breakdown Structure (WBS) is a
  hierarchical description of the work that must be
  done to complete the project as defined in the
  Project Overview Statement (POS) .
• The WBS terms
• Activity An activity is simply a chunk of work.
• Task A task is a smaller chunk of work.
• Milestone a task of zero duration. Usually an
  external event.

49
The Work Breakdown Structure
50
Work Breakdown Structure

• Breaks project into a hierarchy.
• Creates a clear project structure.
• Avoids risk of missing project elements.
• Enables clarity of high level planning.

51
Uses for the WBS

• Thought process tool
• The WBS is a design and planning tool.
• It helps the project manager and the project team
  visualize exactly how the work of the project can
  be defined and managed effectively.
• Architectural design tool
• The WBS is a picture of the work of the project
  and how the items of work are related to one
  another.

52
Uses for the WBS

• Planning tool
• In the planning phase, the WBS gives the project
  team a detailed representation of the project as
  a collection of activities that must be completed
  in order for the project to be completed.
• It is at the lowest activity level of WBS that we
  will estimate effort, elapsed time, and resource
  requirements build a schedule of when the work
  will be completed and estimate deliverable dates
  and project completion .

53
Uses for the WBS

• Project status reporting tool.
• The WBS is used as structure for reporting
  project status.
• The project activities are consolidated from the
  bottom as lower-level activities are completed.
• Completion of lower-level activities cause
  higher-level activities to be partially complete.
  
• Therefore, WBS defines milestone events that can
  be reported to senior management and to the
  customer .

54
Generating the WBS

• The WBS is generated during the Joint Project
  Planning (JPP) session.
• Two different approaches to building the WBS
• Top-Down Approach
• Bottom-Up Approach

55
Top-Down Approach

• The top-down approach begins at the goal level
  and successively partitions work down to lower
  levels of definition until the participants are
  satisfied that the work has been sufficiently
  defined.
• Once the project activities have been defined,
  they will allow you to estimate time, cost, and
  resource requirements first at the activity level
  and then aggregate to the project level.
• Two variations of this approach
• Team Approach
• Subteam Approach

56
Top-Down Approach

• Team Approach
• The team approach requires more time to complete
  than the subteam approach even though it is the
  preferred approach.
• In this approach the entire team works on all
  parts of the WBS. For each Level 1 activity,
  appoint the most knowledgeable member of the
  planning team to facilitate the further
  decomposition of that part of the WBS. Continue
  with similar appointments until the WBS is
  complete.
• This approach allows all members of the planning
  team to pay particular attention to the WBS as it
  is developed, noting discrepancies and commenting
  on them in real time.

57
Top-Down Approach

• Subteam Approach
• The first step is to divide the planning team
  into as many subteams as there are activities at
  Level 1 of the WBS. Then follow these steps
• The planning team agrees on the approach to
  building the first level of the Work Breakdown
  Structure.
• The planning team creates the Level 1 activities.
• A subject matter expert leads the team in further
  decomposition of the WBS for his or her area of
  expertise.
• The team suggests decomposition ideas for the
  expert until each activity within the Level 1
  activities meets the WBS completion criteria.

58
Bottom-Up Approach

• This approach is more like a brainstorming
  session than an organized approach to building
  the WBS.
• The bottom-up procedure
• The planning team agrees to the first-level
  breakdown.
• The planning team is then divided into as many
  groups as there are first-level activities.
• Each group then makes a list of the activities
  that must be completed in order to complete the
  first-level activity. Someone in the group
  identifies an activity and tells it to the group.
  The process repeats itself until no new ideas are
  forthcoming. The group then sorts activities that
  are related to one another.
• Each group then reports to the entire planning
  team the results of its work final critiques are
  given, missing activities added, redundant
  activities removed.

59
Six Criteria to Test for Completeness in the WBS

• The WBS is developed as part of JPP session. But
  how do you know that youve done this right? Each
  activity must possess six characteristics to be
  considered complete-that is, completely
  decomposed. The six characteristics are
• Status/completion is measurable
• Start/end events are clearly defined
• Activity has a deliverable
• Time/cost is easily estimated
• Activity duration is within acceptable limits
• Work assignments are independent
• Let us review each one in detail

60
Six Criteria to Test for Completeness in the WBS

• Measurable Status The project manager can ask
  for the status of an activity at any point in
  time during the project. If the activity has been
  defined properly, that question is answered
  easily.
• Example a systems documentation is estimated to
  be about 300 pages long and requires
  approximately four months of full-time work to
  write, here is a possible report that a developer
  can provide regarding the status
• Ive written 150 pages, so I guess I am 50
  percent complete.

61
Six Criteria to Test for Completeness in the WBS

• Bounded
• Each activity should have a clearly defined start
  and end event.
• Once the start event has occurred, work can begin
  on the activity.
• The deliverable is most likely the end event that
  signals work is closed on the activity.
• For example, using the systems documentation
  example, the start event might be notification to
  the team member who will manage the creation of
  the systems documentation that the final
  acceptance tests of the systems are complete. The
  end event would be notification to the project
  manager that the customer has approved the
  systems documentation.

62
Six Criteria to Test for Completeness in the WBS

• Deliverable
• The result of completing the work that makes up
  the activity is the production of a deliverable.
• The deliverable is a visible sign that the
  activity is complete.
• This could be an approving managers signature, a
  physical product or document.
• Cost/Time Estimate
• Each activity should have an estimated time and
  cost of completion.
• Being able to do this at the lowest level of
  decomposition in the WBS allows you to aggregate
  to higher levels and the total project cost and
  the completion date.

63
Six Criteria to Test for Completeness in the WBS

• Activity Independence
• It is more important that each activity be
  independent. Once work has begun on the activity,
  it can continue reasonably without interruption
  and without the need of additional input or
  information until the activity is complete.
• Though it is possible that an activity could be
  scheduled during different times based on
  resource availability.

64
Approaches to Building the WBS

• There are many ways to build the WBS. There is no
  one correct way to create the WBS.
  Hypothetically, if we put each member of the JPP
  session in a different room and asked that person
  to develop the project WBS, they might all come
  with different answers.
• There are three general approaches to building
  the WBS
• Noun-type approaches.
• Verb-type approaches.
• Organizational approaches

65
Approaches to Building the WBS

• Noun-type approaches. Noun-type approaches define
  the deliverable of the project work in terms of
  the components ( physical or functional) that
  make up the deliverable.
• Verb-type approaches. Verb-type approaches define
  the deliverable of the project work in terms of
  the actions that must be done to produce the
  deliverable. These include the design-build-test-i
  mplement and project objectives approaches.
• Organizational approaches. Organizational
  approaches define the deliverable of the project
  work in terms of the organizational units that
  will work on the project. This type of approach
  includes the department, process, and geographic
  location approaches.

66
WBS and Gantt Chart in Microsoft Project
67
Importance of Phases

• The end of each phase should be a milestone
• The end of each significant task should be a
  milestone
• These can define your management review points
• Phase exits or kill points
• Ensure continued alignment with goals
• Form of Validation Verification (VV)
• Milestones should be entered into the WBS as a
  zero duration task such as approve project plan

68
Next Class

• Topic
• Project Planning Activity
• Lots of Project Details Scheduling Estimation
• Activity Definition 
• Sequencing
• Estimating size and complexity, resource
  management, duration, resources
• Tools    WBS, PERT, CPM,
• Reading
• PMP Study Guide Chapter 4, 7
• Kerzner Chapter 11.9-11.16, 12, 14
• Hallows Chapter 4
• Lewis Chapter 5-6
• Taylor Chapter 6

69
Journal Exercise

• Considering the WBS
• How detailed should a project get?
• Should we include sub-activities?
• For example, should the coding task have
  sub-tasks of
• Write code
• Review code
• Test code
• Release code to the CM system
• Should we have a test for each code module?
• We dont even know what the software looks like!