We have an existing Project charter with a section on Benefits to be realized. However, I'm struggling with what content should go in this section of the charter.
Deliverables or Outcomes?
for example: if the project was to paint 12 buses blue, then, the deliverable would be 12 blue buses. However, the business told us the "benefit" would be 10% happier people with blue buses.
based upon the above...what goes into the benefits section?
(10% happier people I assume.).
if so, what section would the deliverables belong to?
I'm tripping up on where to place deliverables vs benefits inside a charter.
There are a lot, and they don't all treat deliverables the same. You can include them in the project description or create a section just for deliverables. Depending upon the project and number of deliverables, I might include them with project milestones.
With regards to the benefits section, you might include (estimated) benefits milestones, when they will be measured, how they will be measured, and how long they will be measured. For example, if the product/service you are delivering has a 2 year ROI with measurable outcomes at set periods within those 2 years, include what you can in the charter. I say "what you can" because you might not know these details at the beginning of the project. Saving Changes...
Project Charter must include only major deliverables description. The difference is that while deliverables are products or services that are going to be developed, benefits are positive results that affect the enterprise or community where the project is performed. Saving Changes...
Think of the deliverables as the "what" and benefits/outcome as the "why". The why generally precedes that what, because it is the rationale for chartering the project. It is the difference between designing a solution to fit a problem, and starting with a solution in mind, and trying to define the problem to make the solution a good fit.
If your objective (why) is to improve efficiency, the deliverables (what) are the project output/product that enables efficiency. How well the product fits the problem (KPIs) are metrics to evaluate how well the deliverables address the underlying objective. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Allen,
good question.
How did that section get into the project charter? Traditionally, benefits are not identified, analysed and planned for by the project manager but are created by a program manager or sponsor by the means of a pre-project (also called front-loading). Often, you can rely on a business case which will identify expected benefits and then you can copy-paste these in the charter section.
No, deliverables or the project product do not represent benefits. Outcomes also are not benefits, outcomes are enabled by deliverables, but can mean different things to different stakeholders. Benefits or dis-benefits are perceived by stakeholder groups.
Think a new SW system as deliverable, think the users being able to use the SW effectively as outcome, think the layed-off employees as receiving disbenefits and the management as receiving costdown as benefits.
Despite a current hype to ask project managers to deliver benefits, I do not think they are enabled, nor have the organizational role and influence to do so.
In your project, even if you fill out the section of expected benefits, what are you doing about them? Heard of benefits realisation, tracking, measurement etc.?
The only PMI foundational standard containing information about how to define and deliver benefits is the program mgmt standard, and the PgMP certification.
So, again, how did that section turn up in the project charter?
In the absence of a business case (used to justify the project's existence or as part of an intake process), the charter could include benefits. These should focus on the (hopefully measurable) outcomes expected from the project's completion. Normally, a charter would also provide some high-level understanding of "what's in" and "what's out" - the deliverables could be listed there.
Kiron Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
All projects are subject to changes, some of which may threaten the initial project justification. I think the Charter should identify the benefits (the 'why'). Not such that the PM should question or revisit the benefits but to ensure that proposed changes (to the 'what') do not unintentionally adversely impact those benefits. Sometimes we get so focused on what we are doing we forget why we are doing it. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
The project will not deliver benefits. The product/service/result created by the project will deliver benefits. Product/service/results plus project is equal to solution. Because of that, benefits are not stated into the project charter. Benefits are stated inside the business case because is the place where the solution is defined at high level. How the project contribute to the solution benefits? Because the project will deliver the product/service/result as defined (scope), in the needed time (time), at the stated cost (cost) and mainly with the defined quality. All this stuff has been highly debated when I was part of the team that created the PMI´s benefit realization practice guide. Just a personal comment: if you do not put this clear then you are lost. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Fully agree, Sergio.
The why can be described by benefits, but for most projects it is just a verbal unmeasurable justification (we want to reach India - to exploit it - by sailing westwards). So yes, each project charter should have a justification section but rarely does it include manageable benefits.
Not all projects understand the expected benefits, and sometimes they are even hidden from projects (e.g. in contractual situations, if employees are negatively impacted, in competitive environments, in warfare). Knowing about expected benefits in some cases may distract the project from its scope.
I'm sensing an area of disagreement where people are using some different terms to describe the same thing.
First however I will disagree with Sergio that only products deliver benefits. That is strategically short sighted in my honest opinion. Sometimes the product is simply a vehicle to achieve a larger goal. Projects may be launched with a negative business case for reasons such as: We can generate enough cash flow that we don't have to furlough employees or we can develop employee talent or production capabilities. Developing organizational assets is a value difficult to quantify in a business case.
As for stating the benefits, rationale, justification, pick your term...if you can't state why you are launching a project, there is no sense in it. If people making decisions do not understand the benefits, they may never realize them because they focus on other thinks immaterial to the reason the project was authorized. Whether that goes in a charter may be debatable, however you can find dozens of templates where the authorizing body believes the reason should be stated in addition to the deliverables.
Returning to the OP's actual question about the sections of the charter...it depends. Information can be grouped in many ways under various headings. The benefit "improved customer satisfaction", could be in a section such as "Objectives". Deliverables could be in their own section, a section such as Scope or Objectives also (12 buses painted), or left out entirely in some cases. PMI may have their preferred way of organizing things, but not everyone agrees with their preferences.
If you are developing a greenfield solution to a cutting edge technology problem, defining the solution constrains the developers. Instead the deliverable is whatever product best fits the customer and performing organization R&Os, where the solution approach is left to the design team.
...
1 reply by Sergio Luis Conte
Jan 11, 2022 12:46 PM
Sergio Luis Conte
...
@Keith. "The thing" to be created by the project will deliver benefits. Call it product, or service, or result if we talked according to the PMI. The project is just a mean to create "the thing". "The thing" is created to achieve a goal. If not, it has no sense. And goals are created according to a basic strategy: survive, growth and develop. Organizations do not achieve the goal thanks the project (the process to create "the thing"). Organizations achieve the objectives thanks "the thing" the project creates, that could be a product, a service or a result. What the project "can do" is to assure the needed quality (which involves scope, cost, time and other things) to create "the thing" as defined according to the goal to be reach. In the examples you stated somebody (usually the business analyst) must help the organization to define "the thing" to be created by the project to achieve the goal. The project will be a mean only. That is because when the project ends must be a continue monitoring of the delivered product/service/result to understand if the benefits are reached as stated (usually inside the business case) and, if not, a decision must be taken about the delivered product/service/result and a new project is usually started to do something with it. This is an activity that belongs to business analysis too.
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Jan 11, 2022 11:30 AM
Replying to Keith Novak
...
I'm sensing an area of disagreement where people are using some different terms to describe the same thing.
First however I will disagree with Sergio that only products deliver benefits. That is strategically short sighted in my honest opinion. Sometimes the product is simply a vehicle to achieve a larger goal. Projects may be launched with a negative business case for reasons such as: We can generate enough cash flow that we don't have to furlough employees or we can develop employee talent or production capabilities. Developing organizational assets is a value difficult to quantify in a business case.
As for stating the benefits, rationale, justification, pick your term...if you can't state why you are launching a project, there is no sense in it. If people making decisions do not understand the benefits, they may never realize them because they focus on other thinks immaterial to the reason the project was authorized. Whether that goes in a charter may be debatable, however you can find dozens of templates where the authorizing body believes the reason should be stated in addition to the deliverables.
Returning to the OP's actual question about the sections of the charter...it depends. Information can be grouped in many ways under various headings. The benefit "improved customer satisfaction", could be in a section such as "Objectives". Deliverables could be in their own section, a section such as Scope or Objectives also (12 buses painted), or left out entirely in some cases. PMI may have their preferred way of organizing things, but not everyone agrees with their preferences.
If you are developing a greenfield solution to a cutting edge technology problem, defining the solution constrains the developers. Instead the deliverable is whatever product best fits the customer and performing organization R&Os, where the solution approach is left to the design team.
@Keith. "The thing" to be created by the project will deliver benefits. Call it product, or service, or result if we talked according to the PMI. The project is just a mean to create "the thing". "The thing" is created to achieve a goal. If not, it has no sense. And goals are created according to a basic strategy: survive, growth and develop. Organizations do not achieve the goal thanks the project (the process to create "the thing"). Organizations achieve the objectives thanks "the thing" the project creates, that could be a product, a service or a result. What the project "can do" is to assure the needed quality (which involves scope, cost, time and other things) to create "the thing" as defined according to the goal to be reach. In the examples you stated somebody (usually the business analyst) must help the organization to define "the thing" to be created by the project to achieve the goal. The project will be a mean only. That is because when the project ends must be a continue monitoring of the delivered product/service/result to understand if the benefits are reached as stated (usually inside the business case) and, if not, a decision must be taken about the delivered product/service/result and a new project is usually started to do something with it. This is an activity that belongs to business analysis too.
...
1 reply by Keith Novak
Jan 15, 2022 12:52 PM
Keith Novak
...
I understand what you are saying, however I think that the thing being created is not always the end goal, so much as the process to develop the thing. Some projects are really job creation programs or other business growth/sustainability measures such as utilizing otherwise idle capital equipment. The operational value of the thing actually produced is less important than the organizational benefits.
It is really the difference between whether you consider the thing being produced, the system design or the system architecture. The architecture level involves not only the operational environment of the system produced and how much value the thing provides to the end customer, but also the business environment and how well the project execution fits the organization's needs.
If the product/thing is really the system architecture and not the actual system itself, then it includes the development process and therefore the value of the thing is to maintain critical staffing levels.
Even to use the iconic military example of a project to dig a hole and then fill it back up can have organizational value. There is team building involved, practice doing something that may be useful later, and human/capital resources are not sitting idle where they are likely to face downsizing.
The filled in hole was never the objective. The hole has negative NPV and no use to anyone as a physical thing. At a strategic level however, it may be better long-term than the do nothing option. Staffing and assets were preserved until needed for something with a positive business case at the system level.
As they say, sometimes the journey is more important than the destination.
Community Champion
