Solved

How are you guys grouping work? Pros and cons of one deliverable per project.

Forum|Forum|2 years ago
April 13, 2023
5 replies
5143 views

Hi guys -

We are currently only using projects in Workfront and I'd like to get us to start using more of the organizational hierarchy. Currently we track multiple deliverables in 1 project, but sometimes items that should be associated with that same work effort are then created in a secondary project and not linked. Or sometimes one project will have multiple items related to totally different work efforts. This is messing with our cost reporting. The goal is to get everything related into one centralized view with minimal impact to our project managers.

Programs seems like the most logical next step, but I also wanted to get thoughts on the 1 deliverable per project method to see if that may also help our teams consistently track items back to programs.

edit: Additional context - we are a marketing group

Thank you,

Sarah Wood

Workfront

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

Best answer by Madalyn_Destafney

Hi Sarah, I've been in a few different orgs with both approaches - multi-deliverable projects vs. one project per deliverable (with different nuances). Of the different approaches I've worked in as both a PM and as a WF Admin responsible for reporting, the best approach in my opinion was:

- Things that are multi-deliverable like an event, a campaign, etc. are a Program under the appropriate portfolio. So the name of the event, campaign, etc. is the Program name. The different deliverables are projects within the program, with a naming convention of [deliverable]: [description]. Ex: Press Release: Grand Opening, Social: Earth Day, Email: Org Announcement, are all projects. Each project has their own tasks for that project's deliverable.

- Note there is a level of combination within this scenario. For example, a blog post is 1 project. The copy, image sourcing/sizing, and publishing are all covered in tasks within that project, not 1 project for the image, another for the copy, etc. Same with things like digital ads, 1 digital ad project would house the creation of the various sizes.

- This makes it very clear when going into any program and seeing the listed projects when the timing is for each, overall % complete, and with the naming convention, it is clear to see what is what.

- Things that are not multi-deliverable like an ad hoc social post, the random flyer, etc. are not part of a program, but are still under the appropriate portfolio.

Hope this helps!

RandyRoberts

Community Advisor

We mandate one project per deliverable and for grouping, we use programs. Multi-deliverables mess with your timelines. What if one is late and the other 5 are not? Is the whole thing late? What if one gets cancelled and you have to re-adjust your timeline? How do you calculate overages and delays when there are several deliverables? Which one or ones are at fault? it makes things a LOT harder to analyse and interpret when you have to weed through several deliverables.

We do one master project that has start and finish for each deliverable plus anything that applies to all. Then each deliverable has it's own project that matches the start and finish dates on the main project. Then they all go in the same program.

S

SarahWoAuthor

So, almost like a planning project to do research, define requirements, etc and then smaller projects for each deliverable? All those would then map back to a program.. Interesting approach. We do embed our discovery into our projects, so that may be something that we need to discuss as a planning project. What you laid out is exactly why I want to change the way we are organizing our work. We mitigated some of the issues through forms on each parent task and each parent task is the deliverable, but it's still messy.

Madalyn_Destafney

Accepted solution

Community Advisor

Hi Sarah, I've been in a few different orgs with both approaches - multi-deliverable projects vs. one project per deliverable (with different nuances). Of the different approaches I've worked in as both a PM and as a WF Admin responsible for reporting, the best approach in my opinion was:

- Things that are multi-deliverable like an event, a campaign, etc. are a Program under the appropriate portfolio. So the name of the event, campaign, etc. is the Program name. The different deliverables are projects within the program, with a naming convention of [deliverable]: [description]. Ex: Press Release: Grand Opening, Social: Earth Day, Email: Org Announcement, are all projects. Each project has their own tasks for that project's deliverable.

- Note there is a level of combination within this scenario. For example, a blog post is 1 project. The copy, image sourcing/sizing, and publishing are all covered in tasks within that project, not 1 project for the image, another for the copy, etc. Same with things like digital ads, 1 digital ad project would house the creation of the various sizes.

- This makes it very clear when going into any program and seeing the listed projects when the timing is for each, overall % complete, and with the naming convention, it is clear to see what is what.

- Things that are not multi-deliverable like an ad hoc social post, the random flyer, etc. are not part of a program, but are still under the appropriate portfolio.

Hope this helps!

If this helped you, please mark correct to help others : )

S

SarahWoAuthor

Yep! That's exactly what I'm thinking. It's a much different approach for our teams so I am anticipating a little bit of pushback, but it's going to be the best way to get our leadership reporting buttoned up. Thanks for you response!

RandyRoberts

Community Advisor

Agree, that's exactly how we do it.

Madalyn_Destafney

Community Advisor

I saw your approach and it's very similar! I think only difference is we didn't have a separate master project, just a program and the projects within are the deliverables/all tasks are for that respective deliverable in the project.

If this helped you, please mark correct to help others : )

RandyRoberts

Community Advisor

With some types of projects we don't really need a master project but for things like a trade show or a product launch event, there are tasks that don't really have deliverables, like planning, booking venues, etc. We use the master for those types of tasks and we just toss in the single task per deliverable so everything is in one place. So yes, I think we really have the same approach and would recommend it to others as well.

Madalyn_Destafney

Community Advisor

We used to have only the tactile things in the program like the assets, but as they matured we starting also putting the planning-related things in there too as deliverables themselves, like different event planning projects or marketing campaign messaging projects as part of the program's projects, so Messaging: XYZ Campaign, Event Planning: WEF, etc. and that really stepped up their game bc so much goes into planning and they should be treated as a deliverable in themselves. I recommend this to groups looking to mature their WF use beyond just executional/tactile projects!

If this helped you, please mark correct to help others : )

J

JillAc

Level 10

I have an example of how I manage this with cross project predecessors that I find works pretty well, though the situation is slightly different. I find using Programs gets complicated and my team has trouble incorporating that additional level into their views, so I gave up on using it in any meaningful way. However, we don't do many things that are campaigns with multiple deliverables to track, so it's slightly different than what you describe.

We have dozens of clients who we create multiple different deliverables like a brochure, video, email, flyer - any combinations of these things that are personalized to them. I create a Campaign project for each client and the year that the thing is happening (so I will have a separate campaign for Client ABC 2023 and Client ABC 2024) . The campaign project is structured from a template that includes all the variables - Parent Task for each marketing type (brochure, video, email etc) with appropriate child tasks that are very high level. When I create each client campaign project I delete the sections that aren't applicable so it is consistent across all client campaign projects. I have milestones on each parent task so that I can view all the clients and what we are creating, as well as their progress in a milestone report.

The Parent tasks are 2 types:

1 - Brochure or Email -those are more complicated and have to be their own projects, because they have multiple tasks required to complete with multiple people who have to work on them. So I create one task per brochure or email and at the same time create the brochure project and link them together via cross project predecessor, so progress and due dates are aligned. I put the URL for the brochure project in the Description field on the master campaign project.

2 - Flyer or something else simple: Parent with maximum 3 tasks that are the basic things that need to be done, and the master campaign project is where these are held. Tasks are like this 1-create the brief 2-create the thing 3-approve the thing

This means that each client (or in your case project) has a master project list that shows in summary all the things that have to be done, can be viewed in a milestone report, and includes links to the more complex projects if you need to see more detail.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded