If you are in the trenches of IT, as in information technology, you owe it to yourself to read the book called The Phoenix Project. There is a lot you can learn from this book about achieving success with your information technology projects. This book can add value to all sorts of IT companies form Software Development to MSP’s.
The book came out early 2013 as a fiction novel but the premise of the book is very real and encountered in some way, shape or form in the business world everywhere. The IT department of fictitious company, Parts Unlimited, finds itself at peril. All the IT top brass was unceremoniously fired from their positions. Bill, the protagonist of the novel, who once was a lowly manager, suddenly finds himself to be in charge of the Phoenix Project, which is too late and way over budget. Moreover, the CEO of the company gives him an ultimatum to fix it in 90 days or have all the IT department to be outsourced.
Sounds familiar, doesn’t it ? We, the veterans of IT departments, all have found ourselves in a position to clean up after an incompetent manager or team, while shouldering the burden of mistakes we have no part in making. The authors of the book Gene Kim, George Spafford and Kevin Behr, who are considered to be the pioneers of the DevOps movement, give you the glimpse of how the enormous changes in technology can be leveraged for the success of the business.
The book is full of characters that you most probably have worked with during your IT career. The IT services manager, who is a stickler for following the process to the dot, or the Rowdy distributed systems manager. And as you expect there is the Brent guy, who is a lowly operations engineer but due to his in depth knowledge of the IT systems, he is embedded in the heart of the whole organization. There is also the security and compliance guy who is always wanting to keep the systems updated and patched without think of the fall out.
If you look at the picture the authors depict in this book, although it is a fictional novel, it actually reflects real life. Hence, any IT person can relate to the events and can learn from the mistakes and victories of the book’s main characters. To me, this book is a reference manual of how to do DevOps right. Also, it is a book telling me, despite how bad the general picture looks, there is always a solution. Failure, together being an option, should not be taken as the default outcome. The book helps put mishandled IT departments in a positive view. Give hope for correcting the department’s issues with simple instructions.
More than the characters in this book, the reader will find the problems they face, interesting. Poor corporate organization, tightly wound systems without much documentation, leaving the administrators no options but to carry on with the technical debt acquired from their predecessors, are all realities in the life of an IT person.
The book, throughout the whole narrative, explains four main types of work that goes around, in the IT department. If we look at these classes of work individually, it will make more sense, how correlated they are to one another and not all the time in a positive way.
First type of work is what we call as Business Projects. This type of work drives the business process and as a result, affects how the business is run and how it interacts with outside entities. It has the highest visibility and lowest tolerance for failure. This is the main function of the business.
Second type of work is called Internal Projects. This is the work which the company functionality depends on. Although it may not be regarded as high visibility, breakdown in one or more of these projects will have severe impacts on how the company runs. This is supporting the main function of the business.
Third one is the changes. This is not a type of work that everyone plans for, but breakdowns in any of the first two types of work, cause these changes. Bug fixes, or feature enhancements are examples of this kind of work.
Last but not the least, there is unplanned work, which is the fourth and the most unwanted type of work. It exhibits itself spontaneously while performing other planned work but the effects of unplanned work can be disastrous. Hence, it should be avoided at all costs.
The underlying premise of the book is The Three Ways methodology. In summary.
First way is implementing ways to improve efficiency (also known as continuous improvement)
Second way is getting feedback from the community and handling the loudest noises first, continuing to weaker ones, eliminating premature problems, before they become major (i.e. loud) issues.
The third way rapid experimentation to achieve quality gains faster by using the efficiencies gained by the first way, strengthened by safety net of the second way.
As you can see, the book basically gives the blueprint for success of the IT projects. Even if you are not an IT person but have to work with the IT systems because of your tasks, you will find few, very good points, showing you how to communicate with the IT department to get the most out of them.
Here is the link for more information about the book.