Work Breakdown Structure in Construction Management - Revision history

Tkokotas at 17:49, 16 November 2018

2018-11-16T17:49:03Z

← Older revision		Revision as of 17:49, 16 November 2018
Line 1:		Line 1:
			''Developed by Kasper Løwe Olsen''


	Ever since the Work Breakdown Structure (WBS) was first introduced to Project Management by NASA <ref name=''Nasa''> ''Fleming, Jon F., and Kenneth W. Poole. “NASA Work Breakdown Structure (WBS) Handbook.” (2016)'' </ref>, it has been used in many different fields of engineering. The work breakdown structure is found to be a very useful tool as projects grow more and more advanced and with increased complexity. Projects with huge budgets such as with the Apollo space program, having multiple tasks needed to be complete in order to send humans to the moon, requires a lot of management through the whole life-cycle of these project. Time has shown over and over again, that having a poorly planned project the effects can be very severe and end up as a direct impact of the success of a project. For this exact problem a model that provides the project manager the tool to handle and plan a project is needed, and this is where the work breakdown structure come in handy. Not many projects in the field of civil engineering comes close to the innovative and complexity of the Apollo space program. However, they grow more and more complex and the work breakdown structure is therefore very useful in construction management. The work breakdown structure takes the scope of the project and make it into smaller manageable chunks which frames the project and all its tasks. Doing this, an overview of cost, time and risks is a lot easier to establish and manage.		Ever since the Work Breakdown Structure (WBS) was first introduced to Project Management by NASA <ref name=''Nasa''> ''Fleming, Jon F., and Kenneth W. Poole. “NASA Work Breakdown Structure (WBS) Handbook.” (2016)'' </ref>, it has been used in many different fields of engineering. The work breakdown structure is found to be a very useful tool as projects grow more and more advanced and with increased complexity. Projects with huge budgets such as with the Apollo space program, having multiple tasks needed to be complete in order to send humans to the moon, requires a lot of management through the whole life-cycle of these project. Time has shown over and over again, that having a poorly planned project the effects can be very severe and end up as a direct impact of the success of a project. For this exact problem a model that provides the project manager the tool to handle and plan a project is needed, and this is where the work breakdown structure come in handy. Not many projects in the field of civil engineering comes close to the innovative and complexity of the Apollo space program. However, they grow more and more complex and the work breakdown structure is therefore very useful in construction management. The work breakdown structure takes the scope of the project and make it into smaller manageable chunks which frames the project and all its tasks. Doing this, an overview of cost, time and risks is a lot easier to establish and manage.

Kasperloewe: /* Annotated bibliography */

2018-02-28T18:14:20Z

Annotated bibliography

← Older revision		Revision as of 18:14, 28 February 2018
Line 67:		Line 67:
	''NASA Work Breakdown Structure (WBS), Handbook (2010)''		''NASA Work Breakdown Structure (WBS), Handbook (2010)''

	As NASA were the first to develop the concept of a work breakdown structure, their have a great deal of experience is working out one. Therefor a very useful article regarding ~~WBS~~.		As NASA were the first to develop the concept of a work breakdown structure, their have a great deal of experience is working out one. Therefor a very useful article regarding work breakdown structure.

	''Managing successful projects with PRINCE2, 2009.''		''Managing successful projects with PRINCE2, 2009.''

Kasperloewe: /* Limitations of the tool */

2018-02-28T18:13:37Z

Limitations of the tool

← Older revision		Revision as of 18:13, 28 February 2018
Line 58:		Line 58:
	Any model used in project management comes with limitations, where a work breakdown structure is no excuse. A number of things can go wrong during a project to destroy the work breakdown structure, or there could simple be a lack of input, so a project manager cannot create one. The input required to construct a work breakdown structure is shown in Figure 1.		Any model used in project management comes with limitations, where a work breakdown structure is no excuse. A number of things can go wrong during a project to destroy the work breakdown structure, or there could simple be a lack of input, so a project manager cannot create one. The input required to construct a work breakdown structure is shown in Figure 1.

	Another one of the worst things that can happen to a work breakdown structure, is [[scope creep]]. Scope creep is when the scope of a project changes, resulting in a change of activities/deliverables. As an example, this could be the new metro line decides once the project plans and budgets are complete, that they want to add an extra station, perhaps make 4 tunnels instead of 2 or maybe even make half the metro run above ground. This makes the original work breakdown more or less useless as it will now require numerous of new activities to achieve the final goal.		Another one of the worst things that can happen to a work breakdown structure, is scope creep. Scope creep is when the scope of a project changes, resulting in a change of activities/deliverables. As an example, this could be the new metro line decides once the project plans and budgets are complete, that they want to add an extra station, perhaps make 4 tunnels instead of 2 or maybe even make half the metro run above ground. This makes the original work breakdown more or less useless as it will now require numerous of new activities to achieve the final goal.

	It is also important to realize that the model cannot be used as a schedule on its own. The work breakdown structure does not ~~give~~ any information regarding the interdependency of each tasks of a project. This meaning that many of the tasks for each activity may involve other tasks, and some must be done in a specific order. This being said, the model is a very useful tool when making the project schedule as all the tasks are already outlined.		It is also important to realize that the model cannot be used as a schedule on its own. The work breakdown structure does not provide any information regarding the interdependency of each tasks of a project. This meaning that many of the tasks for each activity may involve other tasks, and some must be done in a specific order. This being said, the model is a very useful tool when making the project schedule as all the tasks are already outlined.
	As tried in the section [[Estimating cost and identify risks]] putting a cost to a risk might prove useful when doing a budget with a work breakdown structure but this does not include the unknown unknowns. With this meaning the risks no one expected or even knew could happen during a project.		As tried in the section Estimating cost and identify risks putting a cost to a risk might prove useful when doing a budget with a work breakdown structure but this does not include the unknown unknowns. With this meaning the risks no one expected or even knew could happen during a project. These are impossible/extremely difficult to take into consideration of any projects.

	== Annotated bibliography ==		== Annotated bibliography ==

Kasperloewe: /* Estimating cost and identify risks */

2018-02-28T18:12:42Z

Estimating cost and identify risks

← Older revision		Revision as of 18:12, 28 February 2018
Line 46:		Line 46:
	== Estimating cost and identify risks ==		== Estimating cost and identify risks ==

	Having the project broken into manageable chunks, each task is then associated with time, resources, cost and risks/opportunities. Each is very important to evaluate and ~~estimate~~ as a part of a work breakdown structure, as they can determine the success of a project. The definition of a ~~projects~~ success is a whole field of itself in project management and will not be covered further in this article. However, having made a wrong estimation of time causes delays, which means higher cost. PRINCE2 suggests a great number of techniques useful when doing estimations of projects. As an example of one of these techniques, PRINCE2 suggests using the so-called bottom-up estimation. This method does as the name hence, sum all the cost/time from the bottom and up. Each ~~tasks~~ can also have a risk or opportunity added as a number of cost for each. For the sake of simplicity, a cost of a risk could be ~~labeled~~ with red and an opportunity green. These are obviously difficult to take into the calculation of cost/time estimates, because taking all risks in to account will most likely blow the entire budget, as that would be very expensive.		Having the project broken into manageable chunks, each task is then associated with time, resources, cost and risks/opportunities. Each is very important to evaluate and estimations as a part of a work breakdown structure, as they can determine the success of a project. The definition of a project’s success is a whole field of itself in project management and will not be covered further in this article. However, having made a wrong estimation of time causes delays, which means higher cost. PRINCE2 [2] suggests a great number of techniques useful when doing estimations of projects. As an example of one of these techniques, PRINCE2 [2] suggests using the so-called bottom-up estimation. This method does as the name hence, sum all the cost/time from the bottom and up. Each task can also have a risk or opportunity added as a number of cost for each. For the sake of simplicity, a cost of a risk could be labelled with red and an opportunity green. These are obviously difficult to take into the calculation of cost/time estimates, because taking all risks in to account will most likely blow the entire budget, as that would be very expensive, and they are often not very likely to take place.

	Risks and opportunities are always a big part of project execution and planning and are associated with a high potential of impacts on a project. Risks are defined as negative impacts which could be both an increase in cost or time of a project. Opportunities on the other hand are defined as positive impacts which could mean a task taking shorter than expected or lower cost of one. Both are obviously dangerous to calculate for and put into a project. Risks as they may come totally unexpected and threatening the entire project, where an opportunity can prove dangerous if you calculate as you are expecting it.		Risks and opportunities are always a big part of project execution and planning and are associated with a high potential of impacts on a project. Risks are defined as negative impacts which could be both an increase in cost or time of a project or others. Opportunities on the other hand are defined as positive impacts which could mean a task taking shorter than expected or lower cost of one. Both are obviously dangerous to calculate for and put into a project. Risks as they may come totally unexpected and threatening the entire project, where an opportunity can prove dangerous if you calculate as you are expecting it.

	As a practical example of risk/opportunity management, one could look at the excavation for the Metro Cityring. Prior to any excavation a number of tests are conducted on site, to determine the soil conditions. This means having an idea of how much the soil can carry and also how much time it will take to remove. Having hard rock takes a lot longer time removing than digging through sand. When estimating the risks one could ~~chose~~ to include that the soil conditions are not exactly as the tests has proven, meaning the excavation will take longer than estimated. On the other hand it could also be that the excavation takes shorter time than expected, causing the task to cost less. Both these situations could be added to the work breakdown structure when estimating the cost and time. However, one can obviously not take both into account for each ~~tasks~~.		As a practical example of risk/opportunity management, one could look at the excavation for the Metro Cityring. Prior to any excavation a number of tests are conducted on site, to determine the soil conditions. This means having an idea of how much the soil can carry and also how much time it will take to remove the excess soil. Having a soil/ground of hard rock takes a lot longer time removing than digging through than sand. When estimating the risks, one could choose to include that the soil conditions are not exactly as the tests has proven, meaning the excavation will take longer than estimated. On the other hand, it could also be that the excavation takes shorter time than expected, causing the task to cost less. Both these situations could be added to the work breakdown structure when estimating the cost and time. However, one can obviously not take both into account for each task. On Figure 4 and example of how this could look in the work breakdown structure is illustrated.

	[[File:Risk_estimate.png\|center\|thumb\|caption\|Figure 2: ''~~An illustration the hierarchy~~ of a ~~WBS model. Figure taken from "Work Breakdown Structure of the Project~~.''\|600px]]
			[[File:Risk_estimate.png\|center\|thumb\|caption\|Figure 2: ''– Example of how one could use risk/opportunity cost estimates of a task.''\|600px]]

	== Limitations of the tool ==		== Limitations of the tool ==

Kasperloewe: /* Estimating cost and identify risks */

2018-02-28T18:11:40Z

Estimating cost and identify risks

← Older revision		Revision as of 18:11, 28 February 2018
Line 52:		Line 52:
	As a practical example of risk/opportunity management, one could look at the excavation for the Metro Cityring. Prior to any excavation a number of tests are conducted on site, to determine the soil conditions. This means having an idea of how much the soil can carry and also how much time it will take to remove. Having hard rock takes a lot longer time removing than digging through sand. When estimating the risks one could chose to include that the soil conditions are not exactly as the tests has proven, meaning the excavation will take longer than estimated. On the other hand it could also be that the excavation takes shorter time than expected, causing the task to cost less. Both these situations could be added to the work breakdown structure when estimating the cost and time. However, one can obviously not take both into account for each tasks.		As a practical example of risk/opportunity management, one could look at the excavation for the Metro Cityring. Prior to any excavation a number of tests are conducted on site, to determine the soil conditions. This means having an idea of how much the soil can carry and also how much time it will take to remove. Having hard rock takes a lot longer time removing than digging through sand. When estimating the risks one could chose to include that the soil conditions are not exactly as the tests has proven, meaning the excavation will take longer than estimated. On the other hand it could also be that the excavation takes shorter time than expected, causing the task to cost less. Both these situations could be added to the work breakdown structure when estimating the cost and time. However, one can obviously not take both into account for each tasks.

	[[File:Risk_estimate.png\|center\|thumb\|caption\|Figure 2: ''An illustration the hierarchy of a WBS model. Figure taken from "Work Breakdown Structure of the Project.''\|~~200px~~]]		[[File:Risk_estimate.png\|center\|thumb\|caption\|Figure 2: ''An illustration the hierarchy of a WBS model. Figure taken from "Work Breakdown Structure of the Project.''\|600px]]

	== Limitations of the tool ==		== Limitations of the tool ==

Kasperloewe: /* Estimating cost and identify risks */

2018-02-28T18:11:29Z

Estimating cost and identify risks

← Older revision		Revision as of 18:11, 28 February 2018
Line 52:		Line 52:
	As a practical example of risk/opportunity management, one could look at the excavation for the Metro Cityring. Prior to any excavation a number of tests are conducted on site, to determine the soil conditions. This means having an idea of how much the soil can carry and also how much time it will take to remove. Having hard rock takes a lot longer time removing than digging through sand. When estimating the risks one could chose to include that the soil conditions are not exactly as the tests has proven, meaning the excavation will take longer than estimated. On the other hand it could also be that the excavation takes shorter time than expected, causing the task to cost less. Both these situations could be added to the work breakdown structure when estimating the cost and time. However, one can obviously not take both into account for each tasks.		As a practical example of risk/opportunity management, one could look at the excavation for the Metro Cityring. Prior to any excavation a number of tests are conducted on site, to determine the soil conditions. This means having an idea of how much the soil can carry and also how much time it will take to remove. Having hard rock takes a lot longer time removing than digging through sand. When estimating the risks one could chose to include that the soil conditions are not exactly as the tests has proven, meaning the excavation will take longer than estimated. On the other hand it could also be that the excavation takes shorter time than expected, causing the task to cost less. Both these situations could be added to the work breakdown structure when estimating the cost and time. However, one can obviously not take both into account for each tasks.

	[[File:Risk_estimate.~~jpg~~\|center\|thumb\|caption\|Figure 2: ''An illustration the hierarchy of a WBS model. Figure taken from "Work Breakdown Structure of the Project.''\|200px]]		[[File:Risk_estimate.png\|center\|thumb\|caption\|Figure 2: ''An illustration the hierarchy of a WBS model. Figure taken from "Work Breakdown Structure of the Project.''\|200px]]

	== Limitations of the tool ==		== Limitations of the tool ==

Kasperloewe: /* Estimating cost and identify risks */

2018-02-28T18:10:36Z

Estimating cost and identify risks

← Older revision		Revision as of 18:10, 28 February 2018
Line 52:		Line 52:
	As a practical example of risk/opportunity management, one could look at the excavation for the Metro Cityring. Prior to any excavation a number of tests are conducted on site, to determine the soil conditions. This means having an idea of how much the soil can carry and also how much time it will take to remove. Having hard rock takes a lot longer time removing than digging through sand. When estimating the risks one could chose to include that the soil conditions are not exactly as the tests has proven, meaning the excavation will take longer than estimated. On the other hand it could also be that the excavation takes shorter time than expected, causing the task to cost less. Both these situations could be added to the work breakdown structure when estimating the cost and time. However, one can obviously not take both into account for each tasks.		As a practical example of risk/opportunity management, one could look at the excavation for the Metro Cityring. Prior to any excavation a number of tests are conducted on site, to determine the soil conditions. This means having an idea of how much the soil can carry and also how much time it will take to remove. Having hard rock takes a lot longer time removing than digging through sand. When estimating the risks one could chose to include that the soil conditions are not exactly as the tests has proven, meaning the excavation will take longer than estimated. On the other hand it could also be that the excavation takes shorter time than expected, causing the task to cost less. Both these situations could be added to the work breakdown structure when estimating the cost and time. However, one can obviously not take both into account for each tasks.

	[[File:~~Risk estimate~~.jpg\|center\|thumb\|caption\|Figure 2: ''An illustration the hierarchy of a WBS model. Figure taken from "Work Breakdown Structure of the Project."''\|200px]]		[[File:Risk_estimate.jpg\|center\|thumb\|caption\|Figure 2: ''An illustration the hierarchy of a WBS model. Figure taken from "Work Breakdown Structure of the Project.''\|200px]]

	== Limitations of the tool ==		== Limitations of the tool ==

Kasperloewe: /* Breaking a project into chunks */

2018-02-28T18:10:06Z

Breaking a project into chunks

← Older revision		Revision as of 18:10, 28 February 2018
Line 42:		Line 42:
	[[File:Wbs_metro.jpg\|center\|thumb\|caption\|Figure 3: ''– Principle sketch of what a work breakdown structure could look like on a metro project.''\|600px]]		[[File:Wbs_metro.jpg\|center\|thumb\|caption\|Figure 3: ''– Principle sketch of what a work breakdown structure could look like on a metro project.''\|600px]]

	A good question to this approach and procedure would then be, when the “breaking down” stops. As mentioned in [[The basics behind and the reason to do a WBS]] at some point the tasks has to be extracted out of the work breakdown model and used as a goal itself in a new model. ~~WBS~~ suggests that this is a common practice to do when a task exceeds a duration of one day. This obviously makes a lot of new breakdowns, but again this is to keep the original model neat.		A good question to this approach and procedure would then be: when does the “breaking down” stops? As mentioned in The basics behind and the reason to do a WBS at some point the tasks has to be extracted out of the work breakdown model and used as a goal itself in a new model. Rajani Devi, T., & Shobha Reddy, V. [4] suggests that this is a common practice to do, when a task exceeds a duration of one day. This obviously makes a lot of new breakdowns, but again this is to keep the original model neat.

	== Estimating cost and identify risks ==		== Estimating cost and identify risks ==

Kasperloewe: /* Breaking a project into chunks */

2018-02-28T18:09:46Z

Breaking a project into chunks

← Older revision		Revision as of 18:09, 28 February 2018
Line 38:		Line 38:
	== Breaking a project into chunks ==		== Breaking a project into chunks ==

	To begin with the project manager defines the main deliverables of the project. Taking the Metro Cityring into an example, the main goal and first level of the work breakdown structure would be to complete a fully operational metro line. The next level would be to define the deliverables needed to achieve this goal. In this case a completed tunnel with functional trains, completed stations with all architectural finishes and also a re-instated surface level after the excavations. On the third level each of these three deliverables are then broken into activities needed to achieve ~~the~~ deliverables, where after those activities are broken further down into tasks. At this level hierarchy order of the work breakdown structure stops, as at this point time, resources, cost and risks can be identified. This way of breaking down the work into level is taken as an inspiration from NASA page 4.		To begin with the project manager defines the main deliverables of the project. This is done by splitting the work breakdown structure into different levels. Taking the Metro Cityring into an example, the main goal and first level of the work breakdown structure would be to complete a fully operational metro line. The next level would be to define the deliverables needed to achieve this goal. In this case a completed tunnel with functional trains, completed stations with all architectural finishes and also a re-instated surface level after the excavations. On the third level each of these three deliverables are then broken into activities needed to achieve these deliverables, where after those activities are broken further down into tasks. At this level the hierarchy order of the work breakdown structure stops, as at this point time, resources, cost and risks can be identified. This way of breaking down the work into level is taken as an inspiration from NASA [1] (page 4). An example of this is depictured on Figure 3, where the Metro Cityring is used for illustration.

	[[File:Wbs_metro.jpg\|center\|thumb\|caption\|Figure 3: ''~~Illustration of an example~~ of a ~~WBS from the Metro Cityring~~ project''\|600px]]		[[File:Wbs_metro.jpg\|center\|thumb\|caption\|Figure 3: ''– Principle sketch of what a work breakdown structure could look like on a metro project.''\|600px]]

	A good question to this approach and procedure would then be, when the “breaking down” stops. As mentioned in [[The basics behind and the reason to do a WBS]] at some point the tasks has to be extracted out of the work breakdown model and used as a goal itself in a new model. WBS suggests that this is a common practice to do when a task exceeds a duration of one day. This obviously makes a lot of new breakdowns, but again this is to keep the original model neat.		A good question to this approach and procedure would then be, when the “breaking down” stops. As mentioned in [[The basics behind and the reason to do a WBS]] at some point the tasks has to be extracted out of the work breakdown model and used as a goal itself in a new model. WBS suggests that this is a common practice to do when a task exceeds a duration of one day. This obviously makes a lot of new breakdowns, but again this is to keep the original model neat.

Kasperloewe: /* The basics behind and the reason to do a work breakdown structure */

2018-02-28T18:08:36Z

The basics behind and the reason to do a work breakdown structure

← Older revision		Revision as of 18:08, 28 February 2018
Line 12:		Line 12:
	The input needed in order to construct a work breakdown structure is defined in the ISO21500 standards <ref name=''ISO21500''> ''DS/ISO 21500, 2013. Guidance on project management, 2nd edition.'' </ref> as in the following table on Figure 1.		The input needed in order to construct a work breakdown structure is defined in the ISO21500 standards <ref name=''ISO21500''> ''DS/ISO 21500, 2013. Guidance on project management, 2nd edition.'' </ref> as in the following table on Figure 1.

	[[File:Wbs_iso1.jpg\|center\|thumb\|caption\|Figure 1: ''~~The~~ required ~~input for~~ a ~~WBS according to ISO21500 standards~~. Figure taken from ~~DS/ISO 21500~~''\|600px]]		[[File:Wbs_iso1.jpg\|center\|thumb\|caption\|Figure 1: ''– Inputs required to construct a work breakdown structure. Figure taken from ISO21500 [3]''\|600px]]

	This gives a so called product-orientated grouping of project work elements which defines the scope <ref name=''wbs''> ''Rajani Devi, T., & Shobha Reddy, V. (2014). Work Breakdown Structure of the Project.'' </ref> .Having this hierarchy of activities gives the project manager a clear picture of each jobs that needs to be completed in order to reach the final goal. This is a very useful tool as starting a project can be very difficult in terms of knowing what is needed to complete a goal. This especially in construction management as the projects are often large and complex and with many different stakeholders and parties involved. Therefore, a project manager will not know all the smaller processes, and not knowing what workforce is needed for each activity before breaking down the project. When doing the work breakdown structure, PRINCE2 [2] suggests the following:		This gives a so called product-orientated grouping of project work elements which defines the scope <ref name=''wbs''> ''Rajani Devi, T., & Shobha Reddy, V. (2014). Work Breakdown Structure of the Project.'' </ref> .Having this hierarchy of activities gives the project manager a clear picture of each jobs that needs to be completed in order to reach the final goal. This is a very useful tool as starting a project can be very difficult in terms of knowing what is needed to complete a goal. This especially in construction management as the projects are often large and complex and with many different stakeholders and parties involved. Therefore, a project manager will not know all the smaller processes, and not knowing what workforce is needed for each activity before breaking down the project. When doing the work breakdown structure, PRINCE2 [2] suggests the following:
Line 34:		Line 34:


	[[File:Wbs_hierarchy.png\|center\|thumb\|caption\|Figure 2: ''~~An illustration~~ the ~~hierarchy of a WBS~~ model. Figure taken from ~~"Work Breakdown Structure of the Project."~~''\|200px]]		[[File:Wbs_hierarchy.png\|center\|thumb\|caption\|Figure 2: ''- Illustration of block hierarchy in the model. Figure is taken from[4]''\|200px]]

	== Breaking a project into chunks ==		== Breaking a project into chunks ==