March 16, 2020
Apnatomy was recently invited to work on a large government project that involves collaboration among national laboratories and universities spread across the country.
At the time, project teams used different tools and reporting practices. The lack of common tools made it difficult to bring hundreds of different project team-members together.
Apnatomy was tasked with improving visibility and insight into the project at various points in the workflow. To do so, we integrated and scaled modern tools from Atlassian’s suite of software applications, including JIRA Service Desk, Confluence and Bitbucket.
Implementing applications at this scale comes with challenges. To ensure success, we took a measured approach that considered the needs, size, and budgets of each stakeholder. Moreover, we provided ongoing training to address the challenges that come with scaling new workflow management applications.
Here are some lessons we learned:
Before agencies can scale new applications, they have to know how the organization currently operates. Discussions with the leadership team, as well as project teams, should reveal their current development methodologies and processes, the type of tools they use, and how they facilitate day-to-day operations.
The next step is to figure out what infrastructure currently exists within the agency and whether it will be carried over or revamped. Will the application run on the cloud or on-premises? What technology does the organization need to support the applications? What else will be needed for deployment?
One challenge is determining how much a new application needs to be scaled. For example, if a large federal agency needs a solution for a $1 billion project with several thousand users and over 100 project teams, planning the application’s structure can feel daunting.
Instead, the project’s organizational hierarchy should be broken down until individual teams can be identified. Even if there are hundreds of teams, each one is typically 10 or 15 at most. Focusing on smaller pieces of the process makes it easier to build a scenario that scales.
After identifying the resources needed to scale, the next step is to map out a timeline that includes near-term goals—like the software’s implementation and holistic integration within projects—as well as longer term goals of business and organizational needs.
Solidifying agency reporting requirements is a crucial part of workflow software. Many agencies have specific ways in which they review projects to maintain their funding and justify their expenditures.
Additionally, most government projects are made up of smaller companies and contractors, meaning there are often several disparate reporting structures and leadership teams without one main point of contact.
Gaining buy-in from the different leadership teams up front—and agreeing on universal reporting mechanisms—is critical for rapid deployment.
When project stakeholders agree on a strategy, it’s time to get buy-in from employees—the ones who will actually integrate the application into their day-to-day operations.
It’s not unusual to encounter resistance from seasoned employees. After all, they’ve probably been through the process before. Without buy-in, they might view the new applications as more tools they won’t use.
To break down barriers and get buy-in, agency leaders need to be clear about the value the application adds to the organization, and specifically their day-to-day operations. They need to assure employees that new tools will come with customization, support, and ongoing training and mentoring.
Support for users means training them to be self-sufficient with the tools as well as supplying ongoing education. This is critical element to ensuring that new applications are integrated into a project’s workflow for good. Empower users to seek additional ways to make the application their own as the projects and needs change over time.
Technology can help project teams manage complex processes. For example, we found that project change requests took nine weeks to process. After implementing JIRA Service Desk, that process was cut down to a few days.
The process became more efficient and collaborative simply by moving it away from paper files, email and spreadsheets that were difficult to access. The process itself is still complex. We chose JIRA Service Desk because it provides the flexibility to have very complex approval processes.
In this case, it facilitates a linear workflow. As the request moves from the person submitting the change to the person who gives approval at the top-most area of the project, it collects and validates the necessary documentation along the way. With JIRA and some key add-ons, agencies can also map their field level data to hard documents that need physical signatures.