Breaking down large construction projects into smaller projects for better management
John AyersAuthor, writer and consultant| Self EmployedLakeville, Ma, United States
Most large construction projects perform poorly because they are so big. It is well accepted I think that managing a small project is much easier to have a successful project. As a result I propose breaking a large construction project into smaller projects by structuring the WBS to reflect this idea. A project can be one element of the WBS with it's own WBS,WP, IMS, and manager. Earned value then can be to each small project . I think it is feasible and will improve the success rate of large construction projects.
This is an interesting insight that refers to the concept of Program management, that groups related projects which have a connection between them. Saving Changes...
Jorge EscotoDirector of PM/PMO| CET Professionals ServicesSan Pedro Sula, Cortes, Honduras
Totally agree. I have also "split" large construction projects by discipline: civil, electric, mechanical, water treatment, etc. And then by sub-projects, metallic structure, walls, floors, roofs. Electrical substations, illumination. etc. To decide how to do this, it will help to understand if you will manage one contractor, o several subcontractors, timings, etc. We can call them programs and projects, or just project and sub-projects. The concept is the same. Saving Changes...
That is similar to how large aerospace projects are managed. The technical details of how that's done depend a lot on the business systems used to manage scheduling, cost, work statements, etc. My role has often been focused on technical integration, which is where we figure out the details necessary to make the planning fit the tools. Saving Changes...
And in such cases, rolling wave planning would be done by detailing out the specific WBS branches that needed to be refined for near term work vs. those which could be safely decomposed at a later date. Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
Isn't this the normal strategy for the projects? In my mind a task is a sub-sub-project - has a need for resources, a deliverable, a beginning and an end.
The sub-project (collection of related tasks or sub-sub-projects) can be organized by phase, location, discipline, contract - whatever is logical and manageable.
One has to be careful with the dependencies and make sure the sub-projects are integrated so as to allow for resource planning and overall tracking.
I don't believe that large projects fail because they are large - they fail for a number of reasons from poor definition, poor planning and poor implementation. Large government projects fail mostly due to political interference. Saving Changes...
Creo que depende del tipo de proyecto se puede realizar dicha actividad de dividirlo para hacerlo más fácil de administrar, pero en algunos países es mal visto que se haga el proceso de administración de esa forma por la exposición a riesgos más altos, a poder perder el control o a volver más burocrático los mismos procesos... Requiere de muchos controles muy específicos y un mayor gasto en personal para la supervision de proveedores y Subcontratistas... No es imposible, ni un error, pero se debe verificar muy bien los riesgos y conocer muy bien sus límites y entornos... Saludos Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Yes, John,
breaking down larger projects is generally a good idea, not only in construction. You then automatically have a program and should apply PgM principles and mindset, which are quite different from projects.
On the other hand, you have to make sure that the interdependencies are managed on product and work sides, the whole system is integrated and individual projects are aligned to the program or strategy. And I found it is important to align communications and not let all the projects do that by themselves. Think about a system architecture which has to be build and maintained, beyond the architecture you might have in mind coming from construction.
Breaking down means that the individual PM might and need not be aware of the full picture, the overall purpose. The PM should focus on their specific project and system component. Note this counters the current discussion about projects delivering value, as components might not have apparent explicit value to clients. Not every system can be build incrementally.
Thomas
...
1 reply by Peter Rapin
Dec 18, 2021 3:58 PM
Peter Rapin
...
I think you can get around the "value to client" concept by properly defining the client In the case of a sub-project the client is the main project (not the ultimate client). Thus the value to the redefined client is delivering something that is of value to him, possibly allowing the main project (or another sub-project) to proceed to the next task.
This concept works great in the infrastructure delivery industry where each subcontract considers the prime contractor the client and in turn the prime sees the owner as the client - essentially follows the contracting hierarchy.
However, there is a danger that the lower levels of the hierarchy will not grasp the critical nature of some of their work I find it much more motivating when the players are aware of the real consequences of delivery failure rather than "because I told you so" or "its in your contract".
Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
Dec 17, 2021 2:10 PM
Replying to Thomas Walenta
...
Yes, John,
breaking down larger projects is generally a good idea, not only in construction. You then automatically have a program and should apply PgM principles and mindset, which are quite different from projects.
On the other hand, you have to make sure that the interdependencies are managed on product and work sides, the whole system is integrated and individual projects are aligned to the program or strategy. And I found it is important to align communications and not let all the projects do that by themselves. Think about a system architecture which has to be build and maintained, beyond the architecture you might have in mind coming from construction.
Breaking down means that the individual PM might and need not be aware of the full picture, the overall purpose. The PM should focus on their specific project and system component. Note this counters the current discussion about projects delivering value, as components might not have apparent explicit value to clients. Not every system can be build incrementally.
Thomas
I think you can get around the "value to client" concept by properly defining the client In the case of a sub-project the client is the main project (not the ultimate client). Thus the value to the redefined client is delivering something that is of value to him, possibly allowing the main project (or another sub-project) to proceed to the next task.
This concept works great in the infrastructure delivery industry where each subcontract considers the prime contractor the client and in turn the prime sees the owner as the client - essentially follows the contracting hierarchy.
However, there is a danger that the lower levels of the hierarchy will not grasp the critical nature of some of their work I find it much more motivating when the players are aware of the real consequences of delivery failure rather than "because I told you so" or "its in your contract".
...
1 reply by Thomas Walenta
Dec 19, 2021 6:55 AM
Thomas Walenta
...
Peter,
agree that projects can perceive their sponsors as clients and derive a value for this. As you say there is the risk that the overarching vision, purpose gets lost with projects. And creating this lower level perception creates complexity (more elements and relationship).
I prefer not bothering about benefits and value at all on project level. It needs a special mindset and capability to create value and even benefits (from which value flows), which is not taught to project managers. It is challenging enough to deliver a what even without knowing exactly why you are doing it.
Keep it simple for the cook on Columbus' ship - his task is to feed the crew and keep them healthy and happy.
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Decomposition is a tool for lot of things. When decomposing something you have to keep low coupling and high cohesion between components. I did what you stated mainly for programs including it in construction projects. Other key point is integration. Usually, to put it in a role, business analyst is the role that integrate everything from the point of view of the whole solution where project is a component and in this case program manager help the business analyst to integrate at project level. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Dec 18, 2021 3:58 PM
Replying to Peter Rapin
...
I think you can get around the "value to client" concept by properly defining the client In the case of a sub-project the client is the main project (not the ultimate client). Thus the value to the redefined client is delivering something that is of value to him, possibly allowing the main project (or another sub-project) to proceed to the next task.
This concept works great in the infrastructure delivery industry where each subcontract considers the prime contractor the client and in turn the prime sees the owner as the client - essentially follows the contracting hierarchy.
However, there is a danger that the lower levels of the hierarchy will not grasp the critical nature of some of their work I find it much more motivating when the players are aware of the real consequences of delivery failure rather than "because I told you so" or "its in your contract".
Peter,
agree that projects can perceive their sponsors as clients and derive a value for this. As you say there is the risk that the overarching vision, purpose gets lost with projects. And creating this lower level perception creates complexity (more elements and relationship).
I prefer not bothering about benefits and value at all on project level. It needs a special mindset and capability to create value and even benefits (from which value flows), which is not taught to project managers. It is challenging enough to deliver a what even without knowing exactly why you are doing it.
Keep it simple for the cook on Columbus' ship - his task is to feed the crew and keep them healthy and happy.
...
1 reply by Peter Rapin
Dec 19, 2021 2:25 PM
Peter Rapin
...
However, the cook needs to know that the captain/crew will get to the destination before he runs out of food. That's where trust and respect comes in but even the cook needs some encouraging signs or words to keep going.
As a project manager I always felt better having some knowledge of the final program objective. I would also provide periodic 'updates' to the team - here is where we are, this is where we are going. Some team members would appreciate these sessions others would prefer being told what they were specifically responsible for and not want the added burden of the "bigger picture". The updates also controlled, to some degree, the rumours which are bound to happen in just about any environment.
That's part of management, knowing what works for team and members.
