Millet Porridge

English version of https://corvo.myseu.cn

0%

The Phoenix Project

Posted on Edited on In Disqus:
My boss said this book is worth reading for project management. After the first read I felt I'd gained something. He asked me: if I needed to help other colleagues grow, what should I do? I started a second read with these questions; I haven't finished it yet, but I thought I'd write a blog to record it — also convenient for revisiting.

The Phoenix Project

The Phoenix Project is a software project inside a big company that everyone hopes will save the company. After its hasty launch it actually failed to achieve the intended effect; the protagonist is appointed in a crisis, taking over IT’s whole mess. By observing a complete assembly-line factory, the protagonist discovers some commonalities with modern ops, and transforms the system accordingly, finally building a strong IT team and complete workflows.

I’ll simply mention the points that impressed me, as a small summary. It can also be read just as a novel. This article may be updated continuously:

Some Problems the Phoenix Project Encountered

  1. Chaotic project changes
  2. Core people being too busy
  3. Project progress

Points We Should Focus On

The 4 types of IT ops work:

  • Business projects: initiated by business departments to achieve some business goal — e.g. developing new features, launching new products
  • Internal IT projects: initiated by the IT department to improve IT’s capability or efficiency — e.g. building automation platforms, optimizing monitoring systems
  • Changes: physical, logical or virtual operations on existing systems or applications — e.g. version upgrades, defect fixes, configuration adjustments
  • Unplanned work: recovery work caused by sudden failures or problems — e.g. handling production incidents, responding to security events

On the business side, analyze each process and norm in the business iteration:

  • Early stage: the main investment should be in setting the initial norms and processes
  • Middle stage: practice the norms and continuously track each process’s input-output time, striving to make delivery time predictable
  • Later stage: find the points in the process worth improving and invest effort there

On system design goals:

  • The smarter the person in charge, the dumber the whole system. There must be standardized processes and documentation
  • Reduce dependence on technical core people; control the paths by which problems reach the technical core
  • Consider the rate of return and input-output
Related Posts