Resource Requirement Swirl (RSS) and How to Avoid It

When I met Christina G., a director at a community college in the northeast, she was beaming with excitement. Her college had recently approved her budget augmentation request of nearly $250,000 in on-going expenses for the acquisition, implementation, and deployment of a predictive analytics service in the cloud. Unfortunately, Christina fell into the trap of a Resource Requirement Swirl (RRS).

A Resource Requirement Swirl is the stalemate that occurs directly after the honeymoon phase of installing a new product or implementing a new service. It is the careful balance of mismanagement and naive idealization that produces an expensive and cumbersome product on the left and a lack of human capital on the right. Does this sound familiar?

For Christina, this effect has haunted her institution ever since they started streamlining budget requests for technology with a buzzword objective (you know, like “Improve Student Success”). RRS is very similar to recursion, which is when you define something by its previous iteration.

RRS is recursive: you start with a product or service, which then creates a resource requirement; since there aren’t enough people to implement, deploy, or use the product efficiently, a resource need is created; since these resources (usually people) require funding, now we have to go to the budget; since there’s no money in the budget, we can’t hire more people, so you’ll just have to figure out a way to make it work. Unfortunately, the “best case” is for the product or service to exist in the void known as RRS. What usually ends up happening is these products and services remain in a state of RRS until a new product or service comes along promising something new — and then the spiral starts all over again.

“It’s a common problem,” Christina tells me. “We get sold on these fancy products but when it comes time to actually use them there’s no one to use it. Even after we train people to use them, the novelty has worn off and now we have to consciously try to focus our planning around a tool instead of focusing on how a tool can enhance our planning. It’s nonsense.”

No, Christina, it’s higher education! (har har)

Avoiding the Swirl

You don’t need to email me about the joke I just made; I realize that some people are going to scoff at it. Here’s the thing, though: everyday, leaders in higher education are making decisions that will have far-reaching effects at their institutions based solely off of PowerPoint slides delivered by salespeople of third-party vendors. These decisions are rarely vetted through people with the technical knowledge and experience to perform an efficient needs analysis, which causes the institution to invest in something it doesn’t really have the means to fully use.

Imagine your significant other putting a down payment on a 4-ton bulldozer, with a 3-5 year contractual obligation to make annual payments — and you personally have to spend time each day taking care of it.

The next few years you are going to need to justify spending all that money, so you’ll need to start planning your commute differently and even thinking up projects you probably never would have thought up before, all because now you have this tool without first having a plan.

We should be encouraging our fellow leaders to stay away from Resource Requirement Swirls, not facilitate them. Colleges can avoid this condition by promoting capable, tech-savvy people who have shown upward momentum through their commitment to avoiding RRS. Not only should we be encouraging these shining stars to apply for management positions as they become available, we should also be going out of our way to create leadership roles to provide opportunity for up-and-comers to shine. Why? Working your rising stars up the ranks creates technical proficiency at the highest levels, something you cannot get by hiring from the outside.

Avoiding RRS means you have to ask the uncomfortable questions. People who are hyped up on a sales pitch rarely want to hear someone bring down the mood in the room, but someone has to pull everyone down from the clouds.

Before you commit to that piece of software, that new service, or that hyped-up process, ask yourself:

  • Do we have the personnel to use this?
  • Will our people have the necessary training to produce the desired outcomes?
  • Will our people have the time to produce the desired outcomes?
  • Will this project result in MORE work for us? (i.e., are we really being more efficient, here?)

If you can answer these questions smartly and have the answers vetted through the people who will be implementing the product or service, deploying it, using it, and maintaining it (hint: these will all generally be different people and/or groups), then you have yourself a project ready for success!

Have you personally experienced symptoms of RRS? What are some other questions we can ask to avoid it?