UoL CS Notes
Menu

Project Management

COMP201 Lectures

This is the process of organising, planning and scheduling software projects.

We need to make sure that the product is delivered on time and each component is delivered on schedule.

Management Activities

  • Proposal Writing
  • Project Planning and Scheduling
  • Project Costing
  • Project Monitoring and Reviews
  • Personnel Selection and Evaluation
  • Report Writing and Presentations
  • Project Staffing & Training

Project Planning

The following types of project plan exist:

  • Quality Plan - Describes the quality procedures and standards that will be used in a project.
  • Validation Plan - Describes the approach, resources and schedule used for system validation.
  • Configuration Management Plan - Describes the configuration management procedures and structured to be used.
  • Maintenance Plan - Predicts the maintenance requirement for the system, maintenance costs and effort required
  • Staff Development Plan - Describes how the skills and experience of the project team members will be developed.

The project plan should have the following structure:

  1. Introduction
  2. Project Organisation
  3. Risk Analysis
  4. Hardware and Software Resource Requirements
  5. Work Breakdown
  6. Project Schedule
  7. Monitoring and Reporting Mechanisms

Activity Organisation

Activities in a project should be organised to produce tangible outputs for management to judge progress:

  • Milestones - Are the end-pont of a process activity.
  • Deliverable - Are project results delivered to customers.

We can see this in the requirements engineering process:

flowchart LR
subgraph Activities
fs[Feasibility Study] --> ra[Requirements Analysis] --> pd[Prototype Development] --> ds[Design Study] --> rs[Requirements Specification]
end
subgraph Milestones
fs --> fr[Feasibility Report]
ra --> rd[Requirements Definition]
pd --> er[Evaluation Report]
ds --> ad[Architectural Design]
rs --> rs2[Requirements Specification]
end

Project Scheduling

This is the process of splitting projects into tasks and estimating the time and resources required to complete each task. We should:

  • Organise tasks concurrently.
  • Minimise task dependencies to avoid delays.

We could face the following issues:

  • Estimating the difficulty of problems is hard.
  • Productivity is not proportional to the number of people.
  • Adding people late can delay a project due to communication overheads.

Tasks should not be too small, about a week in length.

Task Durations & Dependencies

Task Duration/Days Dependencies
T1 8  
T2 15  
T3 15 T1 (M1)
T4 10  
T5 10 T2, T4 (M2)
T6 5 T1, T2 (M3)
T7 20 T1 (M1)
T8 25 T4 (M5)
T9 15 T3, T6 (M4)
T10 15 T5, T7 (M7)
T11 7 T9 (M6)
T12 10 T11 (M8)

Activity Network

graph LR
Start --- T1 & T2 & T4
T1 --- M1 & M3
T2 --- M3 & M2
T4 --- M2 & M5
M1 --- T3 & T7
M3 --- T6
M2 --- T5
M5 --- T8
T3 --- M4
T6 --- M4
T7 --- M7
T5 --- M7
T8 --- Finish
M4 --- T9
M7 --- T10
T9 --- M6
T10 --- Finish
M6 --- T11
T11 --- M8
M8 --- T12
T12 --- Finish
Start([Start<br>4/7/99])
T1[T1<br>8 days]
T2[T2<br>15 days]
T3[T3<br>15 days]
T4[T4<br>10 days]
T5[T5<br>10 days]
T6[T6<br>5 days]
T7[T7<br>20 days]
T8[T8<br>25 days]
T9[T9<br>15 days]
T10[T10<br>15 days]
T11[T11<br>7 days]
T12[T12<br>10 days]
M1([M1<br>14/7/99])
M2([M2<br>25/7/99])
M3([M3<br>25/7/99])
M4([M4<br>4/8/99])
M5([M5<br>18/7/99])
M6([M6<br>25/8/99])
M7([M7<br>11/8/99])
M8([M8<br>5/9/99])
Finish([Finish<br>19/9/99])
  • Minimal time - Length of the longest (critical) path which is 55 days.

Activity Timeline (Gantt Chart)

gantt
dateFormat DD/MM/YYYY
Start:milestone, Start, 04/07/1999, 0d
T1:T1, after Start, 8d
T2:T2, after Start, 15d
T4:T4, after Start, 10d
M1:milestone, M1, after T1, 0d
T3:T3, after M1, 15d
T7:T7, after M1, 20d
M5:milestone, M5, after T4, 0d
T8:T8, after M5, 25d
M2:milestone, M2, after T2, 0d
M3:milestone, M3, after T2, 0d
T5:T5, after M2, 10d
T6:T6, after M3, 5d
M4:milestone, M4, after T3, 0d
T9:T9, after M4, 15d
M7:milestone, M7, after T7, 0d
T10:T10, after M7, 15d
M6:milestone, M6, after T9, 0d
T11:T11, after M6, 7d
M8:milestone, M8, after T11, 0d
T12:T12, after M8, 10d
Finish:milestone, after T12, 0d

You can extend the bars to show lag.

Staff Allocation (Gantt Chart)

gantt
dateFormat DD/MM/YYYY
section Fred
Start:milestone, Start, 04/07/1999, 0d
T4:T4, after Start, 10d
M5:milestone, M5, after T4, 0d
T8:T8, after M5, 25d
T11:T11, after M6, 7d
M8:milestone, M8, after T11, 0d
T12:T12, after M8, 10d
Finish:milestone, after T12, 0d

section Jane
T1:T1, after Start, 8d
M1:milestone, M1, after T1, 0d
T3:T3, after M1, 15d
M4:milestone, M4, after T3, 0d
T9:T9, after M4, 15d
M6:milestone, M6, after T9, 0d

section Anne
T2:T2, after Start, 15d
M2:milestone, M2, after T2, 0d
M3:milestone, M3, after T2, 0d
T6:T6, after M3, 5d
T10:T10, after M7, 15d

section Jim
T7:T7, after M1, 20d
M7:milestone, M7, after T7, 0d

section Mary
T5:T5, after M2, 10d

The milestones weren’t shown on the slide in this chart. I was too lazy to take them out.

Pert Charts

These show the following:

  • Early Start - Earliest time a task can start.
  • Early End - The earliest time the task can end.
  • Late Start - The latest time the task can start without delaying the deadline.
  • Late End - The latest time the project can end without delaying the deadline.
  • Slack - The amount a task can be delayed without delaying the project.
    • Calculated from Late Start - Early Start.
    • Slack = 0 means that the task is critical.

They are shown as a set of linked tables with the following format:

Duration: 6 Task 1
Start End
Early: 0 Early: 6
Late: 8 Late: 14

You might find better information on this type of chart by searching for activity networks. Pert charts seem to be a different thing.

Risk Management

This is drawing plans to minimise the effect of risks on the project.

Risks can be in the following categories:

  • Project Risks - Affect the schedule or resources.
  • Product Risks - Affect the quality or performance of the software being developed.
  • Business Risks - Affect the organisation developing or procuring the software.

Risk Management Process

  1. Risk Identification - Identify project, product and business risks.
  2. Risk Analysis - Assess the likelihood and consequences of these risks.
  3. Risk Planning - Draw up plans to avoid or minimise the effects of the risk.
  4. Risk Monitoring - Monitor the risks throughout the project.

Risk Identification

You could identify risks in the following categories:

  • Technology - The database used in the system cannot process as many transactions per second as expected. Software components which should be reused contain defects which limit their functionality.
  • People - It is impossible to recruit staff with the skills required. Key staff are ill and unavailable at critical times. Required training for staff is not available.
  • Organisational - The organisation is restructured so that different management are responsible for the project. Organisational financial problems force reductions in the project budget.
  • Tools - The code generated by CASE tools is inefficient. CASE tools cannot be integrated.
  • Requirements - Changes to requirements which require major design rework are proposed. Customers fail to understand the impact of requirements changes.
  • Estimation - The time required to develop the software is underestimated. The rate of defect repair is underestimated. The size of the software is underestimated.

Risk Analysis

We need to estimate the following:

  • Probability:
    • Very Low
    • Low
    • Moderate
    • High
    • Very High
  • Risk Effects:
    • Catastrophic
    • Serious
    • Tolerable
    • Insignificant

We can then put the analysis in the following table:

Risk Probability Effects
Organisational financial problems force reductions in the project budget. Low Catastrophic
     

Risk Planning

We can use the following strategies to minimise risk:

  • Avoidance Strategies - The probability that the risk will arise is reduced.
  • Minimisation Strategies - The impact of the risk on the project or product will be reduced
  • Contingency Plans - If the risk arises, contingency plans are plans to deal with that risk.

Risk Monitoring

We can draw up a table of risk factors and indicators so that we can spot issues early:

Risk Type Potential Indicators
People Poor staff morale, poor relationships amongst team member, job availability