Nailing down agreement

If you haven’t already come across ecademy, it’s worth a look. There’s an active project management community there, and there are often some real gems posted into the community’s forum.

This idea was posted by David Walker in response to a post of mine, talking about the problems of getting agreement on requirements:

A pretty neat thing to get your steering group to agree is a set of principles - if a requirement doesn’t meet all the principles everyone should agree that it gets kicked into touch (or put into Phase II which amounts to the same thing!). Example principles might be;

- ‘keep it vanilla’ (eg; for packaged implementations - Peoplesoft etc) - keep the software as it comes out of the box, with no unnecessary development

- no paper - nothing gets printed

- no additional hardware

- no change costing more than £x

- no hand-offs in the process

- automation, no pre-existing processes ‘computerised’

This strikes me as a simple, but very effective approach - very often it can be difficult to argue against requirements becoming more complicated mid-stream, or ensure that there’s agreement in the first place. Taking this approach means that you get agreement early on about the parameters of what’s acceptable and what isn’t - and gives you a ‘lever to pull’ if the goalposts start to drift later on.

And if you’re working in a Prince environment, this can be formalised in the Project Definition section of the Project Initiation Document, which gives a degree of ‘legal force’ to the agreement.