Project Apollo
Organizational design through PM tools
Overview
Objective // Configure Jira instance to support optimal team processes for implementation of a large-scale technology business platform.
Roles // Program management, organizational design
Collaborations // Business & technology leadership, client executive leadership
Outcome
Situation
We were hired by a client to implement a full-suite core business platform to completely digitize the way business was conducted. As with every engagement, a portion of our strategic planning phase was aimed to understand current state of operations. We found that they were already quite adept at employing Agile practices, and let individual teams determine their own work processes.
Although this adheres more to traditional Scrum, we knew that this wouldn’t work for a timebound implementation on this scale - especially with the budget required when involving consultants. A single project management instance was required to enable productive collaboration across PwC and client teams.
My responsibilities were to own and coordinate all efforts required to materialize our future-state Jira instance, and consisted of:
Conducting user workshops to understand two primary users
Client teams, including scrum masters, as our main target user for ideal experience
PwC team leads, as they had the experience and battle scars from large engagements successfully implemented
Consolidating our workshop findings into a set of future-state business process flows
Converting business process flows into:
An “Issue” type hierarchy (all items, whether they be an Epic, Story, Task, Bug, etc., is called an Issue in Jira)
Workflows for each Jira Issue type
Custom fields to support efficient collection of data for generating metrics
Screen set-ups to display reference information for the team
Publishing team playbooks, on Confluence, documenting reference information as well as process improvements that may arise over sprints
All screenshots below are snippets from the playbooks published for this client
The final product was a customized Jira instance combining PwC and client Agile methodologies, as well as a base set of metrics for use in executive status meetings. Experience while using our engagement instance was a heavy consideration as well, and influenced the addition of several smaller components for a more intuitive and useful experience.
Over the course of a year (after teams acclimated to the new methodology and reached expected velocities), we noted a 23% improvement in team efficiency - determined by development output passing quality assurance standards. Qualitatively, user feedback pointed to improved cross-collaboration and communication, easing the effort of knowledge hand-offs and clarifications.
This engagement was pretty big.
Business for PwC’s Insurance practice was booming. It seemed that every new engagement had set itself a challenge to be larger than the last, and this one was no exception.
On top of the vast scope requested, our client was able to negotiate quite a strict budget as well, which meant that we had to keep our Onshore team as lean as possible to bolster our Offshore development team.
Given the large scope, complexity of development, and required team size, productive and efficient collaboration was a top priority for us on the Program Management team to enable.
To the right is a summary of accomplishments from our “Inception” strategic planning phase. Key items to note are team size, number of platform integrations, and overall scope (user stories & effort hours).
All of this meant that a solid project management tool was an absolute must to ensure a timely and successful delivery.
Here’s what we did.
The first matter of business was to determine how best to house our story backlog.
How did user input influence hierarchy?
We added Themes to organize stories by business capability, after numerous requests from Product Owners and Business Leads for more transparency into the tie between Story and platform business function.
Each Story was split into counterparts for the Requirements, Development, and Testing components for more granular planning by Scrum Masters. Many commented that when there were delays in prerequisite work that it was tough and confusing to track story completion, with how Jira was inherently configured to operate. This served as a perfect workaround to not only avoid Stories dragging on for multiple sprints, but also allow better anticipation of incoming work past the current sprint.
With our hierarchy set, we now needed to confirm a workflow for transitioning stories from Backlog to completion.
A Jira workflow defines how an issue type (e.g. Epic, Story) flows through statuses, which denote what stage a particular item is in - whether, for example, it’s yet to be picked up, under development, or to be reviewed by Product Owner.
Workflows directly impact individual team members as well as program reporting. Progress is primarily tracked in the tool through Stories and their statuses in the set workflow, which flows into reporting on progress and risks. This meant that we had to craft our workflows carefully to not only ensure an intuitive experience when interacting with Jira, but transparency when tracking development work through its lifecycle.
Here is an example of a user pain point converted into a tangible workflow configuration.
Leads for the Development teams asked for more transparency in the code review process, as our client faced a big problem with inadequately tested code making it to user-facing environments.
To address these pain points, we added a status for “Technical Review” to denote when stories were ready for lead review, and a set of statuses (in green) to track stories as they progress through the environments to Production.
We also added another status to distinguish whether a Story was “Ready for Testing” or “Ready for Release” - to further avoid confusion on correct location for code merges.
Screenshot from the Jira playbook published for team reference. The Confluence page above shows the workflow of statuses, along with an explanation of what each status means.
The biggest pain point expressed by teams was the lack of context on Stories assigned out for development.
With this feedback, we customized several elements of the Jira instance for a more optimal team experience.
Indexing system for organizing stories
With roughly 6,248 stories in scope of the overall implementation, a solid foundation for organization was a must. All stories had a code designating their place in the overall platform architecture.
Custom fields for easy navigation and reference
In addition to the in-built fields, all stories also had their planned sprint, indication of custom development required, and theme of work to assist team members in better understanding the work being assigned to them for completion.
Another set of custom fields was added to categorize Stories, essentially treating each as a data array element. This was instrumental in enabling the creation of real-time dashboards (next section).
Issue Linking
Given that we were splitting up the Requirements, Development, and Testing into separate Issues, it was especially important that we had linking in place for quick flipping between R, D, and T components of a particular Story.
Add-on for more comprehensive time tracking
Addition stemming from pain points around entering in time spent on work, and, for scrum masters, accessing information around effort
Stories estimated out for quick sprint planning ceremonies
Although numbers weren’t finalized by Story assignees until the conclusion of planning, each story had an initial T-shirt size estimate inputted for team context.
Scope creep is one of the most common issues we’ve seen at our clients - and this one faced it terribly. From what we heard during our workshops, teams would enter projects with a scope set upfront - but as a project carried on, items in Jira were frequent victims of mismanagement.
We saw that multiple items were sometimes added for work that could be handled with one Story, and that whenever team members added in Stories, it was typically done without the necessary reference information for another team member to autonomously pick up.
Screenshot of a sample Story in Jira
The final piece of the solution was clear reporting, generated in real-time.
Screenshot showing part of the Program Management dashboard.
The most requested feature from our Scrum Masters was for inclusion of mechanisms for concise reporting. Although the tool itself comes with a bevy of reporting capabilities, housed data (e.g. Stories, Tasks, Bugs) must be detailed enough to ensure usefulness of charts Jira can generate.
We enabled this piece through custom fields. Information on related business capability, components involved, type of development work involved, and more was added at a Story level for use in parsing out subsets of data for easy progress tracking and reporting.
Reports comprising Program Management dashboard:
Sprint workload (remaining effort) per workstream
Workstream burndown charts to track overall sprint load, time spent, and remaining effort
Workstream velocity charts
Overall implementation progress (total stories organized by business function, by status)
Opened vs. Closed chart for tracking Bugs logged and resolved
Heat map to track overall Bug landscape, with axes as Age vs. Severity
My Takeaways
Hope for the best, plan for the worst.
Cliché I know, but this one came out of realizing that transition can’t be rushed - especially one as large as this one. I realized I needed to keep ideal state in mind at all times, but empathize with those resisting change to understand why, to ensure a sustainable transition.
Stay objective-oriented.
Opening to the teams let in a torrential amount of feedback, ideal visions, and suggestions that could take a lot longer to implement, so it was crucial that I kept the overall objective in mind of creating a solution that set us up for success during Implementation.
Approach user research with an open mind.
Some of the most valuable feedback came from the least expected sources. I understood the potential toxicity of bias, and I learned that there are no benefits to believing one can anticipate all outputs.