Samuel MorleyProject Manager, CEng MIET | PMPWolverhampton, Shropshire, United Kingdom
Hi All,
I am reaching out to the community as I’m struggling with a WBS conundrum in my current project(s), I hope you can help.
I am dealing with two R&D innovation projects (funded separately), but the final product is shared by both. Essentially the first project '71 WGS' is a gas processing system that captures CO2, the second project '72 PWA' is a complementary process system that purifies H2, and can sit either in parallel or downstream of the 71 project; they can operate separately, but together they become a complete solution / product offering. The projects started at similar times, so this is a great opportunity to deliver the complete solution, and my bosses are backing both projects fully. Since they come from different funding programmes however, I have two significant external stakeholders to manage and an excess of reporting to deal with...standard life of a PM!
However, the challenge is they must share an integration process system in order to operate (utilities piping, process piping, EC&I, civils, analysis equipment). It is clearly more cost effective that they share this equipment, rather than doubling up. As a result, there is a workpackage (WP) 'Integration Engineering' which is shared by both projects and cost are allocated approx 50-50 which is fine. More challenging though is the storing of information and working documents, we must avoid creating copies (to prevent conflict of document versions), so then which data repository to save it in? - So far I have kept all of the information under the first project 71, as the leading project, for simplicity.
Q1: Is this the right approach or should we have created a new project instead? Too late to change now I think since we have created numerous documents and change request references with project code 71.
All equipment WP sit at level 2 in each project, and all pass through workstreams at level 1. So for example, the level 1 'workstreams' ie. 3. Engineering 4. Manufacturing 5. Installation 6. Commissioning; following a traditional ‘gated’ waterfall approach as is usual with these kinds of process plants. In the case of Integration work the sub-work packages are 3.5 Engineering Integration, 4.5 Manufacturing Integration, 5.5 Installation Integration. Which means there are x3 sub-work packages for this integration work (or rather x6 if you include the 72 project reporting as well)
The projects are both part way through, they are essentially neck and neck and we intend to commission them at the same time. Most of the major equipment WPs (ie. guard beds, compressor etc) are already in the 2. Manufacturing phase, whereas the integration is still in engineering. Now, we are contracting an EPC to take care of the integration work under one broad contract that covers the remaining engineering, manufacturing and installation as one. Further to this, the contractor is ‘integrating’ the project so they must drive the delivery of all the other equipment WP items and bring them together in installation, so they need a degree of project management autonomy of the main delivery (including visibility of all equipment WPs from 71 and 72) – but I need to exclude them from some of the high level decision making at cost level as well as other workstreams 7. site planning. 8.commercial deployment, as they are commercially sensitive, so they can’t see the whole project repository.
I want to lift the integration (and delivery) WP up to level 1 so that it can be easily contracted under one agreement, with responsibility handed over, whilst at the same time providing a single data repository space that allows both organisation's teams to collaborate/feedback/share information. This would also see the other workstreams 4,5 and 6 (and their respective equipment WPs) moved underneath this Integration WP. However doing this will go against the logic of the existing WBS and may cause confusion amongst existing team members.
Q2: Is it acceptable to restructure a WBS in this way half way through a project?
Adding further complexity is that the integration also serves 72 equipment, not only the 71 equipment. Ideally, I would want to move 72 items under this integration engineering WP too, so the EPC has the oversight an easy navigation through the project structure. But doing this feels very wrong since all the work done so far in project 72 is registered as 72.
Q3: Should I attempt to integrate the equipment WPs from 71 and 72 project under one data repository for easy of data management and file sharing?
Likewise, document/artifacts such as the risk register, document registers, issue logs exist for each project. In particular the risk register, we want to hand this over to the contractor of the integration engineering so that they are owning the majority of these risks now. All common risks apply to both projects, and we want to avoid duplicating work, so there is no point to have two risk registers at this stage.
Q4: Is it acceptable to retire one of the risk registers before the project is up, and merge them both into one register? How do you then reference it if it is saved under the other project code?
I know there is a lot to digest here, but I don’t have anyone to turn to in my organisation. If there is anyone out there with some suggestions would be greatly appreciated.
There are lot of factors need to be considered. Generally speaking, I would say:
Q1: I do my best to create a new project. That's being said that this may not be a good option in some circumstances.
Q2: Restructuring the WBS has its own consideration. ex.: Its ties/links to a contract or agreement. Anyway, I've done this and it was successful. I am not recommending this without proper procedure.
Q3: I am not sure on this one. More details needs to be reviewed.
Q4: Merging is ok.
One general suggestion I'd make is to see if the information can be stored in an online repository such as a wiki rather than standalone documents. The benefit with that is you can reference the same data element through multiple different views (e.g. a risk from two different registers).
As far as modifying your WBS, it like every other output is expected to be "living" so the only consideration is if it has been baselined you'd want to follow proper change control procedures to update it to reflect the desired end state.
Kiron
...
1 reply by Samuel Morley
Feb 14, 2024 12:02 PM
Samuel Morley
...
Thanks for you suggestion Kiron. Indeed any re-organisation of the projects will be passed through change control.
Sam,
There is a lot to unpack in there but it is an interesting situation, and something that fits my experience well. Engineering integration is what I do, and I like to think I do it well. It sounds like you are trying to merge 2 projects and manage them like a program.
Let me jump straight to Q4: Merging the WBS is fine IF you are not so far along that it will throw everything into chaos. In engineering, the WBS becomes the taxonomy used to organize everything Re-organizing the entire breakdown structure can pay big dividends, or it can cause extreme disruption. Think about if you were mid project, and someone reorganized the entire file structure on your servers where you had all our project information.
The WBS becomes the formal architecture for organizing a lot of business data. What you're going to do, how much it costs, what personnel are involved, requirements, functions etc. is all easier or harder to manage depending on how you organize it. What is best for one team or function is worse for others so compromise is inevitable. Every time you have to convert one set of organization to another, it requires a decoder ring that is both expensive and prone to error.
Once you are about 25% of the way through the project, re-organizing everything becomes a bigger problem than you were trying to solve and a VERY expensive decoder ring.
What you can do however is break out Engineering Integration into its own function. That is how it is done many places, including at NASA and the DoD where the idea of the WBS was 1st invented. If you were to organize your projects by function, you would typically see chemical, civil, electrical, etc, broken out into discrete functions along with integration or Systems Engineering. If your problem is integrating 2 different projects, you can break just Integration into it's own branch of the WBS without disrupting the entire rest of the organization.
...
1 reply by Samuel Morley
Feb 14, 2024 12:15 PM
Samuel Morley
...
Hi Keith, thanks for the advice. Well the project is further on than 25%, more like 50% complete. So as you say, re-organising completely is more challenging, and in this case would ruffle some feathers of the key stakeholders (especially since they are separate government funded projects) and the plans we have in place with them are very rigid.
I will pull out the integration work into a separate data sharing space, and the contract will cover it accordingly. This shouldn't be too painful and the team i think can easily get to grips with it because it is logically a separate package of work shared by both projects' systems. I will just have to continue to dice up the costs 50-50 between 71 and 72, whilst the deliverables will be shared/submitted to both stakeholders.
Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Sam, you are putting in a lot of passion, so I think you will succeed
Q1 Since you decided on this approach already, stick with it but adapt when necessary.
Any approach carries its risks
Q2 sure
Q3 One repository sounds great. Consider the cost vs the benefits (clarity)
Q4 Absolutely, it is not retired. It is moved
Saving Changes...
Samuel MorleyProject Manager, CEng MIET | PMPWolverhampton, Shropshire, United Kingdom
Feb 13, 2024 10:51 AM
Replying to Kiron Bondale
...
Sam -
One general suggestion I'd make is to see if the information can be stored in an online repository such as a wiki rather than standalone documents. The benefit with that is you can reference the same data element through multiple different views (e.g. a risk from two different registers).
As far as modifying your WBS, it like every other output is expected to be "living" so the only consideration is if it has been baselined you'd want to follow proper change control procedures to update it to reflect the desired end state.
Kiron
Thanks for you suggestion Kiron. Indeed any re-organisation of the projects will be passed through change control. Saving Changes...
Samuel MorleyProject Manager, CEng MIET | PMPWolverhampton, Shropshire, United Kingdom
Feb 13, 2024 8:53 PM
Replying to Keith Novak
...
Sam,
There is a lot to unpack in there but it is an interesting situation, and something that fits my experience well. Engineering integration is what I do, and I like to think I do it well. It sounds like you are trying to merge 2 projects and manage them like a program.
Let me jump straight to Q4: Merging the WBS is fine IF you are not so far along that it will throw everything into chaos. In engineering, the WBS becomes the taxonomy used to organize everything Re-organizing the entire breakdown structure can pay big dividends, or it can cause extreme disruption. Think about if you were mid project, and someone reorganized the entire file structure on your servers where you had all our project information.
The WBS becomes the formal architecture for organizing a lot of business data. What you're going to do, how much it costs, what personnel are involved, requirements, functions etc. is all easier or harder to manage depending on how you organize it. What is best for one team or function is worse for others so compromise is inevitable. Every time you have to convert one set of organization to another, it requires a decoder ring that is both expensive and prone to error.
Once you are about 25% of the way through the project, re-organizing everything becomes a bigger problem than you were trying to solve and a VERY expensive decoder ring.
What you can do however is break out Engineering Integration into its own function. That is how it is done many places, including at NASA and the DoD where the idea of the WBS was 1st invented. If you were to organize your projects by function, you would typically see chemical, civil, electrical, etc, broken out into discrete functions along with integration or Systems Engineering. If your problem is integrating 2 different projects, you can break just Integration into it's own branch of the WBS without disrupting the entire rest of the organization.
Hi Keith, thanks for the advice. Well the project is further on than 25%, more like 50% complete. So as you say, re-organising completely is more challenging, and in this case would ruffle some feathers of the key stakeholders (especially since they are separate government funded projects) and the plans we have in place with them are very rigid.
I will pull out the integration work into a separate data sharing space, and the contract will cover it accordingly. This shouldn't be too painful and the team i think can easily get to grips with it because it is logically a separate package of work shared by both projects' systems. I will just have to continue to dice up the costs 50-50 between 71 and 72, whilst the deliverables will be shared/submitted to both stakeholders. Saving Changes...
"When one door closes another door opens; but we often look so long and so regretfully upon the closed door that we do not see the ones which open for us."
