INFO 638Lecture #21 Software Project Management Project scope and activities INFO 638 Glenn Booker.

Download INFO 638Lecture #21 Software Project Management Project scope and activities INFO 638 Glenn Booker.

Post on 21-Dec-2015




0 download

Embed Size (px)


  • Slide 1
  • INFO 638Lecture #21 Software Project Management Project scope and activities INFO 638 Glenn Booker
  • Slide 2
  • INFO 638Lecture #22 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)
  • Slide 3
  • INFO 638Lecture #23 Disclaimer I didnt make up the POS acronym its not my fault
  • Slide 4
  • INFO 638Lecture #24 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 isnt static It is negotiated with the customer
  • Slide 5
  • INFO 638Lecture #25 Role of the POS The POS is a communications tool among the project manager, their development team, the customer, and the project managers boss (upper or senior management) The POS is a concise statement of the project, and a summary of its justification to continue
  • Slide 6
  • INFO 638Lecture #26 Other Views The POS and COS are often known by other terms, like the Vision or Mission of the project POS and COS are Wysockis terminology
  • Slide 7
  • INFO 638Lecture #27 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
  • Slide 8
  • INFO 638Lecture #28 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
  • Slide 9
  • INFO 638Lecture #29 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
  • Slide 10
  • INFO 638Lecture #210 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
  • Slide 11
  • INFO 638Lecture #211 Goal The goal gives direction and purpose to the project, summarizing how the organization will address the problems, or act on the opportunities Dont commit to specific time or cost goals the scope of the project is too vague for that
  • Slide 12
  • INFO 638Lecture #212 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
  • Slide 13
  • INFO 638Lecture #213 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.
  • Slide 14
  • INFO 638Lecture #214 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)
  • Slide 15
  • INFO 638Lecture #215 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.)
  • Slide 16
  • INFO 638Lecture #216 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
  • Slide 17
  • INFO 638Lecture #217 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
  • Slide 18
  • INFO 638Lecture #218 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
  • Slide 19
  • INFO 638Lecture #219 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
  • Slide 20
  • INFO 638Lecture #220 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 Wysockis terminology, tasks make up the smallest level of activity
  • Slide 21
  • INFO 638Lecture #221 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 (well discuss later) are graphic forms of the WBS
  • Slide 22
  • INFO 638Lecture #222 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
  • Slide 23
  • INFO 638Lecture #223 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
  • Slide 24
  • INFO 638Lecture #224 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)
  • Slide 25
  • INFO 638Lecture #225 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
  • Slide 26
  • INFO 638Lecture #226 Special Case WBSs Small projects may want to consider tools to help generate a good WBS, such as mindmappingmindmapping 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
  • Slide 27
  • INFO 638Lecture #227 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?
  • Slide 28
  • INFO 638Lecture #228 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
  • Slide 29
  • INFO 638Lecture #229 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
  • Slide 30
  • INFO 638Lecture #230 WBS Approaches There are three major approaches to structuring a WBS Noun-type approaches Verb-type approaches Organizational approaches
  • Slide 31
  • INFO 638Lecture #231 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 servers development could each be top level WBS activities In assembling a car, each major subsystem could be a WBS activity (drivetrain, body, cabin, suspension,...)
  • Slide 32
  • INFO 638Lecture #232 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
  • Slide 33
  • INFO 638Lecture #233 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
  • Slide 34
  • INFO 638Lecture #234 Showing the WBS The WBS can be shown as an organization chart-like structure (p. 93) This gives an overview of all the activities
  • Slide 35
  • INFO 638Lecture #235 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
  • Slide 36
  • INFO 638Lecture #236 WBS Numbering [This section isnt 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
  • Slide 37
  • INFO 638Lecture #237 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
  • Slide 38
  • INFO 638Lecture #238 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)
  • Slide 39
  • INFO 638Lecture #239 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
  • Slide 40
  • INFO 638Lecture #240 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.
  • Slide 41
  • INFO 638Lecture #241 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
  • Slide 42
  • INFO 638Lecture #242 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
  • Slide 43
  • INFO 638Lecture #243 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?
  • Slide 44
  • INFO 638Lecture #244 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
  • Slide 45
  • INFO 638Lecture #245 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
  • Slide 46
  • INFO 638Lecture #246 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...


View more >