How do you handle a sole request with multiple deliverables?

[ljanz]

I work an in-house creative services department. We have a request intake form that we convert into projects. Sometimes the request has multiple deliverables. I'm wondering what would be the best practice to handle these two different scenarios.

1) In some instances, it makes sense that the sole request with multiple deliverables should really be separated as individual projects. I don't suppose you can create multiple projects from one request, so I'm considering copying the original request into multiple requests (updating them with a new applicable name and description) and then convert them into individual projects to address each individual deliverable. Any other ideas?

2) Sometimes when the sole request with multiple deliverables comes in, it is just extra work for them to be separate projects in terms of tracking and proofing. An example here is that a web ad request comes in and there are 5 different sizes. It doesn't make sense to have a separate request or project for each size as they are all essentially the same,. However, it would be nice to know that 5 ads were created and that is a data point we currently are not tracking. Does anyone have a scenario like this where you have a custom field to include number of deliverables or something similar?

Looking forward to hearing what others do in similar situations!

[Heather_Kulbacki]

Hi Leah,

We have a couple different scenarios that align with your first item.

1a. Campaigns - these for us might be a little different than you're describing. We have a request come in for a campaign which we convert to a project, the we set up a request queue to route the individual campaign tactic requests into that project. Those individual requests generally have additional information specific to that tactic and they get converted to projects of their own. Additionally we have a "campaign number" field, and all the individual tactic projects plus the campaign project all have the same number in that field to tie them together. This way the team can use that number to refer to the original project if needed

1b. Photography requests - we might get 1 request asking us to photograph 200+ individual products - that's a bit too many to copy one at a time. Also generally the details for each product are on a spreadsheet. So we have a template for a kick-start where we can put all the details for the individual products, plus columns for any information pertaining to the entire request such as requestor name and any info about them that is needed on each request. Then with the Kick-Start we create individual issues for each product that needs to be shot. This method allows us to treat each of the items from that original request as their own request.

2. Things like web ads, we treat as one request and train our designers to provide all the sizes needed for each ad type. The "ad" is the deliverable, the various sizes are just something the designers know they need to create.

[AnthonyIm]

Hi!

At my former agency...

• For 1, we usually converted the main request into the "Creative Development" project which included the Discovery and Concepting phases. We would then create a Program for that campaign and then all the various tactics were created as different projects in the program. (NOTE: Each project did have a field for Job Number so we could tie the info together in our financial system, but each project did not have all the details from the original request. Just wanted to be clear.) We would then utilize Cross-Project Predecessors on those projects so if the concepts were running late, it would push the schedules of the tactics. For reporting, we could use Program or Job Number to tie the projects together, but we could also use the projects to see how many websites, banner ads, print ads, OOHs, etc. etc. we had as each tactic was a separate process.
• For 2, like Heather mentioned, we considered the banners just one Banner Project and then just listed the various sizes that were needed for the designer. We didn't consider them 5 different ads.

Hope this helps :)

Heather - your approach to the photography request is interesting. We just had people put a link to an Excel Online spreadsheet (we had Office 365) in the request, and then the team would update that with comments or say that it was done for each photo. (Although the photos themselves were uploaded to WF so that they could be routed as proofs and approved by the right parties.)

[Heather_Kulbacki]

We went the separate issue route for each product to be shot for a few reasons...

- the team wanted to use a kanban board to track their work and especially their backlog. Which would have been real rough with spreadsheets from each request

- we also wanted to bill for each product as they were complete and not wait for the entire request to be wrapped up - often the products themselves are shipping to us from suppliers and we rarely get all the products for a full request at one time, they sort of stream in. The separate issues allow us to pull a report of all completed issues and bill for what's done.

- we also wanted to keep Workfront as our system of record ;)

[SamanthaIsin]

@Leah Janz‚ On the note of multiple deliverables in one projects...

The desire to track that is something that was requested by our executive team members. In our case it was more common for social media posts since we typically have one job per brand per month for all the social posts they need anywhere from 3-15 usually). We created a simple manual text field called 'Number of Deliverables' and put that in our request form for SM. That way we have an accurate count of how many posts are being delivered since thee number of projects wasn't accurate.

It worked for us!

[JillAc]

For one of my groups I have recently developed a new way to handle this. They prefer fewer projects to manage so instead of breaking one campaign into multiples I created a template that has a section for each type of asset in a campaign (ie email, advertising, social media, print , video). When the request comes in I convert it to the project and delete the sections that don’t apply to that campaign. If something is more complicated, then I do create a new project and tie it to the main campaign project with a cross project predecessor. We also use requests from within a project so requests are tied to the main campaign project. It’s pretty tidy.

that said, I’m still after more than 2 years having trouble getting project managers to use Workfront to plan their projects. The creative team loves it because they are the recipients of the work not planning, but the project managers keep side spreadsheets and I can’t seem to train them on how to leverage this tool beyond proof. They can’t grasp predecessors and the waterfall effect of due dates. Every time they use must finish on for every task.. It’s the bane of my very soul.

[ljanz]

I hear you on the project manager side. I just did some interviews with them and they prefer having their own 'to do' list outside of WF.

[AnthonyIm]

Sorry about the adoption issues. Something that worked for two of my agencies... I told them that an executive saw their utilization was really up and wanted to get a daily report at 9am EST so he could see all the tasks due today and over due across the agency by person. [This was not true, but luckily I found some executives who would play along].

Because the report was automated and from Workfront, it really pushed the PMs to use Workfront. Now it didn't help with them always messing up the task constraints so nothing could reflow, but it at least got the info into Workfront. ;)

[TammyWe]

Hi Jill,

We've been in Workfront almost a year and have 4 project managers who each manage 20-30 projects on any given day. We adopted Workfront as a department (creative marketing department within a university) and there wasn't an option for them to adopt or not. Most of our projects are managed via waterfall, and they are pretty skilled at setting up projects with multiple deliverables and utilizing predecessors to manage the workflow. The problem we have is keeping up with the deviations to the plan that happen on a daily basis. We really want to rely on the Workload Balancer to see who has capacity to take on unexpected requests, but it's usually not reflective of reality. Just keeping up with everyone's assigned tasks and shifting hours from one day to the next to be accurate is very time-consuming. If you allocate 6 hours for design across 3 days, it very rarely happens in 2-hour increments for 3 days. That said, I'd be happy to share our experience of training the PMs in project planning.

[AnthonyIm]

Hi Tammy - not sure of your org's size. Any chance you have the ability to move the hour shifting and contouring to a Resource Manager or a Department Lead? At my last company, when we moved the hour shifting away from the PMs, that really helped. Now, PMs still had to make sure that tasks were updated to the right dates and to update total planned hours per assignee, but at least contouring and reassigning to other team members were up to the Department Leads and RMs. {NOTE: The reason the PM still owned total hours is because they were responsible for the project's budget and so if someone needed more hours, they were in the know and could figure out which conversations needed to be have}

Again, I know this is harder for smaller orgs, but wanted to share :)