As Development Manager I am acutely aware of issues around change management and how they, if not managed properly, have the potential to do considerable damage to a business.

Most people know these days just how pervasive IT and related systems are throughout a business and the problems caused when one or more of those systems the business relies on stops working.

In The Phoenix Project I was therefore captivated by this fictional tale of how the main character Bill whom reluctantly inheriting a great deal of IT responsibility overnight at first panicked at the prospect, but then slowly changed both his own mind and the businesses perception of IT.

An eccentric mentor teaches Bill that development and deploying IT systems is just like a manufacturing factory, with ingredients, processes, steps, work stations, quality control, risks etc and how lessons learned optimizing the manufacturing industry can be applied to development and IT deployment. i.e. smaller batches, faster lead times, identifying and optimising constraints and more.

He had to tackle problems on multiple fronts, and not only deal with a barrage of technical issues, and change his mindset, he also had to deal with political enemies, often working against him at the same company and eventually save the company from itself and turn it around from losing market share and shareholder confidence to once again becoming a competitive profitable force in the market.

There are a number of lessons/reminders to be drawn from this story

• Surround yourself with allies
• Not everyone is on the same side as you. They have different agendas and sometimes even want you to fail
• Try and get those working against you to work with you
• The entire business needs to buy into any process that IT wish to implement
• IT is not just a department, but a core competency that every department should have
• IT governs, or is part of almost everything that happens in a business, so it needs to be considered/consulted when changes to the business are proposed
• The number of handoffs when planning and delivering work is proportional to how long something takes to do. Reducing the number of handoffs, reduces risks of errors/ miscommunication
• Manual processes should be automated wherever possible. Infrastructure as code, DevOps etc
• Make what you are doing visible
• Trial small changes to a process, then report on success/failure before scaling/rolling out.

When this book was written DevOps was in its infancy, today it is much more mainstream. The author was also involved in another book called the The DevOps Handbook which I have ordered straight after finishing this book.

In the book, I found the antipathy that IT had towards development difficult at first as I come from a development and software development management side of the business and we already do multiple deployments a day.

In fact, from my experience it is Infrastructure and IT that sometimes make changes to live systems that have caused issues, not the code/application so I had to think like an IT operations guy when reading the book, not a developer.

I came away from reading this book with a desire to help my business better integrate with IT, help them better plan projects and make changes based on business value.

Other things I have started doing, prompted with a renewed focus and by The Phoenix Project include

• Mapping value streams
• Compare to factory process
• Identifying risks and creating a risks register
• Concentrate on recurring issues
• Implementing drills/checklists. i.e. "The website is down, what do you do?"
• Educate the business on the importance of working with IT to ensure the business runs smoothly
• Spending more time optimising processes and improving systems and what Steven Covey would call 'Sharpening the saw'

I'd wholeheartedly recommend anyone whom is involved in building, maintaining or delivering software to read The Phoenix Project. Especially if they think their current process has room for improvement.

-- Lee