Project Planning. CITS3220 Software Requirements & Project Management

Transcription

1 Project Planning CITS3220 Software Requirements & Project Management

2 Why plan? The superior programmer uses superior planning skills to avoid having to use superior crisis management skills British Army Saying (The 6 P's) Proper Planning Prevents Piss Poor Performance

3 Issues in Project Management (a reminder) Before starting the project: planning, estimation, risk analysis; While doing the project: monitoring, evaluation, metrics; After the project is done: assessment and improvement

4 Overview of Today s Lecture Issues Why plan? What s in a plan? Human factors Definitions and Techniques planning steps; work breakdown structure; critical path analysis and PERT charts; Gantt charts

5 Why Plan? Control of the project is based on derivation from the plan Communication of roles, responsibilities and resource requirements Strategy enables trade-offs in the cool light of day rather than within a deadline panic Risk management anticipates problems and provides a management strategy Granularity how much planning to do? A plan is a living document

6 Questions for Project Managers What is the scope of our project? What gets delivered for the available time, people, $? (And what won't we do?) What resources do we need? How do we tell where we are? Are we on schedule? Are we on budget? How do we communicate our plan inside & outside the team?

7 The W 6 H 3 elements of a plan Objectives WHY is the system being built? Deliverables WHAT has to be produced? Milestones WHICH process stages are needed for control? Methods HOW will the tasks be done (technically)? Resources WHERE do we get the people/tools for the work? Risks HOW will potential problems be minimised? Schedule WHEN will the stages be completed? Verification HOW will we know the system is correct? Responsibility WHO is responsible for ensuring completion?

8 An effective plan includes Business perspective financial, technical commercial Deliverable components and the tasks required Clearly defined organizational responsibilities Product requirements and deliverables Risk quantified in $ or hours and risk management strategy proposed Sensible task durations e.g. 2 months max Sensible task size (e.g. 1 to 2 person-months) Defined acceptance criteria

9 A poor plan only technical perspective or only task view no clear assignment of responsibility for production of deliverables no milestones or acceptance criteria risk ignored or buried in bloated estimates long task durations (e.g. 1 year) very large tasks (eg 20 people for 2 months) no process to guarantee the client s needs are met

10 Human Factors in Project Planning people tend to be risk averse when there is a potential of loss people are unduly optimistic in their plans and forecasts people prefer to use intuitive judgment rather than (quantitative) models Managers are people also, and these human tendencies apply to the managers who make business decisions at the project to the executive level.

11 Tasks, Milestones & Deliverables Tasks activities which must be completed to achieve the project goal Milestones important checkpoints Deliverables milestones with an external output

12 Work Breakdown Structure (WBS) A to-do list, sorted by category Task description (what) Estimated time (length) Person responsible for task (who) Resources required Cost ($)

13 3 Steps to a Project Plan Step 1: Identify Tasks & Resources Step 2: Identify Milestones Step 3: Analyse Dependencies and Define Schedule with a Gantt Chart

14 Initial Plan, Tasks and Resources Tedious and hard...but must be done What ==> tasks When ==> schedule How ==> people, materials, equipment costs Set scope and avoid "scope creep"

15 Identifying Tasks & Resources State each task using "verb-noun" form Examples: Write manual; Implement Prototype; Review requirements with client Use appropriate level of detail Function, not form, known at start of project Example: "Build concept demonstration prototype" Make each task significant e.g. Identify competitive products" not "Go to library Defining tasks is hard but worthwhile!

16 Milestones Key targets for completion of certain phases of a project A milestone requires both the state of the task/phase and a date/time to be set. Some typical SE milestones requirement specifications completed key plans completed systems documentation completed test data sets completed tests run with user prepared test data completed user manuals completed acceptance testing completed post-implementation review completed

17 Milestones Types of milestones Provide tangible interim goals Demonstrate progress and so provide motivation Used to enforce schedule State each milestone in "noun-verb" form Examples: Mission stated; Mid-quarter review presented; Prototype completed

18 Scheduling &GANTT charts Gantt charts Best basic scheduling tool Developed in 1917 by Henry L. Gantt Pick appropriate time scale (days/wks) Method of tracking progress Who is responsible Good software (e.g. MS Project) is available. GANTT charts don t show dependencies explicitly

19 Source

20 Gantt Chart components horizontal axis = total time span of the project vertical axis = project tasks horizontal bars = sequences, timing, and time span for each task bar spans (tasks) may overlap secondary bars, arrowheads, or darkened bars added as project progresses to indicate completed tasks vertical line = report date

21 PERT charts Programme Evaluation & Review Technique Explicitly shows dependency and parallel tasks Shows critical path and where flex time is Can be hierarchical (with sub-tasks)

22 Source