In the last two weeks, headlines about two large and hugely important government IT-intensive projects have raised concerns about significant cost overruns, missed deadlines and the potential for scaled-back functionality that formed the basis for the spending decisions. One is the IT modernization work being done to support the 2010 U.S. Census. A $600 million contract to deploy more than 500,000 handheld computing devices to field agents (this is referred to in government circles as the Field Data Collection Automation or FDCA contract) is reported to be in serious trouble because the devices may not work as planned. More disturbing is lack of reliable cost estimates, as well as the possibility that the project may not meet expected deliverable timeframes for the next Census count (even if new requirements are set and more money is made available). The other initiative is the Customs and Border Protection (part of the Department of Homeland Security [DHS]) project known as the Secure Border Initiative Network (SBInet). It involves building a 28-mile "virtual fence" along the 2,000-mile U.S.-Mexico border that would include cameras, sensors, towers and software. Last week, DHS accepted a $21 million "prototype" system developed under contract by Boeing that lacked full operational capabilities. According to recent reports, this could result in as much as a three-year delay in putting surveillance technology along the first 100-mile stretch of the border. Serious technical performance problems may also necessitate a strategy shift away from the originally planned network of tower-mounted sensors and surveillance gear.

Mind-boggling, isn't it? Maybe this lends credence to the famous 1960s quote attributed to Sen. Everett Dirksen about government budgeting: "A billion dollars here; a billion dollars there — pretty soon we are talking about real money!" So how is it that after more than a decade of legislative and executive branch IT management reforms (requiring business cases, senior and executive management controls, enterprise architecture alignment, strong project management practices, and so on) that these kinds of "red light" problems and results arise with greater transparency toward the end of a project life cycle?

The short answer may be politics (with a small "p"). Many times agencies rush to project initiation because of the political pressure “to do something” about a problem, even in the absence of a clear understanding of realistic timeframes, complexities, costs and specific program or process improvement benefits (see "Why IT Projects Fail in Government" and "Lack of Goals and Specifications Doom FBIs Virtual Case Management System"). Another reason may lie in execution deficiencies: You have to actually follow good IT management practices (rather than just create the policies and guidance) for them to be effective. A third revolves around the quality of the data and information being used to justify and manage projects (completeness, quality, reliability, timeliness and broad access). A fourth, and perhaps most important considering the highly decentralized environment typical of government, is the lack of effective and workable IT governance structures (involving PMOs, investment review committees, ARBs, executive councils, and so on) with properly defined authorities and accountabilities. IT governance must scrutinize agency business demands, requirements, and priorities and diligently monitor project progress and performance (business value impact and technical soundness) from concept through deployment. Two conditions tremendously affect the success of governance at operational, tactical, and strategic levels: the degree of transparency in project condition realities (cost, schedule, risk and benefit realization) and agile, proactive and criteria-based decisions/actions. As "battle-tested" PPM approaches clearly illustrate, you have to "see" what’s going on with your IT investments and take action as required — either maintain the existing course, accelerate, stop, kill (not wound), delay or refocus. In government, herein may lie some of the biggest challenges with effective project and portfolio management (PPM). For more views, see my upcoming survey of government PPM technology providers.

Submit a Comment | Permalink

... and of course there's the technology being used. All these problems are exacerbated by the continued use of programmer-centric languages for specifying how policies/laws/regulations and other rules are executed by software. Unless those who make/manage the policies can manage them in their information systems those systems will continue to behave incorrectly.
JT
Author of Smart (enough) Systems

Don't forget contracts go to the lowest bid, often enough the lowest bid is not realistic.

Why oh why do people enjoy focussing on the IT side of major business focus. Since when have cameras, detection devices and the technology associated with the spy industry become IT.
These days every project requires 4 component: Someone to provide FINANCE; Dollars buys a project team: PEOPLE; People create KNOWLEDGE; and the people using that knowledge decide on appropriate infrastructure or TECHNOLOGY which includes everything from ICT to cars, cameras, networks etc.
These days there are very few projects that do not involve ICT but why do we refer to them as ICT projects. Lets be real and talk about them as BUSINESS investments that improve the services that organisations and government wish to offer their clients or citizens.
It is not often the technology that fails, usually it is the People who design it or the knowledge incorrect requirements.
Lets get real and stop taking pot shots.