Project Plans CSCI102 - Systems ITCS905 - Systems MCS 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

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?