Quantified Objectives: A Fundamental Advance in Managing Software Development Projects

Stuart James Woodward, DoubleHelix Software & Services Limited, http://www.doublehelix.co.uk/

Synopsis

Evolutionary techniques are increasingly the default choice for executing software development projects. They have demonstrable advantages over conventional methods. Problems still arise, though, when projects are planned and monitored, and requirements are specified purely on the basis of functionality.

Tom Gilb has argued the case for quantitative objectives and use of evolutionary methods over many years.

This paper supports the use of Planguage (© Copyright Tom Gilb), an advanced planning language and set of methods. By augmenting Evolutionary Project Management with further Planguage methods, the author proposes that a shift of focus from functional to performance requirements will result in a fundamental advance in project management.

Introduction

A Brief Overview of Evolutionary Project Management

Evolutionary Project Management or Evo is a project management process delivering evolutionary ‘high-value-first’ progress towards the desired goals, seeking to obtain, and use, realistic, early feedback [GILB04]. The system is therefore built in steps, enabling the controlled modification of plans and schedules in line with emerging and maturing requirements. In Evo the focus is always on delivering results to the stakeholders so that at the beginning of each step
any aspect of the project including its plans, requirements, architecture, etc. is subject to alteration if it is estimated that by doing so it will benefit those stakeholders.

This contrasts with the conventional Waterfall approach that is based upon a fixed plan and set of requirements and the completion of a sequence of individual processes, the entire sequence leading to a single delivery of a completed system.

A delivery sequence on an Evo project

A delivery sequence on a Waterfall project

In a previous paper, "Evolutionary Project Management" [WOODWARD99], I compared two projects that had intended to deliver the same product, one using conventional Waterfall delivery and one using Evo. The latter project, "OMAR", which I managed between 1996 and 1998, was my first major step into Evo.

Result Metrics from both projects led me to the conclusion that Evo projects deliver more functionality from fewer resources. However, I was aware that some aspects of the OMAR project could have been better even though, at that time, I did not have the knowledge or experience of the detailed methods that could have helped. Accordingly, since the end of that project I have sought to extend and improve my project management by the utilisation, where possible, of new methods.

Evo, as described in Principles of Software Engineering Management [GILB88] by Tom Gilb, had guided my management of OMAR. I have been influenced and encouraged further by Gilb’s work and have attempted to make use of Planguage, an advanced planning language and set of methods for use in Evolutionary Project Management, Requirement Specification, Design Evaluation and Quality Control. Planguage is described in the soon-to-be published Competitive Engineering [GILB04].

The CRM Project

The OMAR project had been fortunate from being shielded from ‘real-world’ users; it took place within a software house. The project was driven, and changed direction during its execution, by the known and market-researched functional requirements of a new product. Although it would serve existing business processes, OMAR itself had no existing system to replace. We had no access, in the early stages, to organisations where the system would later be used.

On a subsequent assignment I worked at an end-user financial organisation on a project named, for the purposes of this paper and confidentiality, CRM (Credit Risk Management). Unlike OMAR, CRM implemented into software the business processes that already existed in the organisation. In other words, the functional requirements of the system already existed in another form.

With this in mind I thought about the following questions:

• What are the underlying objectives of the project?
• How will we know for sure what the next best step is at each stage?
• How will we know when we have met the requirements and when it is best to stop the development project?

These fundamental and powerful questions are not necessarily easy to answer. I found it difficult to find answers on the CRM project owing to the way in which the stakeholders insisted on stating the project requirements and the way in which senior management expected the project to be planned and monitored. My experience on CRM led me to understand that these areas of concern require serious attention in order to improve the management of projects. In particular, I came to the conclusion that when requirements are stated only in terms of functionality, then there is too much subjective decision making by the project’s stakeholders.

Note: In this paper I use the term functionality to mean, "what a system does" or "a system’s functions". Likewise, I use the term performance levels to mean, "how well the functions are carried out".

Go to part 2    Back to the archive list