Rounds of Review - How are you doing it?

[Daniel_Clarke]

I love to see the back and forth, full story of review rounds so we can identify bottlenecks directly through tasks, but it is more admin / tasks to work through. How do you prefer to structure you review rounds? Similar detail, more agile open ended Create Design // Receive Approval tasks? 

My preference:

• Create Design and Send Proof
• Receive Changes
• Create Design V2 and Send Proof
• Receive Changes
• Create Design V3 and Send Proof
• Receive Final Approval

[KarenCastens]

Hi Daniel!

We are a small Marketing team, and we used to do it like you mention, a task for every action. We recently switched and "smooshed" all of those steps into 1 task using Proofing. I attached a screenshot of a timeline Template so you can see.

In the "Deliverables" section, each task gets named based on what the deliverable is... so <insert name of design deliverable> becomes "Create Flyer for XYZ". Then it is assigned to the graphic designer. From there, all this happens in this same task:

1. Designer creates the first proof, uploads as a "Proof" and assigns it to the designated reviewer.
   • Reviewer receives notification of the Proof in their Approvals queue.
2. Reviewer marks up the proof with any edits, marks proof as either approved or changes required.
3. Designer makes edits, uploads a new proof
   • Reviewer receives notification of the Proof in their Approvals queue.
4. Reviewer (hopefully) approves at this point; if not, steps 2/3 are repeated.
5. Designer closes their task once the proof is fully approved and moves the document to Compliance for review in the "Approval" steps below.
   • Same steps happen there until we have obtained Compliance approval.

We have to have Compliance separated out due to how items are audited years later, but hopefully one day we can have that condensed down as well!

[Daniel_Clarke]

Love it! A few questions:

• What was the defining factor in the decision to "smoosh" them together?
• What is the maturity of your team?
• How detailed are you reporting needs, and if detailed, are you seeing success in pulling from proof data instead?

[KarenCastens]

1. Honestly, about 5 new people joined our team at one time, and they were all complaining about "too many tasks" -- so, to mitigate that, I sat up Proofing and we started doing it that way instead for that simple reason. I also attempted to use Approval Templates on the Task level, but no one seemed to understand that.
2. Our team is a mixed bag; we have about 5 people that are seasoned users (10+ years), but about 10 more that have only used Workfront for 2 (or less than) years.
3. We still pull the reporting data we need from a Task level -- we need to report on things like: What was the deliverable? What date was it approved by Compliance? Where did it run (if an ad, social post, etc.)? and we are able to extract that information from the Project Details section. So, I can't give an opinion on Proof data just yet! 

[Daniel_Clarke]

Interesting - I have experienced the junior team LIKING the tasks as it makes it almost brainless "read the task for what needs to happen next", it is usually the PM that doesnt like it if they have to go in and add rounds 4,5,6! 
I 100% use the detailed task view with proofing too. The proof reporting is still pretty limited and harder to see the bottlenecks there. 

I think the addition of the status like @AmyReilly called out makes the whole thing functional and still reportable to see some of the gaps... albiet a bit less detail than the send/receive tasks. 

[KarenCastens]

A lot of those "new" people I mentioned are pretty senior (just new to our team), I should have said that -- they thought it was too much administrative work to maintain so many tasks. But, junior people definitely liked all the tasks, that is for sure; thankfully they've adjusted & it all makes sense to them now, too.

Everyone on my team is their own PM, so I think that was part of the issue - we are not only the person working with the business partner/requestor, but also creating the project, writing the content, and project managing/adding tasks throughout the life of the project. We wear a LOT of hats 🙂

[Daniel_Clarke]

It is a burden to bear, but one that I actually prefer! Less hand-offs and more continuity on the projects and tasks.

Thanks for clarifying the sr vs jr situation - that one caught me by surprise!

[AmyReilly]

Hi @KarenCastens , @Daniel_Clarke ,

We put "all" of the work into one request, so our process is just like @KarenCastens described - but with a request instead of a task.  What has helped us with reporting is adding several custom statuses for the requests.  For example, we start with In Progress while the proof is being created, but then we go to "In Proofing" while it's being reviewed.  (Then, we have about 10 more custom status options to track the deliverable after proofing.) That way, we can use standard request reports to track the item's progress based on status - and we can dive into proof reporting if the item status is "In Proofing" and we need more detail about proof stages.

[KarenCastens]

@AmyReilly @Daniel_Clarke  Oh ditto to this! I left that out -- apologies. We change the status of the task to "In Review" (similar to Amy's In Proofing) so everyone knows where it is sitting.

[Daniel_Clarke]

We have some teams with basic processes using requests like this too - curious what led you down that road vs using projects + tasks? Was it anything that scared you off of that route or just purely did not need the extra detail/admin work?

[AmyReilly]

We are an engineering firm, and our requests that involve proofing are usually "problem ticket" type of items that arise over the course of a project and are different than the planned tasks inside of the project.  So for us, it was easier to just put them into a request queue attached to the project - gave us the ability to easily separate them out from the main project if needed for reporting.

Also, for better or worse, our old process before Workfront relied more on status changes than breaking out each item into multiple steps - so it was also a matter of just going with what had worked in the past.  🙂

[Daniel_Clarke]

Excellent differentiation - those are acting more like change orders for you on a project vs handling / changing your project plan / tasks / baseline. 

And those old habits die hard, but also a testament to the flexibility of Workfront - if it ain't broke... 😄

[Susan_Hart_DeltaDental]

Hello Daniel, 
Our project management team adds a 2.0 review task to the timeline if 'needs work' is selected by the approver. We are using document approval functionality on proofs. This allows us to keep a close eye on rounds of review and planned hours. Plus allows the project manager to review the proposed edits before prompting the team to make, keeping an eye out for scope creep and open ended questions.

1. Creative development (writer and designer)
2. Client review (project manager adds approver to proof)
3. Edits: client review (writer and designer)
4. Client review 2.0 if needed (project manager readds approver to proof

5. Edits: client review 2.0 (writer and designer) 

[Daniel_Clarke]

Thanks for sharing @Susan_Hart_DeltaDental! Sounds like you are well setup for the unified approvals change rolling out since you're already using the document approvals. 

How many rounds do you typically see on your projects? Feels like a 2.0 is guaranteed these days!

[TimWy1]

For our workflow on our basic "get me this deliverable by that date" kinds of projects, we have a general project template that includes Design Proof 1, 2, 3, and 4, along with a "finalize design" task for the designer to ensure they package and store files in the correct place for archiving. Each of those proof tasks has the previous proof task listed as its predecessor with a finish-start dependency plus a 2-day lag to allow for review time. The finalize task has dependencies on each of those design tasks, so if any of them are not needed, they can be deleted and the workflow timeline stays in-tact. 

Proof 1 and finalize are pre-assigned to a designer when the project is initiated so they can be aware of the final due date of their portion of the project just by looking at their task list. We have committed to not move to the next design task until a proof decision has been made. If a second, third, etc. proof is needed because changes are required, the PM assigns them the next proofing task and/or deletes the unnecessary ones if the proof is approved on one of the earlier rounds. Identifying bottlenecks is the trickiest part though, since proof reporting is sketchy at best in Workfront, and the actual reporting within "Proofing" is painfully slow and difficult. We try to stay on top of actual completion dates as design proofs are submitted and always use proofing deadlines. Using this method we can also report on just how many projects are requiring 3+ rounds of revision. Now determining whether that's because the designer isn't getting good direction or because they aren't good at designing is up to the data analyst... 😁

At one point in time, we had a team leader that insisted on having review tasks listed and assigned out to the reviewers/approvers like you mentioned, but that required the approvers/reviewers to mark an additional task as "complete" after they made their proof decision (you'll be shocked here...they never did that step). That clunky process also required the designer to assign those proof review tasks AND assign the proofing workflow for the team (you'll be shocked here...they never wanted to do that additional step too).

Hope that helps!

[Daniel_Clarke]

Haha I hear you on the extra steps @TimWy1! As a former designer, I have no idea why they wouldn't want to!

I like the idea of having task one assigned, and supported by the final design task. Are you utilizing workload balancer / resourcing? If so, does missing the tasks in the middle throw a wrench in your planning? I feel like making the assignments to the "average" number of proof tasks gives a better picture, and gives a bit of head cover to the designers... curious how you manage that.