You’re Sinking My IT Ship: Why Continually Treating IT Like a Battleship is a Problem
Government IT has been characterized by long term monolithic systems that fail to deliver. Part of the problem is approaching IT as a complex durable good, like a battleship, with complete specifications, known life-cycles, and defined missions. Fighter aircraft have six generations of evolving technology and missions, each having known maintenance cycles, life spans, and changing requirements based on future planning and doctrine, as well as, mission feedback.
IT has none of that because it has no duty cycle or doctrine. IT can be obsolete on delivery, regardless of development timeframe. IT delivery can redefine all previous requirements. IT has very little longevity, even if successful on delivery.
Yet we hear report after report of massively monolithic IT systems with four-year development cycles and 10-year duty cycles with increments to follow. Then, we hear report after report on how these fail. Is that to say all government agencies follow this death march plan for IT procurement? Not at all. The Federal Aviation Administration (FAA) has been very successful in creating smaller component programs that, taken as a whole, complete 100% of the requirements. Yet each component is a standalone entity, with milestones and deliverables, designed with the knowledge of the enterprise placement. In other words: a successful IT program.
And don't get the idea that this is a government only problem. I've been with commercial organizations that try to implement a complete enterprise solution encompassing ERP, HRM, and financials that wind up with shelfware and broken tools. Enterprise IT is not a product; it's a problem space. This is a mindset problem, not a technology problem.
So how do we change the way we go about setting up our enterprise IT purchases? First, get an enterprise architecture and stick with the disciplines of planning it. Second, understand that IT delivered quickly, with fewer functions, is often a much more successful than a slow, highly feature-rich delivery. Third, know that the requirements of today may not be relevant to the challenges of tomorrow. Our successes will feed into other successful projects; our failures will continue to make the news.
If Von Moltke was a developer, he may have instead said, "No software requirement extends with certainty beyond the first encounter with the end user's first click".
Photo courtesy of Wikipedia.