Please login or join to subscribe to this thread
It depends on the project life cycle you use and the approach you use. For example, if you use an incremental-iterative life cycle with an Agile based approach. In my personal case in today work place we have a governance process where deliverables are the evidence about a milestone inside the governance process has been completed and that governance process is a layer that is used no matter the life cycle and approch we use.On the other side, because our value framework is client oriented for us a deliverable is a evidence that we are "fulfilling the contract" with our clients.
Thanks for your time and your response. So it seems that every milestone has a deliverable? or should have a deliverable? or "could have a deliverable", hence rather than have a separate task just specific for a project deliverable, a milestone for framework purposes could contain one or more deliverables. Does this sounds about right? Thanks again for your time.
As Sergio indicates, it is really project-specific and it depends on the nature of the deliverables. Documentation byproduct type deliverables are usually provided over the full life of the project without being tied to specific milestones or the closure of the project, whereas those deliverables which represent "real" value to our customers would likely be tied to milestones or the final acceptance of the project.
Sir, I hope all is well, I do agree with both of you gentleman's approach and process. While I had the same hunch as both of you, I wanted the expert opinion of our members. Thanks for both of your time!
Sergio, some additional thoughts
- not every milestone needs to be attached to a deliverable, e.g. if you receive something from outside your project and need it at a specific date, this would be a milestone too
- deliverables need not be delivered to the customer, e.g. if you build a house and need a crane for this, a crane installation would be a project deliverable but not put forward to the customer
- each work package in the WBS should have one or more deliverables, which you can verify and hene say the work package was 'delivered'
- what you define as milestone is up to the needs of the project stakeholders, as milestones are significant events in a project
"Deliverables" is a very broad, generic term. They come in many different types, and at different levels of a project. Example: I might have test results as a deliverable required to certify a product. Certification might be one of many deliverables before I can deliver the product itself. A project might contain many products, or different lifecycle phases such as development, and product support, requiring a different set of deliverables. This is where the project manager must use their best judgement to decide the best way to manage them. There is no one size fits all solution.
Milestones may or may not be tied to deliverables. They are schedule features meant to represent something important but are really an event with zero duration, and zero or many activities which produce deliverables may be tied to a milestone. Examples of milestones that may not include discrete deliverables are decision gates, and project phase transitions like moving from development to production. These are very important, occur at a specific point in time, and there would be information exchanged, meetings held and so forth, but there may not be formal deliverables either leading to these milestones, or generated as a result.
What about the timing or cost of a project deliverable, should the project deliverable (time to complete or to deliver and the cost involved) be discussed during the charter? or the time/cost of the project deliverable should have been added to the cost before the project starts or even before the charter discussion? What is the norm?
Please login or join to reply