Managing Cross Project Dependencies with Deliverables

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:

Click File à Publish…

On the “Publish Project” dialog make sure the “Create a workspace for this project is selected”:

Click Publish

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:

Click on Collaborate à Manage Deliverables:

Click on Add Deliverable:

First, Select the task you want to link to the Deliverable, then click on “Link to selected task” and click done:

Note: The PM can change the start and finish dates for the deliverables without affecting the dates for the tasks. The deliverable name and dates are loosely coupled with the task name and dates. This allows the PM to publish different names and dates from what is in their project plan giving them greater control.

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:

Click Collaborate à“Manage Dependencies on Deliverables”:

Click “Add new dependency”:

Select “Office Schedule” from the Drop Down

Select the task to link the dependency to, click on the deliverable, check the “Link to selected task” and click done:

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:

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:

Click Collaborate à“Manage Deliverables”

Select the “Beta 1” Deliverable

Click “Edit Deliverable”:

Change the finish date to 3/30/2007 and click Done

Now go to the Excel team Project to see how this change has affected the dependency:

Click Collaborate à“Manage Dependencies on Deliverable”:

The red exclamation mark indicates to the PM that the deliverable has change. If you hold your mouse over the dependency the follow information windows will pop up showing in red what has changed:

Click on the drop down arrow and click “Accept Change from Server”

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.

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.

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 projecttask id, for example C:ProjectFilesmyproject.mpp2. For server files this looks like:<>project nametask id, for example <>myproject2.

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?

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.

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.

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.

I wanted to know how can we define whuch projects the user can see when he is trying to connect depndency to his Project. currently I saw a user can see all projects with Deliverables which he has Read-Write or Read only permission.

I want to know how we can hide "old projects" that i don’t won’t other users to see theire deliverables in the "Add dependency" window.

I want to know how i can define the projects that will be showen to the users (how i can define "old projects that although the users has permission to the projects & the projects have deliverables, still they won’t appear in the project list that open for the user when he wants to connect dependency

In my project plan, I have created dependecies on deliverables of another project. When the deliverable on which I am dependent changes, is it possible to get an automated alert sent (of couse I could set up alerts on the Deliverable list directly, but looking for ways to get an auto notification to all project managers that are dependent on that deliverbale.

Secondly, is it possible to include another field in the deliverable list – say % complete – that can be updated in the SharePoint list and will appear as changed (similar to end date example above) the next time I open the project plan which has this deliverable listed as a dependency?

This is exactly how deliverables and dependencies work in Project Server 2007 but is there any difference in Project Server 2010 do you know?

In answer to someones questions if the Manage Dependencies function is greyed out it is because the project has not been published and it is not possible to create the deliverables in the project workspace if you want them to show on the project plan, you will need to do it via the Manage Delvierables in the Project plan.