Dimensions of Quality, Scope, Budget and Timescale

There is an interesting discussion here about the variables that you can control to decide how to deliver a piece of software. Sam argues that there should be five variables of Scope, Time, People, Process and Risk. In a comment, Basil posted a link to his site, where he says he thinks you should consider four variables of time, resources, scope and quality. I agree with Basil, and think it is important to know what contributes to each of these variables. I came up with the following diagram.



The attributes that define quality are Availability, Performance, Scalability, Security, Accessibility, Extensibility, Deployability and Maintainability. You might decide that some of these are non-negotiable, and others can be traded against each other or against budget, scope or delivery deadlines. (I got these criteria from Ed Tittel's Book, where they are described in more detail)

The attributes that define scope are the numbers of features required and their complexity. Some features might be non-negotiable, but you might be able to simplify them to meet deadlines, budgets or quality requirements. Sometimes you might be able to leave features out.

The attributes that define budget are people, equipment and acceptable risk. You might have flexibility to change the numbers of people or quality of equipment on a project to meet other goals. You might also be able to think about the risks. If someone were to become ill just before release date, is it going to be acceptable to get an expensive consultant in for a few days to ensure the release happens, or should other people within the team know what to do so this won’t be necessary. Obviously it will take time to transfer knowledge amongst the team, meaning less can be done or quality has to be compromised.

Finally, the attributes that define time are a deadline, the acceptability of risk and the time taken to learn and reflect. It may be possible to negotiate the deadline. A degree of risk with the deadline may or may not be acceptable. If someone is ill, it may be acceptable to wait a few days and postpone the deadline, or it may not. You also need time to learn and reflect. The more time you spend learning and reflecting on what went well and what didn’t the faster future projects will be.

When you have thought about these attributes, you need to understand what can be changed and what is fixed. The more that is fixed, the more likely it is the project will fail. However, if there are lots of things that can be changed, you need to think about what the priorities are – is it more important to implement lots of features, or is having a few features of high quality preferable?

When you know this, you can choose a process, waterfall or agile, that is best for this particular project.