• Save
Project Management Workshop Overview
Upcoming SlideShare
Loading in...5
×
 

Project Management Workshop Overview

on

  • 2,682 views

Project Management Workshop Overview

Project Management Workshop Overview

Statistics

Views

Total Views
2,682
Views on SlideShare
2,671
Embed Views
11

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 11

http://www.slideshare.net 11

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Project Management Workshop Overview Project Management Workshop Overview Presentation Transcript

  • A Survey of Software Estimating & Planning Techniques Robert Galen Wideband Delphi - Barry Boehm / Rand PSP - PROBE Method & TSP Planning - Watts Humphrey Software Project Survival - Steve McConnell Extreme Programming / Planning - Kent Beck “ Cards on a Wall” - Dwayne Phillips
  • Presentation Overview
      • Quick overview of 5 useful software estimation and planning techniques:
        • Wideband Delphi - Barry Boehm / Rand
        • PSP - PROBE Method & TSP Planning - Watts Humphrey
        • Software Project Survival - Steve McConnell
        • Extreme planning - Kent Beck
        • “ Notes on a Wall” - Dwayne Phillips
      • All of these techniques are “soft” in that no model based estimation tools are used
      • Quick overview then ongoing contrast and analysis of each method. Intended more for exposure and further research
      • As a group, participate in a collaborative breakout illustrating Wideband Delphi & NoaW techniques
  • Wideband Delphi Barry Boehm / Rand
  • Wideband Delphi History
    • Introduced at Rand Corporation
    • Refined by Barry Boehm’s Software Engineering Economics (Prentice Hall, 1981)
    • Re-referenced by Watts Humphrey in Managing the Software Process (Addison Wesley, 1990)
    • Re-referenced by Karl Wiegers in the article Stop Promising Miracles published in Software Development, February 2000 www. processimpact .com
    • Mary Sakry & Neil Potter of The Process Group www.processgroup.com introduced workshops
  • Wideband Delphi Overview
    • The technique can help you estimate, plan and schedule – almost anything
    • It’s comprised of 6 steps:
      • Planning (defining a set of “surrounding” documentation)
      • Kickoff meeting (introducing the process, documentation and expectations)
      • Individual preparation (based on documentation, provide initial estimates)
      • Estimation meeting (group based “normalization” of the estimates)
      • Assembling tasks (Project Manager constructs schedule off-line)
      • Reviewing results & iteration
    • Iterative, team based, collaborative estimating
  • Wideband Delphi Overview (cont-1)
    • Particularly useful for high – mid level “initial” estimates – at the beginning or early phases of a project
    • A basis for the estimating is gathering a set of “experts” in specific areas - then contrasting their estimates
    • Estimates are usually confidential
    • Team based estimate convergence and off-line schedule - materials work by the PM or facilitator
    • Usually only examine a small section or component of the overall effort / project (50-100 tasks)
  • Wideband Delphi Strengths & Weaknesses
    • Strengths:
      • Team based planning - collaboration and buy-in
      • Thorough generation of small task lists
      • Produces estimate data that can be used in a variety of ways
      • Creates useful project artifacts (risks, issues, assumptions, etc.)
    • Weaknesses:
      • Lots of overhead (time, team involvement, planning) for a relatively small sets of tasks
      • Takes quite a few “steps” or iterations
      • How do you update the plan?
  • PSP - PROBE Method & TSP Planning Watts Humphrey
  • PSP PROBE Method History
    • Introduced by Watts Humphrey in the book A Discipline for Software Engineering (Addison Wesley, 1995)
    • The book introduced the Personal Software Process or PSP
    • Since PSP’s introduction, Watts has also introduced the book Team Software Process (Addison Wesley, 2000)
    • There is a hierarchical relationship between the SEI initiatives:
      • PSP - process at the individual software engineer level
      • TSP - process at the software engineering team level
      • CMM - process at the organization level
  • PSP PROBE Method Overview
    • PROBE - PROxy Based Estimation
    • Use or reference similar project and product work experiences when estimating future effort
    • Common proxy for the type of work:
      • LOC, modules, functions
      • Objects, function points, screens, etc
    • Overview:
      • Basic Design
      • Estimate size <=feedback
      • Estimate resources <=feedback
      • Make schedule
      • Execute plan feedback =>
      • Produce product
  • PSP PROBE Method Overview
    • Humphrey created PROBE for small, one person efforts. However, it can be modified for larger efforts and teams of engineers.
    • PROBE was designed around and uses “lines of code” LOC’s and KLOC’s as the basis for measuring product size and effort size. If this isn’t appropriate for your needs, it can be easily modified for
      • Objects, database tables
      • Function points, screens
      • Or other levels of granularity (slides in a presentation, pages in a book, etc.)
  • PSP PROBE Method Strengths & Weaknesses
    • Strengths:
      • Forces you to keep good historical data - then use it
      • Quantitative and very visible estimates
      • Works well at the individual - small effort level
    • Weaknesses:
      • Not very collaborative - lose a sense of team based estimation
      • Doesn’t work without historical data - and of the right “type”
      • Doesn’t scale very well to larger efforts - you lose the “team perspective”
      • Doesn’t help with task sequencing nor exposing “peripheral” items
  • TSP Planning Overview
    • Overriding premise - introduce team dynamics for planning, role definition and development phases over PSP trained and operating developers
    • Key components:
      • Product Need Statement => Project Launch
        • Development Strategy
        • Development Plan
        • Requirements
        • Design ing with Teams
        • Product Implementation
        • Integration & System Test
        • Postmortem
      • Possibly iterations…
  • Software Project Survival Guide Steve McConnell
  • Software Project Survival Guide History
    • Steve McConnell introduced Software Project Survival Guide (Microsoft Press, 1998)
    • He has written two other leading development centric texts - Code Complete (1993) and Rapid Development (1996) both published by Microsoft Press
    • His company, Construx Software’s web site:
        • SPSG link: www. construx .com/ survivalguide /home. htm
        • CxOne Process Framework link: www. construx .com/ cxone /home. htm
        • Construx Estimate v2.0: www. construx .com/estimate/home. htm
  • Software Project Survival Guide Overview
    • Classical strategy for software development
    • Adds many quality checklists for each step
    • Introduces a staged delivery approach
    • Emphasis on use of model based estimating tools
    • Planning steps:
      • Preliminary planning
      • Requirements, QA and Architecture plans
      • Stage execution activity
        • Creating project estimates
        • Writing a Staged Delivery Plan
        • Performing ongoing planning activity
  • Software Project Survival Guide Overview (cont-1)
        • Maintain a project log
      • Stages are iterations, within each the following activities occur:
        • Detailed design
        • Construction w/reviews
        • Testing
        • End of stage wrap-ups
        • Next stage springboard
  • Software Project Survival Guide Detailed Planning
    • Estimating Guidelines
      • There should be a written estimate procedure
      • Estimate should include time for normal activities
      • The project plan should not assume the team will work overtime
      • Estimates should be created using estimation software
      • Estimates should be based on data from completed projects
      • Watch for estimates that developers don’t accept
      • The project team should plan to re-estimate at several specific times during the project
      • Estimates should be placed under change control
    • Create milestone targets (mini-milestones)
  • Software Project Survival Guide Strengths & Weaknesses
    • Strengths:
      • Project plan emphasis good for project start-up, visioning, team cohesion
      • Stages are well encapsulated and understood - iterative planning with miniature milestones
      • Solid emphasis on post stage analysis and injecting lessons learned into future work / stages
    • Weaknesses:
      • Sole reliance on estimation tools ignores inherent domain knowledge, using “alternative” estimation techniques and historical data.Team abstracted from estimation “process”
      • Strong management tactics - difficult to “manage”
  • Extreme Programming (XP) - Planning Kent Beck Martin Fowler
  • Extreme Programming (XP) - Planning History
    • Extreme Programming or XP was practiced by Kent Beck and then documented in the text Extreme Programming Explained: Embrace Change (Addison Wesley, 2000)
    • XP was used successfully by Kent and a team at Chrysler - working on the C3 project. This is where most of the principles were formalized.
    • Other texts covering aspects of XP:
      • Beck, K. and Fowler, M. Planning Extreme Programming (Addison Wesley, 2001)
      • Jeffries, R. et all, Extreme Programming Installed (Addison Wesley, 2001)
  • Extreme Programming (XP) - Planning History
      • Newkirk, J. and Martin, R. Extreme Programming in Practice (Addison Wesley, 2001)
    • Since the original text was written, XP is beginning to explode as one of the better known lightweight methodologies
    • Some related links:
        • www.extremeprogramming.org
        • www.pairprogramming.com
        • www.xprogramming.com
  • Extreme Programming (XP) - Planning Overview
    • Very lightweight and pragmatic approach to software development
    • It usually resonates well with experienced software developers
    • Key XP concepts:
      • Planning Game (story based) & Short releases
      • Simple design & Refactoring
      • Testing & Continuous integration
      • Pair programming & Collective ownership
      • Onsite customer, 40 hour week, Coding standards, System Metaphor
  • Extreme Programming (XP) - Planning Overview
    • XP Planning Concepts (Stories, Story Ordering, Release Planning, Iterations, Yesterday’s Weather, Velocity and Ideal Time
    • Planning Steps:
      • Scoping a project - running the planning game at “course” granularity
      • Planning game - normal (fine) granularity
      • Story estimation & estimate adjustment (feedback)
      • Story ordering
      • Release ordering
  • Extreme Programming (XP) - Planning Planning Game
    • A relatively sharp delineation between business and technical focus points -
    • Business people need to worry about:
        • Scope
        • Priority
        • Composition of releases
        • Dates of releases
    • Technical people need to worry about:
        • Estimates
        • Consequence of decisions
        • Processes
        • Detailed scheduling
  • Extreme Programming (XP) - Planning Strengths & Weaknesses
    • Strengths:
      • Very lightweight approach to work planning - short iteration planning & feedback
      • Quickly detects “velocity” changes and helps with adjustments
      • Active customer involvement
    • Weaknesses:
      • Not clear that it can handle large or maintenance projects - or domains where (known) work outweighs the unknowns
      • Not “really” estimation and planning - short iterations and constant monitoring or progress maximizes results at any point. However, no real plan in the PM sense
  • “ Cards on a Wall” Technique Dwayne Phillips
  • “Cards on a Wall” History
    • Introduced by Dwayne Phillips in Project Manager’s Handbook - Principles that Work at Work (IEEE Computer Society, 2000)
    • Similar to JAD sessions in principle as referenced by Dwayne Phillips and Silver & Wood in Joint Application Development 2’nd. Ed . (John Wiley & Sons, 1995)
    • Also similar to the SST - System Storyboarding Techniques developed by Zahniser (American Programmer, 1993)
  • “Cards on a Wall” Overview
    • It has JAD principles as it’s “roots”
    • Preparation is the same for a JAD session
    • It’s comprised of 5 steps:
      • Scope definition
      • Familiarize key people
      • Prepare for the workshop
      • Conduct the workshop
      • Produce the final document
    • JAD is typically requirements focused, while CoaW is focused on estimation. This creates fundamental differences in deliverables and meeting formats
  • “Cards on a Wall” Overview (cont-1)
    • First 4 steps expanded:
      • Scope definition
        • Problem statement, vision, requirements, business case, etc.
      • Familiarize key people (usually informal)
        • With the process, line up domain experts, assign specific roles
      • Prepare for the workshop
        • Prepare documents, materials and facilitators, reserve room and create agenda
      • Conduct the workshop
        • Brainstorm (tasks - assumptions - risks)
        • Then sequence tasks
        • Brainstorm task durations, qualify assumptions and rank risks
  • “Cards on a Wall” Strengths & Weaknesses
    • Strengths:
      • Team based planning, collaboration and buy-in
      • Can be used on large and small efforts - scaleable
      • Very fast technique
      • Creates useful project artifacts (risks, issues, assumptions, etc.)
    • Weaknesses:
      • Requires skill in the technique and significant preparation to be effective
      • Less formal attendee preparation and very fast, may miss important things
      • How do you update the plan?
  • Estimating Techniques Breakout - Lets try the CoaW technique
  • Estimating Techniques Breakout
      • Break into groups of 4-6
      • Select a group leader/facilitator (or the person with a first name starting with a letter closest to ‘Q’ - “quite willing to be the group leader” ;-)
      • There are two parts to the breakout:
        • First, your group will brainstorm (tasks - issues - assumptions - risks) for a birthday party. Don’t worry about what everyone is writing, just fill in party preparation tasks / etc., 1 to each post-it note, and give them to the facilitator
        • This will go on for exactly 10 minutes
        • Facilitators - as your receiving the post-it notes, try and categorize them and consolidate redundant tasks
  • Estimating Techniques Breakout (cont-1)
      • There are two parts to the breakout:
        • Next, as a team work on the sequencing of the tasks and also take a stab at estimating task duration
        • Also, list any basic assumptions
        • Finally, brainstorm 2-3 key risks for the party preparation
        • You have exactly 10 minutes for this exercise as well
        • At the end of the exercise you should have an ordered set of tasks with time / effort for each and a small list of risks.
        • We’ll take a random sampling of a few teams to see how things went - 5-10 minutes
  • Estimating Techniques Breakout (cont-2)
      • Breakout details:
        • Your twin daughters, Jan and Amy, are having a birthday in two weeks. It’s their 10th birthday and you want to plan a special party.
        • They each want to invite friends, members of their gym and dance clubs and classmates - approximately 20 kids for each of them.
        • Your mom has offered to help with food.
        • Some of the kids will need transportation to and/or from the party.
        • Jan and Amy have already prepared a “wish list” for presents.
        • Each wants a separate cake and unique decorations.
        • You promised them “something special”, so Amy wants to invite a clown and Jan wants to go swimming (you don’t have a pool - yet).
        • You live in a relatively small home, but have plenty of yard space.
        • It’s October 15 and the birthdays are on October 31.
  • Estimating Techniques References
  • Estimating Techniques References
    • Beck, K. Extreme Programming Explained: Embrace Change (Addison Wesley, 2000)
    • Beck, K. and Fowler, M. Planning Extreme Programming (Addison Wesley, 2001)
    • Boehm, B. Software Engineering Economics (Prentice Hall, 1981)
    • Humphrey, W. Managing the Software Process (Addison Wesley, 1990)
    • Humphrey, W. A Discipline for Software Engineering (Addison Wesley, 1995)
    • Humphrey, W. Team Software Process (Addison Wesley, 2000)
    • Jeffries, R. et all, Extreme Programming Installed (Addison Wesley, 2001)
  • Estimating Techniques References (cont-1)
    • McConnell, S. Software Project Management - Survival Guide (Microsoft Press, 1998)
    • Newkirk, J. and Martin, R. Extreme Programming in Practice (Addison Wesley, 2001)
    • Phillips, D. Project Manager’s Handbook - Principles that Work at Work (IEEE Computer Society, 2000)
    • Silver & Wood, Joint Application Development 2’nd. Ed. (John Wiley & Sons, 1995)
    • Wiegers, K. Stop Promising Miracles (Software Development, February 2000)
    • Zahniser SST - System Storyboarding Techniques (American Programmer, 1993)
  • Estimating Techniques Contact Information
      • This presentation is a condensed overview of a longer, full day workshop where we explore and contrast each of the techniques in much more detail. If you are interested in the longer version, please contact me.
        • Robert Galen
        • 919-272-0719
        • galenr@acm.org OR bob@rgalen.com
        • www.rgalen.com