Guild of Project Controls: Compendium | Roles | Assessment | Certifications | Membership

Tips on using this forum..

(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.

Interface Management

1 reply [Last post]
Rhys Burton
User offline. Last seen 9 years 12 weeks ago. Offline
Joined: 4 Mar 2004
Posts: 6
Groups: None
In a programme environment, with many established contractors how best would you manage the interfaces between these contractors given that the interface is the most likely point at which the owner is likely to lose out?

Constraints...
Data, once received can not be changed.
You can not dictate data requirements beyond identifying the interface.
Contracts can not be changed.
When I say programme I mean PROGRAMME!

We have developed a solution after looking at much research and knowledge on the subject but even our answer is not easily introduced and executed (without much legal wrangling anyway). What other alternatives are there?

All answers appreciated.

R

Replies

Paul Harris
User offline. Last seen 1 year 4 weeks ago. Offline
Joined: 11 Apr 2001
Posts: 618
Rhys

Some thoughts from my experiance of setting up programmes.

I feel the approach needs to be flexible and have several alternatives which cater for the skill level and project management maturity of the contractor, and the project/programme requirements.

I tend to use one the following three options for each of the contractors schedule:

1. Providing a scheduling service for the contractors who do not have the skill or in-house expertise. This often requires more that one method of statusing the schedule depending on the ability of the contractor. This works well in an alliance environment.
2. Providing an established environment in your programme managements software where the contractor is able to schedule his work. This would be undertaken in a WBS/Activity Code environment that provides typically two sets of codes, a mandatory set of codes for the programme reporting and an optional set of codes for the contractor and their management and reporting. This works well when the contractor is familiar with your software and does not play contracting games.
3. Representing the contractors schedule in summary format at the minimum level of detail your organization requires for management and reporting. (e.g. like a PRINCE2 Project schedule. You would need to negotiate with the contractor the level of detail required by your organization. Then allow the contractor to schedule his project to a greater level of detail (like PRINCE2 Stage schedules) in his own software but at all times being able to roll his schedule up to the summary level of detail representing your programme activities. This type of project level schedule would also include interface milestones from or to your programme to drive related activities in the contractors schedule or projects/activities in your programme. The update of your summary schedule would often be a manual one. The contractor would be required to provide their schedule in the native file format that they are managing the project in and state the version of the software being used. A statused schedule should be provided at every update. This approach is for the mature contractor with established systems. I recommend against importing a whole load of detail on each update from a schedule created by the contractor in different software. There are many reasons for this but will not go into them here.

It is important that the Baselines form the contractors are established early irrespective.

Paul E Harris
Eastwood Harris Pty Ltd
Planning and Scheduling Book Publishers
www.eh.com.au