[sudont]

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/

[filearts]

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.

[joncrocks]

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.