Thursday, 4 October 2007

Acceptance Criteria

I've been writing some materials updating JISC infoNet's Project Management infoKit and had given some examples of user or customer acceptance criteria:

● target date
● functions required
● performance levels
● capacity
● downtime / availability
● running cost
● security levels
● level of skill required to operate
The above may, at first glance, appear very IT systems based. But consider the installation of a lift in a new build project. The lift needs to be installed by a certain date, a specific function may be that it should only go down to the basement if a key is used to turn a lock to a certain position. It has performance levels - eg speed, it has a capacity in weight and number of people carried safely, it will require servicing at times, it will use electricity, and whilst it may not require any security levels for normal use (though we have mentioned one possible level already), there will need to be security of access to the operating machinery and a level of skill required for servicing personnel.

Then I applied them to producing a new range of paint. Target date becomes shipping date, functions required seems fairly simple, but capable of being thinned and by what or whether undercoat is required, performance levels as in opacity, how many coats required, can it be washed down without coming off a wall, capacity as in what area will one litre of paint cover, let's forget "downtime"(!) but availability is certainly an issue, how much can be produced, how many retail outlets are we aiming for to stock it, how much will it cost, will we need notices about storing out of children's reach, is it suitable for brushing, spraying, rolling, sponging...

For some projects your users or potential customers will be able to specify some, perhaps the majority of the acceptance criteria, but quite often they need some assistance with this.

Many users have an idea of what it is they want from a project but can totally lack the ability to put it into words or at least into enough detail so that you have a clear view of what is required. Specifying the acceptance criteria may need to be an iterative process, but one which needs to be finalised as early as possible.

Making changes before you start is cheaper than making changes once you've finished...

No comments: