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

[SarahWo]

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 

[RandyRoberts]

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.

[SarahWo]

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. 

[KellieGardner]

Interesting approach Randy. 

Do users have to mark items complete in both the master project and each deliverable project or are you able to map them together somehow?

[Lyndsy-Denk]

That's my question, too. It sounds messy having to maintain two projects. I'd rather use a task conversion process. Cross-project predecessors, however—I'm trying to find the secret to recalculating schedules more automatically.

I definitely support the concept of one deliverable per project for all the reasons Randy mentioned. In short, it's easier to measure how many deliverables are actually delivered. You can cancel a project with a couple clicks, and, if necessary reopen that project. In a monster project, there's no good way to reflect tasks that have been canceled.

[RandyRoberts]

You can use cross-project predecessors if you like but IMO, that makes it more complicated than it needs to be. Say I have a master project (for instance, a meeting) with 3 sub-projects, an email invite, a presentation, and a manuscript. In the master project I have the planning of the meeting, timeline, etc. Then I have 3 tasks, one for each deliverable with a start and end date. I can check those tasks as done when each deliverable is finished. If I wanna be fancy (and complicated) I can create cross-project predecessors, or I can just check them off when I know the sub-projects are done. Sometimes cross-project items are more work than they're worth. They have their place and thier worth but IMO, and in this case, it's easier just to mark the deliverable as done when it's done seeing as how you're in the master project every day anyway. You are checking each project every day, right?

[Lyndsy-Denk]

Theoretically, sure. I, however, have project owners who push back if there is any amount of redundancy. Those redundancies also mess with our reporting, which sends leadership in a tailspin.

[RandyRoberts]

I only deal with technical and logistical solutions, not political ones. 

And the reporting is fine if you report on only what you need. I've been doing it this way for hundreds of projects and its been great.

[SarahWo]

I think the approach I want to go with is very similar to yours with one difference. I am planning on making the planning/strategy project the deliverable backlog with requests for each deliverable instead of tasks. So when they are ready to grab a deliverable they can convert the request to a project and we can scrub the reporting by the resolve ID. This conversation has been so helpful! Thank you. 

[Madalyn_Destafney · Accepted solution]

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!

[SarahWo]

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]

Agree, that's exactly how we do it.

[Madalyn_Destafney]

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.

[RandyRoberts]

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]

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!

[JillAc]

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.