Benefits Realization vs deliverables inside a Project Charter

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

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.

I think it boils down to clearly defining the objective. In job creation the objective is not the hole but the employment (or training, team building) of the resources. This is where a Charter may be important - it should not read "dig and fill the hole" but "utilize resources (or team building)".

Much like life itself - its the journey, not the final destination.

True Christopher, these terms mean mental concepts and it is a benefit (hic) if people collaborating share those concepts.

On the other hand, using standardized terms/concepts adds benefits regarding 1. knowing what others that defined the term learned already (and decrease own mistakes) and 2. being able to onboard new people quickly.

Thomas