Software Project Management

Software Project Management Project scope and activities INFO 638 Glenn Booker Lecture #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) Lecture #2

Disclaimer • I didn’t make up the POS acronym – it’s not my fault Lecture #2

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 Lecture #2

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 Lecture #2

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 Lecture #2

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 Lecture #2

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 Lecture #2

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 Lecture #2

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 Lecture #2

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 Lecture #2

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 Lecture #2

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. Lecture #2

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) Lecture #2

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.) Lecture #2

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 Lecture #2

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 Lecture #2

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 Lecture #2

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 Lecture #2

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’ Lecture #2

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 Lecture #2

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 Lecture #2

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 Lecture #2

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) Lecture #2

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 Lecture #2

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 Lecture #2

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? Lecture #2

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 Lecture #2

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 Lecture #2

WBS Approaches • There are three major approaches to structuring a WBS • Noun-type approaches • Verb-type approaches • Organizational approaches Lecture #2

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, ...) Lecture #2

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 Lecture #2

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 Lecture #2

Showing the WBS • The WBS can be shown as an organization chart-like structure (p. 93) • This gives an overview of all the activities Lecture #2

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’ Lecture #2

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 Lecture #2

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 Lecture #2

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) Lecture #2

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 Lecture #2

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) Lecture #2

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 Lecture #2

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 Lecture #2

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? Lecture #2

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 Lecture #2

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 Lecture #2

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 Lecture #2

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 Lecture #2

Software Project Management