Unfortunately, those examples might be too hard to view.
If that is the case, thank you for your initial comments. They have helped me to reassess my own approach and I think I can offer a solution while also being open to the original requests from the Owner.
Much appreciated.
GP
Member for
7 years 4 months
Member for7 years4 months
Submitted by G.P.Willikers on Fri, 2018-08-17 17:38
Below is what I'd prepared for talking points when we meet to discuss how these activities should be added. In this example, there are four submittal packages that need to be approved prior to procurement:
A) Baseline Sequence
[[wysiwyg_imageupload:5923:]]
B) Owner's requested method
[[wysiwyg_imageupload:5924:]]
Note that without an task dependent activity between the current review milestone, there isn't an anticipated review period prior to procurement.
3) My proposed method
[[wysiwyg_imageupload:5925:]]
Note that there is a task dependent review period between submittal and procurement.
After looking at this, though, I can see how tracking multiple submittals in the submittal status column can be just as cumbersome as insterting them into the Activity Name.
4) Using milestones in conjunction with task dependent activities
[[wysiwyg_imageupload:5926:]]
This covers all bases, but will also be cumbersome to create for each submittal sequence I will be adding into the schedule (approx 70).
Looking at these, I think I am going to request we use task dependent activities, as shown in Method 3, but with activity names as shown in Method 2.
I am trying to check my ego and not go with my own idea simply because it is my own. So any further consideration is greatly appreciated!
Thanks again,
GP
Member for
16 years 3 months
Member for16 years4 months
Submitted by Zoltan Palffy on Fri, 2018-08-17 14:02
1) using a miles has its benefits when multiple resubmissions are required. This is because the milestone is tied as a FS to the procurrement activity or to the release of something or frees up some work to do.
If you use a milestone you can just add the resubmission process as a successor to the rejected submittal and then tie the resubmission process into the same milestone. Then you can manage by by milestone. So you would have 2 activities as predcessors to the milestone whoch would be the rejected approval and the 2nd approval.
2) That requests not unreasonable and I suggest that you abbreviate the description once the approval is rejected just as RAR for Revised and Resbmit or RNA for Returned Not Approved.
3) I think that depneds on if the submittal could be rejected by and area. If it is a universal, project type submittal I would level it as one. Something line 1/2" rigid conduit wil be used over the entire project so I dont need multiple submittals.
The approval of the submittal can be a predcessor to a procurement activity that SHOULD be by area or however you have it broken out.
Member for
16 years 3 monthsglad I could help
glad I could help
Member for
7 years 4 monthsUnfortunately, those examples
Unfortunately, those examples might be too hard to view.
If that is the case, thank you for your initial comments. They have helped me to reassess my own approach and I think I can offer a solution while also being open to the original requests from the Owner.
Much appreciated.
GP
Member for
7 years 4 monthsThank you for the
Thank you for the response.
Below is what I'd prepared for talking points when we meet to discuss how these activities should be added. In this example, there are four submittal packages that need to be approved prior to procurement:
A) Baseline Sequence
[[wysiwyg_imageupload:5923:]]
B) Owner's requested method
[[wysiwyg_imageupload:5924:]]
Note that without an task dependent activity between the current review milestone, there isn't an anticipated review period prior to procurement.
3) My proposed method
[[wysiwyg_imageupload:5925:]]
Note that there is a task dependent review period between submittal and procurement.
After looking at this, though, I can see how tracking multiple submittals in the submittal status column can be just as cumbersome as insterting them into the Activity Name.
4) Using milestones in conjunction with task dependent activities
[[wysiwyg_imageupload:5926:]]
This covers all bases, but will also be cumbersome to create for each submittal sequence I will be adding into the schedule (approx 70).
Looking at these, I think I am going to request we use task dependent activities, as shown in Method 3, but with activity names as shown in Method 2.
I am trying to check my ego and not go with my own idea simply because it is my own. So any further consideration is greatly appreciated!
Thanks again,
GP
Member for
16 years 3 months1) using a miles has its
1) using a miles has its benefits when multiple resubmissions are required. This is because the milestone is tied as a FS to the procurrement activity or to the release of something or frees up some work to do.
If you use a milestone you can just add the resubmission process as a successor to the rejected submittal and then tie the resubmission process into the same milestone. Then you can manage by by milestone. So you would have 2 activities as predcessors to the milestone whoch would be the rejected approval and the 2nd approval.
2) That requests not unreasonable and I suggest that you abbreviate the description once the approval is rejected just as RAR for Revised and Resbmit or RNA for Returned Not Approved.
3) I think that depneds on if the submittal could be rejected by and area. If it is a universal, project type submittal I would level it as one. Something line 1/2" rigid conduit wil be used over the entire project so I dont need multiple submittals.
The approval of the submittal can be a predcessor to a procurement activity that SHOULD be by area or however you have it broken out.