It's June. I hate June. Hockey just ended and football is still months away. June -- ha! -- what is it good for? Absolutely nothing. I'm so jonsing for some football I actually wouldn't mind the sucker punch feeling of a close game lost in the final seconds like the description above. Of course, the game is never truly lost in the final seconds. It's everything that leads up to that last play that really determines the outcome.
I could go on, but this blog isn't about football. It's about public service. It's about the nobility of government and radically changing how we work, not desperate attempts during the last seconds of a game. Yet the hail Mary play (or what my dad always called the "all fast guys go long" play) is exactly what we're seeing more and more in the public sector.
It's cleverly disguised as an expensive, well planned, drawn out, honest attempt to win. But make no mistake: It's done on a wing and a prayer. It's the rush to automate our processes in an attempt to deal with our capacity problems. The thought that your CIO and his staff can swoop in and make everything OK. The belief that IT can take the ball, magically transform into Tim Tebow, and complete the fourth-quarter comeback. The problem is, our projects hit the turf with a multi-million dollar thud.
First, the facts. Just a few years ago, an article on ZDnet discussed the 68 percent failure rate of IT projects in our country; not in our government, in our country. That's a success rate that rivals Clark Griswald's Vegas blackjack run. Add to this the fact that the average cost of an IT project for a large company is $2.3 million, according to a Standish Group report. That's a $2 million bet with worse odds than you'll get at the craps table.
Those numbers were a little shocking to me -- shockingly low in cost, anyway. Having worked in the CIO's office for years, I can attest that at any given time we had multiple projects in the eight- or nine-figure range. While $100 million projects weren't the norm, they certainly existed, or on the radar, in multiple departments. Also, the word "failure" for IT is like the word "savings" to the business folks. There are many definitions and it isn't always what it appears. For instance, being six months late might sound like failure, but IT guys feel that's more like the ball that's still in the air. A project that comes in at twice the original estimated price tag? That's not a project failure; it's a failure to anticipate budget needs.
Lest you think this is a "let's beat up the IT guys" post, let me ask you this: If you watch football, do you blame the players when the hail Mary pass falls incomplete? Most times, it's not a case of Ochocinco butterfingers or Moss-ish laziness. The hail Mary pass is doomed from the huddle.
Our IT projects are in disarray for three reasons:
1) We are automating bad pipes and faulty systems.
2) IT is not the cause of our issues, so it cannot save us.
3) Process improvement cannot be done in conjunction with system design.
First, we are automating bad pipes. There's a great story about how the spread of a horse's backside continues to influence modern space travel. Here's the gist: The wheel-spacing on ancient Roman war chariots was designed to accomodate the size of a typical horse's rear end. The wheel ruts from those chariots caused everyone to calibrate their wheel spacing the same, for fear of destroying their wheels by getting out of the ruts. Over the centuries, minor adjustments in technology took us from wagons to trollies to railroads, but the same people kept making the same jigs and equipment in the same specifications. Eventually, when the space shuttle was constructed, the size of the solid booster rockets (SBRs) was determined by the fact that they were shipped by train from the manufacturing facility. Engineers may have wanted to make the SBRs bigger, but they had to fit through train tunnels...which were only wide enough to accomodate trains...whose rail gauges were determined by wagon axles...which were determined by ruts from Roman chariots.
Technology works the same way. When we just take the work we do and automate it, we are making minor tweaks to work designed for a capacity that is no longer the norm. Certainly we get some advantages, but rarely is it the innovation and huge boost in productivity we anticipated. Often, it actually limits our thinking and ability to radically improve, like railroad tracks limited the engineering designs of the shuttle - but that's another article. Simply automating a bad process yields less than radical results.
Second, IT didn't cause the issues that rob us of capacity. Unless your IT systems are crashing at high-volume times (which happens), then IT enhancements are not going to help. Most of our process pipes are twisted and clogged by CYA, backlog and bottlenecks. IT alone will not fix those problems. It may get us to the bottleneck really fast, but we will still sit waiting. It may route the application electronically and save time in the mail room, but it doesn't, by itself, limit the amount of approval signatures needed to process. In the words of Billy Joel, "We didn't start the fire. No we didn't light it, but we try to fight it." (Good luck getting that tune out of your head. You're welcome!)
Finally, fixing the pipes cannot be done in conjunction with application development. We like to think it can, but I am more and more convinced that all efforts to combine these tasks are as fruitless as John Corabi joining forces with Mötley Crüe. They just don't go together. They never should have been combined, and they should try to never be combined again. The truth is, they both have a role in our future, but process improvement has to come before automation. It should not be done in JAD sessions, or in your project manager's business case. It needs to be independent of any automation thoughts and completed before we begin looking at the role of technology. Otherwise, we spend too much time trying to get our process improvement ideas to match our automation plans, and it has been my experience this relationship doesn't work out for anybody. Every process improvement change impacts work the IT folks have started and every IT decision has the potential to lock in a direction, pushing the estimated completion date and driving up costs. It is best to fix the pipes, then automate them. I would argue it's not only easier, but cheaper as well.
The best way to win the game is to call the right plays for four straight quarters. You should never be in a position where a $100 million hail Mary pass is the only way to get ahead. In the first quarter, identify your crucial pipes and the issues impacting success. Use the second quarter to improve those pipes by evaluating and working on how the work is done. Tackle the backlog, sack the CYA and assist the bottlenecks. In the third quarter, implement the changes and introduce automation where applicable. Then in the fourth quarter, enjoy the game.
As a fan of this game, I have seen teams routinely get 80 percent improvement using this model, recapturing not only their capacity, but their passion for their jobs.
Wow, I miss football. Take some time to share with everyone your favorite football story, or more productively, the plays you see being run today that are not working for us.
