Hey everyone, so to frame this discussion, our company is looking at moving away from some jira products due to the complexity of setup and difficulty in training people on its use for managing projects. We're a small team, so we're trying to come up with a simple way for multiple people to maintain project schedules, requirements, deliverables, and then have that roll-up into a summary view.
What's a good setup that you use or like for project management across multiple teams? For reference, we have confluence, jira, and service desk licenses for our users, as well as some MS Project licenses and the usual excel / word / sharepoint stuff that some people prefer.
What I personally like doing is starting out in confluence and using it for note taking, meetings with customers, and capturing of requirements. This helps me capture the initial logic of why a requirement came up, what the user story is, etc. Once we're done with a meeting I can summarize all the requirements into a requirements table automatically in confluence, create kanban tasks or tickets for each one, and once I have them fully documented I can transition the issue to our product management and dev team to look at. They can then write the functional design documents, kick it back to the customer and I for review, and after that step we can put it into the backlog of work. There's a complete chain from start to finish of the birth and completion of a requirement.
If necessary I can build in approvals, required fields, etc., but that's where the undesirable complexity creeps in so I avoid it. Once we deliver the software, if something comes up during user testing, production, etc. and it's discussed during a regular meeting with the customer, I can still create tasks but throw them into service desk instead of kanban. At the next meeting I already have an up to date list of what they asked for, the status of it, etc. without having to manually go back and forth between systems and ask people for updates. I can also reference the original discussion of requirements so that when Bob says something needs to change in the software after delivery, I can explain to him that he asked for the exact opposite thing 6 months ago and delve into the discussions about why that decision made sense.
Speaking of which, decision logs are nice as well, and I can get an automated list of decisions I'm waiting on the customer for. I don't see a simple way to build these into dependencies like I could in MS Project (eg. I have a requirement from you to build a login page and that's documented and created on a list somewhere, but you just added a dependency when you brought SSO into the discussion. I need your decision on SSO vs non-SSO logins before I can finish the design phase of that part of the program), but generally it seems to work well enough.
I personally see a lot of value in this setup, despite all the complaints I have about individual atlassian products. The rest of my team is overwhelmed by the complexity, unfamiliar with the products, and I guess their projects are sometimes smaller so they don't see the need to use three different systems when an excel export from the customer's MS Project file and word documents for note taking work well enough.
Any thoughts on what works well for you? I'm worried that if we only use Jira for service desk and development kanban, but do meetings, documentation, and project plans in a similar product like clickup, trello, monday.com, versionone, whatever, that I'll be side-grading to a slightly different version of basically the same thing, but then have to manually transfer updates back and forth between development and customer.
Also, the other concern I'm not able to address in great detail is managing multiple projects. For example, if I have three on-going projects with different customers, I can build workspaces under each customer's file in confluence to document meetings & requirements development, then build epics and tasks in a board for each project, and finally push sub-tasks from my kanban board which is more high-level to the appropriate development board for work tracking.
So for example, I might have two projects:
1.) Install of existing application for customer #1
Most of the tasks in my board would be for our team only, such as development & product modification, ETL data from customer system, key user training, conduct user acceptance testing, go-live, etc.
In this type of project most of the tasks are managed in my group and only a few go to the development team to get done, so I could manage updates to my tasks and link kanban tasks to the dev team for enhancements, bugfixes, etc. that I need from them. The problem here for us is rebuilding the automation logic and rules for every new project board.
2.) Development of new application for customer #2
If we're developing new software for a customer, then most of the tasks will eventually need to fall on the development team. So after the planning & design phases are done and we've made all the necessary decisions and captured all the requirements, which I can keep track of and update on the various epics, then in the development phase all the subtasks mostly would be linked to our development kanban board where they and QA would be making updates, moving tasks around, etc.
To me this all makes pretty good sense and the only issue is making sure linked tasks are setup and rules are in place so that eg. when a dev finishes a task or QA approves a build I can get those updates automatically back into my epics and in turn back into confluence meeting pages.
The part I'm not very familiar with though is rolling up these projects into a single summary. So is there a good way to get a list of upcoming / overdue deliverables for all projects, and a good way to display them all in one place? I've seen how you can display kanban boards and epic timelines in confluence so I think something like that could work for showing a high level summary of where each project is at, but I'm not sure about extracting out tasks by due date, priority, financial impact (eg. potential penalties for late delivery), and showing all of those in one places so that all the various projects with various customers could be managed centrally.
