ZeePedia Add to Favourites   |   Contact us


Software Project Management

<<< Previous WBS- Major Steps, WBS Implementation, high level WBS tasks Next >>>
 
img
Software Project Management (CS615)
LECTURE # 36
7. Work Breakdown Structure
7.8
WBS- Major Steps
e) Define Project Development Phases
For large systems, the decomposition of the system into smaller components
needs to be done early in the planning cycle.
The rationale for the decomposition must be known, otherwise, different results
derived from different reasons for the system decomposition may occur.
For example, if a phase is defined to accommodate user needs, the phase may
cross multiple functional areas of the system. If, on the other hand, a system is
divided into phases simply to reduce risk, a functional division might occur where
the phases represent completion of entire functional areas of the system.
The way in which the phases are handled, differs with each application. Often,
phases are handled as top level WBS elements, with tasks associated with each
phase defined.
f) Define Task Relationships
If a project is broken down into phases, be sure that the WBS reflects this. The
WBS structure denotes a hierarchy of task relationship.
Subtask completion eventually rolls up into task completion, which ultimately
results in project completion.
There can, however, also be relationships between tasks that are not within the
outlined hierarchy.
These relationships need to be noted, and the ultimate structuring of the tasks
optimized to favor a minimum of horizontal dependencies and relationships. If the
tasks are not organized efficiently, it becomes difficult to schedule and allocate
resources to the tasks.
The project scope of work is an iterative process that is generally done by the
project team with the use of a Work Breakdown Structure (WBS), allowing the
team to capture and then decompose all of the work of the project.
273
img
Software Project Management (CS615)
A WBS is a deliverable-oriented grouping of project components that organizes
and defines the total scope of the project; work not in the WBS is outside the
scope of the project.
As with the scope statement, the WBS is often used to develop or confirm a
common understanding of project scope. Each descending level represents an
increasingly detailed description of the project deliverables.
A WBS is normally presented in chart form, however, the WBS should not be
confused with the method of presentation--drawing an unstructured activity list
in chart form does not make it a WBS.
g) Defining Deliverables
Deliverables associated with each task are shown in the WBS and are reflected in
the Deliverables portion of the Project Plan. A sample of a Deliverables template
is shown next. All deliverables are listed as they are identified.
As the schedule is completed, the due date is filled in, and responsibility for the
deliverable is assigned as it is known (typically when the organization chart is
defined). The date delivered is a field that is filled in as deliveries are made.
Over the course of the project, a comparison of the due date and the date delivered
provides a metric for how well deliverable dates are met by the project team.
While the deliverables list is a compilation of information identified in the WBS
and the project schedule, it is useful to maintain a separate list since deliverable
completion can be a key metric of project progress. Separate tracking of
deliverables can help keep a project on track. It also serves as a useful
communication tool with both stakeholders and the project team.
Product
Due
Date
Author/
Name
Date
Delivered
POC
4/1/96
4/1/96
ABC
Requirement
Specification
8/1/96
XYZ
Design Specification
8/1/96
DEF
Test Plan
...
11/1/96
Implementation Plan
274
img
Software Project Management (CS615)
...
12/1/96
Source Code
1/30/97
...
Test Report
h) Creating a Work Breakdown Structure
A project can be compared to a large system. A large system consists of multiple,
independent subsystems that achieve a common goal. Similarly, a project consists
of small, independent tasks.
Each task can be subdivided into sub tasks. Fro example, in a general software
project, a task is to perform project analysis. You may also consider studying the
organizational objectives and preparing a project proposal to present to the client.
Therefore, in a project analysis task, there are three subtasks. A subtask is also
known as a work package. A work package is a unit-level entity in a project
system.
You can create a WBS by following the three steps listed below. These are
general steps, and they can vary in relation to an individual or an organization.
a) Brainstorm to arrive at board tasks for a project
b) Refine the board tasks
c) Categorize tasks into logical task headers
a) Brainstorming to Arrive at Broad Tasks
The first step in creating a WBS is to organize a meeting of all senior managers,
system analysts, and prospective developers. The objective of the meeting is to
brainstorm and come up with a set of broad tasks that need to be performed in a
project. During the brainstorming session, you can make a note of all possible
tasks.
Subsequently, the feasibility of each task is assessed. In addition, any conflict of
common tasks can be eliminated. To enable you to perform this activity better,
you can arrange tasks as and when they are brainstormed.
For example, XYZ Inc. conducts a brainstorming session to divide the tasks into
multiple subtasks that are performed during the analysis phase of a project.
During the session the project managers and the analysts come up with tasks on
the basis of prior project experience. These include tasks such as determining the
scope of a project, drafting the software specifications, and securing resources for
the project.
275
img
Software Project Management (CS615)
Some additional tasks are also determined based on client requirements. Preparing
the initial project budget and estimating the approximate project timeline are
examples of such tasks. In addition, personnel responsible to complete each task
are also determined.
The subtasks are subsequently arranged in the order in which they are executed.
Figure 6 depicts the subtasks in the analysis phase. Note that after a questionnaire
is prepared, you can either arrange to meet the client or document the feedback
collected by the questionnaire. It is clear from the figure that preparation of the
SRS document can begin only after the preceding three tasks are complete.
Prepare a Client
questionnaire.
Prepare a Software
Requirements Specification
(SRS) document.
Arrange for
meetings with
li t
Document client
feedback
Figure 6: WBS Activity
Dividing a main task into multiple subtasks also enables you to estimate the
duration and the effort required for individual tasks.
Subsequently, at the end of the phase, you can evaluate the actual effort and
duration. This helps you compare the estimated values with the actual values and
prepare a schedule for the subsequent phases.
The duration of each task affects the total duration of a phase. This, in turn,
affects the schedule of the subsequent phases. You can make similar deductions
while comparing the estimated costs with the actual costs of a task.
b) Refining Broad Tasks
276
img
Software Project Management (CS615)
In the second step of creating a WBS, you refine the list of tasks that was
compiled during brainstorming.
Refining the tasks may include adding more tasks or combining the existing ones.
During this step, you may also change the arrangement of tasks.
A change in the arrangement of tasks can occur on the basis of two theories of
WBS.
·
Deliverable-based theory
·
Project life-cycle-based theory
You use the deliverable-based theory when the deliverables of a project are more
important than its phases. This normally happens when the deliverables are
decided before the project begins.
However, if the phases of a project are completely defined, you use the project
life-cycle-based theory. You can use the project life-cycle-based theory to arrange
the tasks in a project.
c) Categorizing Tasks into Logical Headers
Finally, after defining tasks and arranging them, you categorize each task into a
logical task header.
For example, preparing test plans and test cases and drawing up the test plans can
be categorized as Testing.
This activity provides another chance to ensure that you have not missed any task
during brainstorming.
In addition, you can also consult an expert such as a senior manager to review and
validate the tasks identified.
7.8
WBS Implementation
i.
Implementation Strategy
When you set up a project WBS, think about how you will be using it later in the
project. Consider how you will organize the WBS, schedule format, manager
assignments, and charge numbers, in your early project planning. It will be
helpful if you can map the charge numbers, managers, and task groups to each
other. This will help you track costs and progress for each manager.
277
img
Software Project Management (CS615)
If your project schedule will on MS-Project, you may want to insert "text"
columns into your schedule (Gantt View) for project charge numbers and
manager names.
Some project management environments have definite conventions for grouping
items in a WBS. The best method is to have a WBS that works for your particular
project environment. The WBS should be designed with consideration for its
eventual uses.
Your WBS design should try to achieve certain goals:
­
Be compatible with how the work will be done and how costs and
schedules will be managed,
­
Give visibility to important or risky work efforts,
­
Allow mapping of requirements, plans, testing, and deliverables,
­
Foster clear ownership by managers and task leaders,
­
Provide data for performance measurement and historical databases, and
­
Make sense to the workers and accountants
There are usually many ways to design a WBS for a particular project, and there
are sometimes as many views as people in the process.
Experience teaches that everyone takes a slightly different slice of the apple, so
make sure WBS arguments seeking metaphysical certainty are quickly brought to
closure.
ii.
Methodology
­ PM must map activities to chosen lifecycle as each lifecycle has different sets
of activities.
­ Integral process activities occur for all Planning, configuration and testing.
­ Operations and maintenance phases are not normally in plan (considered
post-project)
­ Some models are "straightened" for WBS:
·
Spiral and other iterative models
·
Linear sequence several times
­ Deliverables of tasks vary by methodology
7.9
Guidelines for decomposition of work tasks
278
img
Software Project Management (CS615)
i.
General Guidelines
­
A WBS should be easy to understand. Some companies have corporate
standards for these schemes. Some top-level items, like Project Mgmt. are in
WBS for each project. Others vary by project
­
What often hurts most is what's missing. Break down until you can generate
accurate time & cost estimates. Ensure each element corresponds to a
deliverable.
­
How detailed should it be?
·  Not as detailed as the final MS-Project plan
·  Each level should have no more than 7 items
·  It can evolve over time
­
What tool should you use?
·  Excel, Word, Project
·  Org chart diagramming tool (Visio, etc)
·  Specialized commercial apps
­
Re-use a "template" if you have one. Although each project is unique, WBS
can often be "reused" since most projects will resemble another project to
some extent.
·
Ex: Most projects within a given organization will have the same or similar
project life cycles, and will thus have the same or similar deliverables required
from each phase.
­
Many application areas or performing organizations have standard or semi-
standard WBS s that can be used as templates.
·
Ex: Financial Management System etc
­
Identify major elements of the project. In general, the major elements will be
project deliverables and project management.
­
Decide if adequate cost and duration estimates can be developed at this level
of detail for each deliverable.
­
Identify constituent components of the deliverable. Constituent components
should be described in terms of tangible, verifiable results to facilitate
performance measurement.
­
Verify the correctness of the decomposition: are the low-level items both
necessary and sufficient for completion of the decomposed item? Is each item
clearly and completely defined? Can each item be appropriately scheduled and
279
img
Software Project Management (CS615)
budgeted?
­
The WBS is not a decomposition of the software produced by the project. It is
a decomposition of the project itself, and includes such activities as
management, procurement, installation and, of course, software development.
­
Each low level module may be assigned three basic work tasks:
·  module design,
·  coding and
·  unit testing
­
Additional development tasks such as prototyping, testing, and integration are
derived from the other development phases.
ii.
A typical list of high level WBS tasks
Following table contains a typical list of high level WBS tasks to be included in
the formal WBS task list.
­
This is not an exhaustive list of all project development tasks, and not all
projects will require all the tasks described.
­
However, this table will be useful as a checklist to assist in locating tasks that
may have been overlooked.
Table: High level WBS structure tasks
Software development
Requirements analysis
Prototype development
Prototype specification
Prototype design
Prototype implementation
Design
Top level design
Detailed design
Implementation
Coding
Unit test
Integration
Software integration
Hardware/software integration
Testing
Alpha testing
Beta testing
280
img
Software Project Management (CS615)
Acceptance
Installation / Maintenance
Error correction
Software enhancement
Management
Planning
Staffing
Administration and services
Budget administration
Personnel management
Quality assurance
Configuration management
Training / Procurement
Acquisition of development tools
Acquisition of system components (off the shell)
Equipment selection
Vendor selection
Ordering procedure
Inventory control
Documentation
Technical writing
Project publishing activities
Development documentation
Non-deliverable development documentation
Deliverable development documentation
Maintenance documentation / User documentation
iii.  Management and Administration Tasks
­
Non-development activities, such as high level management WBS tasks, are
standard, to a large extent, and any variance is determined by either the
magnitude of the project, or the introduction of a new management model.
­
An example of a list of management WBS tasks appears in the following
Table.
­
This list contains many of the most important management tasks required for
most software development projects.
­
Those tasks that are mandatory for all projects are marked as such in the list.
Table: Management and administration tasks
Mandatory
Management task
1. Planning
2. Preparation or estimates
281
img
Software Project Management (CS615)
3. Risk analysis and risk management
4. Scheduling
5. Staffing
6. Budget analysis and administration
7. Personnel management
8. Task assignment
9. Delegation of authority
10. Assignment of development resources
11. Supervision of development equipment maintenance
12. Supervision and control of development
13. Organization of reviews and formal presentations
14. Establishment of standards and methods
15. Quality assurance and control
16. Configuration management and control
17. Supervision of subcontractors and vendors
18. Higher management interface and coordination
19. Customer interface and coordination
20. Reporting
21. Administration and services
­
Note that budget analysis and administration is not a mandatory management
task, simply because not all projects administer their own budget. Some
organizations have a financial officer responsible for the administration of
project budgets.
­
Customer interface is also not a mandatory management task because not all
projects have a customer. In the case of company internal projects, high level
management, together with the designated users of the system being
developed, play the role of customer. It is usually they who specify the initial
project requirements, and it is to them that the project manager must come for
final approval and for final system acceptance.
­
Break down the work until accurate estimates of cost and resources needed to
perform the task are provided.
­
Ensure that clearly defined starting and ending events are defined for the task.
This may be the production of a deliverable or the occurrence of an event.
­
Verify that the lowest level tasks can be performed within a "reasonable"
period of time. Each state organization must define "reasonable."
­
If the time period to complete a task is too long, an accurate project status in
the implementation phase may not be possible.
­
An industry standard rule of thumb is to make work packages that can be
282
img
Software Project Management (CS615)
completed in timeframes of two weeks.
­
Verify that people assigned to the project are all assigned a WBS task. Have a
firm rule: if the task is not on WBS, it is not worked on.
­
The work breakdown structure and any support documentation should be easy
to understand.
­
The work should not be subdivided arbitrarily to the lowest possible level.
Work breakdown structure elements at the lowest control level should
typically range from 0.5% to 2.5% of total project budget.
­
Furthermore, you should be aware that the work breakdown structure can be
developed to reflect the trust that you have in specific line groups, by leaving
them the autonomy over specific areas of work.
­
Finally, always remember that projects are dynamic working environments -
so try to maintain flexibility in the work breakdown structure.
­
As a general guideline, no single functional decomposition should be selected
just because it was conceived first. The functional decomposition of a
software system may be substantially different from the design decomposition
of the system. However, a good functional decomposition will have taken into
account design as the next development phase, and will often be a good
starting point for the division of the system into high level design components.
The high level design components are then further decomposed into
successive lower levels that ultimately produce programming modules. A
good modular design produces small, simple, independent modules.
283
Table of Contents:
  1. Introduction & Fundamentals
  2. Goals of Project management
  3. Project Dimensions, Software Development Lifecycle
  4. Cost Management, Project vs. Program Management, Project Success
  5. Project Management’s nine Knowledge Areas
  6. Team leader, Project Organization, Organizational structure
  7. Project Execution Fundamentals Tracking
  8. Organizational Issues and Project Management
  9. Managing Processes: Project Plan, Managing Quality, Project Execution, Project Initiation
  10. Project Execution: Product Implementation, Project Closedown
  11. Problems in Software Projects, Process- related Problems
  12. Product-related Problems, Technology-related problems
  13. Requirements Management, Requirements analysis
  14. Requirements Elicitation for Software
  15. The Software Requirements Specification
  16. Attributes of Software Design, Key Features of Design
  17. Software Configuration Management Vs Software Maintenance
  18. Quality Assurance Management, Quality Factors
  19. Software Quality Assurance Activities
  20. Software Process, PM Process Groups, Links, PM Phase interactions
  21. Initiating Process: Inputs, Outputs, Tools and Techniques
  22. Planning Process Tasks, Executing Process Tasks, Controlling Process Tasks
  23. Project Planning Objectives, Primary Planning Steps
  24. Tools and Techniques for SDP, Outputs from SDP, SDP Execution
  25. PLANNING: Elements of SDP
  26. Life cycle Models: Spiral Model, Statement of Requirement, Data Item Descriptions
  27. Organizational Systems
  28. ORGANIZATIONAL PLANNING, Organizational Management Tools
  29. Estimation - Concepts
  30. Decomposition Techniques, Estimation – Tools
  31. Estimation – Tools
  32. Work Breakdown Structure
  33. WBS- A Mandatory Management Tool
  34. Characteristics of a High-Quality WBS
  35. Work Breakdown Structure (WBS)
  36. WBS- Major Steps, WBS Implementation, high level WBS tasks
  37. Schedule: Scheduling Fundamentals
  38. Scheduling Tools: GANTT CHARTS, PERT, CPM
  39. Risk and Change Management: Risk Management Concepts
  40. Risk & Change Management Concepts
  41. Risk Management Process
  42. Quality Concept, Producing quality software, Quality Control
  43. Managing Tasks in Microsoft Project 2000
  44. Commissioning & Migration