Saturday, August 27, 2005

Revolution #9

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!):


  1. Is it possible to encapsulate the front-end in our current system?

  2. 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?

  3. 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.



Another comment:
Radical change sometimes requires that we forget the past and embrace the future.

I say:
Those who forget the past are doomed to repeat it.



Another comment:
You say you got a real solution Well, you know We’d all love to see the plan

I say:
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.

I say:
Amen...except for that part about the "tortoise, slow and steady"...can we agree instead on the "fox, smart and nimble"?

3 comments:

Nancy August 27, 2005 at 8:34 AM  

Assuming it makes sense to talk strategy at this point, and it may, I'd like to hear your perception of our systems' users' greatest unmet needs. It's great that you've been able to speak with so many people so quickly; no doubt you've gotten more varied input than many of us who've been here for years. Do you have an idea, at this point, about what we're most lacking?

I'd also like to make a comment about the nature of Internet communication, from Website to blog to discussion list: it's helpful to know who's talking, in terms of their experience and background. It helps one know how to weigh their written opinion. So I'll add that to my signature.

I do wish some other folks with long experience in administrative computing would chime in here. There are lots of people with more frontline application development and support experience here in AIS than I (I've spent a lot of time doing internal support/development/project leadership) and I wish they'd speak up.

Nancy
(currently AIS uPortal; formerly Java instigator, Y2K IDMS/COBOL remediator; internal infrastructure/project life cycle support; U of I Med Center Hospital DBA; U of I internal support; U of I SIS COBOL programmer starting in 1976)

rbellavia,  August 29, 2005 at 10:30 AM  

Interesting to read the comment made in the last post about.. "the key to success was a plan that produced usable results, piece by piece, every 6 months." 
 
For many years while working on various applications for different departments around campus, it seemed the problem was apparent and the solution was to write code and fix it.  Nothing wrong with that except the solution was often attempted without really analyzing the problem.  This usually resulted in an application that was inefficient or had many re-workings in order to get it right.  In our recent endeavor, we (AFIT) have been following a very tight CPI approach.  Over the last 7 months, we have been tasked with taking paper driven processes (which is only one aspect of the project) and moving them to an online format (and I don't mean word or PDF) and most of the work has been trying to understand the business requirements and gathering those requirements. 
 
We (along with the department team members) have discovered many ways to improve that process that often gets overlooked when shoveling paper back and forth.  Several conceptual workflow drafts have gone back and forth and none of them have been spared the red ink marks.  Every time we think we are getting closer we realize there is a better approach or one less step required.  This is good, my team and I welcome the red marks, it will make a better solution in the end where instead of having an inefficient tool or application, we will have a system that will only get better. The focus of the project has therefore shifted so that pushing out the application is by far the easiest and fastest aspect, given the Vignette tools with which we have to work. For some however, this process has been a struggle because they want to see results, they want to see a prototype.  For me it has been a struggle as well, not because I don't believe our CPI approach is the right way, but because I don't know how to often comfort those who want to see prototypes and perhaps are not used to this process we are going through.
 
So back to why I initially wrote this comment... We are taking the piece by piece approach.  We are not looking for the all out solution until we can clearly and successfully deliver something of value and benefit.   My team is not an expert in the business functions for the departments we support.  Instead, having the departments drive the business needs is the key to a successful solution.   I like the comment Max made.. "We need to apply continuous improvement to our business processes not just our technology. Technology must not only be continually improving but technology must also be flexible and nimble enough to support the continual improvement of business processes".  I absolutely agree.  We chose to purchase that flexibility with a set of tools that would allow us to achieve the flexible and nimble support for continual improvement of our business processes.  I can honestly say that my team has a long way to go before we can solve all our units’ requirements but I can also say that I am excited at the direction our team and organization is heading and the benefit this approach will bring.

Cat,  August 31, 2005 at 7:18 PM  

What a breath of fresh air. I don't have the history that many of you have at ASU, so I will no doubt [and inadvertently] step on toes all over the place here. It's about time we stopped hiding the ugly baby at the family reunion. Let's be honest, acknowledge our shortcomings, forget about duck-and-cover and witchhunts to pin the blame on someone. To twist a phrase, "It's about the customers, stupid." Let's nail down the real problem and get on about fixing it.

In the last year and a half since I came aboard with Administration and Finance IT [AFIT], I've gone from dismay to morbid fascination to excitement to passion about the potential we have for improvement. I refuse to believe "it can't be done" or "that'll never work." I choose to believe that we CAN do anything we decide to do. Stop saying no and figure out how.

I also believe we have talented people who want to do good work. What I hear many of these people say is that they feel they're working their keesters off, that they can't possibly work any harder and why can't the customers be satisfied with that? Maybe we're working on the wrong things...

There's been a lot of talk about approach -- fast and nimble vs. slow and steady, front-end vs. backend, yada, yada. Not that these aren't great discussions, but are they keeping us from doing the work? Can we talk WHILE we work? We don't have time to sit back and philosophize.

Here's the start of a plan -- hopefully the HTML formatting will work:
1. Focus on greatest needs and solutions with most impact first. We have a vision and a mission as the New American University. Are we close to that vision? Where do we fall short? What is holding us back? Be brutally honest. We need a quick triage and action short list. Where are we bleeding money, time, manhours and lost opportunities? Let's cauterize those wounds quickly.

2. Identify solutions with highest short-term ROI and long-term flexibility. At AFIT, we believe we've found one of those solutions with the toolset we recently purchased from Vignette for enterprise content management, web-based application development and delivery of web content and applications in the portal environment of our choice. Vignette is not the be-all, end-all solution -- nothing is. But after extensive research, a six-month public RFP selection and contract negotiation process involving stakeholders from Administration and Finance to Central IT and student services, we believe we identified the best solution available at the time and one that can help us build a bridge across existing systems now and in the future.

3. GET GOING! Move, quickly enough to capitalize on opportunities, wisely enough to recognize when we're heading the wrong direction, and flexibly enough to change our trajectory, all the while keeping our view wide, including all our customers, the entire organization, both short- and long-term goals and documenting everything along the way.

Do we have the people in place to do this? I don't know. I'd like to be one of them. How do we get the right people in the right place? I hope this open and frank discussion will break down the walls of our dusty silos, let in the light and fresh air, and draw those people to us.

Just do it -- and count me in!