In my previous post, I discussed the importance of dollars per capita re: resource shortages rather than simply number of staff or absolute budget. This may be something that all IT leaders have already discovered on their own, but to me, divorcing myself from thinking in terms of absolute budget (well, of course Santa Clara has a smaller budget than Stanford or a huge state school) or number of staff and thinking in relative terms really helped open my eyes. Basically, the real issue at the university or even project level is how much funding is available per user/customer/student/etc. It’s not about an absolute budget. $10,000 for 1 customer is enough to buy a whole dedicated server plus a decent bit of enterprise software. But the same budget for an entire project meant to serve 1000 students means sapping staff time and other resources from other projects and initiatives. That actually provides poor DPC for the one project, and decreases DPC for the other one(s).
Of course, low DPC is a problem that plagues many organization, especially higher education. Let’s face it – many corporate IT departments, for all their notoriety for being somewhat “faceless,” would still laugh at higher ed budgets in relation to goals. When a for-profit company decides to do X, and doing so requires $Y, then they find the money (or they cease to exist as a company, I suppose). That’s not the case in higher ed. So how do we address low DPC? First, there is the “let’s step back” part of the process. Jared Diamond wrote a great (though somewhat first-person-ish) book called Collapse that discussed, essentially, how civilizations generally decided whether they would perish or not. Examples he provided were the Anasazi Native American tribes, the Norse efforts in Greenland and, notably, the tribes on Easter Island that built their iconic Maoi statues. As each tribe attempted to “one-up” the other with larger and larger sculptures in greater and greater numbers, valuable natural resources – notably trees – were consumed at unsustainable rates.
Diamond asks the sobering question – what went through the mind of the man who cut down the last tree?
I think that a better question (and one that Diamond acknowledges) is – what went through the mind of the tribal leader that initiated the project that led to cutting down the last tree? Or what about the second to last project?
All IT departments make compromises. Choose one product over another. Assign X number of staff rather than 2X. Utilize existing vs. new equipment, etc. Sometimes it’s even “choose one product because it’s closest to what we need, but don’t implement all features to reduce scope and minimize staffing needs.” That’s the most dangerous compromise, because you are limiting the service from the very beginning. As software gets more complex and customer demands become more sophisticated, the service becomes less and less useful (even if the actual needed functionality is there, it just can’t be turned on).
But the compromises that one makes today are probably like that last tree on Easter Island. It’s part of a project that involved cutting down a lot of trees, including the last one. And before that, there was another project that got the islanders perilously close to cutting down the last tree. And a project before that, etc. Each involved a compromise – tribal prominence vs. societal destruction via deforestation.
In a realm where one is not looking at quite such steep consequences…it is still important to look back a bit at the history of compromises. It’s fine, in my opinion, to have made a series of choices that perhaps led one down a one-way street. But we can back-up and get onto a road with options that lead towards a new, hopefully better solution.
But that involves being able to step back and gain perspective and, importantly, guts. Lots and lots of guts. Because having gone down that original path meant telling someone “this is the right way.” And backing out means “oops. No it wasn’t” or “Turns out we got ourselves into a bind even though it looked good at first.” And it involves the concept of “sunk cost.” Money already spent should not impact your decision-making on future projects. It’s already been spent. You can’t unspend it. Nor will making more use of a ill-fitting service make that a better investment. So you have to back track, find the point at which infrastructure can be salvaged and head off in a new direction, all the while ignoring the $$$ already invested and looking trustees, co-workers, managers and everyone else in the eye and saying “We made earlier decisions because they were the right ones at the time. We are reversing course because it’s the new right decision at this current time.”
I’m not sure I’d be brave enough to do that on a daily basis. I’ll admit that freely.
The other option is to improve DPC by either limiting the number of new projects that will sap resources from existing ones, finding points of collaboration between departments that will make more efficient use of DPC, or both.
In the example I provided in my previous posts, two separate BUs within Central IT made decisions on the provision of mobile device access to the university e-mail system. One managed the systems decided not to support it. The other decided it was necessary but did not administer any servers. The latter therefore had to purchase a third-party product that wasn’t fully compliant and has presented numerous problems for mobile users. By not working together, DPC is reduced for everyone. But (and bear in mind that I do not know the inner machinations of the respective BUs) had their been some resource-sharing, the impact on any one person might have been lessened, the resulting product might have been better, and DPC would have been used more efficiently.
More later as I continue to have revelations, I am sure.