I am consulting a customer that has to manage a big project (5 years) in project management (tooling). The project has a timeline of 5 years. Each year is seen as a separate phase or "cycle". Each phase consists of a number of independently/external managed projects. The project management is also seen as one project.
Since the customer has Confluenc/ JIRA (with Agile and BigPicture) i would say BigPicture seems to be the weapon of choice for managing the whole project.
My main question is: How to structure this projects with BigPicture and it's "programs". I see 2 options:
What are possible implications from this choice?
Within each program i would create an epic per sub-project. I see possible problems on creating separate Jira-Projects for each Subproject in regards of control and overview. On the other hand the subproject's manager have their own seperate tools to manage their projects. The JIRA instance is only a tool for managing the whole project and for communicating and controlling the state.
So how would you structure this projects in terms of Jira, Agile and BigPicture
If I were in your position, I would (personally) create separate JIRA projects for every phase. Then create a single Program for every project, as well as an overview one using the JQL filter option.
Epics, Stories and subtasks would be used for hierarchy. If more is needed, Versions and Components can be used. In such a setup, it is important to have the same WBS settings for each Program, including the overview one, for a coherent hierarchy.
The managers of a specific phase would work in their own respective Programs. They would have either none, either view-only permissions for the overview program, which would be dedicated to high-level managers, shareholders etc. You could go a step further and customize the phase-Programs permissions too, like make only the high-level managers administrators so that no PM will accidentally change the WBS or misalign something.
Granted, BigPicture is an EXTREMELY flexible tool and as all process questions the best answer depends on preferences. This is just how I would set things up based on your description. The only downside of such a setup would be that to see the overview a person would need to switch from a given phase (go to another Program), which literally 3 clicks. In my mind this hassle is worth the benefits, but of course it is up to your customer to decide.
So the the object on the upmost level is a JIRA project (one for each year)? And beneath this i create programs?
What i still don't understand: what is a "program" for? When in general should i create a program in contrast to a JIRA project?
At the moment i am not completely sure how encapsulated each phase/year is. Probably there could be task dependencies between the years or probably it could be necessary to move a task from one phase to another. Are both use cases possible by using JIRA projects for each phase?
Yes, project represents a year and Pograms are created based on these projects.
Program is an additional level of hierarchy. JIRA has projects and that's it - with Programs you can create one that has multiple projects inside it (so it is higher than a project in hierarchy then), or only a selected part of a project (in which case it is below project).
In the overview Program that has all projects you can define, edit and track cross-project dependencies, one of Program's major benefits. The tasks don't need to be in 1 project to be connected. And yes, you can move issues between projects in JIRA easily.
Either i misunderstood you or vice versa?!
You say the upmost level is "program" this was my initial understanding. So the hierarchy would be program->JIRA project->epic->story->task, right?
the project i talk about has this hierarchy: Project (5 years)->Phase(one for each year)->Subproject (5 + 1 for management in first year)->Big tasks to monitor progress on monthly base-> if subproject's manager want they could create sub tasks.
Sorry for the hassle but could you please map both. Especially regarding the first 2 levels.
Subtasks as smaller tasks
Separate Program for each Phase for convenience and 1 overview Program pulling all of them at once.
Is what I had in mind. Granted, this is just how I would do this - a fully feasible alternative would be to have only the overview cross-project Program and everyone working inside it, introducing more levels of hierarchy (like Versions for Subprojects, Epics for big tasks and then you have stories and subtasks free to use).
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs