Management. Business Analysts. "Metawork" in the words of a coworker who used to architect BPM implementations at the parent corporation of my job. Getting consensus from possibly hundreds of stakeholders.

Generally, the disconnect is that management is under the assumption that you can manage your way to success, so they add more overhead to watch and prod at the proceedings. Development is almost always an afterthought in most business projects. The first thing they do? Get consensus, which is generally everyone putting in ideas so that they seem involved—see Atwood's Duck[1]. After you have a ton of often contradictory ideas, you need to have them prioritized. And since nobody managing the project is technical, they need to hold countless "prioritization meetings with stakeholders and implementers." Often times the meetings will grind to a standstill while process analysts and engineers argue over the wording of things. Usually the analyst will tell the engineer that the business has standardized on a set of terms, of which are not the trade names for things. Maybe everyone uses a set of terms which aren't the "correct" wording.

After things are prioritized based on the wrong criteria, they're then pushed off to an engineering group who are tasked with implementing things exactly to spec. Since the definitions are incorrect, they need to constantly circle back and check with the stakeholders to double check. Occasionally checking in will involve a "subject matter expert" who is on vacation, and the only one allowed to answer the question. (Thus stalling that item and anything depending on it.) Others will often say "it's above my paygrade" in an attempt to avoid culpability.

After the project has run long and only has a majority of the features complete, people are reassigned to other projects, and the app is sent to QA to hand-test features. Sometimes it will involve the "stakeholders" sitting in a room for days or weeks, manually clicking their way through the interface. Maybe the project is declared a boondoggle, deleted, and replaced with someone else's pet project.

So yes, not logical.

1: http://blog.codinghorror.com/new-programming-jargon/

It is a bit scary that an accurate description of reality could easily have been sourced from Dilbert.

The tough reality is that certain projects have a scope such that a small team could never reasonably be expected to capture the requirements of the project. Also, remember that large enterprise projects are generally built by people who are not users themselves. This is where the technology crowd often draws false conclusions, reflecting on projects of their own, where they have intimate knowledge of the problem space. There are likely very few forward-thinking engineers who also have visibility into the intricacies of the various SS systems. This is where the layers get piled on and the efficiency vanishes.

This is true. And it doesn't just apply to governments, but any organisation that is large.

Once a organisation gets to a sufficient size, organising and allocating resources and communication starts to eat up a disproportionate amount of time, if the organisation is left to drift into whatever shape it likes.

I can recommend the book "Plundering the Public Sector" by David Craig that explains how projects like the NHS IT fiasco happened:

http://www.amazon.co.uk/Plundering-Public-Sector-Letting-Con...

[NB Note recommended for UK taxpayers who have high blood pressure and/or easily upset]

"I can't even see how it can be manpower"

From personal experience in software development, dilution of responsibility can be incredibly expensive.

Scenario 1: I wonder about a minor detail, call up a random user, we hash it out in 5 minutes. Cost is about 10 minutes of total labor, figure maybe $10

Scenario 2: I have to organize a meeting with the exec stakeholder, the dept manager, and the entire dept staff. Which due to scheduling conflicts is in two weeks. Finally the meeting arrives and due to bike shedding we spend 2 hours talking about everything other than the topic until its hashed out. So the cost is two weeks of my salary doing nothing but surfing HN, lets say $3K, plus 2 hrs of mgmt for exec at $100/hr and the manager at $75 thats $350, plus double that time for them to make the "command decision" and later inform me, so thats $700 of management, plus the ten person working team has to burn an extra 2 hrs of overtime each at lets say $25/hr and 10 people that's $750 so we'll call it $4450.

So figuring out the default value, if any, for a blank of a form can cost anywhere from ten bucks at a personally responsible organization up to about five grand at a fully diluted responsibility organization.

Its obviously orders of magnitude more if you involve consultants, people flying in from out of state, etc.

The hourly rates are kind of low across the board. May be doubling it or tripling it?

gov.uk which had a great success, was done by hiring their own people to work on it. I don't see why anyone would think outsourcing is good for public projects.

I worked on a high profile government project that had five different vendors involved. FIVE. The inter-organizational management problems were astonishing. I'm pretty sure that by the time I left, managers actually outnumbered technical staff.

The biggest problem, though, was the lack of pushback. The government officials would ask for the moon, and the vendors would promise to deliver it. There was almost no one saying NO - the word that project most desperately needed to hear. Features outweighed core infrastructure reliability, so configuration management was a nightmare.

Because ramping up a huge staff to build a new project generally requires keeping them forever. It's much easier to request a budget for a project then it is to try to expand headcount of well-protected government jobs.

It's very good for the companies that benefit from the outsourcing.