Looking for a way to take one intake request with multiple actions to split them into multiple projects.

[djmitchell]

Many of our marketing teams have a single intake form where intent requestors can ask for multiple actions and channels.  However, the work associated with the different asks and/or channels requires different teams and/or different levels of effort (and often a different template).  My understanding is that an Issue can only be associated with one project.  How are folks in the community managing this?  Thanks! 

[Jason_JB]

Hello - is Fusion an option in your instance?

We leverage fusion to take an inbound request and then create the needed project and pull in a number of related attributes. Based on your description, I'm picturing something similar that could create the multiple items and replicate requests, if needed.

[RandyRoberts]

That sounds pretty interesting, Jason. I've not toyed with that but I can see it being useful for split projects with multiple deliverables all related to a main project.

[KellieGardner]

Correct, that it's a 1:1 relationship.

In a past life, we would convert to a single project with parent tasks as the individual pieces of the project and then the sub tasks for those tasks to complete but we only had 1 project manager that managed them all. If you are going to have multiple PMs managing the different deliverables, you might have to play around with some access permissions to give everyone proper manage access.

Project Name

• Parent Task: Deliverable 1
  • Task 1
  • Task 2
  • Task 3
• Parent Task: Deliverable 2
  • Task 1
  • Task 2
  • Task 3
• Parent Task: Deliverable 3
  • Task 1
  • Task 2
  • Task 3

[ChrisStephens · Accepted solution]

I have built a very similar use case to this with Fusion. In the one that I think works the best, we configured it like this.

1. In the request form, there were several text fields. Each text field represented the type of deliverable they wanted, and then if they wanted multiple of the same deliverable they could add it in on a new line in the text field.

2. In Fusion, we then iterated thru each of the text fields, and in the text fields converted them to an array based on each line being an entry in an array

3. Then for all of those, a new project was created for each deliverable. Templates were based on which deliverable type the project was for, as well as some other criteria within the request form.

4. On each project, we copied down the original request metadata, as well as recording which request was the original request. Final project location was also based on information provided in the request form.

The end result was multiple projects, based on multiple and/or various templates, in different locations, based on a single request. Note that we preserved the originating issue with the project on a custom field, not on the default resolving object field, as that requires a 1:1 relationship.

[ChrisStephens]

A thought I just had on this, you could possible create a top-level project that resolves the originating issue, then in that project create issues for each deliverable, and make resolving projects for each of those. This way you could preserve using the built-in resolving object functionality, and would allow the permissions/governance granularity you would be looking for, but with the cost of having the overseer project someone would have to manage.

[RandyRoberts]

I like it! It would be worth testing it and then writing a procedure or cheatsheet.

[BrendaCh]

We are exploring a pilot (without Fusion) to use one request issue for multiple resolving projects. The idea is for the Stakeholder to submit a full campaign brief that multiple project managers will leverage for their specialized projects. Ideally we want to keep the one issue, but convert to project as many times as needed, and show all of those resolving projects in the original issue (breaking the 1:1 relationship).

[djmitchell]

Thank you everyone!  We are going to give this a try with Fusion