In July, I wrote about Secretary of Veterans AffairsEric K. Shinseki taking the unheard of decision to temporarily halt 45 information technology projects which are either behind schedule or over budget. These projects, Shinseki said, would be reviewed, and he and the VA's CIO Roger Baker would then determine whether individual IT projects should be continued or scrapped.

Government Computing News (GCN) reports this week that 15 of the 45 IT projects are going to be stopped or have their funding cut. Another 17 have committed to meeting milestones to deliver new functionality to customers, while the final 13 have been re-planned or restarted.

GCN quotes W. Scott Gould, Deputy Secretary of the VA., as warning the 17 projects that,

 "... basically you've got 60 days. You tell us what that new schedule is and if you don't make it we're going to shut you down,... Many projects, frankly, are challenged by the inability to meet basic cost and schedule performance measures."

Gould made the remarks at the Executive Leadership Conference in Williamsburg, VA sponsored by the American Council for Technology and the Industry Advisory Council.


It is about time an organization held IT projects - government and contractor-led - accountable for their promises.

Secretary Shinseki, Deputy Secretary Gould and CIO Baker deserve praise for courage under what has been no doubt some political fire. I am quite certain that all three have been fielding phone calls from disgruntled US Congressman and Senators demanding to know why their constituent's IT project was canceled.

Let's hope their idea spreads across government, as well as into the commercial sector where too many projects are also abject blunders.

The Conversation (0)

Why Functional Programming Should Be the Future of Software Development

It’s hard to learn, but your code will produce fewer nasty surprises

11 min read
A plate of spaghetti made from code
Shira Inbar

You’d expectthe longest and most costly phase in the lifecycle of a software product to be the initial development of the system, when all those great features are first imagined and then created. In fact, the hardest part comes later, during the maintenance phase. That’s when programmers pay the price for the shortcuts they took during development.

So why did they take shortcuts? Maybe they didn’t realize that they were cutting any corners. Only when their code was deployed and exercised by a lot of users did its hidden flaws come to light. And maybe the developers were rushed. Time-to-market pressures would almost guarantee that their software will contain more bugs than it would otherwise.

Keep Reading ↓Show less