CS3007A Software Project Management

Problem Sheet 6

Lecturer: Dr Robert Macredie

E-mail: Robert.Macredie@brunel.ac.uk,

Introduction

In the sixth session we talked about monitoring and control. We looked at dimensions of a project against which we would want to monitor, notably time/effort, cost and quality. We considered what might contribute to time/effort, cost and quality (i.e., what we would have to monitor) and discussed ways in which we might monitor them. We then explored how we might exercise control over aspects of a software project, focusing on the possible corrective actions which we might take and scenarios in which they might be more and less appropriate.

Learning Outcomes

The learning outcomes for the problem sheet are as follows:

(i)     you should be able to explain the ways in which progress 
        may be monitored in software projects with respect to: 
        time/effort; cost; and quality;

(ii)    you should be able to list and explain different reasons for 
        overrun in software projects, providing examples from 
        real software projects;

(iii)   you should be able to discuss ways in which the balance and 
        aims of a project might influence the development of corrective 
        actions, giving examples from real software projects;

(iv)    you should be able to list and critically appraise the value of 
        different corrective actions, proposing scenarios where 
        each might be appropriate.

Questions

(i)     How might progress be monitored in software projects with 
        respect to: (i) time/effort; (ii) cost; and (iii) quality. 

(ii)    Why might we encounter overrun  in software projects? 
        Give examples from real software projects in support of each 
        of the reasons that you give.  There are many examples in the 
        trade-press and academic books and papers in the area.  

(iii)   How might the balance and aims of a project influence the 
        development of corrective actions, using examples from real 
        software projects.   For example, how might the safety criticality 
        of a project constrain the corrective actions that might be taken?

(iv)    What broad corrective actions might you take as a software project 
        manager when you find problems in your project.  Provide brief 
        scenarios where each action might be appropriate, justifying your 
        suggestions.  Where might each also be inappropriate?

I would encourage you to work in groups of around five for this and subsequent exercises.

Robert Macredie

30 October 1998