Parent/Child Projects

[#1]

I apologize if this is duplicate but I did not see it anywhere. We have a need to create parent projects that would live between the Program level and the current project level. While I understand that the work could be completed in one project using parent/child tasks we have many departments that would prefer to have their projects tracked separately. There would be many child projects which would roll up to many parent projects and into ONE program.

I saw some talk about this on the Global forum but that was it. Please help me vote up this feature request!

Thanks!!

Michael

[#2]

Elisa, we would love to communicate our needs for this. There are a lot of aspects to consider and the current work-arounds are very limiting. We would be happy to schedule into a conference call to share our thoughts.

[#3]

Hi Elissa,

Our team would also love to discuss this in more detail with you.

Thank you,

Marisa

[#4]

Thank you everyone for messaging me! I am going to set up some time to talk with those of you who responded about this. Currently, I've had 8 people reach out (which is awesome!), so I will post here if I need any more feedback in the future. Thank you!!

[#5]

Hello Lisa... Can you please include me!

[#6]

Hi Elissa,

I don't know if we're quite ready to have a call to discuss in too much detail, other than there's a general consensus that sub-project functionality (parent/child) would be beneficial. We recently created a PMO, and have a Director of PMO defining standards. Given the early stages of her work, we're not quite ready to elaborate more than the below.

I rounded up some examples that folks felt this functionality could help with:

1) Project ABC: within this project we built an authentication piece that was non-billable to the client but driven by the same timelines as the migration project. Impact to the account services team was that they had to manually remove the 'non-billable' component manually when reconciling (subject to user error). Also, testing was conducted at a shared level, therefore the client may pay for too much or too little because that is a shared task (billable and non billable).

2) Project DEF: As part of the strategic audit for our client, we had a separate work stream created in a separate project plan, and created a linked dependency in the Project DEF plan for 'one-line visibility'. This may have solved itself because even though it's a separate project plan to manage, the end date is visible. Don't know about scalability yet.

3) Project GHI: This will start with an internal project, non billable, and then as it details out, some activities will need to be billable to clients. So is our plan of action to create a new project plan for each billable client and link into the non-billable plan for visibility?

Hopefully this is helpful information when constructing this functionality.

Cheers.

Nick

[#7]

Hi Elissa!

Please include me as well!

Thanks

Tiffany S.

[#8]

Hi Elissa! Please include me as well!

Chris

[#9]

Count me in! This is on our top 10 list of requested features.

[#10]

I'd be happy to chat with you on this, Elissa.

Regards,

Doug

[#11]

Elissa,

At the moment I am more intrigued to know how people intend to use this functionality in depth, but on the surface we could just use the additional layer of categorizing for projects. So if you end up having a zoom meeting to discuss usage ideas, count me in.