At the Movies: Learning to Balance IT Demand and Delivery

I Love Lucy: The Chocolate Factory

Like most IT organizations, Notre Dame has seen tremendous growth in the demand for its services. Just as technology has developed rapidly, so too has our customers' appetite for IT. At Notre Dame, we refer to this reality as "IT for Everything," which reflects that there is virtually no opportunity or business improvement that doesn't contain an IT component. Every new campus initiative comes with a new app, a new device, or new infrastructure needs.

With this swelling of IT demand, IT professionals may feel like they are in a "Lucy and the Chocolate Factory" episode, where the chocolates (IT demand in our case) are coming down the conveyor belt so fast that despite Lucy and Ethel's doing everything they could to keep up with the chocolates — eating them, putting them in their hats, and stuffing them in their shirts — they were soon overwhelmed. Furthermore, this increase in IT demand occurs within the backdrop of a world in which IT resources and budgets largely stay the same or even shrink. Extending the metaphor, many organizations simply cannot add another Lucy or Ethel to help them meet this increased IT demand.

Harry Potter: No Magic for Muggles

So what can an IT organization do as demand increases while IT capacity stays the same (or shrinks)? If we lived in the Harry Potter wizarding world, we could possibly chant an incantation ("Projectus Reducio") that would magically ensure that IT demand always matched available capacity. Unfortunately, IT leadership must find another path forward or the work environment for our staff will be characterized by stress, suboptimal performance, and burnout.

Slow Down, Do Less, Achieve More

Cathartic as it feels to bemoan the challenges facing IT, that is not my intent in this case study. Rather, I want to share some solutions that we have used at Notre Dame to address what might often seem like an intractable problem. As a word of warning, some of the ideas might seem counterintuitive at first. For example, the first piece of advice is simply to slow down.

Slow Down

With all the demand coming at us as IT professionals, slowing down is probably the last thing you feel like you can do, yet we have found it to be a critical first step.

With the fast pace of change and limited resources, it is extremely easy to become so "busy working in the IT business, that we don't take time to work on the IT business." However, if we don't take the time to improve how we conduct business, we ensure we never get better. This requires taking time to plan up front as well as taking time to reflect on what is and isn't working well and to make course corrections as needed. This is certainly not a new concept, as W. Edwards Deming popularized it in his Plan-Do-Check-Act model.

Nearly six years ago, Notre Dame's IT organization slowed down so that we could plan a better process for handling project governance. We put together a cross-functional project team (consisting of customers and IT professionals), freed up roughly two days a week of IT staff time for several months, and used Lean Six Sigma methods and tools to address our IT demand/capacity dilemma. The rest of this case study describes the steps and lessons learned along our journey.

Step 1: Set Up Guidance Councils

At the core of our IT project governance framework are guidance councils — customer-centric committees typically organized around customers that share a business context (e.g. our Employee/Finance guidance council includes representatives from Budget, HR, Provost, Payroll, Finance, etc.). The purpose of the guidance councils is to receive, evaluate, and prioritize IT demand relative to the capacity available. These guidance councils usually meet every six to eight weeks and have some unique characteristics:

• Customer Chaired: Previous attempts at project governance started with the committee chair role filled by central IT. In this more successful iteration, we flipped the script and moved to a shared governance model. Despite some initial concern about ceding control to others who might not understand technology nearly as well as IT staff, we have found this model preferable. It immediately changes the dynamic so that central IT is not perceived as a gatekeeper and does not put central IT in an "us vs. them" situation relative to our customers.
• Customer-Only Voting: Also new, our customers are the only ones who have a vote (one vote per represented customer group) on which project requests get approved. Central IT's role in these committees are twofold: (1) to inform the group as to different projects' level of effort and complexity, and (2) to provide options, guidance, and answers to questions about the technical tradeoffs of different approaches. We can provide recommendations when asked, but we are not a voting member of the councils. Our stance is that the customers know their business better than we ever will, so they are the best ones to set priorities.
• Customer Institutional Focus: While the guidance councils have the autonomy to determine the way they want to work together, we did insist on several guiding principles. One of the most critical ones is that we asked each of them to maintain an institutional focus and not to focus only on their immediate departmental needs. We want to prevent sub-optimization, where logical, well-intentioned local decisions can result in sub-optimal decisions for the university as a whole (e.g. implementing a Microsoft Dynamics CRM departmental solution when the rest of the university uses Salesforce). In addition, we ask each department to put aside their immediate departmental needs when voting so as to prioritize the projects that provide the most value or serve the greatest need for the university.

We have five functioning customer guidance councils at Notre Dame, including Employee/Finance, Student Administrative solutions, Teaching and Learning, Campus Administrative solutions (e.g. Athletics, Campus Safety), and an IT Executive guidance council for larger, more complicated enterprise initiatives. In addition, we have one IT guidance council for internal IT projects.

Step 2: Determine Capacity

Once we set up the guidance council structures, the next step was to determine how much project capacity would be available to each council. We determined our capacity by evaluating the type of work each team needs to do:

• Maintenance of Business (MOB) — the operational activities necessary to support, upgrade, and troubleshoot existing technology. This is the effort needed to "keep the lights on."
• Customer Care — small projects/enhancements that represent new functionality that we can deliver quickly (we use "less than 50 hours" as a guide). The value delivered can greatly outweigh the small effort and provide quick wins.
• Project — the delta between the size of your project team and the capacity needed for MOB and customer care, which represents project capacity available for use by the guidance councils.

Step 3: Determine Project Inbox Size

You might think that once you determine capacity, you have all the puzzle pieces in place. However, we took it a step further to get an estimate of how many projects we thought we could reasonably work on and deliver to customers, based on our capacity. This is an important concept because our guidance council structure borrows from the Japanese lean manufacturing principle of a Kanban. In a Kanban system you establish an upper control threshold to limit the work in progress so as not to overload the system. Once you hit your upper control threshold, you cannot put another item into the queue until you have completed one. We employ this concept for our project work. Its importance is underscored in the next step.

Do Less (At One Time)

Step 4: Evaluate and Prioritize Demand

Once we determined the guidance council makeup, capacity, and inbox size, it was time to instantiate them. We granted a good deal of autonomy to the different guidance councils so that they could best determine how they wanted to work together. In fact, the first one or two meetings focused only on developing team ground rules. Because many of these customers had not worked together in this type of structure before, it was important to recognize and provide time for the forming, storming, norming, and performing stages of team development. While all guidance councils work slightly differently, they all had to work through the following:

• Project Intake — How would the guidance council receive project requests, and what information did they need to make good decisions?
• Decision Criteria — What criteria would the guidance council use to evaluate and approve project requests?
• Reports/Data — What reports/data would the guidance council need to make data-informed decisions?

After we made these decisions, it was time to accept, evaluate, and prioritize requests for IT. Using their established processes, each guidance council would accept project requests, assess them against one another using their specific decision criteria, and approve and prioritize the requests. As mentioned, the guidance councils are limited on how many projects they can put into the queue based on the established project inbox size. For example, if we determine that our upper control limit is four projects, four is the maximum number of projects our customers can approve to work on at one time. Once we hit four projects, another project cannot be approved until we complete a project. Only after a completed project is removed from the queue is a "pull" signal issued that allows another project to enter the queue. The idea is to keep projects flowing through the queue at the optimally determined pace; too few projects result in underutilization of resources, and too many projects result in overloading our process.

Achieve More

While it would be disingenuous to suggest that all of IT's throughput gains over the past several years have resulted solely from our guidance councils, it is fair to say that they have been a major contributor. Except for the first year we implemented the IT project governance changes (FY 2011), we have increased our project throughput every year from our baseline (FY 2010). In fact, our project throughput improved every year for four years before slightly leveling off this past fiscal year (figure 1).

Apollo 13: Failure Is Not an Option

Like the Apollo 13 mission, failure is not an option, so it is critical to learn rapidly from one’s previous mistakes

Having stood up our first guidance councils over six years ago, we continue to learn what works well and what doesn't work quite so well. Here are some well-earned lessons learned over the years.

• Involve Customers in All Aspects of the Process. Because our guidance councils center on our customers, it makes sense to involve them in the project governance process as early and as much as possible. For example, our customers determined the logical groupings of our customer-facing guidance councils. We also had each guidance council set up their prioritization process in the ways that worked best for them. Involving customers is critical for several reasons. First, your customers will have unique experiences and insights that will make the process better. Second, involving them early instills acceptance of the process and ultimately, buy-in.
• Maintain Your Focus. The guidance council concepts built on the idea of giving IT staff the ability to focus on only one activity (or at least only a couple of activities) at a time. Although many people believe they are good multitaskers, science does not bear this out. What people think of as multitasking is actually switching back and forth between activities; these switching costs can be substantial, with estimates as high as 30—50 percent drops in productivity. Allowing IT staff to focus on one activity is why we separated staff into project-based and support-based resources. It is also why we set and enforce project inbox sizes. Letting IT staff focus alleviates some of the pressure they feel (since they are not bouncing back and forth between activities) and encourages positive morale because they can deliver results faster. Success definitely boosts morale!
• Respect Your Established Guidelines. A lot of thought goes into establishing guidance council guidelines such as the project inbox size and the amount of time you carve out for the smaller customer care initiatives. Ignore these at your peril. For example, every time we have we have opted to work on more projects than our suggested inbox size, it has come back to bite us. We end up taking on too many projects, which results in increased switching costs and frustration on the part of our customers and staff because we have far too many projects vying for limited resources. Likewise, we have sometimes tried to add more project capacity, squeezing out customer care resources. The result has been customer frustration because we no longer have the capacity to do the lower effort, quick win types of projects that are often as important to our customers as their bigger projects.
• Don't Schedule Projects Too Far in Advance. A good rule of thumb in scheduling projects is to only schedule projects three to four months in advance. The reason for this is twofold: (1) if you schedule projects too far out, you will lose a major incentive for your customers to meet — they might get frustrated if no resources are available for their projects; and (2) the purpose of the guidance councils is to gain agility. Since technology changes so quickly, you need to be able to respond to changing IT demand quickly. If you schedule projects 6–12 months out, you lose this flexibility.
• Limit Projects by Decree. High-level executives approve some projects "by decree" outside the guidance council process. While your organization will need such flexibility at times, projects should be decreed from above on a limited basis. Otherwise, customers will become frustrated that they no longer have a say in project prioritization and the process will collapse. Before we implemented our new guidance council project governance process, more than 40 percent of our projects were decreed from above. Since then, we have had less than a handful because executives have respected our project governance process.

Forrest Gump: A Box of Chocolates

With the rapid pace of innovation, technology demand will only continue to increase in the future. Furthermore, the amount of IT staff we have available will probably not increase to keep pace with this demand. But don't despair!

While we may not have control over IT demand (chocolates in my I Love Lucy analogy) or our IT capacity (Lucy and Ethel in the chocolate factory), I hope this case study demonstrates that we do have considerable control over at least one variable — the amount of IT demand we work on at a time (the conveyor belt).

By slowing down and doing less (at one time), we can actually achieve more with the constrained resources we have. The best way to do accomplish this is to engage in a shared project governance structure with your customers. By partnering with customers and employing some of the concepts described in this case study, our IT professional lives no longer have to resemble a box of chocolates where we don't know what we are going to get (Forrest Gump: "My mama always said life was like a box of chocolates. You never know what you're gonna get."). Rather, we can position our IT staff and our customers so they know exactly what, when, and how much they are going to get. This will build credibility with customers, reduce the stress levels of IT staff, and deliver more value to the university through increased project throughput.

As Forrest was wont to say, "And that is all I have to say about that."

---

Todd Hill is senior director of Customer IT Solutions in the Office of Information Technology, Notre Dame. He also serves as concurrent instructor for the Mendoza College of Business and currently teaches Project Management and Lean Six Sigma.