How can I manage candidate projects and goals?
Asked by Matt_Stratford:

I am using Atlas fairly successfully to communicate updates about in-flight projects.

However, there is also a need in the business to also communicate what we *intend to do* over the next year.

(That doesn't mean that the projects and goals over the next year need to be fixed, but we need a future-facing plan even if it will change.)

Since there is no way to do this in Atlas today, I am using a workaround which is to create a project, leave it as "pending" and name it \`\[Candidate\] Project name\`.

But it really feels like I am working around Atlas here...

What I'd like to be able to do is the following:

* For **current** projects, track current *status* and *target date*and get nudged for weekly updates
* For **candidate** projects that have not started yet but are planned, track current *confidence\** and *target date*, do NOT get nudged for weekly updates

...and be able to see both current and candidate projects on the timeline view.

Am I missing something obvious about how to plan ahead using Atlas? Or should I be using another tool for this?

Matt

*\* For confidence, I think there's a set of intervals equivalent to "status", something like "might do this project" \> "likely to do this project" \> "committed to do this project".*


Answers:
author: Diogo Teles
body: HI [@Matt_Stratford](/t5/user/viewprofilepage/user-id/5171249)!

The only way to do that with Atlas now is to create a goal, set a target for a quarter far into the future (e.g. 5 years or another timeframe more consistent with your strategic planning) and leave it pending. Additionally, add a tag to it to group it (e.g., r\&d, strategic, people, finance, etc.)

In the use case of our company, where we are still trying out Atlas, we are in a similar position as yours. But instead of Jira, we use a confluence space for strategic projects with the first level of content with a page matching each org area of accountability, the next level down are project plans, and below that, docs related to the project (e.g. meeting notes, lessons learned, etc.). Once the project starts, we use Atlas for progress tracking and Jira for day-to-day work and team-level progress management.

comments: author: Matt_Stratford
body: Interesting, thanks for sharing. Your insight leads me to question whether my mental model is incorrect.

If I'm reading your response right, in your view Jira Atlas is currently more about **progress tracking** for projects that are happening "Now". Where I'm getting frustrated is that I want Atlas projects to be a functioning part of the strategic roadmap.

I'll share a bit of context.

I have been creating my roadmap in Jira Product Discovery (JPD) with loose time horizons Now, Next, and Later. In my mind, this roadmap describes what is important and why. It's strategic in the sense of providing an outline of the "how" we can win in our market.

In my head, that roadmap should principally comprise current projects and candidate projects for the coming time periods. For each project, I would like to attach high-level ideas on how we can deliver. The high-level ideas can then be linked to Jira Software delivery tickets (which show what we're *actually* delivering).

Instead, though, JPD seems to want me to organise on the basis of ideas, because when you tag an idea with an Atlas project it just seems to function as a piece of metadata. You can't add an idea to more than one project, and you can't "cluster" ideas by project very satisfactorily in the views provided. That's a problem, because candidate projects are a really great emergent way to organise ideas (one idea to many project relationship). Then when it comes to pick up a project, you already have idea options on how to do it.

Perhaps Jira Atlas is more of a counterpart to Jira Software/Jira Plan than JPD...


author: Diogo Teles
body: Thank you for the context info. There are no right or wrong ways of using these tools together, not yet, at least. You'll eventually find the best combination for the business. Atlas and JPD are still very new tools and are limited in scope. The common point is that they are both reasonably high-level.

From the existing documentation, Atlas is rolling out a stakeholder information management tool and JPD as an idea-to-project tool. At least, that is my perception of it.

The featured posts in the [Atlas Community Group](https://community.atlassian.com/t5/Atlas-Group/gh-p/teamcentral) are a good source of information on using Atlas. Have you had the opportunity to explore it yet? If not, I recommend giving it a try.

A bit more information on how we're using these tools

**Atlas**

As mentioned above, we are still testing Atlas in a closed internal trial. We created a goal aligned with one of our strategic objectives, split into sub-goals, each with around 10 contributing projects.

This is what it looks like on Atlas.

In the business, however, things play out differently regarding naming convention (there will be more alignment in the future if we decide to use the tool).

This is what it looks like in the business. The Atlas goal is one of our strategic objectives; this part is straightforward. The two sub-goals correspond to business projects (in the classical project-management definition of the project). Each Atlas project corresponds to the contribution of a specific team to that project. From a Kanban perspective, for example, we could say these Atlas "projects" correspond to Epics.

The project plans we have in confluence (they match what is classically called a project charter) are the "About" section of our sub-goals in Atlas. The About section of the parent goal is the business case for the strategic objective.

**JPD**

We have yet to use this, but it is being considered. I'll outline the use case that is on the table right now:

Our high-level projects follow the usual pattern you described, "now, next, later". It fits nicely with JPD. Using JPD in this context, we would add an idea for a project. It would mature in JPD until Delivery. We first consider strategic alignment/elaborate on it/research it, and assess its place within our 3-horizon model (discovery status). During this stage, we'll put together a business case.

Then we evaluate the business case (impact status) and approve or reject it.

If approved, we transition it to "Ready for Delivery" and give it a time frame. This stage is when the idea gets into the roadmap as either now, next or later. The "Ready for delivery" means we have correctly assessed the idea and want to deliver it. Its place on the road map reflects when we want to do it. Senior leadership would move it along the roadmap until it reaches "Now". At that stage, we start using other tools. We'll create a goal in Atlas that contains the delivery plan. Confluence will continue to host supporting documentation. We will create issues in Jira to drive the work and roadmaps at the team level. Once we know how to distribute work, we'll create projects in Atlas to contribute to the goal.

As soon as the first Jira issue hits "in progress", the idea in JPD is transitioned to "Delivery". When the Atlas goal is completed, the idea is archived.


author: Matt_Stratford
body: (NB: Can't see the pictures)

We have been using JPD for gathering all sorts of ideas from teams, not only using it for candidate projects. I like that it then serves as an "organisational memory" of discussions about ideas. It's also working out well as a collaboration space for ideas that we're exploring but not committed to delivering.

However, the point that ideas *can be* incipient projects is very stimulating. If I just consider that we create a project every time we have a big idea we're committing to implementing (or even doing discovery on) that is worthy of its own set of communication updates, I think that resolves the trade off.

I'm not in love with the idea that I can't easily frame up potential projects bottom-up by clustering ideas on a theme, but now with your help I have the realisation that Atlas is about communicating status and not building up options for projects to do --- rather, this can also live in JPD alongside other ideas --- I think there is enough flexibility in JPD to be able to set up custom fields to do this.


author: Diogo Teles
body: This ended up being quite an interesting discussion! There were no pictures in my post. The large empty spaces were to make that massive wall of text more edible.

I forgot to mention another use case of JPD, which will likely happen very short term. We're implementing Little Improvements From Everyone (LIFE) to capture suggestions from all team members across the business. We are considering JPD for this. Precisely to create the organisational memory you mentioned. If, down the line, someone suggests something we had already considered and not implemented, it will be easy to refer back to the first time the idea was reported and why it was decided against (or reconsider it in light of a change in circumstances). And to remind ourselves why we approved a suggestion in the past.

Thank you for sharing your experience with these tools. It is especially useful when we're still testing them out.