SE 477 Software and Systems Project Management - PowerPoint PPT Presentation

Loading...

PPT – SE 477 Software and Systems Project Management PowerPoint presentation | free to download - id: 5e9ef1-ZmMyM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

SE 477 Software and Systems Project Management

Description:

Title: Lecture 4 Subject: SE 477: Software and Systems Project Management Author: Dennis L. Mumaugh Last modified by: Dennis L. Mumaugh Created Date – PowerPoint PPT presentation

Number of Views:300
Avg rating:3.0/5.0
Slides: 102
Provided by: DennisL65
Learn more at: http://condor.depaul.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: SE 477 Software and Systems Project Management


1
SE 477 Software and Systems Project Management
  • Dennis Mumaugh, Instructor
  • dmumaugh_at_cdm.depaul.edu
  • Office CDM, Room 429
  • Office Hours Tuesday, 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 October 21, 2014
  • 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 10/21/2014? Dont
    forget holidays!
  • Show the duration and delivery schedule given the
    start date is October 21, 2014.
  • Show the staffing and resources used, and the
    total staff time.
  • You should use OpenProject, 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
  • PMP Study Guide Chapters 4, 5, 7

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 judgement
  • 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
    Groups 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 a 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 teams 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
  • 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 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
  • Work in the context of the WBS means work
    products or deliverables, not the effort itself,
    as in staff-hours of effort

32
Overview Tasks
  • 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

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

34
Decomposition
  • Decomposition is the core tool and technique of
    all WBS effort
  • Decomposition is the process of breaking down
    project deliverables and work 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
  • The level of detail for work packages vary
    depending on project size and complexity
  • As we have seen, for IT projects using the
    process we have defined, each iteration (sprint)
    defines one or more work packages

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 Managementit 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 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

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

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

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
  • Whats 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, 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
  • 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
    teams 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 teams 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
  • PMP Study Guide Chapters 5 and 7

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 dont even know what the software looks like!
About PowerShow.com