Ongoing Processes: *Current* Project, Aging, and Archiving Best Practices

English Forum Tips and Tricks Forum Leaders tips
, ,
1

Do you annually recreate some projects so you can update for the new year, like 2023 Marketing Requests? Or even worse, frequently recreate monthly or weekly projects, for example, Week 24 Dev Sprint?

Stop that! (I’ll explain . . .)

For ongoing process projects, like a marketing or operation team’s workstream, where work flows in, is actioned, then completed only to be replaced by more work, there’s a simple tweak you can make to simplify and clarify.

Just recast that project instead as “evergreen.” Remove the year (or month or week) from the name and just call it Marketing Requests (or Current Marketing Requests if you prefer).

If you think that “renaming a project” is not much of Forum Leader Tip, well consider that it has just saved you from having to update all reporting dashboards, saved search reports, portfolios, the project URL itself which may be in bookmarks, intranets, and emails, and who knows what else by effectively making something static that you previously changed regularly.

You may have noticed there’s a catch, unless you have very low volume: Your evergreen project will grow and grow, and you might want to age tasks from it annually, say, both to keep performance fast and perhaps to make reporting easier too.

You can annually create 202x Marketing Requests aging project, or even just a single Marketing Requests Archive to hold the aged off tasks. Either sort+filter the project or use advanced search within the project to group and multi-select (in batches of 50) the completed tasks to be aged off by re-homing them (replacing the project membership) to the aging project. Having batches of tasks already in separate aging projects may simplify reporting and metrics.

By having evergreen projects, the more frequent, day-to-day active-oriented searches and reporting needs are now streamlined.

Thanks,

Larry

9 Likes
2

Great post Larry! Sound advice for ongoing processes!

I’m just curious, hoping you could expand on this part a bit:

I find that leaving completed tasks in an ongoing project provides statistics in Dashboards that a manager or leader would want to know, eg. how many tasks have been completed over time etc.
By moving old completed tasks into an archive project, they would lose this visibility of the past, right?

3

@Richard_Sather,

Thanks for the compliments!

Re the question on aging projects: As I’ve allowed, if you don’t need to age, then don’t; that’s certainly less work.

But if you do need to for performance reasons, or you find it helpful to match work to a time period because that’s how you like to metrics, separate projects may facilitate that by knowing the time period is already split out for you. For example, current year-to-date marketing requests are in Current Marketing Requests, last year’s are in 2022 Marketing Requests, etc. For metrics across all of history, Universal Reporting could apply to the Marketing Requests team in which all these projects are found for reporting like you mention, e. g., tasks completed over all time.

Hope that makes sense,

Larry

1 Like
4

Yup, makes perfect sense, thanks! :wink:

1 Like
5

I created a “Historical Tasks Project” then used a special Section that automatically moves any task switched to that section in the source “evergreen” project to the “historical” project. I put warning emojis (:rotating_light: :zap:) in the section title and placed a task (before making the auto-move rule) that warns as well plus has documentation in the task’s description.
Why?
You can multi-select (up to 50) tasks then use the up-down arrow to switch to that section which moves them to the historical project’s “inbox” section. I then create sections in that historical project to keep things organized. You don’t need advanced searches or special keywords and you don’t worry about accidentally mixing projects. If you want to, you could manually change the rule to move to a specific “annual” project when the calendar flips.

The Section and “warning” Task look kinda like this in Asana:

:rotating_light: Move to Historical Project :rotating_light: :zap:
:rotating_light: Items moved here are moved to “Historical” Project :rotating_light:

The rule also clears Assignees and moves them to a special “Done-by” field so that old tasks do not show up in “My Tasks” but we can still track who was responsible.

Note: like all Asana moves, meta-data (like tags, stage, and priority) for the moved Tasks, moves with it. So before moving a set of Tasks we add a ‘version’ tag to them.

2 Likes
6

:thinking: Clever. I was using a ‘evergreen’ project as a staging ground for our development team. Maybe I have that inversed.

2 Likes
7

I’m interested in your setup. You mention that…

you could change the rule to move to a specific “annual” project when the calendar flips

I don’t see in Asana rules where a ‘When’ or ‘Check if’ trigger can include an ‘if current date greater than X date’ statement? I see if due date changed, approaching or overdue, but you seemed to imply that the trigger could be a general current date change.

Did I interpret something incorrectly or am I missing something in Asana? Thanks for your help.

8

Apologies for the late reply. I don’t do this automatically. I create a “Historical Project” that I move tasks from my main project into. I use a special section + rule to enable this to happen (see below). So when a Task is moved to that special Section it is moved to the new Project. We do this move as we make a build. The “Historical” project is going to get too big and unmanageable so I will name it something like “Historical 2024” at some point.
So the “calendar flipping” means you would need to manually change the rule to point to a new annual project like “Historical 2024” so when you use the rule it points to the right place.

Move to Section => Move to Project Work-around
Since it is very cumbersome to move a Task to a new Project, I created a special section that when a set of Tasks are moved to it (up to 50 at a time), they are moved to a different Project. I made a “warning” task before the rule that let’s people know what will happen. So it looks kinda like this in Asana:

:rotating_light: Move to Historical Project :rotating_light: :zap:
:rotating_light: Items moved here are moved to “Historical” Project :rotating_light:

The rule also clears Assignees and moves them to a special “Done-by” field so that old tasks do not show up in “My Tasks” but we can still track who was responsible.

9

@JeffreyR,

Nice!

Is there a reason you don’t just mark the tasks complete and skip the Done-by part?

Thanks,

Larry

10

They are marked “complete” but that does not remove them from “My Tasks” list. Obviously you can filter out completed tasks from “My Tasks” but by doing the Done-by you actually get a compact view even when looking at “My Tasks” completed Tasks. So that way you can figure out what you have done recently. We use release version “tags” to link to your release notes. So this way you can make sure you have them tagged.

1 Like