Project Maps and Progress

It’s been another exciting week for the G2 Components project! As of today, we’ve essentially completed the first of four phases for G2 x Gutenberg integration (the “Prep” phase). In addition to continuing design and development improvements, I’ve worked on expanding, clarifying, and refining the roadmap and task coordination efforts I mentioned last week.

For this post, I’m sharing my ideas on how tasks are coordinated and how folks can follow along.

The Project “Maps”

I think the most important aspects of planning and managing a project are:

1. Communicating the vision for the project (macro)
2. Communicating the tasks that need to be completed (micro)
3. Communicating what tasks depend on what (dependencies)
4. Communicating where we’re currently at (timeline)

The common thread is communication. It’s the most important factor in ensuring things run smoothly. It’s not about frequency, nor is it about effort. It’s about effectiveness.

I wanted to be as effective as possible in communicating the 4 points above to others. With that goal in mind, I eventually landed on 4 primary mediums for task planning and management. 4 slightly different but complementary mediums that help illustrate what needs to be done to successfully integrate G2 Components with Gutenberg.

The 4 mediums are:

1. A Roadmap View
2. A Project Board
3. A Chart View
4. A Flow Map (This one is interesting! More on that later)

Note: At the moment, the majority of tasks are development based. After the first project, my hope is for G2 Components to be more design-driven and design-led.

Roadmap View

Screenshot of the rough overall roadmap from Miro.

It starts with a high-level roadmap for how I’m envisioning how G2 Components would fully integrate with Gutenberg. It highlights (roughly) the primary tasks and features. From that, I “zoomed” into the first large project – introducing G2 Components to build the Typography Tools to help with the Global Styles/Full Site Editing initiative.

The idea is to provide a quick at-a-glance sense of what needed to be done.

Link to the Roadmap View

Project Board

Screenshot of the Phase 1 Github project board.

We’ll be using (Github) Project boards with a Kanban workflow to order and track the ongoing tasks. Github Project boards are a familiar tool for the community. They’re also right at the heart of where design and code is produced and reviewed.

The idea is to provide a zoomed-in/micro sense of a particular portion or “phase” of the project.

Link to the Phase 1: Prep Github Project Board

Chart View

Screenshot of the Gaant chart from Google Sheets.

I’ve created a spreadsheet (Gantt chart) that visualizes when the tasks would be completed.

The idea is to provide a sense of date and time.

Link to the Chart View

Flow Map

Screenshot of the Flow Map from Miro.

Lastly, for Phases 2 and 3, I’ve created a flow map to visualize the task dependencies. Zoomed out, the arrow links look like total madness – that’s because they kinda are. From my experience, understanding, coordinating, and working on dependencies is one of the trickiest parts for a project (I suppose this applies to other things as well).

Link to the Phase:2 Flow Map

Understanding the Flow Map

Here is how I’m envisioning this playing out.

Zooming in, we can identify one of the first tasks (with zero dependencies).Once that task is completed, it can be visualized as “green” along with the connected outgoing paths – effectively “unlocking” the next tasks. This helps visualize the next task that needs to be worked on – just follow the arrows!

Screenshot of the initial task marked as completed.

As we progress, the map will start looking something like this:

Screenshot of additional tasks being “unlocked”.



To indicate dependency blockers, we can colour a path “red”:

Screenshot of a task being “blocked”.

This dependency flow and “unlocking” mechanic can also help us spot opportunities to work on things in parallel. In the example below, we can see that a future “HStack” task was unlocked with “Flex”. If needed, we can expedite “HStack” and work on it at the same time as other tasks.

Screenshot of a future task being unlocked.

Folks I’ve shared this with have noted that it reminded them of skill trees for video games. And they’re not far off!

Skill tree overview from Assassin’s Creed: Origin.

I indeed drew a lot of inspiration from video game mechanics to create this map. I envisioned it being a combination of skill tree interfaces with interconnecting overworld maps – maps that reveal themselves over time.

Overworld map from Hollow Knight.

In Conclusion

I’m going to try using the 4 mediums to coordinate and communicate the G2 Components project as effectively as I can. On their own, these mediums communicate certain attributes of the project – such as the Chart View for timelines or the Flow Map for dependencies. Together, they work in concert to provide a richer and clearer picture for the project as a whole.

There’s going to be a lot of manual task wrangling and updating of things – but I think it’s worth it.

As always, feedback is welcome!

Advertisement