Hope folks are reading the comments here too. Both on the forum and in private emails, we are starting to talk about more than scorpions. Not that I didn't appreciate the help with the vermin, but I am anxious to learn from and respond to what people are thinking about the future of technology here at ASU.
In the past couple of days some questions have been raised that I'd like to respond to. I'm doing it as a post instead of a reply to the comments to maximize the chance that people will read both.
Please remember, as I will try to, that we're having this dialog for the good of ASU. So it’s incumbent on all of us to tell the truth as we see it, to look for common ground, and to be open to being convinced of another way.
So here goes.
One comment -- and I'm paraphrasing here --
"CPI is no revolution. It's business as usual and if that's the "Grand New Idea", well it puts our hearts in our shoes."
I hear you. And if you accept that ASU has been as nimble and creative as possible in providing the solutions to its business units' problems in the past several years, and the only impediments to progress are the aging systems, then you're right.
So let me be absolutely clear. Based on what I've seen so far, I don't accept that.
Not trying to be abusive here, or to denigrate the work of hard working people, but my "thin slice" tells me that we are not responsive enough; that there are lots of folks who feel that the most creative, aggressive solutions to the problems that people have right now are not happening quickly enough. And that feeling is not confined to users. There are a lot of technical experts who believe it too.
I appreciate the flaws that exist in the legacy systems. I do. I think that these systems need to be replaced. But nimbleness must reign in the meantime, and the replacement must be done without a multi-year interruption in improvement.
If I'm wrong about that, by all means correct me. But if I'm right, I'd like to hear from some people who agree. Because breakout ideas for rapid improvement will help kickstart the change everyone wants. People must believe.
I don't want to dodge the issue of money either. There's a question about the payscale in there too. I have to admit that I haven't yet looked into relative salary issues. But I can assure you that I will look in to it. And if paying too little for excellent performance is holding back progress, that will have to get figured out. But so will paying too much for inadequate performance. They go hand in hand.
There's also a question about the value of agile development. Out of the four listed:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
numbers two and four are pointed out as possible errors.
I can see the concern here. Large, complex systems require good documentation and planning. So hearing someone say that we're gonna just start coding stuff as fast as we can and throwing it over the wall without any idea of how it all works together sounds a lot like suicide.
The problem with a discussion like this is that it’s an argument of generalities, and generalities of any kind are hard to argue with. Who could be against being agile? But who could be against writing documentation? Who's not for being more responsive? But who's for charging off to do complex things without a plan?
A benefit of my being here should be the process of self-examination that it forces. Part of my role is to facilitate a hard look in the mirror to find the things that need to change. And right now, I'm focused on speed and responsiveness. Why? Because I think most people in the institution believe we're behind where we need to be and we're not moving quickly enough to keep pace.
Will we need to spend money? I bet we will. Will we need to buy products and consulting services from vendors to help? I bet so. Will those things, by themselves, be enough? I don't think so. I've yet to find anyone on the campus who says we're humming along like a Swiss watch. So I'm trying to understand what needs to be done to accelerate the pace of change; hence, the leaning toward the values of agile development.
But to reassure you, I'm very much for planning. I like plans. I like them to come together quickly though. I like them to adapt to change. And I like them to have results that can be tested, early and often, to allow for mid-course correction.
I talked with a higher-ed CIO yesterday morning, who has been involved in two system modernization projects: one, at a research I institution, that cost more than $100M and took more than 6 years, with middling results; the other, at a large community college, that took less than 3 years, cost less than $5M and has made his team heroes.
I asked him what the differences had been. I asked him straight out if the reason the community college project had come together so quickly was that it was much simpler. I asked him if the research I institutional overhaul had to be costly and slow because of the complexity of the problem.
He said no. He said that, based on his experience, the difference between the two projects was simply a matter of approach. He felt the key to success was a plan that produced usable results, piece by piece, every 6 months. Transparency and community involvement were also critical of course, but that incremental results were by far the most important component of success.
That is CPI to me. Significant, well understood, valuable, high-priority, incremental results that inspire the entire organization to say "Man, we are really moving forward!". Belief in progress is a powerful force. That's all I'm looking for. And that could be the way people already feel about technology on campus, and I'm just talking to all the wrong people, but I don't think so. I think a jump start is required.
Again, if I'm wrong, teach me. But if I'm right, I'd like to hear from some people who agree.
I don't have any agenda other than helping ASU achieve a technology organization and information system that is capable of supporting the scale and vision of the New American University.
Another commenter summarized the CPI process I described in "Revolution" as:
...we make small changes gradually, until we have both the updated working system we wanted in the first place, plus ASU’s current business practices changed.
That's pretty accurate. I guess I’d rather the changes be medium-sized and rapid, as opposed to small and gradual, but this is the basic idea. The commenter goes on to list several advantages, which is great, but also indicates that there are some key questions (which is even better!):
- Is it possible to encapsulate the front-end in our current system?
- If we abstract from the back-end, will we have to maintain and update the front-end each time the Vendor makes corrections/enhancements to the back-end?
- Can our current business model adapt to these changes or must we abandon them?
These are the key questions, and we need some deep answers, not analogies to rock songs. But I also think they aren't yes/no questions for the system as a whole. I think these answers can be different, component by component. It’s possible that when we dive deeper we find different approaches for different problems. That’s the process I’m hoping to accelerate.
I just don't want to see ASU go the familiar route up the mountain, halting forward progress for a long time while we try to create some uber-system that solves everyone's problems all at once.
Radical change sometimes requires that we forget the past and embrace the future.
Those who forget the past are doomed to repeat it.
You say you got a real solution Well, you know We’d all love to see the plan
Let's change the song. I hope to learn enough here, and forge a broad enough alliance that our song goes:
You say you got a real solution well, you know, we'd all love to make the plan
Another commenter warns:
Seldom in this industry are those systems that offer everything — the revolution — best for our objectives, our destination…Open standards allow for connectivity and extensibility but are not tied to legacy systems — just because one system may change doesn’t mean that all should. These “Baby Steps” to improvement overtime, like the tortoise slow and steady, offer the best chance of improving processes, reducing costs, and implementing now rather than later — we owe this to all of our stakeholders especially our customers.
Amen...except for that part about the "tortoise, slow and steady"...can we agree instead on the "fox, smart and nimble"?