SOEN 341 Tutorial 1

Project Management Quick

Start
Steve Morse
(Some Slides and Material by Dr. C.
Constantinides & others)

Scope & The WBS

The Scope of a project refers to all the
work involved in creating the products
and the processes used to produce
that project.
A project is over-scoped if it cannot be
completed within the time or budget
for that project

Work breakdown structure

(WBS)
A complex project is made
manageable by first breaking it down
into individual components in a
hierarchical structure, known as the
work breakdown structure, or the WBS.
WBS is an exhaustive, hierarchical
(from general to specific) tree structure
of deliverables and tasks that need to
be performed to complete a project.

Numbering Tasks
Level 1
Task 1
Level 2
Subtask 1.1
Level 3
Work Package 1.1.1

Why WBS?
A WBS provides the following
information structure:
A description of all significant work.
A clear task decomposition for
assignment of responsibilities.
A framework for scheduling,
budgeting, and expenditure tracking.

Some Basic WBS Rules

The 100% rule
One of the most important Work Breakdown Structure design
principles is called the 100% Rule. It has been defined as follows:
The 100% Rule...states that the WBS includes 100% of the work
defined by the project scope and captures all deliverables
internal, external, interim in terms of the work to be completed,
including project management. The 100% rule is one of the most
important principles guiding the development, decomposition and
evaluation of the WBS. The rule applies at all levels within the
hierarchy: the sum of the work at the child level must equal 100%
of the work represented by the parent and the WBS should not
include any work that falls outside the actual scope of the project,
that is, it cannot include more than 100% of the work It is
important to remember that the 100% rule also applies to the
activity level. The work represented by the activities in each work
package must add up to 100% of the work necessary to complete
the work package.
(from Wikipedia)

 Mutually exclusive elements

Mutually exclusive: In addition to the 100% Rule, it
is important that there is no overlap in scope
definition between two elements of a Work
Breakdown Structure. This ambiguity could result
in duplicated work or mis-communications about
responsibility and authority. Likewise, such overlap
is likely to cause confusion regarding project cost
accounting. If the WBS element names are
ambiguous, a WBS dictionary can help clarify the
distinctions between WBS elements. The WBS
Dictionary describes each component of the WBS
with milestones, deliverables, activities, scope,
and sometimes dates, resources, costs, quality.
(from Wikipedia)

 Planned outcomes, not planned actions

If the Work Breakdown Structure designer
attempts to capture any action-oriented details
in the WBS, he/she will likely include either too
many actions or too few actions. Too many
actions will exceed 100% of the parent's scope
and too few will fall short of 100% of the parent's
scope. The best way to adhere to the 100% Rule
is to define WBS elements in terms of outcomes
or results. This also ensures that the WBS is not
overly prescriptive of methods, allowing for
greater ingenuity and creative thinking on the
part of the project participants.
(from Wikipedia)

Estimating Effort
While A number of more accurate
methods exist for estimating cost and
effort here you will simply make your
best guess for the effort in person
hours requires to complete each work
package, subtask and task in your WBS.
Try to be as realistic as possible in
estimating what you can do in what
time.

Estimating Available
Resources
Try and determine how much time, in
person-hours, you can as a team
devote to the project.
Once again, be realistic.

Scoping The Project

Limit the size of your project to the
number of tasks you can actually
finish given your estimations of total
available effort and the estimated
effort required to perform those tasks.
This is probably the most important
decision you will make in respect of
your project.

Less Is More
You will be assessed on the quality of
the work you submit, NOT the
quantity.

Scheduling
Precedence of tasks. Some tasks cannot be
undertaken before others have been completed.
The set of relationships between the dependencies
for these tasks are called precedence relations.
To depict project tasks, their duration, and precedence
you are likely going to want to use some type of
chart that shows timeframes and scheduling. The
Gantt chart, otherwise known as a bar chart is
commonly used to do this. A Gantt chart is "a
graphic display of schedule-related information. In
the typical bar chart, activities of other project
elements are listed down the left side of the chart,
dates are shown across the top, and activity
durations are show as date-placed horizontal bars."
(Newell, 2002, p. 391).

Scheduling Exercise
Consider the scenario below and map it to Gantt Chart.
The requirements specification of an IT application is estimated to take two
weeks to complete. When this activity has been completed, work can start
on three software modules, A, B and C. The design/implementation of A, B
and C will need five, ten and ten days respectively. Modules A and B can
only be unit-tested together as their functionality is closely associated. This
joint testing should take two weeks. Module C will require eight days of unit
testing. Once all unit-testing has been completed, the planning of
integrated
system testing must take place and it would require a ten days. The activity
itself would take three weeks.
The project manager has decided not to allow any holiday for the duration
of this project.
(Excercise by: L. Eshkevari, P. Frem)

Activity

Duration

Precedence

Specification (S)

14 days

Design/Coding A
(DCA)

5 days

Design/Coding B
(DCB)

10 days

Design/Coding C
(DCC)

10 days

Unit Test A,B (UTAB)

14 days

DCA,DCB

Unit Test C (UTC)

8 days

DCC

Planning of Integrated 10 days

System Test (P)

UTAB,UTC

Implementing
Integrated System
Test (IST)

21 days

Risk Management

Risk management is concerned with identifying

risks and drawing up plans to minimise their
effect on a project.

A risk is a probability that some abnormal

situation will occur.

Project risks affect schedule or resources.

Product risks affect the quality or performance of the
software being developed.
Business risks affect the organisation developing the
software.

The risk management process

1) Risk Assessment

The things you do as you plan your project

2) Risk Control

The things you do during the project

In respect of this project we will only assess risks and only in a

simple manner.
For each task assign a risk level:
Low
Moderate
High
For the purposes of this project risks are directly related to the
difficulty of completing the task by the deadlines given.

21

UCM

source:http://en.wikipedia.org/wiki/Use_case_diagram

Domain Models

source: http://nubyonrails.files.wordpress.com/2007/07/domain-model.jpg