Why are governments so slow in taking up eGov?

I recently was asked this question in an exchange on an article I wrote on good public governance, a couple of years ago. The article underlying this question is behind this link, and was written by Bill Eggers of Deloitte.

Governments aren’t necessarily that slow in taking up eGov

My first off-the-cuff reaction was “but are they?” Because I’m not sure governments are really that slow in taking up eGov. Now, you need to take this for what it is worth, a view from one person who has been involved both as a consultant and as an auditor with the Belgian federal and Flemish governments in one way or another since 1997.

Deloitte’s arguments are not really public sector specific

If you have not read Eggers’ article, the crux of the argument he makes is that technology is easier to access now, the development life cycle of ICT implementations was not appropriate, the skills were not there and the delivery models were not adequately developed. I’m summarising, perhaps too much. The point is, I don’t agree. Some of the points Eggers makes are relevant, but he is not surprising me or kicking in doors that were not open to begin with. His arguments can as easily be applied to private sector as to public sector or government services.

He fails to highlight some of the most essential reasons why digital government/e-gov has not yet fully taken off to date, and is very likely to take off in the near future. Let me explain my main four main arguments.

My four main arguments

First, mosts government are and remain a social employer for quite a few people whose skillset could partially or even entirely be replaced by eGov solutions. Social employment is considered by many government officials and politicians to be a core responsibility of government. However, structural budget constraints are changing this attitude. But such attitude change takes time to have tangible effects. The natural reduction of such employees, mainly through retirement, is not at a point where an eGov replacement solution is completely realistic, yet. And if the work is being done now, many people don’t see the use of replacing people with systems at this point in time. This is one of the reasons that Eggers fails to mention in his article for the proliferation of web front-ends that have no back-end. The back-end are these people. Eventually, they will no longer be required to do this type of menial work.

Second, the article ignores the maturity and the cost of the necessary backbone systems. Because public key infrastructure used to be expensive. As in “really expensive”. And it's essential to ensure the security that these systems need. After all, we're talking about significant amounts of essential information and money being exchanged.
Belgium built one of the first integrated public key infrastructures in the late 1990’s to early 2000’s. Our electronic ID card and the integration with our social security systems remains one of the more advanced in the world and an example for many countries.
But the upkeep costs a lot. The cost of public key infrastructure is influenced by the need for data quality and the total cost of ownership of the central systems. The cost of ensuring and maintaining data quality is still very important and remains labor intensive, but technology allows citizens and legal entities to provide this information more freely and in an much easier way now than before. The solution for this is really starting to take shape only now. Technologies like block chain can make a real cost difference, because the need for an expensive central clearing house is at least reduced. The cost and time to build a similar backbone system now, using modern techniques, would be significantly lower, as would the total cost of ownership.

Third, and dependent on the second, the need to rethink services e-Services, while often the same for the end-user, will need to be administratively set-up completely differently than the current mainly labor-powered systems. This is beyond restructuring/reengineering, and requires a fundamental rethinking. Few consultants are both embedded enough to understand the specific needs of an administration, its support structure and the end-user on the one hand and independent enough to escape incremental thinking on the other.
However, such break-through thinking and the willingness to let go of existing service paradigms will be essential in the future. Now, it happens already. Look at the service-voucher system the Belgian federal, Flemish and Walloon governments have implemented. It is a subsidy based co-payment system that completely rethought the existing service paradigm and ended up bringing a lot of household service from the grey to the real economy. In the process, it automated and outsourced the back-end, which is not a core government competency. Does the government lose out? Not really: it still has access to all the information, but does not need to focus on the menial work of processing.

Fourth and last, questioning the essential tasks of government We often forget that most government services were built in a time where the market could not cost-effectively provide certain services, and those services then evolved into large administrations. Administrations that strive to keep themselves alive and growing. This is not just a conclusion in public sector. Read Clay Shirky on this topic if you need convincing that it plays in any large structure.
However, public sector has no real tradition of zero-based service assessment, where we first look at what is necessary, then at what the market can offer at correct rates and then have the government pick up the rest of the necessary services the market does not yet provide. This requires thinking and a certain freedom of thought and action that is not easily found.

In conclusion

Governments are not necessarily that slow in taking up eGov. However, governments are powered by lots of people that do work that computers can do. Budget pressures and a progressively older group of public servants lead to a gradual replacement of menial work by systems. But public sector systems have security requirements whose requirements are much more stringent than most commercial systems. The back bone required for providing that level of security cost a lot of money. New technologies, such as block chain, are likely to bring down that cost. Once those systems are available, creative groups of people, most appropriately combinations of consultants and public servants, need to fundamentally rethink services. This is already being done, but we can go beyond what exists now, and liberate the public sector from the requirement of doing menial work that can be automated. And last, but not least, the public sector needs to question its own role - especially at the task level - in light of the evolving capabilities of systems offered in the marketplace. Why should the public sector provide those services that can be provided by private sector at a correct price?

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. by Ben Broeckx

A better email tool

Whenever I write a letter, especially a draft letter, I usually write the text first. The reason is simple: texts tend to evolve, and may end up being about something completely different from what I set out to write about.

Paper is not forgiving, in that a mistake requires me to cross out or apply correcting fluid to the text. We believe our electronic tools are much more forgiving. But they are not.

Email applications are not fit for email

Case in point: email applications. The way in which they are set up invites mistakes or waste of time. Think about your favorite program. In all likelihood, it asks you for the email address of the intended recipient first, then for the subject, then for the actual text. However, that is not how you work. You know who you are writing to, but the subject line may well evolve throughout the actual writing of the text. And with the change in subject matter may well come the realization that other people need to be informed about the contents of your message.

However, few people take the time to revisit their subject lines or to reconsider whom they add to the already filled in recipient list.

There is one tool I have been using on iPad and Mac and that I miss on my iPhone: Ulysses. This markdown editor has a dazzling array of features, among which is a diverse set of export features. Any email I write starts right there, in that application, in markdown. First I write the text, then I write the tittle, which is the subject line, and only when I export as a mail, I add the subject line.

Mails have the time to develop and mature. I have no flashing send button imploring me to share whatever complete or incomplete considerations with the perhaps inappropriate but most certainly incomplete list of recipients.

So, Soulmen, kind purveyors of this app, when will you bring this tool to iPhone? And thanks for developing such a great tool.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. by Ben Broeckx

Why I use a static and a dynamic phase in a risk management approach?

This article is a rewrite of an article I originally wrote about six years ago on a now discontinued blog aptly titled “complexity risk management”. I am reviewing a paper on risk management and felt it relevant to update this post as an additional comment to one of my review points.

Whenever I speak about risk management, I insist on performing an initial static assessment of the situation in which you are implementing a risk approach, which I refer to as the static risk management phase, to be followed by recurring, significantly lighter phases which I call the dynamic risk management phases. People eventually ask the question on why I insist using both an initial static and the recurring dynamic phase. The simple answer is that there is no real fundamental difference between both phases.

But the actual, real in-depth answer is a bit more complicated than that. While there may not be significant differences in the steps to be executed in each of the phases, the context in which these steps are taken are significantly different. These contexts impact both the scope of the step and the duration and related investment in the step. Static steps are broad in scope, take a significant amount of time and therefore investment, whereas dynamic steps are narrower in scope and take significantly less time. This actually is the essence of the methodology. That is the theoretical explanation. Let me illustrate this with the example I’ve been using since 2002. 

You and a box on the North Pole

Imagine yourself suddenly transported to the coastal regions of the North Pole area and left there with a large box and assurances that most of what you need to survive is present in that box. What do you do? Well, after screaming for a bit, you will eventually settle down and …

Static phase

… you will scan your surroundings, making sure there are no immediate threats to your well being. So you go ahead and scan your environment in order to assess the situation and the event potential around you. Once you are fairly certain nothing can directly impact you, you will open the box.

On top of a lot of other tools you find a wonderful, white, warm jacket and a pair of polar pants. There is also a cute little red hat and a pair of sunglasses. You put on the pants, the jacket and the red hat (remember, it's freezing cold on the North Pole) and you put on the sunglasses and do another 360° observation scan. Once assured nothing threatens you, you examine the other contents of the box: you notice it's a very large box, with in it a big gun, labeled ‘point in the direction of polar bear and pull trigger to discharge, only when life is threatened’. Oh, and there is also a fold-up chair. The box contains some army meals which heat up when you pull a tab, and a large thermos of warm coffee. You take out the chair and decide to have a bite to eat … which you do.

In essence, you have assessed a new situation in which you have been put, as completely as possible with the available tools, and you have dealt with key concerns such as hunger, thirst, safety and comfort.

You are now quite comfortable in your chair, looking around and deciding the arctic region is, in effect, a very nice region to be in …

The static phase entails an as complete as possible inventory of key risks which could threaten the objectives. In case of an individual, this would be survival, in case of an organisation, survival will be defined quite differently but will be a key element too. After this time-intensive first priority inventory and assessment, corrective actions need to be taken. Quite often these actions need to be developed from scratch, and this too requires time and effort. The static phase is therefore time and resource intensive.

Dynamic phase

… when suddenly, you become aware of the relative heat of the sun on you new jacket. It is getting hot … but you quickly figure out there are a number of zipper controlled 'vents' in the jacket which you can use to control airflow through the vest.

Having dealt with this, you turn your attention to your surroundings once more, and you notice a small spec in the distance. You dig in the box for your binoculars, and focus on what appears to be … oh no, a polar bear with a very hungry and determined demeanor, at full speed, running straight at you. You intuitively check whether you consider your life to be in danger. The answer, alas, is yes, so you turn around, grab the gun, aim and fire at the polar bear … But you are not a very good shot. You have missed. You aim again, pull the trigger again, and are rewarded with a small "snap" sound of the trigger hitting the backend of the trigger guard. You are out of bullets.

Meanwhile, the polar bear is getting dangerously close. You reassess your options and quickly scan the small letters on the side of the box. You have not read these small letters, which state "Will protect one (1) person from polar bear attack."

You jump in the box, slam the lid shut, but not before smelling the foul breath of the polar bear … but you are safe … and you fall asleep, happy to have survived this ordeal.

In essence, you have reassessed the known situation based on the changes in this situation, and focused only on dealing with the changes, not with the rest of your reality which remained unchanged and under control.

The dynamic phase entails an assessment of the changes in a known situation which is initially, after the static phase, considered under control. Any change with a potential of threatening the objectives needs to be dealt with, but after the initial and significant investment of the static phase, the subsequent investment in dealing with these changes is significantly lower. The economy of using a layered approach comes to bear (pun very much intended) only during the dynamic phase.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. by Ben Broeckx

Minimal requirements

If you have ever played a video game, you must have noticed the “minimal requirements” explicitly mentioned on either the package the game came in or the description on the game store site you purchased the game from. These minimal requirements are an indication of what your system needs to be capable of in order to run the software that makes up the game.

The minimal requirements are seldom absolute. It’s usually not the case that a computer that does not comply with all the requirements cannot run the software, but the experience will be less, to the point of potentially being unsatisfactory. And that is, of course, an issue if you want to enjoy what you paid for.

Minimal knowledge requirements as a barrier to entry

Now, in the world removed from the virtual realms of video games, there are similar minimal requirements … the minimal knowledge requirements. And these requirements are all around us. Some of them are based on culture and assist in “compliance” with societal norms. Those are beneficial, but if you are an outsider you will be sticking out very soon and sometimes the understanding of these norms is assumed.

There are other minimal knowledge requirements as well. These are the exclusive and excluding ones, and are usually based on language.

I, the insider, speak a - usually technical - language with other insiders that you - the outsider - cannot understand. This language has an upside, in that it allows me to efficiently communicate with the other insider, but it excludes you, who does not speak my technical language.

The problem here is that when the outsider is actively implicated by the content and consequences of the communication, he or she tends to become disenfranchised very fast.

Think cancer patients, for example. Quite often, the details of the treatment that have profound impact on their being are discussed over their heads in language they cannot understand. How lost do you feel?

By using the key tool for mutual understanding - language - in a way to separate rather than to include, we distance people who do not have the minimal knowledge requirements.

Government administrations are often worst case examples …

And it’s not just medicine where this is a real problem. Government is quite bad at this as well. Some interactions with government are so convoluted that even people who are supposed to have the minimal knowledge requirements don’t understand whether or not they are in compliance with what the government asks of them.

This Economist article on the letter Donald Rumsfeld sent to the IRS is an interesting example of someone who explicitly admits not having the minimal knowledge requirements to return his taxes.

An initiative such as the Center for Plain Language in the US is an attempt to right such a wrong. We have had a similar initiative in Belgium for years, the Agency for Administrative Simplification, but both initiatives, while making inroads, appear to be mostly impacting the fringes.

But never by intent

The interesting thing is that this - according to me, based on the experiences I have had - is almost never by intent. Rather, administrations are so focused on getting done what needs to be done that working on that communication is one aspect that is too often forgotten

Interesting initiatives

There are other initiatives that are worth looking into. Take the Open Law Lab for example. This initiative looks at how to make law more accessible. It understands that there are certain aspects of law as it exists now that do not make it accessible to a large group of people. Instead, they need interpreters of the law, lawyers, to explain something that as well could be written in plain language.

There are other possibilities as well. Why make laws just understandable? Why not actively implicate as many interested people as possible in the process. I wrote about wiki-based law initiatives a while back. You can find the article here.

We need to aim for inclusiveness in our communications

At the most fundamental level, we should not exclude someone because of artificial differences. We should not play the game of information asymmetry but we need to level the playing field. The best way to do that, still, is by providing people with timely access to complete and accurate information provided in an understandable language.

The current inability of people to access our discussions is not to our advantage. No, it is our problem and our challenge. Imposing a requirement on ourselves to give as many people as possible access to the necessary information is essential to our long term credibility and viability, as any type of actor in a society which is becoming more and more replete with data.

Ultimately, it is our responsibility to distill key information out of that data. That information, when adequately and comprehensively put in context, should ultimately lead to the development of insights and wisdom in what is our constituency, whether we are the government, an private sector organisation, a civil society structure … and the only way to realise that is to be as transparent as possible.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. by Ben Broeckx

An updated look

You may have noticed that the blog has significantly changed. If you are reading this in a browser, you will notice there is a lot less clutter.

I had been an absentee landlord on this blog, only occasionally publishing. The work was only an excuse for my neglect of what had become a set appointment in my schedule: publish a blog post. When thinking about why I was no longer that committed to writing, I realised it was not about the writing at all. I’m still writing as much as I ever was, only not on my blog … but rather in my journal, or when writing individual papers.

But the idea behind the blog was for it to be a repository of my thinking, which would include some of the ideas I developed during my off the blog time. And it turns out that the main reason I did not write on the blog anymore was because I did not like the lay-out of the blog anymore.

Once I realised that, I started experimenting … mainly with Jekyll and Github Pages, because they allow for a minimalist design. But that turned out to be a time sink all by itself … and while I did okay in terms of the look and feel of a minimalist blog, it still was not what I really wanted it to be.

Therefore, I turned back to my original blog on Squarespace, and found a template which is very simple and really what I like. I removed most of the pictures from the headers and the articles, and toned down the blog to what I want it to be.

And now it is nice. I like it. It generates a certain rest for the reader, as it should.

Now if I only could convince the good people at Squarespace to allow plugins for the more popular Mac blogging software …

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. by Ben Broeckx