Our PM has requested a list of delverables for the client (and him) to be kept informed of the items currently included in the project. This document will change periodically based on new requests to be added in and not only include enhancments scheduled for the release but also future enhancements currently in progress, i.e requirements gathering and BRS. The original idea was to post these to the Release Notes. I disagree with this since the Release Notes should include only those items implemented forthe release. What document should this deliverables list be included with?
Hi 003762,
Could you be a little more specific about what exactly this document will contain? Is it to contain all the business requirements for the scope of the project, system specifications, functional requirements, etc.?
To me this sounds like a living requirements document that also tracks the state of each requirement (in/out of current scope field as well as not started, in development, in progress, in system testing, in UAT, completed, etc. progress field). This document will manage your overall set of requirements for the life of the project, and when the project is completed you can retain the incomplete/unmet requirements and pass them off to the sponsor so they can decide whether to develop a business case for a new project.
Depending on the methodology you are following, this information would fit well in a Iteration Plan. However, if you are not planning on using iterations, you can still utilize this type document by calling it a Release Plan. I would suggest keeping this document focused on the measurable, deliverable pieces of functionality the client is requesting, rather than the detailed requirements of each functional piece. Based on my experience, clients and PMs get bogged down in the details of requirements, but respond well to status of functionality. You can then utilize a traceability matrix to map the larger functional pieces to the detailed requirements pieces.
Your Release Plan may include future releases, and therefore is a changing document. You are correct that your Release Notes should include only those items actually delivered in the release.
Feel free to contact me if you would like an example template.
Brad Botz
[email protected]
Prime Proficiency
There are a couple of tools you could use to do this effectively. My preference would be for a release plan, or at a more detailed level, a product backlog. Both of these terms can be found on the www.scrumalliance.org website.
You could also use a feature list, or a product breakdown (aka product breakdown structure). The Product breakdown is good because it maps tightly to a work breakdown structure, which should (could) be your PM's main work plan.
more info
Good luck.
brought to you by enabling practitioners & organizations to achieve their goals using: