nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

What makes a Confluence project hub stay useful after the first week?

Maya Lindholm

I have been experimenting with a small Jira and Confluence sandbox, and the thing I keep noticing is that project hub pages are easy to create but harder to keep useful.

The setup that feels most maintainable so far is:

- one overview page with owner, goal, current status, and key links

- a decisions page so important choices do not disappear into meeting notes

- meeting notes kept chronological, not mixed into the overview

- a short risks/open questions page

- Jira links embedded only where they add context

The part I am still thinking about is ownership. If nobody owns the hub, it gets stale quickly.

For Confluence admins, what structure or habit has helped your project pages stay useful after the launch week?

Comments

Jason Hills

You need a project manager role whose job that is.

If the team doesn't keep it updated, it's because purely implementation-focused people rarely do that. Depending on the context, the team may need that role.

I work in tech, and I can't tell you how many time and money has been wasted through improper project managment ...cause I'd get in trouble if I did!

Destin Woodruff_xt3t4l

Agree with Jason. Someone's job like a PM or Scrum to help update this during/after meetings. Seems like you are describing a RAID log. I've been looking into something similar as well. A RAID log is also for showcasing to upper management, which may also help buy in.

Jason Hills

You asked for structure.

I run enterprise-wide projects from a few people to 100, usually systems development, data architecture, process architecture, etc.

I prefer to write the project charter and initial project plan in Confluence.

When we get sign-off, I write a more detailed plan in Confluence using tables, where I establish the epic / story / task structure as well as workstreams / swimlanes for Jira. When it looks good, I use that draft to build the project in Jira and link the epics / stories back into Confluence.

Execs and upper leadership generally don't want to look at Jira unless its the Gant chart. Confluence is a much easier way to share that, and gives them the ability to click-through for the details. Even better, the Jira link shows the current status of any linked item.

But the real work is done in Jira, including the RAID log.

Sometimes, we use the action item / action report feature if Jira is too much for the project

Kythera

Surfacing the most important information is definitely step 1!

You're on to the key part of it with ownership. I'd like to expand on what others have said with assigning the "ownership" job to project manager (PM). Personally, I think the PM should be at the top of the Confluence-keeper hierarchy. In addition, I'm a huge advocate for cultivating a "shared ownership" mindset when it comes to Confluence. Yes, the PM is "in charge" and steering the ship (including Confluence). The same way each member of the team works on their expertise, keeping their part of Confluence updated should, ideally, be part of that. And a general agreement that "if you see something outdated, update it." Or add an inline comment and tag the person who owns the part that needs to be updated.

I favor this mindset because it takes the weight of updating off of a single person and distributes it more equitably, and prevents potential bottlenecks of relying on one person to handle all the updates (a trap that a solo technical writer could easily get caught in...ask me how I know!). When everyone feels like their contributions matter, you get a kind of emotional investment that becomes an excellent motivator.

Ideally. We all know that reality is rarely ideal. 😅

To make it work, it requires the whole team to at least have a basic understanding of how to Confluence, and to agree on this way of working (and holding each other accountable). For example, "Update relevant information in Confluence" might be part of the "definition of done." Keeping a Confluence space viable as a single source of truth is a task that a lot of folks underestimate, and the overall value of it can go unrecognized until people realize it's missing.

[Nota bene: Yes, I'm assuming an Agile way of working. 😅 And there are, of course, exceptions to all of the above. Spaces where the content needs to be strictly controlled, like HR-related pages maintained by the HR team, or IT's security info space. I'm referring generally to project-specific spaces, like a software-development team might have for a specific project, where everyone on the team contributing to the space is a desirable thing.]

Welcome!

It looks like you're new here. Sign in or register to get started.