basically a level of effort
Post on 21-Jan-2016
Embed Size (px)
Basically a Level of Effort (or LoE) task is generally like any other task in your schedule, where it will possess following properties:
1. LoE tasks cannot be open ended (that must have atleast one predecessor and successor) for them to be operational/ meaningful(Remember, you should not have any open ended tasks in your schedule apart from Project Start and Finish milestones).
2. LoE tasks DO NOT drive any other tasks and are driven byother tasks themselves. Hence, their durations are always moving according to their driving activities. This should not be confused with the fact that sometimes LoE tasks can even show on Critical Path of a project, they still do not drive other critical tasks.
3. As for the location within a particular WBS, I don't believe there is any "hard & fast" rule there but generally its better to keep them under a separate WBS so they are segregated from the rest of the planned tasks (For eg, if you are preparing a Construction program, the LoE task relating to lets say Construction Management should be under a separate sub-WBS level within the overall Construction WBS).
What Swissvalian is trying to emphasise on is the fact thatLoE tasks do not drive any other tasksand infact their duration gets driven by other tasks, hence not casting any impact on the overall duration of the program.
Level of Effort:
For how many days/weeks/months would you need a Project Manager on a project? You cannot answer with an absolute number of days. You can only answer "From the beginning of the project to the end, irespecitve of how many ever days/weeks/months it takes". This is a case where you would use LoE.
Here you would define an activity, say, "Project Management", and the predecessor would be "Start Project"; the successor would be "End Project" and the activity type would be Level of Effort. So, if the "End Project" date changes, the duration of the "Project Management" activity would automagically change without you having to remember to go and change it.
"Activity Type" is a field that helps you determine the duration of an activity.
If the Activity Type is a milestone, Duration is zero. If it is LoE, the duration is the time between the predecessor and successor and will be automatically recalculated when one or both change. If it is "WBS Summary", duration is from the start date of that WBS element to the finish date of that WBS element. This includes this element's sub-nodes too. If it is "Task Dependent" or "Resource Dependent" then, the duration is controlled by manual entry and/or the combination of "Duration Type" and "Calendar"
Task Dependent & Resource Dependent:
These two entries determine which calendar the activity will use to determine duration. The choices are Activity Calendar & resource Calendar.
Imagine the curing of concrete - this should work on a 24x7 calendar and will not take more or fewer days depending on how many resources are assigned to it. So, this activity should be "task dependent".
Imagine digging a hole - let's say it takes 2 days and that you need two guys. Te problem is that Guy 1 is available on Monday and Tue this week, but Guy 2 is available only on Tue and wed this week.
Now you should make the activity "Resource Dependent" because you would have mentioned in the Guy 1 and Guy 2 calendar that they are available as I mentioned.
So, now this two day activity will actually take three days to finish because Guy 1 works two days (Mon-Tue) and Guy 2 works two days (Tue and Wed), so the whole activity goes Mon-Tue-Wed, which is three days duration.
This is what "Task Dependent" and "Resource Dependent" do.
This is out of Primaveras help function:Level of effort activityA level of effort activitys duration is dependent on its predecessor and/or successor activities. Level of effort activities cannot have constraints assigned to them. Level of effort activities are not included when leveling resources.Use level of effort activities for on-going tasks that depend on other activities. For example, you could assign level of effort activities for clerical work, a security guard, or even some aspects of project management.A level of effort activity uses its assigned calendar to summarize its dates.Any type of relationship can be assigned to a level of effort activity.A level of effort activitys duration is calculated from the earliest early start of its predecessors/successors (linked to the start end of the level of effort activity) to the latest early finish of its predecessors/successors (linked to the finish end of the level of effort activity).
But there are some additions to be made:- No need, that the LOE-Activity is in the same project as the activities from which it depends - but all related projects must be open during scheduling.- The first predecessor activity, started, automatically starts the LOE. The last successor activity finished, automatically finishs the LOE.- A LOE cannot drive another LOE
Creating WBS is a task that required not only planner effort but also required inputs from the project team.Suppose a petrochemical plant revamp project scope includeddesign and engineering, purchasing of equipments and materials and construction of furnace and compressor areas. The followingis a sample WBS which may differ from your project nature, project scopeand organization's preferences.WBS CodeDescription AEngineering A.1Project Engineering A.2 Process Engineering A.3 Piping Engineering A.4 Mechanical (Rotating) Engineering A.5 Mechanical (Static) Engineering A.6 Civil Engineering A.7 Structure Engineering A.8 Electrical Engineering A.9 Instrumentation EngineeringB Procurement B.1 Heat Exchanger/Air Fin Cooler B.2 Column/Towers B.3 Drums/Vessel B.4 Tankages B.5 Pump/Blower/Compressor B.6 Bulk Materials (i.e piping materials, control valves, electrical cables, lighting fixture, filed Instrument,etc) B.7 PackagesC ConstructionC.1 Pre ConstructionC.1.1 Site development/Reclamation C.1.2 Roads,fencing and paving C.1.3 Water supply and drainage C.1.4 Piling WorkC.1.5Foundation WorkC.1.6Fabrication Work C.1.6.1 Pipe fabrication C.1.6.2 Steel fabrication(piperacks,platforms)C.2 ShutdownC.2.1Furnace Area C.2.1.1 Piping tie-in work C.2.1.2 Equipment Work C.2.1.3 Electrical Work C.2.1.4 Instrumentation Work C.2.1.5 Insulation Work C.2.1.6 Fireproofing including refractory, brick lining C.2.1.7 PaintingC.2.2Compressor AreaC.2.2.1Piping tie-in WorkC.2.2.2Equipment WorkC.2.2.3Electrical Work C.2.2.4InstrumentationWork C.2.2.5InsulationWorkC.2.2.6Painting Work C.3 Major ConstructionC.3.1Furnace Area C.3.1.1 Piping Installation including tie-in C.3.1.2 Steel Installation (Piperacks,platforms) C.3.1.3 Equipment Work C.3.1.4 Electrical Work C.3.1.5 Instrumentation Work C.3.1.6 Insulation WorkC.3.1.7 Fireproofing including refractory, brick lining C.3.1.8PaintingC.3.2Compressor Area C.3.2.1 Piping Installation including tie-in C.3.2.2 Steel Installation (Piperacks,platforms) C.3.2.3 Equipment WorkC.3.2.4 Electrical Work C.3.2.5 Instrumentation WorkC.3.2.6 Insulation Work C.3.2.7 PaintingC.4 Pre-commissioning C.4.1 Furnace Area C.4.2 Compressor Area
What is a Work Breakdown Structure?
A work breakdown structure is a key project deliverable that organizes the teams work into manageable sections. The Project Management Body of Knowledge (PMBOK) defines the work breakdown structure as a deliverable oriented hierarchical decomposition of the work to be executed by the project team. The work breakdown structure visually defines the scope into manageable chunks that a project team can understand, as each level of the work breakdown structure provides further definition and detail. Figure 1(below) depicts a sample work breakdown structure with three levels defined.
Figure 1. Work Breakdown Structure Example Click for Full SizeAn easy way to think about a work breakdown structure is as an outline or map of the specific project. A work breakdown structure starts with the project as the top level deliverable and is further decomposed into sub-deliverables using the following outline hierarchy (Figure 2):
Figure 2. Work Breakdown Structure Hierarchy using Matchware MindViewThe project team creates the project work breakdown structure by identifying the major functional deliverables and subdividing those deliverables into smaller systems and sub-deliverables. These sub-deliverables are further decomposed until a single person can be assigned. At this level, the specific work packages required to produce the sub- deliverable are identified and grouped together. The work package represents the list of tasks or to-dos to produce the specific unit of work. If youve seen detailed project schedules, then youll recognize the tasks under the work package as the stuff people need to complete by a specific time and within a specific level of effort.From a cost perspective, these work packages are usually grouped and assigned to a specific department to produce the work. These departments, or cost accounts, are defined in an organizational breakdown structure and are allocated budget to produce the specific deliverables. By integrating the cost accounts from the organizational breakdown structure and the projects work breakdown structure, the entire organization can track financial progress in addition to project performance.Why Do Project Teams Need a Work Breakdown Structure?The work breakdown structure has a number of benefits in addition to defining and organizing the project work. A project budget can be allocated to the top levels of the work breakdown structure, and department budgets can be quickly calculated based on the each projects work breakdown structure. By allocating time and cost estimates to specific sections of the work breakdown