The Phoenix Project: UX Perspective
The Phoenix Project is a fun and enlightening book by Gene Kim that teaches us about how important process and operations are to the success of a business. While primarily focused on an example IT & Dev-Ops environment, there are so many lessons about the interwoven fabric that make up a company, and the processes with which we structure work, that can inform and empower UX organizations to become more effective as part of a cross functional team.
Synopsis:
The book begins by outlining a nightmarish scenario wherein Bill Palmer, an IT director at a large auto parts manufacturer, is tasked with a new leadership role at a seemingly dying company. Plagued by all facets of business challenges, Parts Unlimited basically needs a miracle to bring the company back on track which they're targeting in the form of a project Phoenix.
Bill’s process in tackling his new role is Guided by an experience IT / Dev Ops guru in the form of a company board member named Erik, who directs Bill to work through the hairy issues by focusing on a few key concepts of Dev Ops Success and by understanding the type of work his team is doing, and how it can be optimized similarly to a factory production environment.
Throughout the book Bill meets a myriad of failures & learning opportunities, and in the end helps create a new operations structure for his team that focuses on both quality of work as well as delivery, and utilizes improved communications, tracking processes, and various operations theories to eventually deliver products that turn the company around and make everyones lives better.
Relevance to UX:
The stories here of dev-ops scenarios are not unlike our own positions as a large UX team. Growing teams, high value projects, a swirling evolution fo stakeholders and players all add up to a very similar scenario in which a teams process can be the primary cause of success or failure. While the book is mainly focused on dev ops and IT concepts, there are a lot of principles that we can borrow from and apply to our own practice that can mean better pathways to project success, and less time fretting about deadlines and resources. In this post, I’ll outline a few key takeaways, and how we can take these lessons in the world of UX...
Key Takeaway 1: Visibility of Work In Progress
One of the key elements of failure at the fictitious company in The Phoenix Project is the lack of visibility into the workloads of the IT department teams. This essentially creates a situation where more and more tasks are assigned to the teams, and creates a snowball effect of unrealistic deadlines, and poor quality work, that causes more problems down the line.
This can happen in our world as well, when we work on big UX projects with multiple teams and stakeholders, there are multiple timelines and expectations layered on top of one another, and when there is poor transparency and communication of how those timelines and projects are moving along, it creates a rift between Product, UX and Development teams, that typically ends in timelines being crunched and the quality of work potentially suffering.
What we can do as UX'ers:
Create and maintain a transparent view into your teams granular UX work, over communicate this information and make sure other teams know where to find it!
Creating a single pane of glass where stakeholders like product managers and developers can see example what is in progress, and when and how its moving forward, is key to maintaining cross-team understanding of timelines etc. that in the end will contribute to the successful delivery of UX pieces as well as the products themselves.
Tools we can use to improve this process:
Kanban Boards: Try using the planner app in Sharepoint to show your whole team where your projects stand and how they are progressing (here’s and example of how we’re doing this in our own project pheonix)
Key Takeaway 2: Ten “Deployments” Per Day
There is a concept in the Phoenix Project where as the team starts to make operational strides, they improve on their ability to deploy their work quickly rather than on a quarter by quarter basis, which leads to lots of improvements and opportunities for the team to learn from what they’re customers need and release it more immediately.
While the concept in the book is more focused on actual deployment of code, we can apply the same principle to our designs, wherein our “deployment” is a somewhat finished state or prototype that we can show our users. The second part of this is the frequency at which we get those impressions, so for the UX world it is the efficiency at which we can get real feedback from hands on sessions with our users.
What we can do as UX'ers:
Luis & Larry's work on operationalizing the usertesting.com engagement is our own form of “10 Deployments per day”, for us its “10 user interviews a day” especially in the context of evaluating the usability of our designs, and rapidly applying that feedback before we hand off for implementation.
The key here is is the speed at which we can do this, and the teams work this year to get our new tooling set up with undoubtedly contribute to the success of our projects more than anything else. This allows us to iterate quickly, and uncover opportunities for our designs without waiting weeks to get designs in front of our users.
Key Takeaway 3: The Theory of Constraints
In the Phoenix project, one of the tactics employed by our fearless IT ops leader is something called the Theory of Constraints. This theory essentially states that to effectively manage the output of large system, you must identify and address the systems constraints or bottle necks, that reduce the systems efficiency down to the output of those problem areas.
Identifying these constraints by mapping out our processes (using things like value stream mapping (link) ) allows us to look at how work flows through our team and our company, in our case this can be looking at how designs make it from conception to execution, and finding the areas that restrict the output of that process.
So what are some examples in the UX world? Maybe as you work with your development team, you have to spend a lot of time walking through your designs as you hand them off, constantly responding to little questions about a how a design etc. That’s an example of a process bottleneck or a constraint. From there you can ask the question: how do I unblock this area? For example you could find that creating a short walkthrough video of your design prototype and attaching it to a JIRA ticket may be the most effective way to communicate your designs in a way that doesn’t create a lengthier process!
What we can do as UX'ers:
Constantly try to evaluate where in your design process (and the process of the teams) you find these constraints or bottlenecks. Once you identify these areas, work with the team to brainstorm how we can open up the floodgates by designing a process solution that will create more time for quality design work, and less time repeating parts of a process that don’t need to be so arduous!
Conclusion:
The dev-ops and UX-ops worlds have many parallels, in one world their is delivery of code, and in the other, design. But the commonality is that the way in which we create these things is always with some kind of process. Whether or not this process is well defined, explored, and refined is what makes a key difference in our ability to release great work.
So I urge you: take a look at your own process, and pay attention to the larger processes happening around you, both in the UX org as well as with other orgs, and identify how we can constantly approve this process to make the most efficient amazing UX Machine we can!