Jira vs Confluence Use for non-software project management

Anja Brkljacic

My company has specific project plans for various solutions that we offer to our customers, and I'm debating whether it would be too much upkeep to leverage both Jira and Confluence to keep track of the various project plans. How I see it working is:

• There is a Confluence document with the project plan for each solution we offer; this is used as a reference/learning document
• Then, when it actually comes to executing the project plan and keeping track of the specific tasks PER CUSTOMER for each solution implementation, we would track those in Jira
  • This would likely mean that there's an issue type per solution type, and each issue type has auto-created subtasks that correspond to the project plan steps
• Whenever the Confluence doc is updated, Jira backend would need to be updated so the appropriate subtasks are added/deleted/modified to match the source doc in Confluence

 

Has anyone tried a similar approach? I'm wondering whether this will end up being too much upkeep, and if it makes sense to do it this way? Or if a better approach would be that the project plan page in Confluence is copied for each client, then saved as a new Confluence page with tasks checked off?

Wade Tracy _Boise_ ID_

I've personally never done something quite like what you are suggesting, but off the top of my head I think you could easily create a Confluence template similar to the Product Requirements template for each solution type. The process would look something like this:

1. Each solution type has a Confluence template with an epic and a prepopulated table of stories that need to be created.
2. You create the page based on the template, use the Jira macro to create a new epic, the table  already has the sub-items that will become children of the epic.
3. Publish the page
4. Use the Jira-Confluence 'magic' to generate issues based on the table on the Confluence page. You'll have the option to do multiple stories and even link them to the epic.

And that's it!  You'll have an epic filled with stories for each step of your process. If you ever change the process, you just update the template and all future instances get the changes.  By the way, I wouldn't create a separate issue type for each solution.  In my opinion, it is better to leave them generic rather than deal with issue type proliferation.  The process above would just use epics and stories/tasks.  The differentiation for the solution type would be the Confluence templates--I'd create a template for each solution type so you can pre-populate the stories table for each different type.