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...

Monday, 1 October 2007

Workshop Writing

I'm about to start writing JISC infoNet's new workshop - Project Management Masterclass.

This takes the Project Management techniques delivered in our original Project Management Workshop into senior management territory and explores in depth, things like turning strategy into projects, portfolio management, management by exception etc.

We have always used the same tool for putting workshops together and it's a very simple one. We take a flip chart (or a wall) and cover it in post-it notes.

The different colours represent different delivery tools or activities during the workshop.

The blue notes are for "TALK" (not "TRUC", yes I know it looks a bit like that at the bottom...)

The yellow notes represent a shout-out session, where delegates are asked to give answers to a question, opinions on a point, or feedback.

The pink notes represent an activity that the delegates will undertake either singly or in groups.

Ensuring that there is not a whole bunch blue notes together can help your lesson or workshop motor along without risking delegates or students getting bored.

Quite often during the shout-out sessions I will write down any delegate points on-screen using Word. This can be minimised afterwards but then contains a record if I want to come back to a point someone made during the workshop or we can put the delegates' feedback online afterwards where they can compare it with previous groups' feedback.