Your SlideShare is downloading. ×
Software Project Management
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Software Project Management

891
views

Published on

Published in: Business, Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
891
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
41
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Software Project Management Project scope and activities INFO 638 Glenn Booker
  • 2. Project Scope
    • In Traditional Project Management (TPM), it is assumed that you can determine the goal of the project from the onset
      • The adaptive or extreme management methods examined later will allow this not to be true
    • Capture key project objectives in the Project Overview Statement (POS)
  • 3. Disclaimer
    • I didn’t make up the POS acronym – it’s not my fault
  • 4. Role of the POS
    • The POS captures key objectives of the project, such as the Conditions of Satisfaction (COS)
      • It should be a short document (1-2 pp)
      • The COS should convey what the project is expected to deliver and accomplish
      • It should be reviewed and updated throughout the project – it isn’t static
      • It is negotiated with the customer
  • 5. Role of the POS
    • The POS is a communications tool among the project manager, their development team, the customer, and the project manager’s boss (upper or senior management)
    • The POS is a concise statement of the project, and a summary of its justification to continue
  • 6. Other Views
    • The POS and COS are often known by other terms, like the Vision or Mission of the project
      • POS and COS are Wysocki’s terminology
  • 7. Generating the POS
    • Often the POS is developed through an iterative process
      • The customer makes a request for some major aspect of the product (key set of features, for example)
      • The developer asks to clarify the request
      • The customer provides a response
      • Customer and developer agree on the response
      • Repeat the previous four steps until done
  • 8. Non-traditional POS Uses
    • The POS can help understand a project even if not starting from scratch
      • Inheriting a project from someone else
      • Using a POS as a suggestion to start an unsolicited project
      • Use a POS as a reference to guide your team during development
  • 9. Parts of a POS
    • The POS has five major sections
      • Problem/opportunity
      • Goal
      • Objectives
      • Success criteria
      • Assumptions, risks, obstacles
    • Each is typically a few paragraphs long
  • 10. Problem/opportunity
    • This section summarizes major problems the project will fix, and identify significant new opportunities of which it will take advantage
      • Like the INFO 503 analysis method of the same name, this helps prove there is significant motivation for the project to occur
  • 11. Goal
    • The goal gives direction and purpose to the project, summarizing how the organization will address the problems, or act on the opportunities
    • Don’t commit to specific time or cost goals – the scope of the project is too vague for that
  • 12. Objectives
    • The objective statements elaborate on the goal, and clarify its scope or boundaries
      • If you meet all the objectives, then the goal must also be met
      • Each objective should define an expected outcome, the rough time frame it will be done, a measure, and the action needed to meet the objective
  • 13. Success criteria
    • Imagine the project is done, and you want to prove how much the organization benefited from it
      • What specific measures could you make to prove the project was worthwhile?
      • These are your success criteria
    • Typical criteria are increased revenue, reduced costs, improved service, etc.
  • 14. Assumptions, risks, obstacles
    • This is an executive summary of major assumptions the project is based upon, key risks to manage, and foreseeable obstacles that will need to be overcome
      • Particularly focus on areas you might need help managing
    • More details will appear in the Project Definition Statement (PDS)
  • 15. POS Attachments
    • The POS can have attachments for more information on the project
    • Most common are
      • A risk analysis (to show more detail than given earlier), and/or
      • A financial analysis (such as cost-benefit analysis, feasibility studies, ROI, etc.)
  • 16. POS Approval
    • The POS is submitted to middle or upper management for approval
    • The expected outcome is to continue more detailed planning and analysis for the project
  • 17. Expand POS into PDS
    • The Project Definition Statement (PDS) expands on the POS in two key areas
      • Objectives can be more specific, and use more technical language to convey their exact intent
      • Assumptions, risks, obstacles can cover more details of interest to the development team
  • 18. Summary of Project Scope
    • The POS and PDS capture the key concepts needed to
      • Understand the basis for the project (why does it need to exist?)
      • Demonstrate understanding of the project risks, context, and concerns
      • Provide an outline of objectives the project will (hopefully) achieve
      • And therefore justify approval for the project to continue
  • 19. Work Breakdown Structure (WBS)
    • The WBS gives structure to the set of activities in a project
    • It expands on the POS by describing activities in more and more detail, until you get down to the smallest level of task you need to define for your project
      • The WBS is a really big ‘to-do’ list
  • 20. Smallest Level of Task?
    • How big is the smallest level of task?
      • Depends on the size of the project, and how mature the staff are
      • In general, from a couple hours to a week might be the range
      • Near term tasks are typically defined in more detail than distant ones
      • In Wysocki’s terminology, ‘tasks’ make up the smallest level of ‘activity’
  • 21. WBS
    • The goal of the project should be accomplished when all tasks in the WBS are completed
    • When major activities are sequential, they typically appear in that order in the WBS
      • The Gantt chart and PERT chart (we’ll discuss later) are graphic forms of the WBS
  • 22. Activity Decomposition
    • The key to writing a good WBS is to decompose the project goal into major activities
      • Then keep breaking those activities down until you get to the smallest level of tasks mentioned earlier
      • A WBS with too much detail is time consuming to generate and follow
        • …not enough detail, and you miss important tasks
  • 23. Why Create a WBS?
    • The WBS helps plan out the process needed to accomplish the project
    • It also helps design the architecture of the project
    • It forms the basis for estimating the time and effort needed for the project
    • It establishes a baseline for reporting project status
  • 24. Generating a WBS
    • There are two basic approaches to generating a WBS
      • Top-down
        • Start at the project goal, and keep breaking down activities until you get to the smallest task needed
          • Can use the Team approach (have everyone work on the schedule together) or
          • The Subteam approach (agree on level 1 activities, then have subteams tackle each activity in detail; then check for duplication and missed tasks)
  • 25. Generating a WBS
      • Bottom-up
        • Agree on the top level activities using the top-down approach
        • Then break into teams and brainstorm all the activities you think are within that overall activity
        • Organize the activities, and check for missed tasks and redundancies
    • Often the top-down approach results in a more complete draft WBS
  • 26. Special Case WBS’s
    • Small projects may want to consider tools to help generate a good WBS, such as mindmapping
    • Large projects may need to alter the approach to develop the top two WBS levels as a group, then establish subteams or teams to fill out the details below that
  • 27. Are we Done Yet?
    • Six criteria can help determine if a WBS is complete
      • Measurable Status – Is each task defined in a way to help monitor its status toward completion?
        • Typically requires some kind of measurement to assess percent completion
      • Bounded – Is each task clearly bounded by start and stop events?
        • What event marks the start and stop of each task?
  • 28. Are we Done Yet?
      • Deliverable – Does each activity have a clearly defined deliverable?
        • What output should the activity produce?
      • Cost and Time Estimate – Is each activity defined in a way that allows a meaningful estimate of its calendar time and cost to completion?
        • Often software cost is largely driven by the labor cost, and hence the amount of effort needed to develop it
  • 29. Are we Done Yet?
      • Acceptable Duration Limits – Most activities should be broken down into tasks which are reasonably small
        • Under two weeks is the upper limit
        • There can be exceptions to this rule
      • Activity Independence – Are the activities defined to be independent of each other as much as practical?
        • Avoid activities that are too complex, or the other extreme, micromanaging
  • 30. WBS Approaches
    • There are three major approaches to structuring a WBS
      • Noun-type approaches
      • Verb-type approaches
      • Organizational approaches
  • 31. Noun-type approaches
    • The noun-type approach means the WBS is structured by the physical or functional components of the project
      • In a client-server system, the client and server’s development could each be top level WBS activities
      • In assembling a car, each major subsystem could be a WBS activity (drivetrain, body, cabin, suspension, ...)
  • 32. Verb-type approaches
    • Verb-type approaches focus on the processes in the project
      • Most common for software development, this includes using each phase of the life cycle as a top level WBS activity – Requirements Analysis, High Level Design, Low Level Design, Coding, various kinds of Testing, etc.
      • Could define WBS by project objectives
        • Shows how close project is to completion
  • 33. Organizational approaches
    • The organizational approach groups activities by who does them
      • Could be based on geographic location, department, etc.
      • Might be good for a distributed development team, to help make it clear what each group is supposed to do
  • 34. Showing the WBS
    • The WBS can be shown as an organization chart-like structure (p. 93)
    • This gives an overview of all the activities
  • 35. Naming WBS Tasks
    • The tasks in a WBS (and ideally, the activities too) should start with a verb
    • Include tasks to plan the project, conduct the actual work of the project, make decisions, etc.
      • Task names might include ‘Prepare test plan,’ ‘Conduct system test,’ ‘Write test report,’ ‘Approve system release’
  • 36. WBS Numbering
    • [This section isn’t part of Wysocki]
    • Tasks and activities are often given unique identification numbers to help do cost accounting and generate status summaries
      • In Microsoft Project, you can add a column called WBS which will automatically follow this numbering
  • 37. WBS Numbering
    • The goal of a WBS is to structure activities to allow for unique identification and tracking of existing activities, while being expandable to allow for new ones
    • The WBS numbers are a series of numbers separated by periods, used to identify tasks on a project
  • 38. WBS Number Format
    • The highest level of each major task is a “whole” number (1.0, 2.0, …)
    • The duration of major tasks (1.0) is the span of all tasks under it (e.g. 1.1 to 1.3)
    • Lower level tasks are components of their higher level task (2.1 is part of 2.0), hence a short WBS number (2.1) is a higher level task than a long WBS number (2.1.2)
  • 39. WBS Number Example
    • For example
      • 1.0 Risk Management Activities
        • 1.1 Develop Risk Management Plan
        • 1.2 Approve Risk Management Plan
        • 1.3 Conduct Ongoing Risk Management
    • Task 1.0 is the highest level task shown; composed of tasks 1.1 to 1.3
    • Note that lower levels are indented
  • 40. WBS Numbering
    • Numbers above nine under one task just keep counting (e.g. 1.8, 1.9, 1.10, 1.11, …)
    • The WBS numbers allow new tasks to be inserted where needed, such as tasks 1.1.1, 1.1.2 and 1.4 in the RM example, and yet uniquely identifies each task.
    • A WBS can use as many digits as needed (e.g. 1.2.3.14.7.6.5)
  • 41. Typical Software WBS
    • A typical waterfall life cycle project might use a WBS that follows the life cycle phases
      • 1.0 Do Requirements Analysis
      • 2.0 Conduct High Level Design
      • 3.0 Conduct Low Level Design
      • 4.0 Conduct Coding and Unit Testing
      • 5.0 Conduct Integration and System Testing
  • 42. Typical Software WBS
    • While that handles the development life cycle activities, often support activities will be broken out into separate WBS elements
      • 6.0 Perform Quality Assurance
      • 7.0 Conduct Configuration Management
      • 8.0 Conduct Project Management
    • This is a hybrid of the verb and organizational WBS approaches
  • 43. Typical Software WBS
    • Then, within each of the top level WBS activities, you decide what activities and tasks are needed
      • Within requirements analysis, what will you do to accomplish that?
        • Examine legacy system documentation?
        • Conduct interviews?
        • Study similar systems?
        • Describe use cases?
  • 44. OO WBS
    • The top level WBS for an object oriented (OO) project might follow the Rational Unified Process life cycle phases
      • 1.0 Conduct Inception Phase
      • 2.0 Conduct Elaboration Phase
      • 3.0 Conduct Construction Phase
      • 4.0 Conduct Transition Phase
  • 45. OO WBS
    • For an OO project, you may not need separate top level WBS entries for support tasks, if they are integrated into each phase
    • Then each phase has iterations, and you need to determine how long they are (eventually) and what tasks happen inside each iteration
  • 46. OO WBS
      • 1.0 Conduct Inception Phase
        • 1.1 Conduct iteration I-1
          • 1.1.1 insert tasks for this iteration
          • 1.1.2 insert tasks for this iteration
        • 1.2 Conduct iteration I-2
          • 1.2.1 insert tasks for this iteration
      • 2.0 Conduct Elaboration Phase
        • 2.1 Conduct iteration E-1
          • 2.1.1 you get the idea
  • 47. WBS Summary
    • There is no one perfect correct way to generate a WBS for a given project
      • Many solutions could work well
      • It is common to blend the noun, verb, and organizational structures
        • Such as use the verb approach for the top level WBS, then noun or organizational for lower level elements