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

6 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 change the rule to move to a specific “annual” project when the calendar flips.

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

2 Likes
6

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

1 Like