Last time I wrote some quick, general reflections on The Phoenix Project. This time I want to get more specific and discuss ways in which The Phoenix Project applies to higher ed IT and suggests some directions for progress and improvement.
1. Plan Smaller (but Faster)
Probably the most well-known feature of DevOps is the idea that you should make frequent, small code releases. This allows for the faster detection and fixing of problems before they have a chance to compound. In higher ed, you typically aren’t running a pure software development shop, where you release new code for software you’ve developed in-house. Instead, you live in a messy world of modifications and maintenance for ERP systems, dozens of data integrations between softwares: many SaaS, maybe some built in-house. The lesson for this environment is about change management. When you are planning changes that affect the campus, do it gradually. Implement one new module of a software at a time or migrate to a new campus Wi-Fi management system a few access points at a time. This will allow you to anticipate problems before they affect the whole campus and you can make adjustments from what you learn as you implement.
2. Make Work Visible
To deal with their broken change management system, the IT team in The Phoenix Project starts writing down every proposed change on an index card, which are then categorized and scheduled out on a white board. Later on, they start implementing a kanban board for Brent, their key employee. In both of these cases, they are making their backlog of work and planned work visible. I think there are a lot of ways to effectively visualize work, but the key is to make the important work of your IT department visible. This doesn’t automatically happen; in a small team, people may just manage their own projects, and their work may only become visible when it has a dependency on another team member or when a problem arises. If you make a concerted effort to visualize and track the progress of your projects and tasks, you’ll be in a better position to anticipate obstacles and conflicts with other priorities. It will also make it easier to understand and communicate the impact of shifting gears and focusing your staff on the highest priority initiatives.
3. Internalize your School’s Priorities
As part of the process of turning things around at Parts Unlimited, Bill and John (the security guy) start meeting with key executives at the company to learn about their pain points and discover where IT is either part of the problem or could provide solutions. Anyone leading an school IT department should be a part of the school’s planning and decision-making processes, both short-term and long-term. They should know the school’s areas of focus and initiatives. Are there particular challenges with enrollment that are being prioritized? Is there an emphasize on completion and getting students successfully out the door? Maybe the school values cutting-edge classroom technology and its faculty want to be able to experiment with new toys. Whatever your school’s focus is, make sure that you find every opportunity for IT to support and enhancement these initiatives to make sure they succeed. No IT department exists in a vacuum - your job is always in support of something else. Know what it is.
4. Put your Resources Towards What Matters
Tying up the last couple points, once you can visualize your work and resources and you know your institution’s priorities, you can make sure that your department’s time, energy, and talents are going towards what will support and sustain your institution’s goals. This may sound obvious, but it sometimes involves thinking about things differently. One clear example of this in The Phoenix Project is the issue of security. In the first half of the book, John frames security in an abstract, rule-focused way that has no obvious connection to what the business is doing. Later on, the goal of security becomes to support and protect the company. In higher ed, we can take a similar approach - when we are explaining the value of any IT initiative, we should tie it back into our institution’s priorities and explain how it supports them. This approach also ends up helping IT. You won’t be viewed as that department that just says “no” and tells people why they can’t do something. Instead, you’re more likely to be viewed as an essential and active participant in the success of the school and a key part of the community.