Potential levers for “capacity to deliver”

  1. Reusable Components: One lever is to have some parts which are standardized DU components which can be reused across DUs. A component can be uniquely crafted by the person for the first time, but if it has been done in the past, we can create an IP package around it. Once an IP package is created, the quality of the person needed for that job can be brought down, and a less competent person can deliver using the IP package. This means we have to break down projects into reusable components. The value creation of the group goes up 10-fold.

Each time an “Able to deliver” has been done in the past, a DU package gets created around it. Once a DU package is ready, it can be reused the next time it is needed in the system.

Also, there are unique and global packages. Unique packages are those which are unique to the project and cannot be reused. While global packages can be used across projects – e.g. valves, cooling tower, etc. When we made a global package – effort came down by 70% and cost came down by 30%.

  1. Agile ecosystem of partners: While one has to go through strong processes, it is also necessary to have an agile ecosystem of partners who can be rapidly responsive to changing project requirements. The agile ecosystem is also ideally around a DU – who can deliver DU turnkey.
  2. Need for Project Delivery Owners
    • On one side, there is functional expertise (mechanical, civil, etc.) On the other side, there is business domain expertise (like Pellet plant, etc.). But there is a middle zone which is project delivery where capability to deliver is needed.
    • Capability to deliver is the ability to link up functional expertise and business domain expertise into a product. This is what projects are committing to.

E.g. If a person involved in the Build Phase moves from Blast Furnace to Pellet, the domain changes, but the ability to deliver the “build phase” in time is the project competency which is in the middle zone. It is not an expertise alone, or a domain alone. It is the ability to translate expertise into deliverables, on the ground in the committed timelines and cost. This is the project expertise space of E&P. 

  • We have lot of people who can “do” things, and people who can lead, but the middle layer who can take ownership of product/ service deliverables is the layer we want to build. This middle level is needed to take on commitments.
  • E.g. HR is organized by its functions, not project functions. When they come into projects, they still have a HR function orientation and don’t know how to deliver. This is what we have to figure out across functions.

Clarify your doubts & questions about the model with the Implementation Team: Post your question