By Dick Stark

I recently finished The Phoenix Project, and made this required reading for our entire company. It is a story about “IT, DevOps, and helping your business win.”  Who ever thought a book about IT would be a page turner? But, it is. Check it out for yourself.  Here is a short summary for those interested in the “CliffsNotes” version.

The Phoenix Project, written by Gene Kim, Kevin Behr, and George Spafford, is about a fictional auto-parts company, Parts Unlimited, with retail outlets nationwide. (Gene Kim is the former CEO of TripWire, a security management software company. Years ago TripWire focused on closed-loop change management and was a BMC technology alliance partner.)

The novel is about Bill Palmer, a recently promoted VP of IT and other company executives as they race to bring to market a new application, code named “Phoenix” which will attempt to close the gap between its arch-rival, that is “eating Parts Unlimited’s lunch.” Phoenix is a customer facing service catalog / retail site, closely integrated with its e-commerce channels. Along the way, nearly every IT calamity possible befalls the company. Here are several lessons learned.

Tribal Knowledge. Like a lot of IT departments, Parts Unlimited has a key IT engineer, Brent Geller, that is available nearly 24×7. There is no IT issue that he cannot solve. Naturally, Brent does not document anything in their incident and problem management system. This presents two significant challenges. First because nothing is documented, it appears that less work is happening, making it difficult to ask for extra resources. Second, if Brent “gets hit by a bus,” there is no documentation, especially among the many legacy applications that are still in use, and which he supports. One of Bill Palmer’s first tasks is to implement Knowledge Management.

Prioritize. A common RightStar implementation risk factor is optimization of our customers’ resources and systems. In our rush to get a project started, we often find out that the customer is not ready. Either their systems are not available or our project is not high enough in their queue. Even worse, the key stakeholders are not available during the design and planning stage of the project.

Change Management Matters. Like several customers we know, Parts Unlimited purchased a Change Management system and paid a software company and its consultants thousands of dollars to get the system up and running. After about two weeks, the company abandoned its regular CAB meetings and users stopped using the system complaining, “it is too  cumbersome and slow.”

The result: a payroll application outage thanks to a rogue security application applied without following any change processes. This was a minor incident compared to what comes next….

Stay tuned for part two in my next blog post. I’ll next discuss how Parts Unlimited came together as one cohesive team.