Part 1:  Background on the Space Shuttle program

By looking at some of NASA’s manned space flight history, we can see two of the easiest mistakes that managers make when self-preservation of a favorite project becomes their modus operandi.  These mistakes are becoming blind to reality and forgetting how to listen to those closest to the action.  These two mistakes can kill any mission-critical system implementation.  

Last year I watched Apollo 13 with one of my daughters.  Apollo 13 is the movie based on Jim Lovell’s book Lost Moon, which tells the true story of the Apollo mission just 8 months after the first landing on the moon.  This is a dramatic story where everything that could go wrong in the mission does go wrong.  After liftoff, when the mission is halfway to the moon, the astronauts heard a violent explosion that no one could explain.  Suddenly the ground crew and the astronauts are faced with a situation that they have never faced before - no one knows what exploded or what subsystems have been damaged on the spacecraft.  All they know is that the oxygen tanks and battery levels are falling.

The movie then shows the ground crew and the astronauts making a series of improvised solutions to various problems that arise, all while the astronauts know they have a slim chance to return alive.  While watching this movie, both of my daughters said that they would be scared to be astronauts.  Later, after the astronauts safely land and the movie finishes, my youngest daughter Olivia seemed to be thinking.  Eventually she said to me, “But Dad, it must be much safer now that we have all this experience, and we must know better how to do this.  Don't we?”

It turns out there was no good way to answer Olivia.  Do we really know better how to “do this”, if by “doing this” we mean safely sending astronauts into space and returning them while completing the mission?  The evidence is not at all clear.

In this note, I'd like to focus on getting real buy-in for IT initiatives - buy-in that results in decisions and follow-through on those decisions. How can governance help you gain support and engagement from the whole organization?

I don't know about you, but seldom have I heard people discussing a project say "Boy, we'd be a lot more successful if IT initiatives were in alignment with overall institutional strategy." If you do hear that statement, I'm willing to bet that you're sitting in a committee meeting thinking about a new game of buzzword bingo.

While we need alignment, these abstract discussions miss an opportunity for governance to be relevant to major IT initiatives. What I do hear from people discussing a project is something closer to "Those guys in the College of Engineering seem to fight us every step of the way. Why do they always feel they need to use their own system rather than work with us in central IT?" Or, how about the lament that "We do have a steering committee for our system-wide LMS initiative. We just can't get half the campus to actually use the new system."

You can get a good look at this situation by viewing two recent studies. The new 2009 Sloan Consortium report just came out last week, and it documents the continued, and potentially accelerating growth of online courses and programs. For the first time, the report includes enrollment numbers affected by the recession that started in 2008, giving us a perspective on its potential affects.  The highlights are that for fall 2008, 1 in 4 higher ed students takes at least one online course, with 4.6 million students in this category, and enrollment growth rates of ~17% per year. Compare this to overall enrollment growth rates of 1 - 2%, and you get the distinct picture of online's growth - it's here as a major option, regardless of any skepticism.

At the same time, a WCET and Campus Computing Project survey was released in October 2009, and it documents the turmoil of our online organizations and academic technology infrastructure. The highlights are that 45% of online units have re-organized in the past 2 years, 52% of online units plan to re-organize in the next 2 years, and 29% of online units have reorganized in the past 2 years and still plan to do so again in the next 2 years.  Talk about instability. Furthermore, while 88% of online units use the same LMS as the main campus, 47% plan to re-evaluate their strategy, and 24% plan to change LMS in the next 2 years.

As this example shows, many times major system upgrades are viewed as a technology project, and organizations miss the opportunity to improve the associated processes and improve business results. Even with the best implementations of major systems, organizations quickly learn that they could have taken better advantage of the system if they would have made some different decisions during the implementation. Projects that were driven as technology implementations usually missed providing many of the break-through transformations of business processes that deliver real business benefits. Often the upgrades are a result of a technical decision to stay current with software versions to ensure the vendor continues to provide support. Upgrading for support reasons provides business benefits to the vendor, but does the organization receive benefits? As the upgrade project begins, questions that should be asked are:

• What was the result of the last implementation/upgrade?  We there open issues or problems with the implementation?  Did the organization achieve the expected business benefits?
• Are there particular processes that are not performing well? Potentially highly manual processes, high error rates, or too slow?
• Were there requested enhancements that are included in the release?
• Many times organizations or people within the organization will have a negative opinion of the software package. Is there a negative opinion? Has anyone done a root cause analysis to determine the cause of the discontent? Many times perceived problems are based on the implementation or business processes, and not based on the software itself. Upgrading the software will not eliminate these issues.  Are there project or business process changes that should be addressed before implementing the upgraded system?

Based on an assessment that asked these questions, the organization listed above decided to remove the custom component as part of their first upgrade.  Some of the benefits they received were:

The enterprise software market has gone through a significant period of consolidation, which has resulted in organizations selecting among a decreasing number of vendors for increasingly large and complex applications. Even though the market has changed, too many organizations still make enterprise software decisions based on the obsolete assumption that there are multiple vendors that are primarily differentiated by their product features. From this standpoint, the selection of enterprise software often comes down to scoring exercises based on product features, technology choices, product pricing, total cost of ownership (TCO), and implementation planning. The problem with this approach is that it focuses too narrowly on the past — what features and configuration capabilities have been developed to date? — whereas the focus should be aimed toward the future — what is the underlying system design and its implications?

Continue reading. Download the PDF.