Lessons learned from “The Phoenix Project”- Part 1
I was looking all over the internet for a book that can help me get the knowledge of the scenarios that occur in enterprise so that I can gain much knowledge in the starting of my career. Luckily, this book was given to me by Mr. Albert Anthony(Founder of Loves Cloud) as he believed this can help me gain that knowledge that I was looking for. Indeed this book has all the scenarios that one will be willing to know how to handle if you are moving towards the managerial positions.
FYI, this book talks about Agile, DevOps, IT silos and many such topics that are in hype but these are not discussed in detail and that is definitely not an agenda of this book. So, if you are a newbie and looking for some definitions than this book is too advance for you to read.
I am writing this for the people who might want to read this book but somehow find it tricky to buy. I am sharing the highlights from this 35 chapter book : The phoenix project by Gene Kim, Kevin Behr and George Spafford.
Storyline
The narrator is Bill who is an IT manager at Parts Unlimited and one Tuesday morning he got promoted. Well, he couldn’t have the joy of being promoted when he realized he has been promoted to handle a position for saving the ass of The Phoenix project which was in a doomed condition. If he is not able to do it in 90 days, the whole department will be outsourced. With the clock ticking, Bill revised the way the department worked, streamlined the interdepartmental communications and other services. While his journey, he came across several types of people who were actually responsible for this condition of the whole organization.
The funny part are actually these people, I am pretty sure you will find them relatable if you read this book :)
20+ pointers I wrote down in my diary and are taken from this book
1)Work not done
The book focuses on waiting time due to resource acquisition by some other task and leading to delay in several other tasks that might have taken less time if the resources were utilized efficiently. So it highlights about the work that is not being done and is staying in the software as tickets and the count of tickets increasing day after day due to prioritization and non-synchronized behavior of departments.
2) Dependence on Brent
Brent is the one who is known to be “life-saver” for several departments as he is able to resolve issues being reported by people. But Bill uncovered the fact that Brent was the one who was creating those issues on the first place and then waiting for those issues to create a bug which had to be fixed. And if he learned to resolve an issue than he never transfers the knowledge to the team mates so this dependence was never over.
3) Chaos without process and tools
Most of the issues were reported and resolved offline, leading to no records on the tools being used in the organization and due to this there was no record of the resource utilization in that work which was not at all reported on the tools.
4) Trust between departments
This book shows how the departments are fighting with each other due to lacking trust in work environment. Each of them believes the other to be less competitive and thinks that issues are occurring due to under performance of the other department. Here Bill tries to help them understand the importance of team work, not just department work where each and every person of the project hold equal responsibility for the project success.
5) Blowing off every commitment and schedule made by the team
Team is not really able to understand the problem, they are not at all performing the feasibility. So they promise of doing something at x time, which will actually take x mins in a normal condition. But what “the phoenix” was going through, x time has several constraints and those constraints were never estimated. One big reason behind this was they were not even knowing that these constraints existed.
6) Unplanned work is expensive
Couldn’t agree more. The work that you know has to be done and will take x time period to complete is not dangerous, but the work that comes up and changes the priority immediately is dangerous. So your planning is always on stake. To avoid or decrease the frequency of these emergency works popping in, it will take effort from all the departments as they will have to manage such situations on their end at first.
7) Work must not depend on who yelled the loudest
Deciding the priority of the work depends on the team, it must not depend on the pitch of the person who is assigning you the work. Everyone has right to speak out, and tell about what is right and what is wrong. Work in queue must not re-position on the basis of the person who is assigning, everyone must respect each other’s work importance.
8) Priority conflicts and bad multitasking
Just as explained in points 5, 6 and 7, you can now easily understand about the arising situation in point 8. Team has a piled up work and more work is coming everyday, now the departments have started working in isolation and there is bad multitasking as each of them is not aware what is happening on the other side of the wall.
9) Improving daily work is more important then doing daily work.
If you are spending your daily just doing your work like a robot then you are not doing it right. Each day you must analyze what you are doing and how you can improve it, at least the way you work can always be improved. Thinking about these ways of improvement will bring a change in your work routine too.
10) The improvement Kata
The book says “ It almost doesn’t matter what you improve, as long as you are improving something. Because if you are not improving, entropy guarantees that you are actually getting worse, which ensures that there is no path to zero errors, zero work- related accidents and zero loss.”
