(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.
If you are on the owner side of an oil and gas company that is developing major oil and gas projects and have to supervise EPC contractors, how would you supervise and provide technical direction to them on planning and scheduling activities? How would you do it?
Printer-friendly version
Send to friend
Use the available standards –
The PMI Practice Standard for Scheduling has a good technical framework.
The CIOB / Wiley ‘Guide to Good Practice in the Management of Time in Complex Projects’ offers a more proactive approach to effective time management.
Finishing a project late is not good for anyone! By using defined standards you can neutralise the arguments about good practice and focus on doing a good job. The CIOB ‘Guide’ has been designed to be used in any jurisdiction, under any form of contract, with any type of project and can easily be identified as the required standard for the preparation and updating of contract programmes, progress reporting and time management. For more see: http://www.mosaicprojects.com.au/Book_Sales.html#CIOB
Hi Roland,
I agree not all client planners are alike -I myself have often done this role and there is both good and bad practise out there. Too much of the bad though, IMO.
-I understand the potential benefits to a client of mandating a particular software, but this should be balanced against the disadvantages to the contractor of having to switch to a different software, especially if that contractor has automated linking of timesheet and financial systems to the schedule software they use as a matter of course. On large projects I would contest that the costs to the contractor would typically outweigh the benefits to the client. -it's a relatively simple matter to take info from a detailed EPC schedule in, say, Asta and manually update a summarised client programme with key milestones and interfaces in, say, P6. Much more inefficiencies involved in a contractor switching from an automated loading of actual costs / dates, tracking of cashflow etc and getting the entire project team up to speed with a new planning software.
-My problem with Earned Value when demmanded by a client is that often the earned value metrics will not be used by the contractor to help manage the project, so they become just one of many client reporting KPIs, but one that is very expensive to setup and maintain. I'm yet to be convinced that EV helps forecast realistic end dates either -I think the time would be better spent better monitoring schedule risks than SPI to achieve this, but that's probably a little off topic.
-Absolutely agree that any changes to the schedule should be notified to the client, and indeed go through a formal change management procedure. I have however worked on projects where client has outright banned any changes being made unless they are part of a formal rebaseline instructed by the client. This effectively guarantees that the schedule supplied to the client is a lie. Probably the most self-defeating client requirement I have ever come across.
Bottom line is a client can require whatever they want, but they should make these requirements clear at tender stage and set them out in the contract, so that the contractor can price for them or suggest a cheaper / better alternative. And they should think carefully about those requirements to make sure they benefit the project, and not just the client.
And of course if it's not mandated in the contract, and does not pass the cost/benefit test, the contractor should learn to say "no" more often.
Cheers,
G
Hello Gary,
To be fair, not all Client Planners are alike.
For instance, we sometimes demand almost the same 3 things you've mentioned but for different reasons:
- Usage of particular Planning Software : To keep compatibility across all Contractors/Subcontractors (especially on Multiple Prime Contracts).
- Cost Loading and generate earned value or earned schedule (depending on contract) metrics :To actually properly monitor Contractor Performance , be able to forecast realistic end dates and take any corrective measures when and if necessary..(Side Note: A lot of clients I know don't even read what you send them anyway).
- Shall not change any logic, constraints , calendars, resources or planned durations without informing PM , Client Planner or whoever is in charge at that stage and agreeing on the changes to keep schedule realistic and matching actual progression sequence of works on site. There is also a general tendency with many Contractors, at least round here, to manipulate schedules and mislead uninformed clients . They submit huge , unexplained changes to the schedule structure without explaining the why i.e including a narrative. What is even scarier is that they don't quite grasp the importance of the narrative even after you try to explain it to them. Shows how much most GC management teams view the Schedule as nothing more than a software exercise .GIGO.
Best Regards,
Roland
Hi Raul
Always remember that whatever plan you are discussing with the Contractor he is working to a different programme.
The Contractor will always try to keep the true plan secret and his success depends on the level of detail he has exposed to you.
Insist that you both have level 4 or 5 programmes not level 3 for you and 4 & 5 for him.
Best regards
Mike T.
Hi All,
I think you better develop a planning and scheduling procedure and include it in the contract and what you expect from the contractors with regards to programming, monitoring and control.
On 2nd thought, most of these procedures and progamming requirements are already covered in the contract, it just a matter of implementing it.
Best regards,
Daniel
Carefully.
Firstly, read the contract for each project thoroughly. In particular, you need to understand in detail
a) the scope of the project
b) the contractual requirements relating to planning (update frequency, baselines, planning software to be used, etc)
c) the contractual requirements relating to timely delivery and client obligations (completion & sectional completion dates, client review periods, client deliverables (eg allowing access, providing power, etc), durations of any specific commissioning / relaiability tests, etc)
Secondly, you need to decide what scheduling best practise and standards you want your contractors to adhere to. This forum is full of discussions around best practise and no two planners seem to completely agree, so you will have to take a view yourself on what you consider to be best practise and what you don't. Areas you might think about would include:
-use of lags and negative lags
-use of calendars
-use of non FS relationships
-use of constraints
-maxmimum activity durations
-resource loading & levelling
-earned value
-wbs
-update / review periods
-schedule risks and buffers
-activity coding
-multiple schedules
-using particular software
-perfromance measures and reporting requirements
-change management
Thirdly, and this is very important, you need to understand and communicate to all who will listen that the main priority of a project plan is to help the project team delivery the project in good time. The main priority is NOT for it to be used as a tool to satisfy the client.
As such, once you've worked out what the contract demands the contractor does, and also what you would like them to do, you have to then sit down with the contractor and agree what he will actually do. He will have his own ideas about best practise, asting systems in place. Where you have differe opinion, your job is to understand his reasoning, and if you still think your approach is better, convince him. Once you have an agreement in place, get the contractor to submit it in the form of a scheduling plan.
After that, your job is to provide constructive criticism and technical support to help him deliver to that scheduling plan, to lead regular reviews of that scheduling plan with the contractor to ensure it remains fit for purpose, and to encourage the contractor to constantly look for smarter / better / faster / cheaper ways of doing things.
A collaborative approach, where both parties are focused on getting a schedule which will best help the project run smoothly is key. Avoid at all costs the temptation to issue edicts from an ivory tower without understanding the impact such edicts may have on project performance.
Common instructions from client planners I have come across which have been to the detriment of the project include:
-You shall use this particular planning software, because it's the only one I know how to use.
-You shall resource load your projects and track actuals at the activity level and generate earned value metrics, which will only be used as a KPI to report to the client
-Once the baseline is approved, you shall not change any logic, constraints, calendars, resources or planned durations, even if this means the schedule no longer reflects the planned approach.
Ability to be on the driver's seat all the time is key to project delivery. To achieve this, the lead planner on the owner's side should be technically knowledegeable on every aspect of the project. He should be able to communicate effectively and be on top of the project. Familiarity with the planning tools will provide the magic wand in this aspect. Proactivity and sensitivity are twin tools that will lead the horse to the river as it points out the direction at which the project should follow. He should do all to keep the contractors' planners on their toes by highlighting always the missing link in everything predictable, which must happen, failing which the project will not arrive at its expected destination as and when due.
Ujam
If I'm on the owner side, My philosophy will be: Leadership by example.
There was once a post in PP that change the concept on the way I'm doing my work.
It says
"The Contractor is lousy if the Project Manager is Lousy". The Contractorwill bring out is best effort if the project manager will also bring out his best effort." It follows that the Contractor performance is relative to the project manager performance.
Actually it was taken from some NASA guiding philosophy of their Project Manager.
The HOW is really complicated because it varieis on a project to project basis, culture of the project team, scope of work, contractual documents.
But the basic should be depends on you, us or the individual planner.
The basic in project planning is to arrive at a plan, baseline plan or whatever types of plan. This plan will guide the project team. Then, update the plan: weekly update, bi-weekly update, monthly update.
From the update, make your own analysis, conclusion, and recommendation.
Thank you,
Scarlett
Email: PPadmin@planningplanet.com
Replies