(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?
(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.
I am re-entering the world of planning and scheduling (via Primavera) and have been tasked with developing a detailed Engineering schedule. My intent is to do the following:
a) Defining project objectives.
b) Developing a work break down structure - to the deliverable level.
c) At first, develop sequencing of tasks for each specific discpline (via Discipline Lead), then work with all the leads to develop the interconnect logics between deliverables of dferring discplines.
d) Estimate activity durations.
Question:
1. Does the above methodology make sense - any suggestions on an improved approach?
2. As far as utilizing Primavera 6: Looking for pointers as to how to make a sound schedule (i.e. Should I stick to FS relationships as much as possible? What P6 settings do I need to ensure are in place before creating the schedule? What are some things I should be careful of when generating the schedule - whether it be P6 functional settings or bad scheduling practice.
3. Is there a standard logic (to be used as a starting point) for developing a detailed Engineering schedule. I really would like to understand the logic ties for deliverables in each discpline as well as how deliverables in one discpline are tied to the next.
Any help / guidance would be much appreciated.
Thanks
Printer-friendly version
Send to friend
Hi Steve,
I am a new member in this site and fortunatly had the opportunity to face the some issue four years ago when I joined a design company.
There is a couple of tips that I could give in relation to how to do planning, preferred relationship between activities, use of constrains and so forth. The frist thing you already got right, your schedule will be based on deliverables.
The second step is to decide how you want to manage your schedule and how much time you have to develop and maintan it up to date. If you have time to develop a proper schedule I would suggest you to upload the resources by name, as you want to manage holidays and vacations in order to meet your deadline and re-plan your schedule if necessary.
Sounds like a lot, but is not. When you are setting up your schedule make sure you use relationships between activities only when it is necessary. Resource loaded schedule needs a free flow to work for you. And the use of priority on activities will ensure that your resource will work on priority activities when a conflict between activities hapen.
The use of resources by name sometimes is unavoidable as you need the same resource that checked the drawing to re-check it, to improve the team performance.
I have done it heaps of times and I can guide through this journey if you want.
Regards,
Rodolfo Kurek
Gary,
I love your answer, we are not questioning how valuable resource leveling is but how more important it is on my work for construction companies than on your work on design work or vice versa. It highlights the importance of taking care of your resource usage.
Mike
Design firms also have the issue that some specific days their designers must go to a site visit, their calendar is the same just some days reserved for specific activities, it is easy to model, can you figure it out? As a hint I will give you the words "dummy resource" but will not tell you about the full hint "dummy resource in combination with shift work on a same activity", yes that the designer is on a site visit it does not necessarily prevent other designers to continue work on the same activities on the day he/she is out.
Construction activities have volume of work measured in physical quantities such as cubic meters, tons and the like while design work use man-hours as a measure of volume of work. Usually the physical quantities are fixed while the required design man-hours must be revised periodically. Even productivity of resources producing design hours do vary, some resources are more efficient than others and this shall also be included in your models, same as a 20 cm dump truck is not as productive as a 30 cm dump truck on your fleet. The issues are similar, all require some consideration in your planning.
Steve
There is much overlap of activities in design work. Using FS relationships only on activities that can work work at the same time with variable production with time due to variable resource assignments makes it impractical to create good models unless for every change you rework your schedule logic, resource assignments and activities duration.
If you do not believe me try to schedule the sample job I provided using only FS logic, execute a schedule run without resource leveling and then with resource leveling, then add a few resource vacations and progress different to as planned and let me know about your experience. It is very simple model, only 8 activities and 4 resources, a piece of cake.
Then for more fun add 6 additional design jobs and a increase just a bit your resources and enjoy trying manual assignment of your resources all working on partial assignments, of course variable partial assignments as to minimize idle time. A few jobs, not so many resources, not even a hundred activities. Remember, some activities can be worked independently by the resources working on different shifts while other require all to work to be done as a group, all resources working together the same hours.
Who said it is not easy? Well at least easier than a construction job with thousands of activities and hundred of idle resources even if just some 20 trades. Efficient manual resource leveling that minimizes idle resources even for such small quantity of activities can be complicated, efficient bucket planning is nuts. After some warming on your skills try doing it with just FS relationships that in addition will require constant adjustment of your activities splitting in order to get good results.
I hope the discussion is useful to you. I am including some commonly occurring issues on purpose with the idea you take notice. My challenge to Mike is an excuse to share and learn some ideas related to your work and to mine as well.
Best regards,
Rafael
PS. - Efficient scheduling, not just workable at a high cost.
Hi Raphael,
I don't disagree with any of the points you make. Resource levelling is undoubtably a good idea in both construction and design programmes.
But I stand by my position that not doing resource levelling on a design programme is a bigger problem than not doing resource levelling on a construction programme.
Hi Mike,
Yes there are typically as many "trades" within the design phase as there are within construction. I don't think this makes it any harder to level, though.
You are absolutely right that it is important to identify the manhours and "trade" responsible for different stages & approvals of a given design deliverable in order to level it properly. -These approval steps are often rather poorly defined at the outset of a job in terms of duration, responsibility and manhours
It gets even worse on more complex process jobs when often a deliverable you thought had been approved for construction gets "rolled back" to unapproved status after a harrowing HAZOP or SIL review, or a vendor explains to your designers why what they designed won't work, or you finally get your 3D clash-detection working properly and wish you hadn't...
-I had a full and lustrous head of hair before I planned my first process design project...
Cheers,
G
Mike,
I agree 100% with you, it is not that simple but in general 10X easier than Construction Jobs. You have 100X less activities and you have 100X less resources. Of course the complications can be the same on a one by one basis but much less in quantity.
I am not a designer but take a look at the following, the Civil Designer is idle [idle hours/day shown] a lot of time, with variable resource assignment the schedule can be improved. The following is not necessarily a good model as it is not modeling variable resource assignment.
Can you figure it out yourself instead of using a good model? Maybe, but what about 20 jobs at the same time, none progressing as planned, even though it should be easier than manually taking care of getting into productive work idle resources on a single construction job.
Hi Raphael - Hi Gary
When you get into design resource levelling it can get more complex than just building it.
How many designers are involved in any simple project?
Here are a few to mention:
Architect > Structural Engineer > MEP Engineer > Interior Designer > Landscape Designer
Plus HSE and Local Planning Consultant
Then you have an inter related matrix to consider - inter alia:
Lead Design > Co-ordination > Approval > Final issue
Each of which may be attributed to any one of the Designers - or maybe more than one.
Think on.
Best regards
Mike Testro
That it is not leveled it means such schedule is non workable. That it is leveled it does not necessarily means it is a good plan, it only means it is workable. It can be solved by executing only one activity at any given time, leveled but with a lot of idle resources and a very long job duration.
The issue is not merely about making a plan that can be done, it is also about making good plans.
The idea on modeling limited resources is also about making good plans, is also about controlling idle resources and put them into productive use. The contractor has a right to control his resources and make some money.
If you can make partial assignments of your resources, if you can assign variable resource quantities for your activities as more or less resources become available you will do it in practice. A good model will help you plan what you will do in practice to make a buck.
An electrical designer can be assigned to work on several jobs at the same time, a few electrical designers can be assigned to work on the same job but frequently they are not required to work together they can work on different day/hours. This is an example of partial assignment that can be fixed or variable.
A mason can be assigned to work on an activity the whole day but if idle he can join a crew already working on another activity. This is an example of variable resource quantity you can assign to an activity.
I guess no PM will ever plan his resource assignments without taking in consideration idle resources and how best to make some use of them.
I guess no PM will accept Monte Carlo statistics if he needs to consider variable partial assignments and quantities in his schedule and the model is moving in a different direction. Nice graphics, good to impress the unknowledgeable, but useless if they do not represent your plans.
As far as I know, at home, all PMs plan their construction jobs taking into consideration idle time and look to minimize it. This does not means many schedulers move in opposite direction, it is common their software does not provide enough functionality for their needs.
Rafael,
I don't disagree that it is important to plan & manage resource utilisation on construction prgrammes, but I do think it is even more important to do so on (process) design programmes.
To illustrate: During the design phase of the process job I am currently working on, the first task for the mechanical designers once the initial process design had been complete was to specify approx 50 mechanical packages for supplier tenders. Without resource levelling, around 45 of these would have been scheduled to start on the same day, purely based on "hard" logic. It is rare that you will see an analogous situation in a construction programme that has not been resource-levelled.
Construction programmes tend to have more "hard logic" than design programmes, and the "hard logic" in construction activities tends to consist of more unique driving predecesors than design activities, so an un-levelled construction programme will in general look a lot more sensible than an un-levelled design programme.
Cheers,
G
---"Design programmes are generally constrained by limited resources -more so than construction programmes. You should get man-hours as well as duration estimates for each deliverable, and be prepared to do resource leveling."
In general I agree wit the above statement except I would say.
-Design programmes are generally constrained by limited resources - similar to construction programmes. You should get man-hours as well as duration estimates for each deliverable, and be prepared to do resource leveling.
It is a phalacy that because construction resources can be hired everyday at the job gate they shall be managed as if availability is unlimited. One of the main reasons to perform resource leveling with limited resources is to take control of unnecessary idle resources that can get your job into red.
I say similar because it is possible that in design programme resources are mostly shared on partial assignment (resources can work on several projects/activities during the same day) while in construction the proportion might be a bit lower.
The unnecessary assignment of resources to be all day on a single activity if abused can lead to excessive idle time of your resources. In a similar way assigning a fixed quantity of resources to an activity does not makes much sense when adding idle resources to the activity is possible, possible to the extent it will reduce activity duration.
Look to model resource allocation the way it works in practice. If your resources can be allocated part time, if your resources can be allocated on variable quantities and if your resource assignment will drive activity duration do not lie yourself and others, just make a model that will follow how resources shall/will be managed, otherwise the tool will be useless (well you will still be able to draw bars), you will end up drawing bars to force the software to follow true logic. You might end up doing ineffective "bucket planning" every day.
By avoiding ineffective bucket planning, far from optimal, at times far from good, I do not mean a scheduler can predict the future. Many unpredictable events will still require some management decisions you will have to adjust in your model as Gary expressed so well.
1) Yes, this makes sense. A couple of other tips:
-you will probably need to break each design deliverable down into stages (e.g issued for comment / approval / tender / construction)
-Design programmes are generally constrained by limited resources -more so than construction programmes. You should get manhours as well as duration estimates for each deliverable, and be prepared to do resource levelling.
2) Yes use FS constrains as much as possible, however this is not easy to do in design programmes -especially for process jobs. This is because generally a design deliverable will start when sufficient information to make progress is available, but before all information requried to complete is available. -Design programmes are very iterative and difficult to apply proper logic to. An example:
You might schedule the path to design of of an MCC Kiosk base like this:
Basis of Design (FS) to Block Flow Diagram (FS) to P&ID (FS) to Pump data sheet (FS) to tender for pumps (FS) to procurement of pumps (FS) to MCC Spec (FS) to tender for MCC (FS) to procurement of MCC (FS) to vendor design of MCC (FS) to Design approval (FS) to MCC Kiosk spec (FS) to tender for kiosk (FS) to procurement of kiosk (FS) to vendor design of kiosk (FS) to approval of design (FS) to Civil design of kiosk base
But in reality:
-You don't need the P&ID finished to do the pump spec -only some of the info has to be there
-You may well put out a spec for MCC based on indicative pump loadings gleaned from the data sheet or tender returns, rather than waiting for final procurement
-You don't need the complete MCC design to be able to spec the kiosk
-You can design the kiosk slab based on a worst-case size & loading instead of waiting for the approved vendor design.
It is important to get the logic as complete and accurate as you can though, as you will almost certaintly need to do some resource levelling to get an accurate schedule and to do this, you need a good handle on the floats of your deliverables.
Ref resource levelling: Be aware that the P6 levelling algorithms are not very good. -There have been many discussions regarding this on this site you could search for more info. You may want to consider manually levelling, using "preferential" logic and/or early start constraints.
Try and break the deliverables down into smaller chunks, which will help you get more accurate relationships.
Also be prepared to change logic throughout the design phase. -No matter how good a job you do at the start, there will be additional links that only become apparant as the design progresses, and existing links that will be broken or modified.
If the job starts running late, you will suddenly find that a lot of links you have in place can actually be broken, by designing on assumptions, and taking the risk that re-work may be required later on if the the assumptions prove to be false.
A classic example of this is specifying the MCC. -In an ideal world, you would wait until all you drives had been procured and your control philosophy, URS, instrument & valve schedules have been finalised before you tender the MCCs. Since this would make the MCCs one of the last things to be spec'd, and MCCs are generally long-lead items, often the tendering and procurement process will actually progress in parallel with finalising the required design deliverables.
3) There isn't really a standard logic that can be followed. -It will depend on the industry you are working in, client & internal approval procedures, the type & location of the project, the contractual timelines and attitude to risk, if the contract is an EPC or design-only, etc.
Email: PPadmin@planningplanet.com
Replies