Managing Cross Project Dependencies with Deliverables

  • Article

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:

  1. Click File à Publish…

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

  3. 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:

  1. Click on Collaborate à Manage Deliverables:

  2. Click on Add Deliverable:

  3. 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:

  1. Click Collaborate à “Manage Dependencies on Deliverables”:

  2. Click “Add new dependency”:

  3. Select "Office Schedule" from the Drop Down

  4. 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:

https://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:

  1. Click Collaborate à “Manage Deliverables"

  2. Select the “Beta 1” Deliverable

  3. Click “Edit Deliverable”:


     

  4. 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:

  1. 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:

  2. 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.

Chris Boyd