Core Principle: Thinking Project first, Function second.
Break down functional jargon to clarify actual contribution to project
When a deliverable is described as just a product, e.g. ‘Concept Note’, ‘Scope document’, it is terms of the function’s jargon and doesn’t have enough detail to clarify the contribution to the project.
EG1: A high level catch-all term like “Concept Note” was translated to contribution to projects in the following way:
i) It was found that the first contribution of the function is to clarify and map what user outcomes they are expected to make happen. Mapping user outcomes requires researching current user concerns, current solution models and their strengths & limitations, leading to envisioning of a desired user end-state. User outcomes flow from this proposed end-state.
This is an important contribution because, without clarifying the user outcome, the product/ service is likely to be incremental, and not be break-through enough to deliver significant enhancement in value terms.
ii) Following this, the function will create a Solution Concept that meets those user outcomes.
This is an example of how a high level idea of a ‘concept note’ was clarified in terms of the contribution to the project as i) Solution Map of user outcomes; ii) Solution concept that meets the identified user outcomes.
EG2: Translating a high level term such as ‘Scoping’ or ‘Scope document’ into a contribution.
Just the word ‘Scope document’ can be interpreted differently by different people down the line. The goal is to define deliverables in a way that everyone in the system knows what is expected of them. ‘Scope Document’ was then translated as ‘Identifying facilities & equipment required to achieve the above solution concept’.
EG3: Technical Recommendation (TR) is the product, while Vendor and Tender appraisal is the actual contribution to project (stripped of the jargon of the product name)
Separating handshake with the project from internal “kitchen activities”
Analog: When you go to a dealership and buy a washing machine, as a customer you only want to know i) where to select the item, ii) where to pay the money, and iii) whether they will deliver it and set it up at my home. The rest of the activities are blind to you as a customer.
In order to deliver to the customer, 85% of the dealer activities may be below the iceberg – these need not be visible to the customer.
This approach simplifies the project person’s expectations of you and it simplifies the function’s life, because the function knows what to deliver to a project. The rest is internal.
EG1: Is Value Engineering a deliverable of the Product Engineering Group? It was found that value engineering, i.e. ensuring design is fit for purpose, was part of their internal thinking when they deliver the basic engineering to the project.
EG2:Classifying TGS’ deliverables: TGS has several internal activities such as Capacity planning, Capability(Machine and Resources), Manufacturing Strategy, Resources Planning (Men and Machine), Internal Make vs. Buy decisions, Procurement and Contract Planning, Long lead items ordering, Logistics Planning, etc.
However, from a projects point of view, TGS needs to deliver to specification, quality, time and cost. In a sense, TGS and construction are playing similar roles. Finally, only 4 deliverables were identified for TGS:
| Visioning | Specification | Build | Hand over |
| Commitment to cost, time, specification (quality) | Delivery Plan | Delivered to KPI’s | Troubleshooting -on demand |
All deliverables, therefore, are to be mapped from the project’s point of view, for all functions.
Three levels of hierarchy in the deliverables were identified:
L1: Where the function provides inputs only on-demand. (on-demand deliverable)
L2: Where the function provides a product/deliverable and walks away;(specification based deliverables)
L3: Where the function owns the outcome end-to-end; (outcome-based deliverable)
EG:In the case of Product Design – providing product concept based on user outcomes, technical know-how to commissioning engineers, As-built drawings, etc. are outcome-based deliverables (L3), while troubleshooting and change management in the build phase, are on-demand deliverables (L1).
Role Flexibility: Clarifying what is in the scope of a function’s role towards a project and what is not (several times one person may be playing several roles)
A person may be playing a sigma of 2-3 roles – e.g. a person may be in Process engineering and an Engineering manager. However the separation of each role is important.
E&P would like to ensure IL4 and below, they should be playing only 1 role and not a sigma of roles.
Defining outcomes based on project-enabling role rather than process or activities
EG: In the case of Planning, Variance Analysis is the process, while real-time decision support is the project-enabling outcome.