Defensive denial

… often follows what Freud called “kettle logic“.

“The problem doesn’t exist, and anyway it isn’t a problem for us, and anyway we’re already dealing with it.”

Imagine we ask a manager whether her organization experiences any of the Symptoms of Organizational Stupidity. Suppose she denies it, or says it doesn’t matter. Guess what – defensive denial is one of the symptoms on the list.

In 2008, Blockbuster CEO Jim Keyes expressed some bewilderment at his competitor’s success.

“I’ve been frankly confused by this fascination that everybody has with Netflix. … Netflix doesn’t really have or do anything that we can’t or don’t already do ourselves.” 

Denial is a key phase in the hype curve for new ideas (especially but not exclusively technological ones). A concept is rejected as meaningless, dangerous and/or unnecessary, while simultaneously being bundled together with earlier concepts.

“That concept doesn’t make sense, and even if it did it wouldn’t be technologically feasible, and anyway we already have a perfectly good word for it and lots of people are already doing it so we don’t need a new word.”


Brian Klapper, When Corporations Cannot Adapt (aka Fear the Kid in the Black t-shirt) (January 2013)

Related Posts: The Dynamics of Hype (Feb 2013)

Categories Uncategorized

Towards an Open Architecture for the Public Sector

#diggovreview #publicsectorIT .

Attended an interesting workshop last week to discuss some of the architectural aspects of Digital Government, hosted by Skyscape. One purpose of this discussion was to feed into the Labour Party Digital Government Review, and possibly into the Labour manifesto for the next election. Under modified Chatham House rules, I believe I am permitted to blog about the workshop as long as I don’t attribute anything to anybody or any organization.

There are several architectural themes that are probably shared between the political parties, although there may be some differences of emphasis and interpretation. For example, everyone seems to pay lip service to the idea of opening up public sector IT, and reducing the power of the incompetent and self-interested, whoever these may be. But there will undoubtedly be different views on the right tactics for redistributing commercial and bureaucratic power.

Openness leads to fashionable ideas about IT acquisition – a preference for consuming rather than self-build, and a preference for agile development rather than waterfall. These are great ideas when used properly, but we must be careful not to encourage the illusion that these ideas provide a magic solution to the troubles of public sector IT. Indeed, some recent IT disasters have been attributed to an ill-considered rush to “Agile”. And the Buy-Not-Build agenda must be governed properly, to avoid ceding too much architectural control to the large platform providers.

Openness also means structural change. For example, a shift from vertical integration and vertical silos to lateral modularity and co-creation, which my friend and associate Philip Boxer calls Collaborative Composition. This connects with the notions of Shared Services and Platform.

Finally, there is the question of the tempo of change. Government policies have a fairly rapid cycle time – in some cases around 18-24 months depending on department – but we cannot afford to reengineer systems and services, let alone platforms, at this sort of frequency.

So there was considerable discussion about the role of Government in providing a platform, and whether the platform should be a Minimum Viable Platform (similar to the Internet) or provide added value. There was also some debate as to whether politicians could be persuaded to support systems and platforms that would last longer than the policies that they were intended to implement.

The Public Sector suffers, perhaps even more than other organizations, from a confusion between Requirement and Solution. So people like to talk about Open Standards or Agile as the solution to high IT costs, or advocate Big Central Database as the perfect solution to any information needs, instead of talking about the requirements, such as interoperability and low switching costs. I hope that the Labour Party (or any other party for that matter) can be encouraged to express its policies in terms of the requirements and governance approach, rather than mandating specific technological solutions.

As I’ve pointed out before, the term “Joined-Up Government” has several different interpretations. From an Inside-Out (supply-side) perspective, it is commonly taken to imply improved integration between separate government departments and agencies – in other words, some kind of reorganization, not merely of IT systems and services but also the agencies responsible for these services. Of course, reorganization might sometimes be needed, but this is merely one possible solution to the real requirement, which in my opinion comes from the Outside-In (demand-side) perspective – the citizen’s need for a coherent experience of government services.

For example, the much-discussed integration between Healthcare and Social Care doesn’t entail merging two massive and inefficient silos into one even more massive and inefficient silo, but could be achieved simply by opening up the silos and improving the flows of information between them. The Outside-In perspective merely calls for the citizen to get a coherent joined-up service across both healthcare and social care, however this may be done.

And consider the much maligned Contact Point, which had somehow morphed from an information sharing platform (“System of Engagement”) to a Big Central Database (“System of Record”), largely under the control of people who didn’t appreciate that these weren’t necessarily the same thing.

Effective multi-agency working depends on effective information sharing, but this doesn’t mean putting all the data into a single source of truth. Many of the breakthroughs of Digital Government have come, not from building massive central databases, but from improving collaboration between different agencies – health, social care, police, justice, etc – often dealing with the same problem families from different professional perspectives. As we say at Glue Reply, it’s about the conversation.


Some of us have been talking about these themes for a long time. In my own small way, I have written a number of articles and blogposts about eGovernment and Joined-Up Government, and I submitted something on Shared Services to the Cabinet Office in January 2006, most of which is probably still valid. See previous posts on this blog – eGovernment, Joined-Up, Shared Services.

Philip Boxer, Creating Value in Ecosystems (December 2010)

Jerry Fishenden and Mark Thompson, Digital Government, Open Architecture, and Innovation: Why Public Sector IT Will Never Be the Same Again (Journal of Public Administration Research and Theory September 2012)

Mike Martin, Open Architecture Critique – A Draft (March 2014)

David Sprott and Richard Veryard, Shared Services for the UK Public Sector (Submission to the Cabinet Office, CBDI Forum January 2006)

Richard Veryard, Joined-Up Services (Review of the Public Management and Policy Association. February 2002)

Richard Veryard and Philip Boxer, Public Sector IT – The CSA Case (December 2004)


See also David Sprott’s response to this post. Open Architecture for the Public Sector (May 2014)

Towards an Open Architecture for the Public Sector

#diggovreview #publicsectorIT .

Attended an interesting workshop last week to discuss some of the architectural aspects of Digital Government, hosted by Skyscape. One purpose of this discussion was to feed into the Labour Party Digital Government Review, and possibly into the Labour manifesto for the next election. Under modified Chatham House rules, I believe I am permitted to blog about the workshop as long as I don’t attribute anything to anybody or any organization.

There are several architectural themes that are probably shared between the political parties, although there may be some differences of emphasis and interpretation. For example, everyone seems to pay lip service to the idea of opening up public sector IT, and reducing the power of the incompetent and self-interested, whoever these may be. But there will undoubtedly be different views on the right tactics for redistributing commercial and bureaucratic power.

Openness leads to fashionable ideas about IT acquisition – a preference for consuming rather than self-build, and a preference for agile development rather than waterfall. These are great ideas when used properly, but we must be careful not to encourage the illusion that these ideas provide a magic solution to the troubles of public sector IT. Indeed, some recent IT disasters have been attributed to an ill-considered rush to “Agile”. And the Buy-Not-Build agenda must be governed properly, to avoid ceding too much architectural control to the large platform providers.

Openness also means structural change. For example, a shift from vertical integration and vertical silos to lateral modularity and co-creation, which my friend and associate Philip Boxer calls Collaborative Composition. This connects with the notions of Shared Services and Platform.

Finally, there is the question of the tempo of change. Government policies have a fairly rapid cycle time – in some cases around 18-24 months depending on department – but we cannot afford to reengineer systems and services, let alone platforms, at this sort of frequency.

So there was considerable discussion about the role of Government in providing a platform, and whether the platform should be a Minimum Viable Platform (similar to the Internet) or provide added value. There was also some debate as to whether politicians could be persuaded to support systems and platforms that would last longer than the policies that they were intended to implement.

The Public Sector suffers, perhaps even more than other organizations, from a confusion between Requirement and Solution. So people like to talk about Open Standards or Agile as the solution to high IT costs, or advocate Big Central Database as the perfect solution to any information needs, instead of talking about the requirements, such as interoperability and low switching costs. I hope that the Labour Party (or any other party for that matter) can be encouraged to express its policies in terms of the requirements and governance approach, rather than mandating specific technological solutions.

As I’ve pointed out before, the term “Joined-Up Government” has several different interpretations. From an Inside-Out (supply-side) perspective, it is commonly taken to imply improved integration between separate government departments and agencies – in other words, some kind of reorganization, not merely of IT systems and services but also the agencies responsible for these services. Of course, reorganization might sometimes be needed, but this is merely one possible solution to the real requirement, which in my opinion comes from the Outside-In (demand-side) perspective – the citizen’s need for a coherent experience of government services.

For example, the much-discussed integration between Healthcare and Social Care doesn’t entail merging two massive and inefficient silos into one even more massive and inefficient silo, but could be achieved simply by opening up the silos and improving the flows of information between them. The Outside-In perspective merely calls for the citizen to get a coherent joined-up service across both healthcare and social care, however this may be done.

And consider the much maligned Contact Point, which had somehow morphed from an information sharing platform (“System of Engagement”) to a Big Central Database (“System of Record”), largely under the control of people who didn’t appreciate that these weren’t necessarily the same thing.

Effective multi-agency working depends on effective information sharing, but this doesn’t mean putting all the data into a single source of truth. Many of the breakthroughs of Digital Government have come, not from building massive central databases, but from improving collaboration between different agencies – health, social care, police, justice, etc – often dealing with the same problem families from different professional perspectives. As we say at Glue Reply, it’s about the conversation.


Some of us have been talking about these themes for a long time. In my own small way, I have written a number of articles and blogposts about eGovernment and Joined-Up Government, and I submitted something on Shared Services to the Cabinet Office in January 2006, most of which is probably still valid. See previous posts on this blog – eGovernment, Joined-Up, Shared Services.

Philip Boxer, Creating Value in Ecosystems (December 2010)

Jerry Fishenden and Mark Thompson, Digital Government, Open Architecture, and Innovation: Why Public Sector IT Will Never Be the Same Again (Journal of Public Administration Research and Theory September 2012)

Mike Martin, Open Architecture Critique – A Draft (March 2014)

David Sprott and Richard Veryard, Shared Services for the UK Public Sector (Submission to the Cabinet Office, CBDI Forum January 2006)

Richard Veryard, Joined-Up Services (Review of the Public Management and Policy Association. February 2002)

Richard Veryard and Philip Boxer, Public Sector IT – The CSA Case (December 2004)


See also David Sprott’s response to this post. Open Architecture for the Public Sector (May 2014)

National Decision Model

@antlerboy asks does anyone know theoretical underpinning of the (rather good) police decision-making model?

The National Decision Model (NDM) is a risk assessment framework, or decision making process, that is used by police forces across the UK. It replaces the former Conflict Management Model. Some sources refer to it as the National Decision-Making Model.

Looking around the Internet, I have found two kinds of description of the model – top-down and bottom-up.

The top-down (abstract) description was published by the Association of Chief Police Officers (ACPO) sometime in 2012, and has been replicated in various items of police training material including a page on the College of Policing website. It is fairly abstract, and provides five different stages that officers can follow when making any type of decision – not just conflict management.

Some early responses from the police force regarded the NDM as an ideal model, only weakly connected to the practical reality of decision-making on the ground. See for example The NDM and decision making – what’s the reality? (Inspector Juliet Bravo, April 2012).

In contrast, the bottom-up (context-specific) description emerges when serving police officers discuss using the NDM. According to Mr Google, this discussion tends to focus on one decision in particular – to Taser or not to Taser.

“For me the Taser is a very important link in the National Decision Making Model . It bridges that gap between the baton and the normal firearm that has an almost certain risk of death when used.” (The Peel Blog, July 2012). See also Use of Force – Decision Making (Police Geek, July 2012).

ACPO itself adopts this context-specific perspective in its Questions and Answers on Taser (February 2012, updated July 2013), where it is stated that Taser may be deployed and used as one of a number of tactical options only after application of the National Decision Model (NDM).

Of course, the fact that Taser-related decisions have a high Google ranking doesn’t imply that these decisions represent the most active use of the National Decision Model. The most we can infer from this is that these are the decisions that police and others are most interested in discussing.

(Argyris and Schön introduced the distinction between Espoused Theory and Theory-In-Use. Perhaps we need a third category to refer to what people imagine to be the central or canonical examples of the theory. We might call it Theory-in-View or Theory-in-Gaze.)

In a conflict situation, a police officer often has to decide how much force to use. The officer needs to have a range of tools at his disposal and the ability to select the appropriate tool – in policing, this is known as a use-of-force continuum. More generally, it is an application of the principle of Requisite Variety.

In a particular conflict situation, the police can only use the tools they have at their disposal. The decision to use a Taser can only be taken if the police have the Taser and the training to use it properly. In which case the operational decision must follow the NDM.

More strategic decisions operate on a longer timescale – whether to equip police with certain equipment and training, what rules of engagement to apply, and so on. A truly abstract decision-making model would provide guidance for these strategic decisions as well as the operational decisions.

And that’s exactly what the top-down description of NDM asserts. “It can be applied to spontaneous incidents or planned operations by an individual or team of people, and to both operational and non-operational situations.”

Senior police officers have described the use of the NDM for non-conflict situations. For example, Adrian Lee (Chief Constable of Northants) gave a presentation on the Implications of NDM for Roads Policing (January 2012).

The NDM has also been adapted for use in other organizations. For example, Paul Macfarlane (ex Strathclyde Police) has used the NDM to produced a model aimed at Business Continuity and Risk Management. which he calls Defensive Decision-Making.


How does the NDM relate to other decision-making models? According to Adrian Lee’s presentation, the NDM is based on three earlier models:

  • The Conflict Management Model (CMM). For a discussion from 2011, see Police Oracle.
  • The SARA model (Scan, Analyze, Respond, Assess) – which appears to be similar to the OODA loop.
  • Something called the PLANE model. (I tried Googling this, and I just got lots of Lego kits. If anyone has a link, please send.)

There is considerable discussion in the USA about the relevance of the OODA loop to policing, and this again focuses on conflict management situations (the “Active Shooter”). There are two important differences between combat (the canonical use of OODA) and conflict management. Firstly, the preferred outcome is not to kill the offender but to disarm him (either physically or psychologically). This means that you sometimes need to give the offender time to calm down, orienting himself into making the right decision. So it’s not just about having a faster OODA loop than the other guy (although clearly some American cops think this is important). And secondly, there is a lot of talk about situation awareness and anticipation. For example, Dr. Mike Asken, who is a State Police psychologist, has developed a model called AAADA (Anticipating, Alerting, Assessing, Deciding and Acting). There is also a Cognitive OODA model I need to look into.

However, I interpret @antlerboy’s request for theoretical underpinning as not just a historical question (what theories of decision-making were the creators of NDM consciously following) but a methodological question (what theories of decision-making would be relevant to NDM and any other decision models). But this post is already long enough, and the sun is shining outside, so I shall return to this topic another day.


Sources

Michael J. Asken, From OODA to AAADA ― A cycle for surviving violent police encounters (Dec 2010)

Adrian Lee, Implications of NDM for Roads Policing (January 2012).

Erik P. Blasch et al, User Information Fusion Decision-Making Analysis with the C-OODA Model (Jan 2011)

National Decision Model (ACPO, 2012?)

National Decision Model (College of Policing, 2013)

SARA model (Center for Problem-Oriented Policing)

Updated 19 May 2014

National Decision Model

@antlerboy asks does anyone know theoretical underpinning of the (rather good) police decision-making model?

The National Decision Model (NDM) is a risk assessment framework, or decision making process, that is used by police forces across the UK. It replaces the former Conflict Management Model. Some sources refer to it as the National Decision-Making Model.

Looking around the Internet, I have found two kinds of description of the model – top-down and bottom-up.

The top-down (abstract) description was published by the Association of Chief Police Officers (ACPO) sometime in 2012, and has been replicated in various items of police training material including a page on the College of Policing website. It is fairly abstract, and provides five different stages that officers can follow when making any type of decision – not just conflict management.

Some early responses from the police force regarded the NDM as an ideal model, only weakly connected to the practical reality of decision-making on the ground. See for example The NDM and decision making – what’s the reality? (Inspector Juliet Bravo, April 2012).

In contrast, the bottom-up (context-specific) description emerges when serving police officers discuss using the NDM. According to Mr Google, this discussion tends to focus on one decision in particular – to Taser or not to Taser.

“For me the Taser is a very important link in the National Decision Making Model . It bridges that gap between the baton and the normal firearm that has an almost certain risk of death when used.” (The Peel Blog, July 2012). See also Use of Force – Decision Making (Police Geek, July 2012).

ACPO itself adopts this context-specific perspective in its Questions and Answers on Taser (February 2012, updated July 2013), where it is stated that Taser may be deployed and used as one of a number of tactical options only after application of the National Decision Model (NDM).

Of course, the fact that Taser-related decisions have a high Google ranking doesn’t imply that these decisions represent the most active use of the National Decision Model. The most we can infer from this is that these are the decisions that police and others are most interested in discussing.

(Argyris and Schön introduced the distinction between Espoused Theory and Theory-In-Use. Perhaps we need a third category to refer to what people imagine to be the central or canonical examples of the theory. We might call it Theory-in-View or Theory-in-Gaze.)

In a conflict situation, a police officer often has to decide how much force to use. The officer needs to have a range of tools at his disposal and the ability to select the appropriate tool – in policing, this is known as a use-of-force continuum. More generally, it is an application of the principle of Requisite Variety.

In a particular conflict situation, the police can only use the tools they have at their disposal. The decision to use a Taser can only be taken if the police have the Taser and the training to use it properly. In which case the operational decision must follow the NDM.

More strategic decisions operate on a longer timescale – whether to equip police with certain equipment and training, what rules of engagement to apply, and so on. A truly abstract decision-making model would provide guidance for these strategic decisions as well as the operational decisions.

And that’s exactly what the top-down description of NDM asserts. “It can be applied to spontaneous incidents or planned operations by an individual or team of people, and to both operational and non-operational situations.”

Senior police officers have described the use of the NDM for non-conflict situations. For example, Adrian Lee (Chief Constable of Northants) gave a presentation on the Implications of NDM for Roads Policing (January 2012).

The NDM has also been adapted for use in other organizations. For example, Paul Macfarlane (ex Strathclyde Police) has used the NDM to produced a model aimed at Business Continuity and Risk Management. which he calls Defensive Decision-Making.


How does the NDM relate to other decision-making models? According to Adrian Lee’s presentation, the NDM is based on three earlier models:

  • The Conflict Management Model (CMM). For a discussion from 2011, see Police Oracle.
  • The SARA model (Scan, Analyze, Respond, Assess) – which appears to be similar to the OODA loop.
  • Something called the PLANE model. (I tried Googling this, and I just got lots of Lego kits. If anyone has a link, please send.)

There is considerable discussion in the USA about the relevance of the OODA loop to policing, and this again focuses on conflict management situations (the “Active Shooter”). There are two important differences between combat (the canonical use of OODA) and conflict management. Firstly, the preferred outcome is not to kill the offender but to disarm him (either physically or psychologically). This means that you sometimes need to give the offender time to calm down, orienting himself into making the right decision.

And the cop needs to stay calm. George “Doc” Thompson, who taught US police a de-escalation technique known as Verbal Judo, once said “We know that the most deadly weapon we carry is not the .45 or the 9mm, it is in fact the cop’s tongue … A single sentence fired off at the wrong person at the wrong time can get you fired, it can get you sued, it can get you killed.”

So it’s not just about having a faster OODA loop than the other guy (although clearly some American cops think this is important). And secondly, there is a lot of talk about situation awareness and anticipation. For example, Dr. Mike Asken, who is a State Police psychologist, has developed a model called AAADA (Anticipating, Alerting, Assessing, Deciding and Acting). There is also a Cognitive OODA model I need to look into.

However, I interpret @antlerboy’s request for theoretical underpinning as not just a historical question (what theories of decision-making were the creators of NDM consciously following) but a methodological question (what theories of decision-making would be relevant to NDM and any other decision models). But this post is already long enough, and the sun is shining outside, so I shall return to this topic another day.


Sources

Michael J. Asken, From OODA to AAADA ― A cycle for surviving violent police encounters (Dec 2010)

Erik P. Blasch et al, User Information Fusion Decision-Making Analysis with the C-OODA Model (Jan 2011)

Tom Dart, ‘Verbal judo’: the police tactic that teaches cops to talk before they shoot (Guardian 21 July 2016)

Adrian Lee, Implications of NDM for Roads Policing (January 2012).

Steve Papenfuhs, The OODA loop, reaction time, and decision making (PoliceOne, 23 February 2012)

National Decision Model (ACPO, 2012?)

National Decision Model (College of Policing, 2013)

SARA model (Center for Problem-Oriented Policing)

Related Posts
National Decision Model and Lessons Learned (Feb 2017)

Updated 28 February 2017

On the true nature of knowledge

@pickover suggests that these two books, in theory, contain the sum total of all human knowledge. “The Joy of Logic”, he remarks (via @DavidFCox).Why is this wrong? Because knowledge doesn’t follow the laws of elementary arithmetic. Adding two lots of …

The Enterprise Architect of Hamelyn

Stakeholder Concern Enterprise Focus Project Focus
The city of Hamelyn is plagued with rats. This indicates a serious problem with the “Public Health and Hygiene” capability. We just need a quick project to eliminate the rats. So we buy some “Eliminate Creature” capability from an external vendor.
The Pied Piper gets rid of the rats. Real business problem has not been addressed. Let’s now push on with the next phase of solving the problem. Project successful.

The Pied Piper is too expensive. We need a careful transition plan while we build an in-house capability. Let us immediately renegotiate our contract with the vendor.
The Pied Piper gets rid of the children. It turns out that the Pied Piper can reuse his “Eliminate Creature” capability for other purposes. !*!?**!
Which Role? Enterprise Architect?
Strategic Procurement?
Solution Architect?
Tactical Procurement?

See also my article “Requirements Engineering as if Stakeholders Mattered” (Requirenautics Quarterly, Issue 29, August 2003, pdf)

The Enterprise Architect of Hamelyn

Stakeholder Concern Enterprise Focus Project Focus
The city of Hamelyn is plagued with rats. This indicates a serious problem with the “Public Health and Hygiene” capability. We just need a quick project to eliminate the rats. So we buy some “Eliminate Creature” capability from an external vendor.
The Pied Piper gets rid of the rats. Real business problem has not been addressed. Let’s now push on with the next phase of solving the problem. Project successful.

The Pied Piper is too expensive. We need a careful transition plan while we build an in-house capability. Let us immediately renegotiate our contract with the vendor.
The Pied Piper gets rid of the children. It turns out that the Pied Piper can reuse his “Eliminate Creature” capability for other purposes. !*!?**!
Which Role? Enterprise Architect?
Strategic Procurement?
Solution Architect?
Tactical Procurement?

See also my article “Requirements Engineering as if Stakeholders Mattered” (Requirenautics Quarterly, Issue 29, August 2003, pdf)

What’s Wrong with Universal Credit? On The Rooting of the Particular in the Universal

According to Hegel, the administration of a corporation’s affairs by its own supervisors will often be inept, “for although they know and have before them their own distinct interests and affairs, they have a less complete grasp of the connection between these and more remote conditions and universal points of view”. (GWF Hegel, Elements of the Philosophy of Right, 1820)

Therefore, one of the challenges for enterprise architecture is to maintain a pragmatic balance between the particular and the universal, especially when many of the decision-makers (as Hegel observed) tend to see things from a narrow short-term perspective.

So at first sight, we might think that the UK Government initiative known as Universal Credit represents a welcome exception to this narrow short-term thinking. What a brilliant idea to consolidate all benefit systems into a single simpler system!

The devil, of course, is in the detail. Mark Ballard explains:

Universal Credit would not only re-engineer the complex administration of £70bn social security payments to 8m households, merging six benefits systems across two government departments and local authorities throughout the country. It would also rely on councils up and down the country making their own systems and processes compatible. It would depend upon HM Revenue & Customs completing its own income tax system reforms of unprecedented ambition, Real-Time Information. And HMRC would in turn depend on employers, banks and payroll software suppliers reforming their computer systems and processes as well. Universal Credit would have to navigate this exponentially explosive collection of risk factors. This was a spaghetti junction of high-stakes computer gambits from which Universal Credit would have to pull a benefits payment that was reliable and secure. (Mark Ballard, Universal Credit failures put coalition ICT strategy in purdah. Computer Weekly September 2013)

What went wrong? Agile Development? Procurement? Interdepartmental warfare? Bureaucracy?

“There was an extremely strong command and control culture at the DWP, which goes against agile. We were trying to alleviate that – but it wasn’t working,” said a source. “The fundamental problem was procurement,” said an anonymous participant. “Our hands were tied because of procurement. If you don’t set up the contract properly, you are on a hiding to nothing.” (Mark Ballard, Why agile development failed for Universal Credit, Computer Weekly July 2013)

Iain Duncan Smith is stuck between using traditional waterfall and systems integration, advocated by DWP, and “agile hacking”, advocated by GDS.  (Bryan Glick, The question that matters on Universal Credit: Do you believe Iain Duncan Smith? Computer Weekly Feb 2014, comment by John Alexander)

Any system which is designed to operate with a smaller bureaucracy will be opposed tooth and nail by the bureaucrats mandated to implement it. (Benedict Brogan, Whitehall is shuddering over Universal Credit problems Telegraph February 2014, comment by Littlegrayman)

And was it just poor execution, or was the vision faulty? Paul Spicker thinks the whole project was doomed.

It is easy to blame the IT when things go wrong, but when people are asked to do impossible things, it should not be surprising if they do not deliver. … The most basic flaw rests in the idea that we can “personalise” benefits for millions of people. There are just too many moving parts; and in a system with millions of iterations, anything that can go wrong will go wrong. (Paul Spicker, Universal Credit: Don’t blame the IT Computer Weekly Feb 2014)

(I want to make two observations here. Firstly, requirements are not additive. Even if each requirement makes sense on its own, that doesn’t mean that the whole set of requirements makes sense. And secondly, requirements that make sense in some contexts don’t make sense in other contexts. For example, retail may be able to achieve a good level of personalization, because it doesn’t matter much if a customer sometimes gets the “wrong” promotional voucher. But it matters a lot if people get the “wrong” benefits, so the stakes are much higher.)

And even the Spectator (a right-wing weekly magazine) complains about ministerial incompetence and inflexibility.

The Universal Credit fiasco exemplifies Duncan Smith’s narcissistic failure to admit and remedy mistakes. As Computer Weekly — a far better guardian of the taxpayer than the Conservative backbenches or press, incidentally – has said, Duncan Smith proceeded with a vast and complicated IT project without learning the lessons from the IT disasters of the Labour years. (Nick Cohen, The conservative case against Iain Duncan Smith, Spectator June 2014)

John Naughton compares Universal Credit with Obamacare, and detects the same problem with both.

How is it that governments stuffed with able and conscientious civil servants screw up so spectacularly whenever IT is involved? … The strange thing about this is that you wouldn’t need to have been a geek to spot the problem with healthcare.gov. You just had to think architecturally about it. Yet apparently nobody in the administration did. The same applies to the post-9/11 decision to link all the previously separate US security databases into one giant file to which at least 250,000 people had access, one of whom happened to be Bradley (now Chelsea) Manning. (John Naughton, Obamacare, universal credit… why do governments make such a mess of IT? Observer December 2013)

You don’t have to be a geek. You just have to think architecturally. And thinking architecturally means – among other things – anticipating and resolving the kind of problems faced by projects like these.

Standing up for the universal point of view doesn’t justify a Stalinist approach to smoothing out the unavoidable complexities of dealing with real individuals and their messy lives. Is this a failure for IT, or a failure for bureaucracy? And can we tell the difference?

Updated 3 July 2014