Systemic (Reporting System Transition)
I was responsible for the technical strategy for an effort to transition a large organization to a new internal ticketing/tracking platform for a portfolio of ~1,500 worker safety related projects. Applying design-thinking and product management principles, I facilitated research and brainstorming sessions, redesigned business processes to align with a workflow enabled by new software, created training materials for people impacted by the change, and authored updates to business policy to federate the change.
Problem Statement
To help improve the velocity for a specific portfolio of projects and to modernize internal systems and tools, we sought to rethink a business process and realign it to a new software workflow tool.
Concept Development & Ideation
To explore different challenges and ideas with this portfolio of projects, we held a workshop/focus group bringing together the different internal stakeholders. I facilitated the workshop, which included activities such as people from different job roles sharing some of their likes and dislikes of the current process, and group brainstorming of possible improvements/solutions. We scored the resulting ideas according to the predicted benefits and difficulty of implementation.
One outcome of this was to change the workflow that engineering groups used for addressing a portfolio of projects, and adopting a different and more modern web-based workflow management software. This change would also represent a paradigm shift from a more sequential "silo" workflow to a more collaborative, parallel workflow.
Further Research & Analysis
My next step was to speak with people with differing roles and understand their firsthand experiences with the existing process and software. These included production workers, engineers, and management. I also spoke with these people about the change we were trying to make and to gather any feedback and requests they would have, translating these into product requirements.
What appeared at first as a straightforward tool migration turned out to be a complex process redesign, because the legacy system had critical business logic integrated into it. While the new platform was capable of replicating this, it would take significantly more development time and effort than scoped for the project. Compounding this, stakeholders often couldn't articulate why certain steps existed; many steps were based on "institutional knowledge." This meant reverse-engineering the existing workflow step by step to uncover the true underlying requirements, then designing a new process that harmonized three distinct and sometimes conflicting sets of needs: engineering's technical and budget-approval workflows, environmental health and safety guidelines, and the company's overall problem-solving methodology.
As I better understood the existing situation, to get a good understanding of the solution space and constraints, I also worked with the software development team to understand what functions and capabilities of the new software we might use as-is, what could be changed through administrative/configuration updates, and what capabilities would require additional software development.
Prototyping & Testing
With an understanding of the current process, how different groups of people carried that process out, and how the existing workflow software supported the process, I drafted a high level version of a process that would leverage the functions and capabilities of the new software.
Next I wrote a detailed "beginning to end" description of how a hypothetical project would progress through its lifecycle using the proposed process and workflow changes. The description was written in an accessible "day in the life" format. This was then shared with stakeholders in a technical review where they were able to critique and correct assumptions or errors I made and suggest alternative ideas.
Implementation & Results
With a workable future process designed, I turned my efforts to implementation, which included authoring new policy, as well as creating training and communication materials to distribute internally. The change affected 50k global employees across dozens of global production sites.
The changeover proceeded smoothly. Usage of the legacy system for this process ended, and the primarily impacted organization successfully onboarded to the new system. One affected party email shared this praise with their director:
"Communication on this change has been outstanding."
Conclusion
The key work here went beyond the software -- uncovering the undocumented human processes the old tool had quietly encoded, and designing something new that honored what mattered while letting go of what didn't. The tool was just the occasion for the change.
By applying design thinking and product management techniques alongside sound engineering principles, this complex change was able to proceed with minimal disruption to day-to-day business operations.
