The Phoenix Project and Software Product Development

If you haven’t read The Phoenix Project, go read it now! I don’t intend to write a book review, but I do have some high level thoughts and would like to kick off a conversation as to how those concepts apply to Software Development.

First off, some thoughts. As a long-time developer and now managing a software engineering department many of the scenarios, problems, and suggested solutions in the book greatly resonate with me.

The book, in my opinion, skims over the very difficult people and change management aspects of the equation. Situations and conversations are simplified and agreement reached far too quickly. In most companies, without a solid foundation of trust and strong team dynamics, most of the Phoenix Project’s conversations would end with hurt feelings, misunderstandings, or worse.

In fact, the pivotal plot element of an experienced and understanding Board member who pushes an initially reluctant but wielding CEO toward change is often the critical and lacking element in real life organizations. But given the book’s focus (and strength) on depicting and evangelizing Lean practices and the Theory of Constraints, it is understandable and forgivable. Still, that is not to say that the human aspect of effecting that kind of change isn't, in my opinion, the most important and most difficult part of organizational improvement.

The part that I would like to focus on and discuss is the “four work types”, and how they apply to software product development, particularly in a SaaS business.

The book describes four generic types of work requests placed on IT resources. Categorizing and quantifying the work types eventually helps to identify, exploit, and elevate the constraint. The four work types in the book are: Business Projects, IT Operations Projects, Changes, and Unplanned Work.

How do those “IT work types” translate to a SaaS software development process? Here is a possible interpretation and mapping of each bucket.

Business Projects

Business projects are work requests that have a direct line of sight to revenue. They are new products and new features and enhancements and changes to existing product, all requested and done to directly affect customer engagement and therefore revenue. Notice how I bucket “Changes” into Business Projects, too; unlike IT, where changes are primarily operational overhead, in software product development changes are desired and welcome when they directly affect revenue. In software development, as in the book, the goal would be to maximize Business Project throughput.

Internal Projects

The Phoenix Project classifies this as IT Operational Projects. In software development I would classify these internal projects as work required to sustain a high rate of Business Project throughput. This includes R&D’ing new technologies, CI pipeline development, any kind of major automation work, and of course major architecture & infrastructure initiatives championed by engineering. It is likely desirable to maintain a minimum throughout on Internal Projects as it has a direct, positive effect on Business Project throughput. Any major, internal engineering initiatives that go well beyond this baseline allocation should go through standard “product management” process and championed into the organization road map. Maintaining a minimum rate of Internal Projects should also have suppressing effect on the next category of work, which then again indirectly and positively affects Business Project throughput.

Unplanned Work

One word: defects. As the book suggests, this is the type of work that we want to minimize if not squash entirely.

In a traditional Big Design Upfront world I would also categorize any type of architectural rework into this bucket, as it evidences bad initial assumptions and the need for unplanned and therefore undesired changes.

As we start gathering this new data on our teams’ process and daily work, I expect some interesting insights and correlation to emerge. For example — do Internal Projects in fact have a positive effect on Business Project throughput, and a suppressing effect on Unplanned Work? Could this type of categorization help quantify the value of addressing technical debt, refactoring, and following best practices?