Project Management Deliverables (Practical Project Management Series).
This time the subject is ‘project management deliverables’.
The purpose of a project is to deliver ‘something’ at the end. After delivery the deliverables need to be managed and maintained. During the use of the deliverables changes might be needed which could be the trigger for a new project.
The client needs to document explicitly in measureable terms (S(pecific) M(easureable) A(cceptable) R(ealistic) T(ime constrainted)) what needs to be delivered in order to be able to determine what has been delivered is meeting the requirements as stated by the client.
The contract can use either ‘acceptance criteria’ or ‘completion criteria’. This is from a legal point of view a big difference. Using acceptance criteria the client can refuse a long time not to accept the deliverables resulting in no project closure (and the costs increasing).
Formally this is not allowed using completion criteria but as Project Manager you might also end up in all kind of discussions which prevent project closure.
In all cases it is crucial that you as Project Manager determine as SMART as possible in advance with the client when the project will be finished!
A few generic remarks regarding project delivery:
- Who is the owner of the deliverables (intellectual property)? This should be documented in the contract.
- Especially with software development: does the client receive all source files and documentation?
- Take care of a formal transfer to the organisation which will maintain the deliverables, including possible remaining items, in order to finish your project properly.
This is the last article in this series ‘practical Project Management’. This is a ‘blog’ article by Lex van der Heijden regarding practical Project Management. For questions/remarks I’m available via [email protected] or via LinkedIn (nl.linkedin.com/in/lexvanderheijden/).