Software Project Management

1
Software Project Management

• Project scope and activities
• INFO 638
• Glenn Booker

2
Project Scope

• In Traditional Project Management (TPM), it is
  assumed that you can determine the goal of the
  project from the onset
• The adaptive or extreme management methods
  examined later will allow this not to be true
• Capture key project objectives in the Project
  Overview Statement (POS)

3
Disclaimer

• I didnt make up the POS acronym its not my
  fault

4
Role of the POS

• The POS captures key objectives of the project,
  such as the Conditions of Satisfaction (COS)
• It should be a short document (1-2 pp)
• The COS should convey what the project is
  expected to deliver and accomplish
• It should be reviewed and updated throughout the
  project it isnt static
• It is negotiated with the customer

5
Role of the POS

• The POS is a communications tool among the
  project manager, their development team, the
  customer, and the project managers boss (upper
  or senior management)
• The POS is a concise statement of the project,
  and a summary of its justification to continue

6
Other Views

• The POS and COS are often known by other terms,
  like the Vision or Mission of the project
• POS and COS are Wysockis terminology

7
Generating the POS

• Often the POS is developed through an iterative
  process
• The customer makes a request for some major
  aspect of the product (key set of features, for
  example)
• The developer asks to clarify the request
• The customer provides a response
• Customer and developer agree on the response
• Repeat the previous four steps until done

8
Non-traditional POS Uses

• The POS can help understand a project even if not
  starting from scratch
• Inheriting a project from someone else
• Using a POS as a suggestion to start an
  unsolicited project
• Use a POS as a reference to guide your team
  during development

9
Parts of a POS

• The POS has five major sections
• Problem/opportunity
• Goal
• Objectives
• Success criteria
• Assumptions, risks, obstacles
• Each is typically a few paragraphs long

10
Problem/opportunity

• This section summarizes major problems the
  project will fix, and identify significant new
  opportunities of which it will take advantage
• Like the INFO 503 analysis method of the same
  name, this helps prove there is significant
  motivation for the project to occur

11
Goal

• The goal gives direction and purpose to the
  project, summarizing how the organization will
  address the problems, or act on the opportunities
• Dont commit to specific time or cost goals the
  scope of the project is too vague for that

12
Objectives

• The objective statements elaborate on the goal,
  and clarify its scope or boundaries
• If you meet all the objectives, then the goal
  must also be met
• Each objective should define an expected outcome,
  the rough time frame it will be done, a measure,
  and the action needed to meet the objective

13
Success criteria

• Imagine the project is done, and you want to
  prove how much the organization benefited from it
• What specific measures could you make to prove
  the project was worthwhile?
• These are your success criteria
• Typical criteria are increased revenue, reduced
  costs, improved service, etc.

14
Assumptions, risks, obstacles

• This is an executive summary of major assumptions
  the project is based upon, key risks to manage,
  and foreseeable obstacles that will need to be
  overcome
• Particularly focus on areas you might need help
  managing
• More details will appear in the Project
  Definition Statement (PDS)

15
POS Attachments

• The POS can have attachments for more information
  on the project
• Most common are
• A risk analysis (to show more detail than given
  earlier), and/or
• A financial analysis (such as cost-benefit
  analysis, feasibility studies, ROI, etc.)

16
POS Approval

• The POS is submitted to middle or upper
  management for approval
• The expected outcome is to continue more detailed
  planning and analysis for the project

17
Expand POS into PDS

• The Project Definition Statement (PDS) expands on
  the POS in two key areas
• Objectives can be more specific, and use more
  technical language to convey their exact intent
• Assumptions, risks, obstacles can cover more
  details of interest to the development team

18
Summary of Project Scope

• The POS and PDS capture the key concepts needed
  to
• Understand the basis for the project (why does it
  need to exist?)
• Demonstrate understanding of the project risks,
  context, and concerns
• Provide an outline of objectives the project will
  (hopefully) achieve
• And therefore justify approval for the project to
  continue

19
Work Breakdown Structure (WBS)

• The WBS gives structure to the set of activities
  in a project
• It expands on the POS by describing activities in
  more and more detail, until you get down to the
  smallest level of task you need to define for
  your project
• The WBS is a really big to-do list

20
Smallest Level of Task?

• How big is the smallest level of task?
• Depends on the size of the project, and how
  mature the staff are
• In general, from a couple hours to a week might
  be the range
• Near term tasks are typically defined in more
  detail than distant ones
• In Wysockis terminology, tasks make up the
  smallest level of activity

21
WBS

• The goal of the project should be accomplished
  when all tasks in the WBS are completed
• When major activities are sequential, they
  typically appear in that order in the WBS
• The Gantt chart and PERT chart (well discuss
  later) are graphic forms of the WBS

22
Activity Decomposition

• The key to writing a good WBS is to decompose the
  project goal into major activities
• Then keep breaking those activities down until
  you get to the smallest level of tasks mentioned
  earlier
• A WBS with too much detail is time consuming to
  generate and follow
• not enough detail, and you miss important tasks

23
Why Create a WBS?

• The WBS helps plan out the process needed to
  accomplish the project
• It also helps design the architecture of the
  project
• It forms the basis for estimating the time and
  effort needed for the project
• It establishes a baseline for reporting project
  status

24
Generating a WBS

• There are two basic approaches to generating a
  WBS
• Top-down
• Start at the project goal, and keep breaking down
  activities until you get to the smallest task
  needed
• Can use the Team approach (have everyone work on
  the schedule together) or
• The Subteam approach (agree on level 1
  activities, then have subteams tackle each
  activity in detail then check for duplication
  and missed tasks)

25
Generating a WBS

• Bottom-up
• Agree on the top level activities using the
  top-down approach
• Then break into teams and brainstorm all the
  activities you think are within that overall
  activity
• Organize the activities, and check for missed
  tasks and redundancies
• Often the top-down approach results in a more
  complete draft WBS

26
Special Case WBSs

• Small projects may want to consider tools to help
  generate a good WBS, such as mindmapping
• Large projects may need to alter the approach to
  develop the top two WBS levels as a group, then
  establish subteams or teams to fill out the
  details below that

27
Are we Done Yet?

• Six criteria can help determine if a WBS is
  complete
• Measurable Status Is each task defined in a way
  to help monitor its status toward completion?
• Typically requires some kind of measurement to
  assess percent completion
• Bounded Is each task clearly bounded by start
  and stop events?
• What event marks the start and stop of each task?

28
Are we Done Yet?

• Deliverable Does each activity have a clearly
  defined deliverable?
• What output should the activity produce?
• Cost and Time Estimate Is each activity defined
  in a way that allows a meaningful estimate of its
  calendar time and cost to completion?
• Often software cost is largely driven by the
  labor cost, and hence the amount of effort needed
  to develop it

29
Are we Done Yet?

• Acceptable Duration Limits Most activities
  should be broken down into tasks which are
  reasonably small
• Under two weeks is the upper limit
• There can be exceptions to this rule
• Activity Independence Are the activities
  defined to be independent of each other as much
  as practical?
• Avoid activities that are too complex, or the
  other extreme, micromanaging

30
WBS Approaches

• There are three major approaches to structuring
  a WBS
• Noun-type approaches
• Verb-type approaches
• Organizational approaches

31
Noun-type approaches

• The noun-type approach means the WBS is
  structured by the physical or functional
  components of the project
• In a client-server system, the client and
  servers development could each be top level WBS
  activities
• In assembling a car, each major subsystem could
  be a WBS activity (drivetrain, body, cabin,
  suspension, ...)

32
Verb-type approaches

• Verb-type approaches focus on the processes in
  the project
• Most common for software development, this
  includes using each phase of the life cycle as a
  top level WBS activity Requirements Analysis,
  High Level Design, Low Level Design, Coding,
  various kinds of Testing, etc.
• Could define WBS by project objectives
• Shows how close project is to completion

33
Organizational approaches

• The organizational approach groups activities by
  who does them
• Could be based on geographic location,
  department, etc.
• Might be good for a distributed development team,
  to help make it clear what each group is supposed
  to do

34
Showing the WBS

• The WBS can be shown as an organization
  chart-like structure (p. 93)
• This gives an overview of all the activities

35
Naming WBS Tasks

• The tasks in a WBS (and ideally, the activities
  too) should start with a verb
• Include tasks to plan the project, conduct the
  actual work of the project, make decisions, etc.
• Task names might include Prepare test plan,
  Conduct system test, Write test report,
  Approve system release

36
WBS Numbering

• This section isnt part of Wysocki
• Tasks and activities are often given unique
  identification numbers to help do cost accounting
  and generate status summaries
• In Microsoft Project, you can add a column called
  WBS which will automatically follow this numbering

37
WBS Numbering

• The goal of a WBS is to structure activities to
  allow for unique identification and tracking of
  existing activities, while being expandable to
  allow for new ones
• The WBS numbers are a series of numbers separated
  by periods, used to identify tasks on a project

38
WBS Number Format

• The highest level of each major task is a whole
  number (1.0, 2.0, )
• The duration of major tasks (1.0) is the span of
  all tasks under it (e.g. 1.1 to 1.3)
• Lower level tasks are components of their higher
  level task (2.1 is part of 2.0), hence a short
  WBS number (2.1) is a higher level task than a
  long WBS number (2.1.2)

39
WBS Number Example

• For example
• 1.0 Risk Management Activities
• 1.1 Develop Risk Management Plan
• 1.2 Approve Risk Management Plan
• 1.3 Conduct Ongoing Risk Management
• Task 1.0 is the highest level task shown
  composed of tasks 1.1 to 1.3
• Note that lower levels are indented

40
WBS Numbering

• Numbers above nine under one task just keep
  counting (e.g. 1.8, 1.9, 1.10, 1.11, )
• The WBS numbers allow new tasks to be inserted
  where needed, such as tasks 1.1.1, 1.1.2 and 1.4
  in the RM example, and yet uniquely identifies
  each task.
• A WBS can use as many digits as needed (e.g.
  1.2.3.14.7.6.5)

41
Typical Software WBS

• A typical waterfall life cycle project might use
  a WBS that follows the life cycle phases
• 1.0 Do Requirements Analysis
• 2.0 Conduct High Level Design
• 3.0 Conduct Low Level Design
• 4.0 Conduct Coding and Unit Testing
• 5.0 Conduct Integration and System Testing

42
Typical Software WBS

• While that handles the development life cycle
  activities, often support activities will be
  broken out into separate WBS elements
• 6.0 Perform Quality Assurance
• 7.0 Conduct Configuration Management
• 8.0 Conduct Project Management
• This is a hybrid of the verb and organizational
  WBS approaches

43
Typical Software WBS

• Then, within each of the top level WBS
  activities, you decide what activities and tasks
  are needed
• Within requirements analysis, what will you do to
  accomplish that?
• Examine legacy system documentation?
• Conduct interviews?
• Study similar systems?
• Describe use cases?

44
OO WBS

• The top level WBS for an object oriented (OO)
  project might follow the Rational Unified Process
  life cycle phases
• 1.0 Conduct Inception Phase
• 2.0 Conduct Elaboration Phase
• 3.0 Conduct Construction Phase
• 4.0 Conduct Transition Phase

45
OO WBS

• For an OO project, you may not need separate top
  level WBS entries for support tasks, if they are
  integrated into each phase
• Then each phase has iterations, and you need to
  determine how long they are (eventually) and what
  tasks happen inside each iteration

46
OO WBS

• 1.0 Conduct Inception Phase
• 1.1 Conduct iteration I-1
• 1.1.1 insert tasks for this iteration
• 1.1.2 insert tasks for this iteration
• 1.2 Conduct iteration I-2
• 1.2.1 insert tasks for this iteration
• 2.0 Conduct Elaboration Phase
• 2.1 Conduct iteration E-1
• 2.1.1 you get the idea

47
WBS Summary

• There is no one perfect correct way to generate a
  WBS for a given project
• Many solutions could work well
• It is common to blend the noun, verb, and
  organizational structures
• Such as use the verb approach for the top level
  WBS, then noun or organizational for lower level
  elements