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