SE 477 Software and Systems Project Management

1
SE 477 Software and Systems Project Management

• Dennis Mumaugh, Instructor
• dmumaugh_at_depaul.edu
• Office CDM, Room 428
• Office Hours Wednesday, 400 530

2
Administrivia

• Comments and feedback
• MS-Project
• Short set of slides (from John Musser) on class
  web page
• Download the Automatic Tollbooth example and work
  with it.
• Google microsoft project tutorial
• A random such tutorial is http//www.profsr.com/m
  sproject/msproj01.htm
• Homework
• Page size suggestions are for single spaced
  documents. Double them for double spaced. I
  prefer single spaced or space and a half!
• Show paragraphs indent or use a space change MS
  Word style. Show section heads.
• Proof read!

3
Administrivia

• Project
• Continue work on team assignment
• By now you should have organized and have had
  some virtual meetings.
• Should have some of the work on Project Charter
  and Preliminary Project Scope finished.
• Should have rough schedule for rest of work.
• Keep in touch and make sure your team members are
  communicating and doing work.
• Inform me immediately if your partner(s) are not
  keeping up and you are having problems.

4
Homework

• Assignment 3 Due February 8, 2017
• Develop a plan and project schedule for a small
  subsystem
• Assume the project is using the waterfall SDLC
  and has the following phases Requirements, High
  Level Design, Detailed Design, Coding and Unit
  Test, Integration and Testing, Documentation.
• There is a WBS provided with the required phases,
  activities and information to complete this
  project.
• Assign Resources to the Tasks making any
  assumptions you consider appropriate (Software
  Engineering Assumptions).
• Provide an executive summary
• What is the earliest finish date for this project
  if it is scheduled to start on 3/20/2017? Dont
  forget holidays!
• Show the duration and delivery schedule given the
  start date is March 20, 2017.
• Show the staffing and resources used, and the
  total staff time.
• You should use ProjectLibre or MS Project to
  develop this.

5
SE 477 Class 4

• Topic
• Project Planning
• Project scope management
• Project requirements
• Creating the Work Breakdown Structure (WBS)
• Activity
• Activity Definition
• Activity Sequencing
• Reading
• PMBOK-SWE Ch. 5, Ch. 6.1-6.3

6
Thought for the day

• Predictions are hard, especially about the
  future
• Yogi Berra

7
Last time

• Initial Phase
• Developing the project charter
• Statement of work (SOW)
• Agile Perspective The Product Overview Document
• Stakeholders
• Organizational Structures Influences
• Project planning
• Initial documents
• Project Charter Statement of Work (SOW)
• Project plans
• The Project Management Plan

8
Project Planning A 12 Step Program

1. Set goal and scope
2. Select lifecycle
3. Set organization/team form
4. Start team selection
5. Determine risks
6. Create WBS

1. Identify tasks
2. Identify task dependencies
3. Estimate size
4. Estimate effort
5. Assign resources
6. Schedule work

9
Project scope management

• Scope Planning
• Project Requirements
• Define Scope
• Creating the Work Breakdown Structure (WBS)

10
Scope

• Project scope management is one of the most
  critical project management knowledge (skill)
  areas
• Scope defines
• All the work that is required to complete the
  project successfully and
• Only the work that is required, no more, no less
• This latter point is critical project scope
  management defines and controls what is and is
  not part of the project work

11
Scope planning

• Scope planning is concerned with choosing the
  most appropriate, most effective approach to
  managing the scope of the project
• Scope planning defines how to
• Define the scope
• Develop the detailed project scope statement
• Define and develop the WBS
• Verify project scope
• Control project scope
• Scope planning takes two primary inputs the
  project charter and the preliminary project scope
  statement
• Scope planning results in a project scope
  management plan

12
Project detailed scope statement

• The project detailed scope statement is an
  evolved version of the preliminary project scope
  statement
• Content (template) requirements are identical to
  the preliminary version
• Actual content of the detailed scope definition
  should reflect any additional information
  gathered since preliminary scope statement

13
Inputs, tools techniques, and outputs

• Inputs
• Project management plan
• Project Charter
• Enterprise environmental factors
• Organizational process assets
• Tools Techniques
• Expert judgment
• Meetings
• Outputs
• Scope management plan
• Requirements management plan

14
Scope management plan

• According to PMBOK 5 The scope management plan
  can be formal or informal, broadly framed or
  highly detailed, based on the needs of the
  project.
• This course adopts the informal, broadly-framed
  perspective
• The components of a scope management plan
  include
• Process for preparing a detailed project scope
  statement
• Process that enables the creation of the WBS from
  the detailed project scope statement
• Process that establishes how the WBS will be
  maintained and approved
• Process that speci?es how formal acceptance of
  the completed project deliverables will be
  obtained
• Process to control how requests for changes to
  the detailed project scope statement will be
  processedthis process is directly linked to the
  Perform Integrated Change Control process

15
Requirements management plan

• Components of the requirements management plan
  can include, but are not limited to
• How requirements activities will be planned,
  tracked, and reported
• Con?guration management activities such as
• How changes to the product will be initiated
• How impacts will be analyzed, how they will be
  traced, tracked, and reported
• Authorization levels required to approve these
  changes
• Requirements prioritization process
• Product metrics that will be used and the
  rationale for using them
• Traceability structure to re?ect which
  requirement attributes will be captured on the
  traceability matrix

16
Plan Scope Management Data Flow Diagram
17
Process Collect Requirements

• Recall the most critical lesson from the Standish
  Group's 2009 CHAOS report
• Requirements, requirements, requirements
• Requirements are unclear, incomplete, or the
  project management methodology does not
  accommodate changing requirements effectively
• Collecting initial requirements is a critical
  ?rst step in managing requirements over the
  course of the project
• In an iterative/incremental or adaptive/agile
  project, requirements collection continues
  throughout the life cycle of the project
• Requirements elicitation and analysis requires a
  complete course we touch on the topic here for
  completeness

18
Types of requirements

• Business requirements. Describe the high-level
  needs of the organization as a whole
• Examples Increase e-commerce purchases by 25
• Stakeholder requirements. Describe the needs of a
  particular stakeholder, especially with respect
  to external stakeholders
• Example As the site owner, I want the site
  supply chain applications to interface with the
  Web site
• Functional requirements. Describe the behavior
  of the product
• Example As a retail customer, I want to be able
  to shop by brand or product category
• Nonfunctional requirements. Describe the
  behavioral qualities required for the product to
  be effective
• Example As the Web site owner, I want the site
  to be available 99.99 of the time over a 1-year
  period
• PMBOK 5 groups functional and nonfunctional
  requirements under the heading Solution
  Requirements

19
Types of requirements

• Transition requirements. Describe temporary
  capabilities, such as data conversion and
  training requirements, needed to transition from
  the current to the future state
• Example As a data entry clerk, I want to be able
  to use the keyboard shortcuts from the previous
  order system, so that I can maintain my level of
  productivity
• Project requirements. Describe the actions,
  processes, or other conditions the project needs
  to meet
• Example Project must use the hybrid plan-driven,
  iterative and agile methodology
• Quality requirements. Capture condition or
  criteria needed to validate the successful
  completion of a project deliverable
• Example As the site owner, I want a retail
  customer test group to be able to successfully
  search for and ?nd a requested product within 30
  seconds

20
Inputs, tools techniques, and outputs
21
Requirements documentation

• Business requirements
• Business and project objectives
• Business rules for the performing organization
• Guiding principles of the organization.
• Stakeholder requirements
• Impacts to other organizational areas
• Impacts to other entities inside or outside the
  performing organization
• Stakeholder communication and reporting
  requirements.

22
Requirements documentation

• Solution requirements
• Functional and nonfunctional requirements
• Technology and standard compliance requirements
• Support and training requirements
• Quality requirements
• Reporting requirements
• Project requirements
• Levels of service, performance, safety,
  compliance, etc.
• Acceptance criteria
• Transition requirements
• Requirements assumptions, dependencies, and
  constraints

23
Project Considerations

• Is infrastructure setup part of your project?
• Assumptions
• What are you counting on?
• These can be critical to identify
• Resources expected equipment/people, approvals
• Availability of partners, connections
• Delineate key limits
• For example System load expect a maximum of 100
  users

24
Overview

• The De?ne Scope process develops a detailed
  description of the project and product
• Implicit (and stated) in the De?ne Scope process
  is the assumption that not all of the
  requirements collected in the Collect
  Requirements process may be included in the
  project
• Though compatible with an adaptive/agile
  methodology, this assumption represents a
  less-?exible approach to managing requirements
  and scope
• The Project Scope Statement describes the project
  scope, major deliverables, assumptions, and
  constraints

25
Tools and techniques

• Product analysis. Product analysis is the process
  of translating high-level product descriptions
  into tangible deliverables. Product analysis in
  IT includes techniques such as
• System analysis
• Requirements analysis
• Systems engineering
• Alternatives identi?cation. Attempts to uncover
  alternative approaches to executing and
  performing the project work, using techniques
  such as brainstorming and mind mapping
• Alternatives provide contrasting options to the
  planned approach, allowing better de?nition of
  scope

26
Project scope statement

• The project scope statement documents the entire
  scope, including project and product scope
• Project scope encompasses product scope plus the
  work required to create the product any
  project-related activities, such as documentation
  delivery and training
• Product scope encompasses the functional and
  non-functional requirements for the ?nal project
  deliverable
• The project scope statement provides a common
  understanding of the project scope among project
  stakeholders
• The project scope statement may contain explicit
  scope exclusions that can help to manage
  stakeholder expectations
• This can prevent the project from straying from
  the original vision in all project methodologies
  sequential, iterative/incremental, and
  adaptive/agile

27
Project scope statement

• Project scope statement. The project scope
  statement contents include
• Product scope description. Progressively
  elaborates the characteristics of the product
  described in the project charter and requirements
  
• Product acceptance criteria. Conditions required
  for acceptance of deliverables
• Project deliverables. Deliverables include both
  product outputs and project outputs, such as
  project reports and documentation
• Project exclusions. Identi?es what is excluded
  from project
• Project constraints. Lists and describes anything
  that limits the project team's options, such as
  budget, imposed schedule, milestones, etc.
• Project assumptions. Lists and describes anything
  assumed to be true with respect to the scope and
  impact if these prove to be false

28
Project document updates

• Results of the De?ne Scope process may affect
  other project documents, including
• Stakeholder register
• Requirements documentation
• Requirements traceability matrix not discussed

29
Process Create WBS

• 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

30
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. Can be used to mark completion of
  an activity or phase.

31
Overview Tasks

• Planning and scheduling use tasks as the basic
  element.
• Sometimes this is known as activities.
• The main tool for activity definition is
  decomposition
• Gallia est omnis divisa in partes tres
• Commentarii de Bello Gallico
• Julius Caesar
• Divide and Conquer
• Decomposition is the process of breaking the
  project scope and deliverables into smaller, more
  manageable components
• These more manageable components are called work
  packages
• Work packages are the lowest level of
  decomposition in the WBS
• Reliable time, cost, and resource estimates can
  be made at the level of work packages in a
  project
• Work in the context of the WBS means work
  products or deliverables, not the effort itself,
  as in staff-hours of effort

32
Decomposition

• Decomposition is usually performed in a top-down,
  hierarchical manner as expressed by the Work
  Breakdown Structure (WBS)
• Creating the Work Breakdown Structure (WBS) is
  the process of decomposing project deliverables
  and work into smaller, more manageable components
• The level of detail for work packages vary
  depending on project size and complexity
• As we have seen, for IT projects using the agile
  process we have defined, each iteration (sprint)
  defines one or more work packages

33
Overview Tasks

• Decomposition is the core tool and technique of
  all WBS effort
• The WBS is
• Structured hierarchically each successively
  lower level represents a more-detailed de?nition
  of project work
• Deliverable-oriented each lower level represents
  a more detailed de?nition of project work
• A representation of project scope it organizes
  and de?nes the total scope of the project
• The lowest level of detail in the WBS is the work
  package
• Work packages are scheduled, cost estimated,
  monitored, and controlled
• Decomposition proceeds until it is possible to
  define the component as a work package
• A deliverable or work component at the lowest WBS
  level that includes schedule activities and
  milestones to complete the deliverables or work

34
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!

35
Decomposition activities

• Identify and analyze the deliverables and related
  work
• The project scope statement provides the basis
  for the first iteration of deliverable
  identification
• Structure and organize the WBS according to an
  appropriate high-level hierarchy
• For IT projects using an iterative system
  development model, a phase/iteration/discipline
  hierarchy most closely matches the SDLC process
• Note that one of the disciplines in the iterative
  SDLC process is Project Management it is here
  that appropriate project management processes may
  be entered
• Decompose the upper WBS levels into lower-level
  detailed components
• If appropriate, larger deliverables may be
  decomposed into smaller deliverables, all the way
  down to the work package level

36
Decomposition activities

• Develop and assign identification codes to the
  WBS components
• Note that each item in the WBS has both a unique
  identifier (the code or account identifier) and a
  WBS code
• The unique identifier does not change if a
  component is moved about in the WBS structure
  however, the WBS code does change
• Verify that the amount of decomposition of work
  is necessary and sufficient
• This can be translated into a simple concept the
  just right principle
• The just right principle states that no more
  decomposition is neededit would be too
  detailedand any less decomposition would be too
  coarse
• Insufficient decomposition leads to reduced
  ability to plan, manage, and control the work
• Excessive decomposition leads to wasted effort
  and decreased efficiency

37
The Work Breakdown Structure
38
Work Breakdown Structure

1. Breaks project into a hierarchy.
2. Creates a clear project structure.
3. Avoids risk of missing project elements.
4. Enables clarity of high level planning.

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

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

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

42
Six Criteria to Test for Completeness in the WBS

• The WBS is developed as part of a Joint Planning
  session. But how do you know that you've 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

43
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 system's 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.

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

45
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 manager's 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.

46
Six Criteria to Test for Completeness in the WBS

• Activity Independence
• It is 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.

47
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

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

49
WBS and Gantt Chart in Microsoft Project
50
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

51
Work Breakdown Structure (WBS)

• Recall the definition from the PMBOK Guide
• The WBS is a deliverable-oriented hierarchical
  decomposition of the work to be executed by the
  project team to accomplish the project objectives
  and create the required deliverables.
• WBS is the primary tool for managing the scope of
  a project
• Work in the WBS is within scope
• Work not in the WBS is out of scope
• Though relatively simple, considered the single
  most important project management tool
• In WBS, levels represent different levels of
  project decomposition

52
The 100 rule

• The 100 rule is one of the most important
  principles guiding development, decomposition,
  and evaluation of the WBS
• Rule states that the WBS
• Includes 100 of the work defined by the project
  scope
• Captures all internal, external, and interim
  deliverables in terms of work to be completed,
  including project management
• Rule applies at all levels within the hierarchy
  the sum of the work at the child level must
  equal 100 of the work represented by the
  parent
• WBS should not include any work that falls
  outside the actual scope of the project, that is,
  it cannot include more than 100 of the work

53
Conventional WBS levels

• Level 1
• Project name
• Level 2
• Major subsystems of the project
• Level 3
• Components/task activities of subsystems at Level
  2
• Level 4
• Subcomponents/subtasks of components/tasks at
  Level 3
• Level 5
• Work packages for subcomponents/subtasks at Level
  4
• Work packages are where the actual work takes
  place
• Assigned to a person and given a schedule and
  budget

Note that conventional WBS decomposition levels
are product-oriented
54
Criticisms of conventional WBS

• Conventional WBS is prematurely structured around
  product design
• Note early orientation toward concrete subsystems
• Conventional WBS is prematurely decomposed,
  planned, and budgeted in too much or too little
  detail
• Recall the idea of progressive elaboration
• Conventional WBS is project-specific, making
  cross-project comparisons difficult or impossible
• Result of first item, above

55
Sample conventional WBS
56
WBS terminology (PMI)

• Deliverable. Any unique and verifiable product,
  result, or capability to perform a service that
  must be produced to complete a process, phase, or
  project
• Milestone. A significant point or event in the
  project
• Work Breakdown Structure Component.  Entry in the
  work breakdown structure that can be at any
  level. Also known as WBS Element
• Work Package.  Deliverable or project work
  component at the lowest level of each branch of
  the WBS. Includes schedule activities and
  milestones required to complete the work package
  deliverable or project work component
• Note It is not necessary to enter every work
  package activity as a separate WBS component

57
WBS representations

• There are two common ways of representing the WBS
• Hierarchical graphical format. A graphical view,
  similar in form to an organization chart
• Hierarchical textual format. This is the common
  hierarchical list view of the WBS, provided by
  most project management software such as MS
  Project
• WBS should always be developed before the
  schedule is worked out, without trying to
  sequence specific activities
• This is primarily important (and essential) when
  using a functional WBS decomposition
• Process-oriented WBS decomposition (e.g.
  evolutionary) usually has well-defined
  higher-level WBS components
• Specific activity sequencing is determined in the
  schedule

58
Rolling wave planning

• Our understanding of work that must be
  accomplished in the near term is better than that
  for work to be performed far in the future
• Rolling wave planning varies the amount of
  planning detail depending on the immediacy of the
  tasks to be performed
• Rolling wave planning is a means for implementing
  progressive elaboration
• Work in the upcoming one or two reporting periods
  is planned in detail, while later work is planned
  at a lower level of detail

59
Rolling wave planning

• Note on 100 rule
• What encompasses 100 of the project work is
  referenced to a particular time point in the
  project
• Scope may change, but only with proper approval
  and control
• Implication 100 comprises all approved work
  at a particular point in time

60
Create WBS Outputs

• Scope baseline. The scope baseline is the
  approved version of a scope statement, work
  breakdown structure (WBS), and its associated WBS
  dictionary
• Project scope statement. Output from De?ne Scope
  process
• WBS. Either graphical or tabular form
• WBS dictionary. A companion document to the WBS,
  providing detailed information about components
  in the WBS, including work packages (see next
  slide for content)
• In a conventional project management environment
  the scope baseline can be changed only through
  formal change control procedures

61
WBS dictionary

• Companion document to the WBS
• Provides the detailed content for the WBS,
  including work packages
• Practically, WBS dictionary is developed
  concurrently with Activity Definition process
  under Project Time Management knowledge area
• WBS components are cross-referenced to other WBS
  components as needed

62
WBS dictionary content

• Required
• Code or account identifier unique number
  assigned to a WBS component
• Statement of work scope statement for the WBS
  component
• Responsible organization for WBS component
• Schedule milestones for WBS component

• Optional
• Contract information
• Quality requirements may be used in assessment
  planning
• Technical references to assist in executing work
• Charge number
• List of schedule activities
• Resources required
• Estimate of cost

63
WBS template
64
Activity or task definition
Added System architecture definition WBS component
Note expansion and detailing of WBS template
Architecture design modeling entry renamed
Software architecture description to Document
software architecture
Note expansion and detailing of WBS template
Design demonstration planning and conduct entry
Note rework of WBS template Elaboration phase
assessment entry
Note expansion and detailing of WBS template
Critical component coding demo integration entry
65
Create WBS Data Flow Diagram
66
Agile Perspective Create WBS

• Valuable concepts and tools
• The Create WBS process is among the least
  compatible with a complex (or agile) project
  perspective
• It encourages solidifying the scope of the
  project in a complex, dif?cult to change
  artifact, the WBS
• Once an artifact is created, it assumes an
  authority that may not be justi?ed
• Most WBSs are out-of-date shortly after being
  created
• People are reluctant to toss something that has
  taken so much effort
• Nevertheless, the process of thoughtful
  decomposition of the product into smaller, more
  manageable pieces is certainly compatible with an
  adaptive/agile methodology
• Adaptive/agile limits high-level decomposition to
  the product roadmap, and defers low-level
  decomposition to the release and iteration
  (sprint) level

67
WBS Basis of Many Things

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

68
The MS-Project Process

• Move WBS into a Project outline (in Task Sheet)
• Add resources (team members or roles)
• Add costs for resources
• Assign resources to tasks
• Establish dependencies
• Refine and optimize
• Create baseline
• Track progress (enter actuals, etc.)

69
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

70
Project Planning Project Time Management I

• Introduction
• Activity Definition
• Activity Sequencing

71
Overview

• Project time management is the project management
  knowledge area concerned with analyzing the
  logical and temporal relationships among the
  activities needed to complete the project
• Three elements form the core of time management
  analysis
• The schedule data and associated calculations
  (e.g., activity de?nitions and estimates)
• The scheduling method applied to the schedule
  data in order to de?ne estimated start and end
  dates for activities and milestones, including
  project completion
• The schedule that represents the output from a
  scheduling tool applying the method to the data
• In a conventional methodology, the project
  schedule acts as the planning backbone for
  virtually all other project activities

72
Project time management processes

• The project time management processes include
• De?ne activities. Identi?es speci?c activities to
  be carried out in work packages
• Sequence activities. Identify and document
  relationships among activities
• Estimate activity resources. Estimate the number
  and type of resources needed for activity, such
  as staff, materials, equipment, software, etc.
• Estimate activity durations. Estimate number of
  work periods (e.g. hours, days, weeks) to
  complete activity with estimated resources
• Develop schedule. Analyze network of activity
  sequences, durations, resources, and constraints
  to estimate planned dates for activities and
  milestones

73
Project time management processes

• The project time management processes include
• Control schedule. Monitor schedule status and
  manage schedule updates
• We focus only on the planning process knowledge
  area for time management, comprising the the ?rst
  ?ve processes above. In practice, on smaller
  projects, the middle four processes are carried
  out concurrently

74
Scheduling workflow

• Define activities
• Use of WBS helps guide definition process and
  organize activities
• Perform activity sequencing
• Develop schedule framework according to what is
  logically possible perform resource allocation
  later
• Estimate effort the total number of labor units
  (e.g. staff-days) for each activity
• Estimate elapsed time
• Identify resources for each activity
• Apply calendars to schedule framework

75
Scheduling workflow

• Some of these will be covered in a later lecture.
• Estimate activity duration based on resources for
  activity
• Perform forward pass or backward pass critical
  path analysis to generate schedule model later
  lecture appendix
• Apply schedule compression, if needed
• Perform what-if scenario analysis to identify
  contingency and risk response needs
• Apply resource leveling to schedule model

76
Planning, Estimating, Scheduling

• What's the difference?
• Plan Identify activities. No specific start and
  end dates.
• Estimating Determining the size duration of
  activities.
• Schedule Adds specific start and end dates,
  relationships, and resources.
• Note the term activities much the same as tasks
  but more general.

77
How To Schedule

• Identify what needs to be done
• Work Breakdown Structure (WBS)
• Identify how much (the size)
• Size estimation techniques
• Identify duration
• Effort estimation techniques
• Identify the dependency between tasks
• Dependency graph, network diagram
• Gantt chart and PERT
• Estimate total duration of the work to be done
• The actual schedule
• PERT and CPM

78
Overview

• The De?ne Activities process identi?es the
  speci?c actions or tasks needed to carry out the
  project and produce the project deliverables
• In a conventional project methodology, the Create
  WBS process de?nes the project deliverables and
  work packages
• In an adaptive/agile project methodology, only
  the high-level deliverables are de?ned up front,
  while work packages are de?ned at the iteration
  level
• Each work package comprises the speci?c
  activities needed to complete the work package
• Recall that
• Deliverables and work packages are the planning
  units for project management purposes
• Tasks (activities) are the planning unit for
  development purposes
• An iteration/sprint comprises one or more work
  packages (and their associated activities)

79
Activity definition

• PMBOK factors out activity definition as a
  separate process from the creation of the WBS
• However, in practice, the activity definition
  list, WBS, and WBS dictionary are usually
  developed concurrently
• Rolling wave planning should be applied to
  activity definition in order to optimize the
  level of detail in the WBS neither too little
  (for immediate work) or too much (for later work)
• The main tool for activity definition is
  decomposition

80
Activity definition

• Decomposition is the process of breaking the
  project scope and deliverables into smaller, more
  manageable components
• Decomposition is usually performed in a top-down,
  hierarchical manner
• Decomposition proceeds until it is possible to
  define the component as a work package
• A deliverable or work component at the lowest WBS
  level that includes schedule activities and
  milestones to complete the deliverables or work
• Significant part of the WBS decomposition can be
  defined by WBS templates (see Practice Standard
  for Work Breakdown Structures, Second Edition
  (ebooks 24x7), for examples)

81
Sidebar A useful rule of thumb

• No work package should have a duration greater
  than four to six weeks
• For knowledge work, durations should be in the
  range of one to three weeks, because knowledge
  work is harder to track than tangible work
• People tend to back-end load tasks with lengthy
  durations by pushing all the effort toward the
  end
• For this class the team project, keep work
  package durations in the one-to-two-week range

82
Activity definition workflow

• Choose an appropriate WBS template as a guide for
  activity definition
• Enter WBS template into a project management tool
  (if preloaded template not available)
• Define activities in the task list of the project
  management tool
• If decomposition results in an activity with a
  deliverable/work component and a duration of 1-2
  weeks, consider it a work package
• If decomposition results in a set of shorter (lt1
  wk) activities, group them into one or more 1-2
  week work packages that produce deliverable/work
  components

83
Activity definition workflow

• Assign each activity a unique identification code
  that remains with the activity if it is moved in
  the list
• The WBS code is a position-dependent hierarchical
  code it does not stay with an activity if moved
  
• Example Architectural Cost-Benefit Analysis has
  a WBS code of 4.2.1.2 but a unique identification
  code of (hypothetically) ADM2 (or 25.0, or any
  other code)
• Work packages usually have additional activity
  detail specified in their WBS dictionary entry
• This is essential if the work package is not a
  highly standardized process

84
Agile Perspective De?ne Activities

• Essential, but do it just in time
• In this process, PMBOK leans heavily toward the
  complicatedrather than complexproject
  methodology
• The PMBOK states The activity list is a
  comprehensive list that includes all schedule
  activities required on the project
• In an adaptive/agile project, this list
  cannotand should notbe generated early in the
  project
• Attempting to de?ne activities up-front in a
  complex project leads to wasted effort and
  inconsistencies between documents and reality
• Instead, application of the agile method delays
  speci?c activity de?nition to the start of each
  individual sprint, and delegates the activity
  de?nition to the individual sprint development
  teams
• De?ne activities no earlier than during iteration
  planning

85
Reading

• Practice Standard for Work Breakdown Structures,
  Second Edition by Project Management Institute
  (2006)
• Available on Books 24x7 (through the DePaul
  e-library)
• Appendix K Web Design Work Breakdown Structure
  (WBS) Example
• Appendix O Software Implementation WBS Example
• Note that both of these templates are
  process-oriented

86
Activity Sequencing

• Precedence diagram method
• Dependency types
• Leads and lags

87
Introduction

• Activity sequencing identifies and documents the
  logical relationships among activities in a
  project
• Logical sequencing is determined by precedence
  (predecessor-successor) relationships
• Activity sequencing, though executed differently
  is an important concept in all project management
  methodologies
• Essential inputs
• Activity list, which may be developed
  concurrently with WBS
• May use scope statement information to determine
  or refine precedence constraints
• Essential outputs
• Project schedule network diagrams
• Updated activity list/WBS

88
Precedence Diagram Method (PDM)

• The Precedence Diagram Method (PDM) is a
  graphical schedule diagramming method aka Network
  Diagram
• Represents activities as rectangular nodes
• Connects the nodes with arrows to show
  dependencies
• Connection points of arrows to activities refine
  and impose constraints on dependencies
• Classified as an Activity on Node (AON)
  diagramming scheme
• Alternative is Activity on Arrow (AOA) that
  models project in states, with activities as
  transitions from one state to another

89
Dependency types illustrated
90
Dependency types

• Finish-to-start. Start of successor activity
  depends on finish of predecessor activity
• Example Start of testing after code completion
  in traditional waterfall development
• Finish-to-finish. Finish of successor activity
  depends on finish of predecessor activity
• Example Acceptance of a component can only
  complete when acceptance of last subcomponent is
  complete
• Start-to-start. Start of successor activity
  depends on start of predecessor activity
• Example Start of acquisition of third-party
  software component triggers training for involved
  developers

91
Dependency types

• Start-to-finish. Finish of successor activity
  depends on start of predecessor activity
• Example Subcontract x will complete t days after
  subcontract y begins
• Percent complete Last n of successor activity
  depends on m completion of predecessor activity
• Example Last 30 of network interface
  development will begin when 50 of application
  development is complete
• Note A better choice of terms might be dependent
  and independent activities, as in the cases of
  Start-to-start and Start-to-finish

92
PDM example
93
Activity sequencing
Note dual predecessors. Default relationship is
Finish-to-Start. Here, we have defined a
Start-to-Start relationship with an added lag of
5 days
Here, we have defined a Finish-to-Finish
relationship this is common for
implementation/integration task pairs
94
Dependency type determination

• Mandatory dependencies. Dependencies that are
  inherent in the nature of the work
• Example Acceptance testing can only begin after
  all code development is complete (except for bug
  fixes)
• Discretionary dependencies. Dependencies that are
  not inherent in the work, but might be preferred
  by the PM team based on best practices or other
  factors. Also known as preferred or soft logic
• Discretionary dependencies should be fully
  documented so they can be properly considered and
  evaluated for later scheduling options
• Example Schedule high-risk activities early in
  development in order to mitigate those risks
  (best practice)
• Example Beginning work on second draft of a
  document before first draft is complete
• Example admissions system has a dependency upon
  delivery and configuration of smart card reader

95
Dependency type determination

• Internal dependencies. Dependencies that are
  between project activities and within the project
  team's control
• Example Start of procurement of third-party
  software component triggers training for
  developers who will work with the component
  (internal, discretionary dependency)
• External dependencies. Dependencies that involve
  a relationship between project and non-project
  activities
• External dependencies are usually outside the
  project team's control
• Example Delivery of any third-party component,
  such as a custom or COTS component

96
Leads and lags

• Lead. A lead moves an activity back in time from
  its expected point. Sometimes referred to as an
  accelerated activity
• Example Beginning work on second draft of
  document before first draft is complete
• Lag. A lag introduces a delay into a successor
  activity. Restricts the start of the successor,
  even if predecessor activity is complete
• Example Requiring ten days lag before acceptance
  testing can begin (possibly introduced as
  contingency)

97
Outputs

• Schedule network diagrams. Schedule network
  diagrams graph the project activities and their
  dependencies. These may be produced manually or
  using project management software
• Documentation explaining discretionary
  dependencies, leads and lags, or other
  exceptional dependencies should accompany the
  diagram
• Project document updates. The Sequence Activities
  process may lead to updates in the following
  project documents
• Activity lists
• Activity attributes, speci?cally the predecessor
  and successor activities, logical relationships,
  and leads and lags attributes
• Milestone lists
• Risk register

98
Task

• Name
• ID
• Description of work
• Duration (days)
• Start Date (Earliest, Latest)
• Finish Date (Earliest, Latest)
• Resources (People and equipment)
• Effort (In staff-days)
• Predecessors (other tasks)
• Inputs (documents, decisions, information)
• Successors (other tasks)
• Outputs (documents, decisions, information)

99
Agile Perspective Sequence Activities

• Useful concepts, but apply them just in time
• As in the De?ne Activities process, PMBOK leans
  heavily toward the complicatedrather than
  complexproject methodology perspective
• The concepts of activity dependency are
  applicable across all project management
  methodologies
• However, in an adaptive/agile project, the
  activity list, upon which sequencing depends, is
  generated in small chunks throughout the project
  at the start of each individual sprint
• This is the logical time at which to work out
  sequencing of speci?c activities
• De?ne activities no earlier than during iteration
  planning

100
Next Class

• Topic
• Activity Resource Estimating
• Activity Duration Estimating
• Estimating
• Size and complexity
• Tools 
• Gantt Chart
• PERT
• Schedule Development
• Reading
• PMBOK-SWE Ch. 6 Intro Ch. 6.1-Ch. 6.6

101
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 don't even know what the software looks like!