Question about number of project request templates

[ChristianeRo1]

Wondering if I can pick everyone's brain on here for some best practices. My team is in the process of onboarding Workfront, and we're going through a piloting phase where we're learning what is/is not working before we fully launch. 

Our current setup, based on the recommendations from our Onboarding team, was to have two different types of project templates, one for a Multi-deliverable project and one for a single-deliverable project. 

Multi-deliverable was supposed to be for when someone has a project or marketing campaign that has a number of different deliverables (think email, social post, landing page, etc.), where single deliverable was for when someone only had one final deliverable (and this deliverable could have different components, like copy generation or an image that needed to be done for a final flyer deliverable). 

Our Multi-deliverable project has a custom form with a multi-select field where people can select as few or as many assets as they need.

Our internal Workfront admin team is wondering if having this setup even makes sense to have the projects divided up like this. Would it make more sense to just rename the multi-deliverable project type to just "Project request" and do away with the single-deliverable? Will having this setup be confusing for folks?

Any and all best practices or tips appreciated!

[Lyndsy-Denk · Accepted solution]

You're tapped one of the perennial philosophical debates. The short but complex answer is that it depends on your needs, preferences, and project owner capabilities.

I'm a fan of one project per deliverable. In this approach, my PMs have pushed back because there are sometimes activities done in bulk for multiple, related deliverables. In that case, I recommend a "parent" project. The deliverable projects then use cross-project predecessors to read the parent project and schedule accordingly.

• Pros: I find that this approach makes reporting simpler. For example, counting assets you've created is as easy as reporting on qualifying projects.
• Cons: Some people find cross-project predecessors unintuitive or difficult. Also, in our instance we have so much traffic that overnight timeline refreshes don't happen by design. Fusion would take care of this problem, but we don't have Fusion.

If you go the direction of a monster project with multiple deliverables, I recommend a parent for each deliverable with a custom form to break down the asset types and other details you need. Recently the Customer Success team invited me to share my approach because the PMs I admin for prefer the monster template approach.

[ChristianeRo1]

Thanks @Lyndsy-Denk! Very helpful, especially as it seems our current setup is doing ... both kinds of things. We have the monster project, and we have separate sections of the custom form that indicate what people need from each "deliverable" -- but we're noticing more and more that people are having issues with two things:

1) Things coming in piece by piece that probably should be handled by our monster form, but aren't because people don't know they exist and

2) People are having difficulty with the concept of what specifically constitutes a deliverable. 

I will check out the event you linked! I am sure it will be incredibly helpful. Thanks for the reply. 

[Lyndsy-Denk]

We've struggled with part 2 as well. One place we landed:

• Technically a deliverable is one asset of a specific localization (that is language and/or geographic-specific content).
• Because we often try to generate localizations of an asset simultaneously, there is a lot of pre- and post-work that is lumped together for the localization effort. Therefore a monster project for localization makes sense for us.

Where my philosophy branches is with a campaign of multiple asset types. If you have pre- and post-work in bulk, then a monster project might make sense. Sometimes that is a little awkward, though, when there are multiple asset types, especially if they aren't dependent on each other. Not a lot of my project managers agree with me (mostly because they find cross-project predecessors difficult), so we have monster projects that include multiple asset types and localizations. For example, the key asset might be an email, but the email needs a landing page and two different follow-up emails depending on audience. Or the key asset might be a whitepaper, but there are additional assets to help draw attention to the whitepaper.

Another template model to consider is to use primary templates and add-on templates:

1. Your base template includes activities for kicking off the project and developing the central asset.
2. Add-on templates can be added when there are supporting assets depending on circumstance.

Thinking about the example above with the email it would look like:

1. Email template, which is used for every email effort
2. Add-on for landing page work when the email needs a landing page
3. Add-on for follow-up emails when the primary email needs follow-ups