The Planner on one of my projects has been supplying with programs with constraints in. I wouldnt have minded upto 10 soft constraints per 1000 incomplete activities but the number is about 23-30 % of incomplete. I am curious to know
- If there is a acceptable number of constraints?
- What is the risk of using constraints in a Program? Is there any material out there on this which I can use to inform my knowledge?
Thanks,
Marc Roland
I know you posted this under Constraints in P6 but a new post as opposed to jumping on this one would segregate the 2 issues.
just so that I understan it correctly task "B-Equipment Installation" has the ALAP ? and you say this is being driven by other construction activities why dont you put the ALAP constraint on "Task A-Fabricate & Deliver to Site" ?. You dont want the equipment to get there before the area is physcially ready to install and or get damamged just sitting there. You said it is being driven by othe construction activities anyway.
Anyone who has encountered and resolved this P6 issue? Send you suggestion please...
In P6 "Task A-Fabricate & Deliver to Site" is linked to "Task B-Equipment Installation" with ALAP constraint. "Task B" is driven by other Construction activities. teh result "Task A" is adopting the TF for "Task B". How do I adjust the TF of "Task A", noting that it has actually a lot of float in front of it. Is there an option to change P6 setting to be able to adjust TF with the use of ALAP constraint?
I will echo the previous comments the less contraints the more that the schedule will be logic driven.
If you look at the DCMA 14 Point schedule assessment the rule there is that "Less than 5% of the total # of activities should have hard constraints" (this does not include contractual Milestones).
Constraints will prevent tasks from being moved by their dependencies and, therefore, prevent the schedule from being logic-driven.
look at section 4.5 hard constraintes page 35 of the pdf
http://www.dcma.mil/policy/200-1/PAM-200-1.pdf
I think this is always a fairly contentious issue and let call it a "warm" topic, as to avoid heated discussion.
For me, the first question that should be asked, is are we differentiating between hard and soft constraints? There are many reasons as suggested above to peg an activity, but more crucially, contractual milestones or interfaces in a schedule need that long term reference, and throughout the project updating cycle, it is very important for the project team to see how lack of progress or exceptional progress positively or negatively impacts one of such said activities.
For that reason, I am quite the fan of soft constraints, which do not override logic, yet allow you more efficiently to manage float paths to a milestone. This becomes very important when managing multiple disciplines or multiple contractors on a project where milestones or interfaces are effected by many.
Having the dates still calculate as scheduled and the float path reflecting the negative or positive float on that specific float path is incredibly useful.
Anyway, great thread, I hope to hear more from everyone here.
I have always found it beneficial to adopt the view of NO constraints in programmes. They override or adversely affect the logic and so are not helpful. The only purpose they serve is to peg activities to a certain dates such as for planning meetings and other similar events and in these situations they can be accepted.
If you really are upset by constraints then pout them all in a seperate projects and like them to the activity your are trying to peg.
For forensic delay analysis I always look at the number of constraints within a programme and flag it up as a potential weakness. From the constraint it is but a short step to showing how the logic is adversely affected. Better, I feel, not to have them at all unless they are for dates of meeting etc. but keep them updated and relevant.
Thanks, I have read Garrys work and am in full agreement with him. To be honest I am in agreement with you on the constraints front. A good friend of mine said to me.. if a peice of work can not be represented by an activity with relationships and relationships only it has no place in the schedule. As predicted the schedule goes for a six when I pull the constaints out (six is a small number considering the damage it does!).
Hi V
After you have read Gary's excellent dissertation you may want to consider my approach which is that more than 1 constraint in the whole programme is too many.
Try a small exercise - delete the lot and remove all progress - reschedule - then see what your end date is.
Best regards
Mike Testro
There is no hard and fast rule about %age of constraints, but my approach is to request justification for every constraint.
23-30% sounds far too high.
See link to a previous thread where I explain the risks of each type of constraint in P6:
http://www.planningplanet.com/forums/planning-scheduling-programming-discussion/532479/differnce-between-mandatory-constraints-and
Cheers,
G