Professional Documents
Culture Documents
Software Project Management: Project Scope and Activities
Software Project Management: Project Scope and Activities
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
Disclaimer
I didnt make up the POS acronym its not my fault
INFO 638
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 Wysockis terminology
INFO 638
Lecture #2
INFO 638
Lecture #2
INFO 638
Lecture #2
Parts of a POS
The POS has five major sections
Problem/opportunity Goal Objectives Success criteria Assumptions, risks, obstacles
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
INFO 638
Lecture #2
10
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
INFO 638
Lecture #2
11
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
INFO 638 Lecture #2 12
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.
INFO 638 Lecture #2 13
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.)
INFO 638
Lecture #2
15
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
INFO 638
Lecture #2
16
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
INFO 638 Lecture #2 21
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
INFO 638 Lecture #2 22
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)
INFO 638 Lecture #2 24
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
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
INFO 638 Lecture #2 28
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
INFO 638 Lecture #2 29
WBS Approaches
There are three major approaches to structuring a WBS
Noun-type approaches Verb-type approaches Organizational approaches
INFO 638
Lecture #2
30
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, ...)
INFO 638 Lecture #2 31
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
INFO 638 Lecture #2 32
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
INFO 638
Lecture #2
33
INFO 638
Lecture #2
34
INFO 638
Lecture #2
35
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
INFO 638
Lecture #2
36
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
INFO 638 Lecture #2 37
Task 1.0 is the highest level task shown; composed of tasks 1.1 to 1.3 Note that lower levels are indented
INFO 638 Lecture #2 39
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)
INFO 638
Lecture #2
40
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 41
Examine legacy system documentation? Conduct interviews? Study similar systems? Describe use cases?
Lecture #2 43
OO WBS
The top level WBS for an object oriented (OO) project might follow the Rational Unified Process life cycle phases
INFO 638
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
INFO 638 Lecture #2 45
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
INFO 638
Lecture #2
46
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
INFO 638
Lecture #2
47