04 Oct Deliverables

<budvar>

Moving back to the scenarios, I wanted to give a rounded overview of Deliverables.

Historical implementation of deliverables.

A deliverable is a tangible and measurable result, outcome, or item that must be produced to complete a project or part of a project. Typically, the project team and project stakeholders agree on project deliverables before the project begins  Examples of deliverables would be

• A set of training materials
• A prototype product
• An agreed statement of work

Quite often, a deliverable or set of deliverables are tied into specific project phases, and logically that is a sensible thing to do; however, there is no technical requirement for this.

Historically, we could always define deliverables within our project plan, we’d just call them milestones.  So for example, I could create a project plan to produce trainining materials, the last task of which is Training material Produced, which is a miletone.  Effectively this is our deliverable. 

There are at least three limitations to the above (historical) method of defining outputs. 

1. It is not very easy to see just the deliverables.  You need to create a custom task field and then create a filtered view. 
2. You need to have access to the project plan in order to view deliverables, so sharing the goals and status of the deliverables with team members, stakeholders etc isn’t that easy. 
3. If you are trying to manage inter-project dependencies based upon deliverables, then a change in the schedule of one project plan will cause a scheduling shifts in other project plans – this is confusing to many project managers and it is time consuming to investigate.

Microsoft’s implementation of deliverables.

Now, lets consider Microsoft’s implementation of deliverables.   Microsoft have utilised the WSS 3.0 infrastructure to hold the deliverables, and as such deliverables are published as a SharePoint list of committed dates.  So, you cannot create deliverables until the project is published, because it’s at the publishing stage that the option to create the WSS site appears. 

If we look at the three limitations defined above, we can see if they’ve managed to solve the historical limitations

1. A deliverable name field (and various other fields) are available in the table section of Project, so it’s very easy to create a view that shows any deliverables.  Also, though Microsoft don’t ship a pre-configured filter, it is very easy to create a filter called Tasks with deliverables that just shows those tasks that have a deliverable attached to them (I’ll show you how to do this later)
2. Deliverables are published as a SharePoint list of committed dates, so anyone with access to the Project Workspace can see the deliverables and dates.  They are displayed in the SharePoint Gantt view, so they appear in a familiar format
3. Other project managers can create a link to your deliverable, thereby modelling the inter-project dependencies, without causing any scheduling shifts between the project plans

So, given the above, deliverables appear to be a very useful little peice of functionality.

Creating a deliverable from within Project Professional

There are two ways to create a deliverable for a project, the first is to do this from within Project itself, the second is from the Project Workspace.  I’ll concentrate on doing this from Project.

Once a project is published click on the Collaborate | Manage Deliverables menu.  This opens a new Deliverables task bar…

From here, it is straight forward to create the deliverables for your project. 

If you link a deliverable to a task, then the deliverable inherits the task name, start and finish dates.  You can change these dates to reflect the committed deliverable dates (as opposed to the task dates).  This allows you to build some “slack” between your published deliverable dates and your internal scheduled dates for doing the work.  The deliverable is shown on the Gantt chart view, and an icon is displayed in the indicators column.

In the above screen shot, a deliverable has been created called Deliver training material to customer, with a deliverable start and finish date of 10/25/07.  The deliverable has been linked to the milestone task of Training material Produced.  Note that if the schedule slips, then the deliverable dates will not be effected.

From within the Project Workspace, the deliverables are displayed as a Gannt chart.  This view of the project deliverables would be the view that stakeholders, team members and other interested parties would see.  Note that in the screen shot below, the Deliver training material to customer deliverable is shown as a milestone, as it starts and finishes on the same day.

Creating and amending deliverables from within the PWA browser

As previously mentioned, it is possible to create a deliverable from within PWA.  This is useful if you have a role such as a client manager, or programme manager who is responsible to determining the deliverables that the project has to deliver, and wants to detail these on a Gantt type interface.  The project manager is then able to synchronise these deliverables with the project plan.  It’s an easy way for the programme manager to collect and detail the deliverables, but I think from a process perspective I wouldn’t want to rely soley on this.

To create a new deliverable, click on the New button and fill in the relevent information.  Within this UI the you can add a fuller description and, more importantly, attach a file to the deliverable.  The file could be an artifact such as a customer sign off or similiar.  Once created, deliverables can be amended using same UI. 

All the deliverables are displayed in the Gantt type view, but note, this is not a dynamic schedule, the Gantt view just happens to be one of the views available within WSS3.0, so EPM takes full advantage of it.

Red exclamation mark…

Deliverables are held both in WSS and in the project plan.  Project Professional checks for discrepencies between the project plan and WSS, and if it finds any, it flags these up, and begins to guide the user as to what to do. 

Essentially, it makes sense to have both the WSS and project plan deliverables synchronised, so after reviewing the differences between the WSS site and the project plan and making relevant adjustments, the project manager can select to accept all server changes.

Once this has been done, the deliverable is held within the project plan, but it is not linked to any tasks, and is not graphically displayed within the Gantt chart.  Editing the deliverable allows it to be linked to a task,  and once this is done, it is displayed in the Gantt chart. 

Deliverable fields & Filters

Each deliverable has the following fields associated with it, and they can be displayed in the table section of Project Professional.

• Deliverable Finish
• Deliverable GUID
• Deliverable Name
• Deliverable Start
• Deliverable Type – indicates whether a task is a deliverable (1), is a dependency on a deliverable task (2), or is neither (0).

The Deliverable Type field is useful because you can create filters and groups on the deliverable type.   To create a filter to see what deliverables the project is going to deliver, create a filter with the following values.

Applying the filter quickly shows us the tasks that had deliverables associated with them.

We can modify the filter to quickly identify those tasks that are due to finish after the deliverable is due to start, ie we are going to fail to deliver these committed deliverables.  Create a filter as per below.

Assuming our project plan changed, and re-working the CBT content took 3 weeks, the relevant area of the project plan would look as per below (note task

If we apply the “Tasks with late deliverables” filter, only task 10 (plus the summary task 1) will show.  This gives us the opportunity to focus quickly on those tasks that we have committed deliverables to but that we are going to be late on.

Dependencies on deliverables

So far we have concentrated on pure deliverables, but we can extend this, but creating a dependency on a deliverable, in short, this is a way to manage cross project links, and therefore to manage programmes.  A dependency creates a link from one project, to a deliverable to another project.  In our above example, I’ve got a project that registers delegates for our CBT, however, I cannot register them until I have uploaded the course material for our delegates perusal.  So, I create another project plan called Register candidates, and then create a dependency from that plan to the deliverable Training Material uploaded to website.   After I have saved the plan, I can select the option to Manage Dependencies on Deliverables

And then Add a new dependency

And link it to the relevant task

This External dependency is a type 2 dependency (see dependency type above), and is represented in the Gantt chart as differently to the internal (type 1) dependency.  The default colour is yellow as shown below.

Again, we could create a filter that shows which dependencies are going to cause us issues within the project plan.

Reporting

Deliverables are available within the OLAP cube, so for each Project/Programme etc you can see the number of deliverables.  It is all relatively easy to see so I’m not going to attach any screen shots from the OLAP cube.   This is good from an analytical point of view, but it’s not much good if you actually want to see a description of the dependency etc.  Unfortunately, there is nothing out of the box that gives this descriptive information, so SQL Reporting Services becomes your friend here.  Fortunatley, the Project Server SRS Reporting Pack gives a solid example of deliverables reporting (project give and get) so it is worth downloading it from http://blogs.msdn.com/project/archive/2007/01/30/sql-server-reporting-services-report-pack-for-project-server-2007.aspx.  Again, it’s relatively simple once the reports are up and running, so I’m not going to attach any screen shots here (they are available as part of the Reporting Pack anyway).

Limitations

There are pobably a few more limitations in addition to the ones below, if you can think of any, let me know.

• If you link deliverables to a task (and I think this is a good idea), then you are limited to one deliverable per task
• Deliverables are stored as a WSS3.0 list and therefore can only be created once a project is published
• You cannot create dependencies on a deliverable between tasks within a master project, so in order to use dependencies on a deliverable within a programme, open the individual project file, rather than trying to do it within a master project.

Links

Chris Boyd’s Project Programmability blog on deliverables – http://blogs.msdn.com/project_programmability/archive/2007/02/19/working-with-deliverables.aspx

Credits

Trebb Gate & Chris Boyd; plus others I will have forgotten so please accept my apologies.

Thanks –

any enjoy….  Ben.