There are several ways of breaking down a project into components:
- From a construction point of view, zones of a project can be seen in terms of geographical areas that are being constructed.
- From a process plant point of view, zones can be seen in terms of: Coke Oven > Blast Furnace > Steel Making etc. getting built.
- Also, from a physical completion point of view, there are 6 layers of a project build (linear or non-linear): i) civil, ii) structural, iii) mechanical, iv) piping, v) electrics, vi) instrumentation & control, after which commissioning is done. For every project, the 6 jobs have to be done, but the sequence of the 6 jobs will vary.
Given that there can be so many varied ways of looking at a project unit, it was felt that a consistent understanding of a unit of a project needs to be defined.
In this light, a “modular view” of the project was explored.
Such a view has advantages. E.g. in Automobile Manufacturing, a breakthrough took place when they started looking at manufacturing in terms of modular assemblies, rather than pieces. It was felt that a similar modular view of the project, where each module is a complete whole, could lead to greater clarity and distributed ownership.
The search for a modular view led to a “sub-system” cut of the project:
E.g. in TSK, there is the Blast Furnace, Pellet Plant, CRM, Power Distribution System (PDS), Utility & Water System, Material Handling System, etc. are “sub systems” inside the plant. These sub systems are standalone “wholes” in the plant, and not just geographies.
These sub-systems may go across geography of a plant like in the case of PDS.
Within a blast furnace, there are further sub systems, and so on. These are whole modules in a plant at different levels.
Therefore, it was felt that sub-systems can be defined the unit around which teams build. These whole sub-systems then lead to the whole system getting built.
With this “modular view” of the plant in terms of sub systems, the new unit of build was defined as a “Deliverable Unit” (also in line with the deliverables for functions) –
- A DU is a whole system or sub-system of a project
- Each DU is a whole, self-contained, value-creating unit
- A DU can be uniquely identified through 4 co-ordinates: DU = f (geography, plant, sub-system, cluster of services)
Therefore, each deliverable unit is a complete system – which means it should be ready to use. Therefore, instead of seeing project progress as doing parts of a thing and they don’t come together, each unit is completed wholly, so that it becomes valuable by itself.
A project can be seen as a nested structure of DUs.
One level DU has many DUs inside it & each of those DUs has further DUs inside it, & so on. An example of the nested structure in TSK:
The higher level of DU will be accountable for the interface between DUs one level below. In this way, each DU is aligned to a higher DU, which finally leads to the project being delivered.
Implications of DU as a unit of thinking
- Measurement: This view of a project as sub-systems, shifts the thinking pattern from process thinking to outcome thinking – because no team is performing activities, each team is delivering complete, working wholes.
- Individual fulfillment: It also gives teams the meaning & satisfaction of producing something complete, rather than parts.
- Resource utilization: Building around DU is the most optimal way of using resources, because usable units are getting built at all times rather than lots of half-done components.
Also, it may be more optimal to get partners to do turn-key at that level, rather than ask them to do parts.
- Role of Functions: For Functions, it means they are organized around deliverables for DUs. Further, the only milestones are around DUs. Functional Milestones cease to exist. E.g. a Civil milestone is complete not when they finish their work or a cubic meter target, but when the DU is complete.
- Planning: The unit of planning is a DU. At an E&P level, if one DU is off track by 30 days. The cascaded impact of this should be seen and those resources which are available should be reallocated in the system.
- Moving to “Zones of Ownership” – All teams, at all levels are owners of delivery units, only the size of delivery units change. It is shifting from a hierarchy – delegation downward, to co-ownership.
The nested system of DUs is also shifting from a hierarchy to zones of ownership – the responsibility structure of the organization. Therefore an IL4 could take up more responsibility compared to an IL3. It is not the hierarchy but the zone of ownership.