Greenshore
  • About Greenshore
  • Services
  • Project Portfolio
  • Clients
  • Contact
  • Blog
Home » management » Establishing Ownership of Deliverables
Dec30 0

Establishing Ownership of Deliverables

Posted by Rich Crowley in management, people, planning, Project Management

The fundamental elements of value that a project provides to its stakeholders are sometimes known as deliverables.   Attempting to articulate a project’s deliverables at the beginning of a project is a good way to define what the project sponsors are expecting to gain upon successful completion of the project.  Deliverables can range from the very complex (a large new software system) to the relatively simpler (a high level written assessment by a third party of an existing business process).

There are many ways to bring a deliverable to fruition which are often dependent on the type of project, the methodology being followed, the resources being used etc.  However, one of the key attributes of a project’s deliverables is who the owner is and what this ownership implies.

For anyone who has ever worked in a project environment, you’re probably familiar with the standard practice of identifying project stakeholders and their roles, accountabilities and responsibilities early in the project.   One of the things I like to do on projects I manage is to ensure that the list of project deliverables is tightly tied to the list of stakeholders.  At first glance, it seems this should be fairly straightforward since deliverables are usually pretty high level entities / descriptions and ownership usually falls to key senior project stakeholders.  However, in my experience, assigning ownership and getting consensus on what that ownership implies is sometimes no easy task.

One of the reasons assigning ownership is difficult is because quite often, the work required to produce the deliverable requires involvement from many people and often those people report through different areas of the organization than the deliverable owner does.  For example, consider a project where one of the deliverables is a large event such as a training event for a large group of people hosted by a line of business area.  The owner of this deliverable might be a senior manager in the line of business since it is that line of business that will benefit from the outcomes of the event.

However, the training event will likely involve a significant contribution from the trainers required and perhaps of some event planners who report to a corporate department.  The trainers and event planners, while not the owner of the deliverable, are critical to the deliverable being provided in a successful manner.  They may (reasonably) expect as their starting point some direction from the owner regarding the expected event experience, the budget, the type and depth of training content to be provided.   On the other hand, the owner may likewise (reasonably) expect these key contributors, being experts in their domain, to run with minimal guidance and in fact, to provide options or a proposal for the event that the owner can then consider and make decisions on.   After all, the owner doesn’t understand the subtleties of event planning and how venue selections can provide drastically different experiences or the intricacies of training a large group.

This is where things get very interesting and where a stakeholder ownership and accountabilities document can turn into an artifact of dubious value.  The key is to start with a clear and agreed upon list of deliverables.  The next step is to ensure that there is enough detailed discussion between the owner of the deliverable and those actually doing the work to deliver it to ensure they are both comfortable with what the other is providing.  The owner is accountable, the contributors are responsible.  A deliverable owner can claim they are being full accountable but not really be providing enough direction to help those who are responsible.  Likewise, a stakeholder with responsibilities on some tasks that contribute to the overall deliverable may simply want more direction / guidance than is reasonable.  You as the PM need use whatever techniques you have available to you to educate them and resolve such differences.

In my experience, once a deliverables list has been arrived at, with ownership documented, it is critical to have detailed discussions with the owner and those who will contribute to it in order to identify any lack of consensus, disagreements over resourcing, timing, approach, etc.   When such a disagreement is identified, use your normal PM skills to resolve and if you can’t, get this onto your list of project issues promptly so you can bring project oversight resources to bear on it since quite often, such disagreements are a function of the organization or management structure the project is operating under.  Accountability and responsibility are different beasts and getting them into a harmonious state for a given deliverable is sometimes a challenge.

 

Leave a Comment Cancel reply

You must be logged in to post a comment.

Categories

  • Agile (6)
  • Architecture (1)
  • art (2)
  • Big Data (1)
  • books (11)
  • Cars (1)
  • Change (9)
  • common sense (3)
  • Contracting (1)
  • Cool (1)
  • Design (5)
  • development (1)
  • emotions (3)
  • entrepreneurship (2)
  • google (1)
  • great quotes (2)
  • happiness (1)
  • innovation (3)
  • IT (8)
  • IT Architecture (3)
  • Knowledge Transfer (2)
  • leadership (3)
  • Lean (1)
  • links (1)
  • literature (1)
  • lyrics (1)
  • management (9)
  • Media (1)
  • Negotiating (1)
  • networks (1)
  • people (5)
  • Personal Improvement (8)
  • planning (5)
  • productivity (3)
  • Programming (1)
  • Project Management (23)
  • Projects (1)
  • psychology (3)
  • Requirements (5)
  • Risk (2)
  • scrum (2)
  • strategy (6)
  • struggle (1)
  • summer (1)
  • teams (5)
  • Test Automation (3)
  • thinking (5)
  • Training (2)
  • Travel (1)
  • waterfall (4)

Tag Cloud

Agile Architecture art Big Data books Cars Change common sense Contracting Cool Design development emotions entrepreneurship google great quotes happiness innovation IT IT Architecture Knowledge Transfer leadership Lean links management Media Negotiating people Personal Improvement planning productivity Programming Project Management Projects psychology Requirements Risk scrum strategy teams Test Automation thinking Training Travel waterfall

Recent Posts

  • Maslow’s Hammer, Digitized
  • What’s In Your Attic?
  • Secret Sauce Ingredients: Judgement, Experience and Confidence
  • To Fail or Not to Fail?
  • 7 Speeds of Fast

On Not Planning Too Far In Advance…

Here's a couple of lines from the movie Casablanca that should amuse planners everywhere:

Yvonne: Where were you last night?
Rick: That's so long ago, I don't remember.
Yvonne: Will I see you tonight?
Rick: I never make plans that far ahead.

What’s in a name?

The Green Shore is real and exists as a wild and rugged expanse of rock and evergreens on the shore of a central eastern Ontario lake.

From south western Ontario, it is the prize at the end of a journey that, regardless of how well planned, always provides a few wrinkles and surprises.

However, the journey proves worthwhile every time and as such, is a neat metaphor for our work here at this company.

Blogroll

  • Jim Estill's Blog
  • RallyDev Blog
  • Seth's Blog
  • Signal vs. Noise
  • Springwise
  • Tactical Project Management
  • The Critical Path

© 2011 Greenshore | Designed by Elegant Themes | Powered by WordPress