In my experience, government IT projects often don't come in on time/under budget, for several reasons. 1) Requirements creep, often triggered by political considerations (and often from the same sources as later outrage about increasing costs); 2) lack of coherent oversight by the client (instead of having a small review committee with both technical and other members, approvals are often distributed among a large, diffuse, and ever-changing group of individuals); 3) significant amounts of out-of-band communication between contractor and client, often necessitated by the first two factors, and resulting in a loss of institutional memory (`where did that requirement come from'); 4) poor life-cycle models, veering towards waterfalls, and away from iterative/agile practices (and I am not carrying the agile banner here, just pointing out that waterfall development often produces gargantuan monsters that don't satisfy client needs); 5) lack of end-user involvement (e.g., a senior program manager who thinks he can speak for clerical users of the system); 6) lack of clearly identifiable milestones that relate to the actual project (e.g., `the Frobozz infrastructure is complete', rather than `the system can correctly perform transactions X, Y, and Z'); 7) emphasis on delivering milestone products, rather than ensuring the products meet specified reliability and performance requirements; and 8) lack of proper audit procedures (e.g., looking at numbers of closed and unclosed bugs in the bug database). I could go on and on.
Of course, many private-sector projects go south in exactly the same ways. But government IT projects seem particularly susceptable to these dangers. As someone who has taught software engineering practices to industrial practitioners, it disturbs me greatly how easy it is for large organizations to ignore their own history, and make the same mistakes over and over again.
Biting the hand that feeds IT
