Within Sourcesense we often come across situations when our customers have challenges of complexity, where teams are trying to achieve too many activities inside their Jira configuration, and using workflows across the same projects, that realistically need their own status and transition to fulfil the need and provide business value. While having a set of workflows inside a scheme across multiple projects can be very effective - there comes a time when the highly configurable nature of Jira can be cumbersome and too complicated for the experience of less technical teams.
Earlier this year we completed work with one of our largest financial customers, a global provider of benchmarks, analytics and data solutions who had issues with their workflows.
Problem definition
In the customer organisation, two teams were utilising the same Jira project and workflow to manage their issues. However, Team B began to develop distinct requirements that set them apart from Team A, necessitating a different configuration. Specifically, Team B required an additional status in their workflow that Team A did not need. Furthermore, they sought to have their issues automatically assigned to a separate user group and desired a straightforward method for reporting their work independently.
Unpicking the tangled process
We had already begun delivering our Sustain BAU Service to the customer after pinpointing areas where we could add value to the business, particularly in support of the overwhelmed administration team. We recognized that the workflow was highly intricate, relying on multiple scripts and automation to manage the needs of both teams. Additionally, several transitions were performing the same functions but tailored to different issue types. It became evident that the optimal solution was to separate the project: Team A would retain their original setup, while a new project would be established for Team B to accommodate their specific requirements. This approach would also enable us to streamline the workflows, enhancing their efficiency.
This situation presented a more complex challenge than typical Business As Usual (BAU) support. The customer expressed a desire to address the issue without disrupting the existing BAU services. To facilitate this, we developed a comprehensive statement of work that clearly outlined the definition, scope, and timeline for the additional requirements. This plan included the establishment of a new project for Team B, along with the implementation of a tailored workflow and screens to meet their specific needs.
Implementing a mail handler for the new project - with JEMH Mail Handler from The Plugin People
All incoming issues in Jira were triggered via email, and the team was already utilizing the JEMH Mail Handler to manage these requests. This handler applied signatures based on the Issue Type (Team) and had been configured to recognize certain users. The team needed to set up a new mail handler with custom HTML templates specifically designed for Team B. Once these configurations were completed, we were able to streamline the workflow for Team A by removing any existing scripts that aimed to differentiate between the two teams.
The new workflow was successfully implemented in a Development area and then the User Acceptance Testing (UAT) environment, allowing Team B members to conduct thorough testing to ensure the workflow met their requirements.
After receiving approval, we scheduled a weekend for the deployment to the live environment. This process involved migrating all open issues belonging to Team B, as well as any closed issues from the past six months, into their new project. Team B commenced using their new project at the start of the following week, and no significant issues were encountered during this transition.
Making project deliver value for the Customer
The primary challenge we faced was the existence of a long-standing system that had been operational for many years prior to our involvement. The workflow was exceedingly complex and presented numerous opportunities for simplification. Additionally, there were multiple scripts in place, making it difficult to discern their specific functions.
To address this, we dedicated time to thoroughly analyse the workflow, gaining a clear understanding of its operations and identifying its essential requirements.
Similarly, the JEMH Mail Handler HTML templates used for customer emails were overly complicated. They relied on if statements to determine the appropriate responses based on issue types, among other factors. Furthermore, different scripts were scattered across various post functions within the workflow. We successfully streamlined this process by consolidating everything into a single template, which we assigned to all customer communication transitions using post functions.
This project would have been significantly more challenging if we had not been providing our Sustain Business As Usual (BAU) support, which allowed us to develop a solid understanding of the teams utilising Jira and their various processes. The existing workflow was overly complicated, requiring considerable time to comprehend fully before we could begin refining it. This situation exemplified the pitfalls of over-accommodating by employing convoluted methods while disregarding best practices.
Factors to consider for having projects separate or using shared configuration
In Jira, having separate projects and workflows is beneficial for several reasons, as it provides flexibility, clarity, and efficiency when managing work. However, having a shared configuration can also be beneficial and bring value. making this differentiation can be critical to a successful implementation.
Here's a breakdown of what to consider:
Shared Project Configurations and Workflows
Best for:
Consistency, standardisation, and cross-team collaboration.
Simplified maintenance, centralised updates, and governance.
Scalability, quick onboarding, and efficient reporting.
Advantages:
Reduces administrative overhead.
Ensures uniformity across teams.
Enables easier cross-project metrics and dashboards.
Limitations:
May not accommodate teams with unique processes or needs.
This can lead to rigidity if customization is required.
Separate Project Configurations and Workflows
Best for:
Teams or projects with distinct processes, goals, or methodologies.
Tailored permissions, rules, and workflows for specific needs.
Projects with compliance or governance-specific requirements.
Advantages:
Greater flexibility and customisation.
Focused reporting, boards, and backlogs.
Easier alignment with unique team structures or industries.
Limitations:
Increased administrative complexity.
Harder to standardize and maintain across multiple projects.
Key Decision Factors
Consistency vs. Customisation: Use shared for uniformity; separate for uniqueness.
Complexity vs. Scalability: Shared simplifies scaling; separate supports complex needs.
Collaboration vs. Independence: Shared promotes collaboration; separate supports autonomy.
If your team is struggling with complex workflows, tangled processes, or managing shared configurations, we can help. At Sourcesense, our Sustain BAU Service offers expert support to streamline and optimise your Atlassian tools, ensuring they work effectively for your unique needs.
Get in Touch to schedule a consultation and see how we can help unlock the full potential of your Atlassian setup!