Project Plans

CSCI102 - Systems

ITCS905 - Systems

MCS9102 - Systems

2

What is a project plan• A formal, approved document used to guide

– Project execution

– Project control

• It will provide details on

– Work required to complete a project

• Functional

• Technical

– Group Agreements

• Commitments

• Allocated Tasks

• Responsibilities

3

What is a project plan

• The plan details

– The tasks

– Schedule

– Cost

– Resources

– Milestones

– Deliverables needed to complete the project.

4

Why do we need one?

• The primary uses of the project plan are – To document planning assumptions and

decisions

– Facilitate communications among stakeholders

– Document approved • Scope

• Cost

• Schedule

5

Why do we need one?

• Forces the team to

– Think through their approach

– Make decisions about how to proceed

– May require making commitments

6

Why do we need one?

• A group member may leave or be replaced in the project

– The project plan can inform the new team member of tasks they are responsible for

– The project plan will assist in reallocating remaining tasks

• Main participants will have a clear sense of

– Cost

– Schedule

– Technical objectives

7

Contents of a Project Plan

• Cover sheet• Executive Summary• Introduction• Project goals• Identification of who is authorised to

– Set goals (customer)

– Supply goods and services to achieve goals

• Communication plan

8

Contents of a Project Plan

• Assumptions & Constraints

• Deliverables

• Activities

• Resource & Time allocation

• Quality• Conclusions

9

Cover Sheet

• Project title• Document version• Document author• Document date• Document History

10

Introduction

• Purpose of report and project

• Scope

• Main sections

• Need to describe the current situation

– You can then describe what the project will change in your goals

11

Goals

• Describe what the project will change • Explicitly define how you will know that you

have achieved your goals• Describe why the final outcomes will be an

improvement

12

Goals

• There is a real danger of the purpose getting lost along the way

– As the development action heats up

• Customer and developers discover more and more what is possible

• The system as it is being constructed wanders away from the original goals

– This is bad

• Unless there is some deliberate act by the client to change the goals

– You may need to assign a person to be the “guardian of the goals”,

• Probably enough to make the goals public

• Regularly remind developers of goals

• Normally you would need to obtain written approval on this goal from …

13

Authorised People

• Identification of who is authorised to

– Set goals (customer)

– Supply goods and services to achieve goals

• Typically these would be the customer and the supplier

• Need to make sure that these people actually have the authority to make decisions and commit resources

14

Communication plan

• This section essentially identifies

– Who is who in the project team

– What can each person do and decide?

• Skills

• Knowledge

• Experience

• This would lead to identification of their roles within the team

– What is the regular meeting and reporting structure

– Documentation standards

• This where your group expectations and rules can be defined and spelt out

15

Assumptions & Constraints• Identify any mandated constraints

– Solution constraints

• Define the boundaries within which we can solve the problem

– Implementation environment

– Partner applications

– Off-the-shelf software

– Anticipated workplace environment

– Time frame for delivery

– Financial budget (Not necessary for CSCI102)

– Decisions that have already been made

16

Assumptions & Constraints• Relevant Facts and Assumptions

– External factors

– Anything that has an effect on the product

– New laws or political decisions

– What your developers expect to be ready in time for them to use

– Technological environment in which the product will operate

– The software components that will be available to the developers

– Availability and capability of bought-in components

– Dependencies on computer systems or people external to this project

17

Deliverables

• The project goal translates into a final deliverable

– The first deliverable is always the project plan

– You have been given a number of specific deliverables in your project handout

– Describe each deliverable so that

• Somebody else (in this case your tutor and gene) can decide when it is ready

• Another team could take over your project if necessary

18

Activities

• Each deliverable breaks down into one or more specific tasks

– What do you need to do

– What information do you require in order to complete the task

– How long will it take to complete each task/subtask

– What dependencies exist between specific tasks

– Don’t forget review and decision activities

– Don’t forget delivery itself

• When

• Who

• Where

19

Resource & Time allocation

• Each activity gets resources allocated

– An estimate of expenses and elapsed time per task

– Customer resources

– Who is responsible for each task

– Who will be working on each tasks

– Set the activities in a linear sequence, and eliminate overallocation of resources

• This can later be used to report progress against• The last three sections can be used as data for your

Gannt Chart

20

Gannt Chart

• Gantt charts are useful when planning and scheduling projects

– Allow you to decide how long a project should take

– Lay out the order in which tasks need to be carried out

– Help manage the dependencies between tasks

– Determine the resources needed

03-S

ep-0

4

10-S

ep-0

4

17-S

ep-0

4

24-S

ep-0

4

01-O

ct-0

4

08-O

ct-0

4

15-O

ct-0

4

22-O

ct-0

4

Project Plan

Write Design Plan

Write Test plan

Write Final Report

Insert New Task above this line

Completed Remaining

21

Gannt Chart

• Useful tool during a projects life

– Monitor progress

– Allow you to see how remedial action may bring the project back on course

22

Quality

• What techniques will be used to ensure that the goal is reached?

– Tests

– Reviews

– Metrics

• Which deliverables are reviewed by whom?• Who reviews status reports? • How are changes to already accepted deliverables

handled?• How are changes to schedule handled?• What expectations does the team have of each other?