Making The Initiatives

Back when I was an engineer, I never really cared about projects. I just wanted to know what thing I needed to do and when it needed to be done by, and those things were smaller than a project.

Once I graduated to being the manager of a single engineering team, I cared about projects a bit more, but I was still pretty focused on the aggregate list of stories and tasks that my team needed to execute.

These days?

It's pretty much all projects all the time, because that's the unit of work that makes the most sense to me. Anything smaller than that is better managed by someone else, someone who is closer to the actual implementation than I am, so I try to stay in my lane.

But sometimes, in order to create the outcome that I want, I need something bigger than a project.

Projects Alone Can't Protect Us

Projects are great, but I find that they have an upper bound on how much work they can effectively encapsulate, in a similar way to how you don't want your stories or tasks to get too big.

In addition, a project can really only be owned and executed by a single team.

You can get multiple teams to contribute to a project, but the more teams are involved, the higher the communication overhead and the more likely that there will be conflicts and confusion and all sorts of other issues.

So, there exists a need for a body of work that is larger than a single project, which is what I have taken to calling an initiative.

An initiative is simply a set of projects that aims to achieve some greater goal and is typically spread out over multiple quarters and involving multiple teams.

Reasoning about the overall status of an initiative requires that you can reason about the status of the projects within. If you're already maintaining a project backlog, then you've solved half the problem already, because you know what your projects are and what state they are in.

The other half of the problem is tying everything together.

We Need To Do More

I've gotten quite attached to using Jira Product Discovery (JPD) as my project backlog, so any way of tying initiatives to projects naturally involves that tool.

Originally, I recommended using a themes or goals field in JPD to tie projects together into initiatives, but I've found that muddies the waters a bit around high-level goals, making it hard to differentiate the two things.

Taking the thought a step further, you could have a dedicated field for initiative, where users can select from a curated list of values, but that still requires either an administrator to maintain the list or runs the risk of growing uncontrollably.

Yet another variant is using labels, which is at least less heavy from an administrative point of view, but more vulnerable to an explosion of potential values unless the people you work with are disciplined.

Instead, I recommend leveraging one of the newer features in JPD to create issue types and to create a type specifically for initiatives.

This allows you to create a new ticket for every initiative, leveraging all of the fields that you currently use in your JPD project, while still clearly distinguishing them as a different sort of work. It also means that you can easily filter them out from views where they are irrelevant, like team-level quarterly planning views.

The best part is that JPD also offers connection fields, which you can set up to create bidirectional links between the initiatives and the projects that they contain, distinct from the normal Jira work item links.

There are some limitations though.

For starters, when you're configuring how the list of connected tickets is displayed, you can only select a single field from your project, which is somewhat limiting.

This can be worked around by simply creating a specific view for the initiative though, with the initiative ticket itself as a filter, which you'll probably want to do anyway to see all of the projects as a roadmap or timeline.

The second limitation is a bit more annoying. Connection type fields are a beta feature, which means they aren't available by default, but you also can't enable them unless you have a Premium licence :(

No workaround for that except paying money.

Get Some Rest

Continuing the downer vibe, there are challenges with the general approach of providing more structure around initiatives as well.

The first should come as no surprise, and it's that actually getting everyone to follow the process is hard.

I get it, people are busy, and taking the time to learn something new can be a challenging ask when you have so much stuff to do that any time not spent doing that stuff feels wasted.

As with anything like this, the key is persistence and assistance.

Reinforce the new process in anything that you do, whether it be casually mentioning it during relevant forums or just embodying it in whatever you yourself are doing. The more familiar people are with it, the more they know about it, the more likely it is that they will just do it.

But don't stop there, because if you notice someone doing something the old way, just offer to help them do it the new way. It's much less mentally exhausting to do a new thing when you have someone literally sitting with you helping out.

The second challenge is more specific to the process itself, which is that Jira Product Discovery doesn't really fit a hierarchical model all that well.

JPD is great, don't get me wrong, but it gives the vibe that it's meant to be a flat list of things that you can choose to slice and dice in a variety of dimensions (aka fields).

That means that if you want to use it to represent a hierarchy, even a relatively simple one like initiative > project, it's not particularly good at it.

Obviously the different ticket types and connection fields help, but the reality is that if you really want to capture a hierarchy of stuff, you probably just need to use a full-fledged Jira project, because it does all that stuff and has for a very long time.

We Have Some Big Decisions To Make

Initiative management is something that I've been thinking about for a while, so it's nice to get it off my chest.

Having said that, it feels like this is the sort of problem that someone else has already solved in a better way. I mean, surely I am not the first person to have run into the issues with reasoning about larger chunks of work?

Still, I didn't find anything appropriate in my immediate area within Atlassian, so I suppose that's reason enough to try and put something together myself.

You can't just wait around for someone else to solve your problems after all.

Even if they are infused with the powers of the Tesseract.