Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


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