Deliverables is a new feature that shipped in Project Professional 2007. Deliverables provides the ability to publish key dates to a SharePoint site and for others to consume these keys dates within their project plan. This feature helps you to manage cross project dependencies. A project manager can define deliverables within their project plan using Project Professional and have the dates automatically published to a Deliverable SharePoint list within the Project’s workspace. This allows other project manager to take dependencies on the published deliverables within their own Project Plans. When there is a change with a deliverable, such as a change in the finish date, all the project managers who have taken a dependency on the deliverable get informed of the change with the deliverable when they open their project plan. Deliverables provide a way to loosely tie projects together.
This diagram illustrates deliverables at a high level:
When a project manager creates a deliverable or a dependency on a deliverable they have the option to link it to a task. When a deliverable or dependency is linked to a task, it shows an icon beside the task name and displays bars on the Gantt chart. It is important to note that the dates of the task are not tightly coupled with the dates of the deliverable. This is to allow the project manager to work with his/her schedule without altering the dates of the deliverable. It is by design that the project manager needs to explicitly update the deliverable dates. The below screen shot is a project plan with deliverables and dependencies:
So know that you have an idea what Deliverables are, let’s work through an example. The example that I like to use is the release schedule of large software development project, such as Microsoft Office, which has several beta releases before the actual shipment of the product. The overall schedule is managed in a single project plan, but there are many teams, such as Project, Excel, etc, that adheres to the overall schedule, but requires their own detailed schedule that is specific to them. An Office schedule that is just an example that I made up and has no meaning what so ever, may look like this:
Product teams are very interested in the Beta 1, Beta 2 and RTM dates and they want to be able to easily keep track of these dates. In order for this to happen, the project manager for the Office schedule must create deliverables for these tasks. Before the PM creates deliverables, they are going have to publish the project to Project Server and create a workspace for the project. To do this:
Once the project is published and the workspace is created for the project, the PM ready to create deliverables. To create a deliverable the PM will have to follow these steps:
The PM for the Office schedule would repeat these steps for each deliverable they want to create. Once they have completed creating the deliverables for Beta 2 and RTM the schedule should look like this:
As you can see from the schedule, there are red bars on the Gantt chart that represent each deliverable. There are also informational icons beside each task indicating that there is a deliverable linked to the task. Now that the PM has created these deliverables, other PMs can view these deliverables from the workspace for the project:
Since the deliverables are published to a SharePoint list, there are many built in benefits. Users can easily setup alerts, create RSS feeds, add additional columns, etc. It is important to note that if you change a deliverable from the SharePoint List, it will give the PM the option to sync the change next time they open their project in Project Professional.
PMs can also now consume these deliverables as dependences from within their own project plans. Going back to our example, the Excel team will want to take dependencies on the Beta 1, Beta 2 and RTM deliverables from the Office schedule. This time I am only going to create a very simple project plan with three tasks that represent the Excel team’s project plan. To create a dependency on a deliverable, the PM does not have to publish the project or create a workspace. They only have to do the following steps:
Now a dependency has been created that has been linked to Task A and is dependent on the Beta 1 deliverable from the Office Schedule. These steps will have to be performed for each deliverable, which in this example is Beta 1, Beta 2 and RTM. If you have a large number of deliverables to create from already existing tasks, I suggest you read my programmability post on deliverables: http://blogs.msdn.com/project_programmability/archive/2007/02/19/working-with-deliverables.aspx
You will notice that the dependency dates and the task dates are not aligned. The dependency dates are also loosely coupled with the task dates. This is shown in the below image of the Excel project where the yellow Gantt bars show the dependency dates are much further out then the task dates shown by the blue Gantt bar:Now that we have two projects, one with published deliverables and the other with dependencies on the published deliverables, let’s work through an example where one of the deliverables change. Within the Office schedule there is a deliverable, Beta 1, which has a finish date of March 20th 2007. To change the finish date to March 30th 2007:
Now go to the Excel team Project to see how this change has affected the dependency:
Note that the dependency date is now 3/30/2007 and is back in sync with the Beta 1 deliverable.
Hopefully that gives you an idea on how deliverables feature works. This feature truly provides a flexible way to loosely couple projects together that are not affected by the scheduling engine. I have only given a short overview on how to get started with deliverables. Once you start to play around with them, I am sure you will find great uses for the feature.
I have had many questions with regards to the Deliverables feature and reporting. If your not familiar
When Creating a delivrable, If we don't link it to "selected" task, the delivrable will not be displayed in the Gantt Diagram. My Question if there is a way to display it.
Can i get some clarity on the EVA feature in MS Projects?
Would really appreciate the effort.
There is no way to display it on the Gantt unless it is linked to a task.
When I open the Coolaborate Menu, the Manae Deliverables option is greyed out. I checked Collaboration Options and did not find any Deliverables options. What am I missing?
Hi, I have a question regarding the icon for deliverables. In project center (see if there’s an issues and sofort) and task view I’m not able to see that there is a deliverable attached only in Project proof. Is it possible to get the icon in My task and Project center.
If the date of a Deliverable (Collaborate > Manage Deliverables) has been moved in a project, is it possible to add a comment or a warning in any
dashboard managed by WSS ? How could we do that?
Does Deliverable dates be displayed in MS Project Column ? (using insert column function)
Thank you in advance ?
Is there a way to just link tasks between project plans instead of the brining in the all the project plan to one plan in a program level?
There are multiple ways to do this, if you are using Project server you can use deliverables like this post discusses.
If you don't want to use deliverables, you can link to a task in another project by typing in the full path to the task in the predecessor column. For local mpp files this looks like: full path to project\task id, for example C:\ProjectFiles\myproject.mpp\2. For server files this looks like:<>\project name\task id, for example <>\myproject\2.
I entered a list of deliverables into PWA but they are not showing up in my project plan when I go to Collaborate --> Manage Deliverables. I tried creating a deliverable from within project and it shows up in PWA but it does not seem to be working the other way around. Any ideas why?
This is very strange functionality.
Firstly, if a task is late in reality, not updating the schedule does not "unlate" it. If I am dependent on something I want to know about it's delivery. If I'm working a critical path method (that MSP supports) I do not expect the date of the deliverable to change if on the project or programme CP. If I use critical chain I expect the date to change, but within a control limit. Either way, I need to know so I can choose to take action or not.
Secondly you have to update something twice!! "Loose coupling" appears to be a kind (trendy?) way of describing it - "not coupled" would be more accurate as there appears to be no way to update a task date in the schedule (project proffessional or PWA) and then accept the changes in the corresponding share point list. The sharepoint list has to be manually updated. This would constitute a "waste" in any reasonable process.
Firstly, if a task is late in reality, not updating the schedule does not "unlate" it. If I am dependent on something I want to know about it's delivery. If I'm working a critical path method (that MSP supports) if the date of the deliverable is on the project or programme CP a change to the task makes the project late - critical info. If I use critical chain I expect the date to change, but within a control limit. Either way, I need to know so I can choose to take action or not.
I agree totally with Paul.
I had hoped to use the Deliverable feature as a means of communicating to Stakeholders the status on these tasks. Having to manually update the Deliverables has become so tedious that I've stopped using them. Instead of using the Deliverable feature; I've just added an enterprise field called "Deliverable" to Project Server, tagged the Deliverables in the schedule and then filtered for them in a view that is displayed on the SharePoint Team site.
I see no use for linking Deliverables if they don't update. If I wanted a Deliverable that did not update (which I often do), I would simply enter it into SharePoint and not link it.
I get the feeling that this feature was given the same amount of planning as was given the Status Report feature - little.
What permissions are required in Project Server 2007 to allow project managers to define deliverables. When they try to use the function they get access denied. They are already set up with all permission under project except manage lists.