SOEN 341 Tutorial 1Project 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 1Task 1

Level 2Subtask 1.1

Level 3Work 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 RulesThe 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.

SchedulingPrecedence 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 ExerciseConsider the scenario below and map it to Gantt Chart.

The requirements specification of an IT application is estimated to take twoweeks to complete. When this activity has been completed, work can starton three software modules, A, B and C. The design/implementation of A, Band C will need five, ten and ten days respectively. Modules A and B canonly be unit-tested together as their functionality is closely associated. Thisjoint testing should take two weeks. Module C will require eight days of unittesting. Once all unit-testing has been completed, the planning of integratedsystem testing must take place and it would require a ten days. The activityitself would take three weeks.

The project manager has decided not to allow any holiday for the durationof this project.

(Excercise by: L. Eshkevari, P. Frem)

Activity Duration Precedence

Specification (S) 14 days

Design/Coding A (DCA) 5 days S

Design/Coding B (DCB) 10 days S

Design/Coding C (DCC) 10 days S

Unit Test A,B (UTAB) 14 days DCA,DCB

Unit Test C (UTC) 8 days DCC

Planning of Integrated System Test (P)

10 days UTAB,UTC

Implementing Integrated System Test (IST)

21 days P

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.

21

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:LowModerateHighFor the purposes of this project risks are directly related to the difficulty

of completing the task by the deadlines given.

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

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