(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.
Dear all,
several PM tools (e.g. Primavera, MS Project, Spider) have possibility to have inter-project dependencies.
Whilst they differ in implementation, the idea is the same in all tools.
But the question is: what shall be the general approach to managing project portfolio with interdependent projects?
The idea is that every project has its own scheduler and there is someone who oversees the projects all together.
From one side one would want projects to have interdependencies and be able to influence each other.
From the other side one would want some stability in the whole system. So one would not want the situation that if a project B depends on a project A, then every time Project A scheduler updates his schedule in the system (may be in a draft format) this would alter the schedule B.
My current thinking is that inter-project dependencies shall be treated like external milestones with fixed dates. This shall allow an individual scheduler to have a flexibility to change his individual schedule with the assumption, that external dependencies he imports do not change and trying to maintain external dependencies, which his project exports.
And then once in a while the entire portfolio is assemled together, re-scheduled together and then new dependencies milestones are agreed.
So, can someone with practical experience provide some feedback here?
Printer-friendly version
Send to friend
When I have multiple projects to be linked and typically this in in the situation when I have a client master program and then contractor programs linked into the master.
Regards
Paul E Harris
Eastwood Harris Pty Ltd
Evgeny,
The solution depends on the type of portfolio.
Each interdependency has its own life-cycle: Potential- > Confirmed->Date Agreed->Delivered.
Potential- > Cancelled
Confirmed->Descoped
Also, an inter-dependency could be hard (full stopper), soft (nice to have) or virtual (collaboration required)
The easiest type to manage (Hard->Date Agreed), but in IT and Business portfolios it is a small portion of inter-dependencies :(
In the construction industry in the delivery phase it is the most common type (they are called Interfaces).
Regards,
Alex Lyaschenko
Evgeny,
The problems are largely political and procedural, not P6, and as such vary enormously from client to client.
For example – the interproject relationships. These are best always ‘live’ not bound by fixed milestones. Let’s say that an outage project has to be finished before a capital expansion project starts. Without proper discipline by the outage planner over the use of the ‘ignore relationships to other projects’ switch in the Scheduling Options dialogue, we might have a very unhappy capital projects planner whose start date will vary. During the setup of both projects the outage project will have an end date that is the function of how much scope we have defined, best to leave the ‘ignore relationships to other projects’ button ticked, such that the capital project’s start milestone constraint of ‘Start on or after’ is the driver. Once the outage is underway, and probably having progress added every day, the link to the capital project is very real, and should delay that project if we are late. You can’t set P6 up to do this, well until it gets a ChatGPT interface! – so procedures need to be in place to govern its usage which were not required when every project was a silo. You also need the political control over planners from different departments, possibly even different contractors.
david,
thanks. I think I got idea of the problems you explained, but how did you work them around?
Especially taking into account the fact that once a project is updated, it immediately starts affecting other projects in the same database, if there are inter-project dependencies.
P.S. I think Spider Project has elegant solutions for most of the problems you raised. Definitely on the portfolio-wide resource levelling, this is where Spiders shines.
P6 has a lot of issues. Multi-project portfolios do not add any new ones. You will have to make the usual compromises over:
Levelling, lack of control over activity splitting during resource levelling becomes a bit more obvious. Since it is almost impossible to explain properly to anyone in charge what resource levelling does, you are normally prohibited from using it!
Calendars. P6 behaves impeccably, BUT people sometimes have difficulties when you have a lot of different working weeks. What does ‘5 days duration’ really mean in a world with a mixture of 168, 84,55,40 etc working hours per week. Presentation very important here.
Global Activity code vs WBS. If you have 20 projects in your portfolio, that is 20 WBS structures. You need one. You need a P6 Global Activity code that is the REAL (e.g. SAP) WBS.
Layouts. Let me recommend a ‘Dummy’ project, whose only role is to hold ‘project specific’ layouts for the portfolio. You always open this project with the portfolio project(s) that you want to report on.
Baselines. You can make a ‘Portfolio Baseline’ by using CTRL A in the Maintain Baselines dialogue. You will urgently need a conversation about what baseline(s) to use with all the individual project owners.
Float and other schedule specific calculations. All the features you need BUT like Baselines you cannot manage this properly other than with written procedures. One float path per portfolio or each project, for example.
david kelly, thanks for reply.
I understand the limitations of the P6, described by you as well as how you think it can be done better.
But the question is: how did you do this in practice then, with the current tool (P6) limitations, when you implemented these ‘Integrated Activity Planning’ ambitions ?
How did you work around these limitations?
I helped a lot of clients in the first 20 years of this century to try and realised their ‘Integrated Activity Planning’ ambitions. All in Oil and Gas, mostly in the North Sea.
I have only used P6 or its predecessors. The driver was asset-centric portfolios. A large North Sea asset had a power station, the first half of a refinery, a hotel and restaurant, and product export facilities all in area of such close conjunction that would be illegal onshore, with a strict limit on the number of personnel that could live on it, and incredibly expensive crew change by helicopter.
P6 could have been designed for this environment. A single resource pool across a portfolio of projects, especially the resource ‘bed’, and the essential switch when scheduling to incorporate external projects or not. That switch means the integration milestones you mention are not necessary. Any planner can chose to open, say, an outage project and schedule it as if it was stand alone, then open the project with the routine maintenance project and schedule again, and so on.
Email: PPadmin@planningplanet.com
Replies