Slashdot Mirror
Struggling With Major IT Projects
Ant writes "This article discusses the poor track record of IT projects undertaken by the U.S. government, and says experts blame poor planning, rapid industry advances and the massive scope of some complex projects whose price tags can run into billions of dollars at U.S. agencies with tens of thousands of employees. 'There are very few success stories,' said Paul Brubaker, former deputy chief information officer (CIO) at the Pentagon. 'Failures are very common, and they've been common for a long time.'... Seen on Blue's News."
The basic idea of an "IT project" is to implement something that has never been implemented before, or to replace something wholesale.
This flies in the face of every software engineering textbook. Software, like flora, grows in its environment. Trying to introduce something brand new into an ecosystem is asking for widescale decimation of existing services as well as the increased likelihood of the introduced-species death.
So the key to getting working "IT projects" to succeed is to build on past successes. It's never the "Start from nothing, plan, implement" projects that do well. These typically go way over budget and way past the deadlines. It is the little "I need a little tool" projects that start off small and then are brought together or have extra features added to them that succeed.
Look at your bank's ATM system. When those machines first arrived, they didn't do half of what they can do now. It was through a gradual building upon what works and weeding out what doesn't that allows us the ease of personal banking today. Same with any system, even Linux. Linux started out as a small project to implement a Unix-like kernel. Now it is a huge business and the project itself is much larger in scope than the original idea of Torvald's.
Improvement, not creation, is the key to successful projects.
When a deputy CIO of the Dept. of Labor and than Homeland Security Department has bogus degrees and has never been officially questioned about her educational experience (or lack thereof) for years, its not hard to see how gov't IT could be atrociously run.
From other articles about her, she was notorious in promoting her cronies, many of whom were also incompetent while passing over for promotion and bonuses those who knew what they were doing. Apparently Laura Callahan had a reputation for going ballistic when the occasional techie caught on to her and questioned some of her decisions. In hindsight, its rather obvious why she was so insecure.
I thoroughly agree. I'm a project manager that used to be a tech. I become a pm because I'd worked under too many of them that had *no* idea.
:) These lessons came to me through the development of a fair amount of scar tissue. These days I never employ a project manager that doesn't burst into tears when asked about their worst project.
Projects are all about scope. Defining what it is that you're doing. Everone thinks that's bleedingly obvious... and they're right. But it ain't easy to do.
Once you're got the scope, the rest should be easy. But isn't. Another classic big project blunder is the lack of realistic funding and schedule. Nobody want's to say it's going to take megabucks and go for years.
So instead you end up with "it won't cost much or take very long". Guess what... budgets and schedules "blow out"! More likely they take as much and as long as someone who understood the aforementioned scope would have said in the first place.
Even when the basics are followed things go wrong. This is the final in the classic series of blunders. If something is starting to look bad - don't tell the project sponsor... we'll be right... maybe.
Big no no! Tell the project sponsor *now*! What's wrong, why it went wrong and how you intend to fix it!! You'll get more respect and less stress. Both of which make it more likely you'll get it sorted.
Ahhhh. I feel better now
Forget the truth. Science is fact.