Design patterns for organizing multi-organization Projects #

Recently, I needed to help plan a project that spanned across dozens of teams, as wel as product areas and VPs. My task was planning my team’s deliverables, but to do so, there were multiple pieces of information that one had to consider, including:

  • Estimates on the work my team would perform.
  • Timelines of our dependencies, and the dependencies of my team’s dependencies.
  • Relationships between these dependencies.
  • Stack ranking based on business impact.

The process was quite taxing, resulting in quarterly planning where we had to dig up all the context from previous quarters, find outdated docs, and go through a multi-day effort to get this information presentable to the senior leadership team.

From that, I’ve been working on some patterns and processes, built on our existing project management tooling, make it easier to produce these roadmaps and extract information.

These patterns work in most issue trackers #

I left this blog post conceptual intentionally: it’s because these are design patterns: ideas that can, for the most part, be applied to any issue tracking tool (Jira, Smartsheet, an in-house tracker).

Although a custom tracker may be written for this purpose, I think that these ideas are actually more useful as design patterns. Organizations almost always have decided on their project tracker of choice, and it’s impractical, if not infeasible, to replace that with a bespoke solution.

It’s much simpler to layer these patterns on top of existing trackers, allowing this project structure to leverage the knowledge in the issue tracker, rather than duplicating it.

The Patterns #

A structured graph of tasks #

I’ve seen attempts to manage large project planning in long-form documents, but once execution has begun, the individual projects and dependencies themselves are best off in a data structure: in particular, it should be possible to represent the tasks themselves as nodes in an acyclic graph.

This type of structure allows for multiple use cases, including:

  • Attaching common metadata to each node (like acceptance criteria, business impact).
  • Extracting the delivery date of a node based on the delivery dates of parent nodes, and including the effort estimate of the current one.
  • Visualization (e.g. gantt or graph style), helping one see what the real dependencies are.
  • Traversing the graph to find issues that apply to a particular category (team, org, product area)

Tagging over hierarchical structure #

Although it’s common to enforce a hierarchical structure on data (e.g. issues by team), I think tagging (e.g. Jira labels) ends up being a more useful approach.

Especially with tasks, there are so many different consumers that choosing a single structure certainly will not work for all of them. Consider:

  • The individual contributor who just wants to look at their issues, and maybe their teams.
  • The manager who wants to look at all projects for their team.
  • The director, who wants to look at projects for their team, and possibly others that they depend on.
  • The project manager, who wants to see all tasks that pertain to their project, regardless of the individual or team executing that task.

This, combined with products moving teams and teams moving organizations, creates change that makes organizational hierarchy at minimum a brittle choice.

With tagging, along with a convention around those, it should be very easy to create new roadmaps (just add a new tag to all relevant issues), add one-off issues to a view for the team or organization.

Spreadsheets for easy editing #

At Google, we had a giant table for bugs (likely implemented as multiple tables with foreign keys for custom fields) called buganizer. You can see a glimpse of what it looks like at https://issuetracker.google.com/issues.

A developer wrote a tool that would do a bidirectional sync to a Google sheet, thereby allowing us to:

  1. Easily review the data and fields in a data dense format.
  2. Visualize roadmaps
  3. Copy-paste the spreadsheet content into documents or presentations with leadership.
  4. Modify the fields quickly for project planning.
  5. Add new issues as we found dependencies or tasks missing.

This tool was absolutely amazing - it overcame the friction of mass modification and at-a-glance visualization.

Metadata to attach a node #

This is not a design pattern per se, but there are often specific fields in projects that I’ve found to be very useful in roadmapping discussions. Those are:

  • The business impact of the milestone: senior leadership will often ask about the cost-benefit of lowering the priority of specific tasks, and it’s helpful to understand why this is valuable.
  • Acceptance criteria: a good practice regardless of this post, but it’s valuable to be crystal clear on what you’re planning on delivering, and how to validate it has been delivered. It often discovers gaps in understanding or expectations.
  • A target delivery date: if there is a hard due date, it’s valuable to specify that.
  • An effort or wall time estimate, in a unit of time: this helps you calculate the actual time it would take to deliver something, based on the target date of a tasks’s dependencies.

Specify a target date, or calculate based on dependencies. #

A big issue with cross-organizational planning is figuring out how long it will actually take to deliver something. In an ideal model, the actual delivery date of something is the sum of the duration of current task, and the sum or the delivery dates of all of the upstream dependencies that will take the longest.

Therefore, two pieces of information are necessary to calculate such a date:

  • The duration of the actual task (also known as effort, cost, or other names).
  • The estimated delivery date. for example, an external dependency on a vendor, or hardware with target date at which it will finish being constructed. These commitments are generally dates, not based on some effort estimate.

Make project trackers fast #

The biggest killer to project management trackers is the speed or friction it takes to update them. If changing a single field requires five steps, or a page load takes a long time, those will both completely disincentivize people to fill things in as they go. Speed is a common reason I’ve heard, discussing the ideas in this blog post with colleagues.

Due to similar friction I’ve faced with documents anod knowledge bases, I just keep a bunch of markdown document in a folder for my notes. I opened it with VSCode so I can easily jot down notes - this is vastly faster than any web-based solution I’ve found, and I’m more likely to take good notes as a result.

Existing Challenges #

These patterns above provide a great structure for organizing this knowledge. However, this alone is not a complete solution for a well organized project.

I’ve enumerated some of the challenges below.

Keeping task metadata up to date #

Like any semi-automated system, the above is only valuable if the data is up to date. In my experience, individual contributors like doing the work, but do not like rotely filling in updates in project trackers.

Some patterns I’ve seen work, albeit sub-optimal:

  • Have a single project manager be responsible for ensuring tickets are up to date. Have a regular sync meeting where individuals give updates and update the project tracker live.
  • Communal updates: whoever happens to ask the question also helps update the tickets. This is not 100% effective, but does ensure that some updates occur.
  • Have a dedicated time, with a program / project manager as a driver, to ask everyone to update their issues.
  • Make it so that the issues are the only way to update management on the progress of a task: the forcing function will build the habit.

Again, none of these are completely effective, but do help.

Enabling deeper roadmap discussions #

One reason I believe people gravitate toward ad-hoc planning documents is because of how the document format (with some commenting infrastructure) allows for great long-form discussion.

Task tracking is traditionally quite bad at this - you can’t go comment on a specific aspect of an issue (e.g. one or two lines in it’s description), it’s hard to see the project overall without going to some other format like a spreadsheet, which may not sync data back upstream.

At some point, project trackers should start to support this use case.

Other thoughts #

Issue tracker should use a global id, not namespace by project #

Issue trackers like Jira namespace their issues with a project space (e.g. PRJ-001). I think a single global id is better, perhaps a sequential, monotonically increasing integer (e.g. Google buganizer). The metadata for which project an issue belongs to can live in some other field.

The reasoning is:

  • It’s easy to move issues from one team to another: links don’t break as renames happen, you don’t need to keep a table of old ids on the server side.
  • It’s straightforward to link issues to another: you don’t need to know which project it was in.
  • It simplifies any linking metadata, to have all issues in the same format (e.g. pattern matching for APIs and what not).

Final Thoughts #

I’ll be updating this periodically with some more thoughts, but I’d love to hear feedback on these patterns if you try them, or let me know about one what works for you!