BFM2013_4_10_Costing e-government

As discussed in a future book , a different approach on the definition of the market positioning of your organization will be needed.

“Organization”, not “company”, as local authorities and countries alike lose/gain through this additional transparency, and, with the extension of subsidiarity, they too will need to find ways to attract investment (and tax-paying corporations).

After this extended assessment and evaluation of its qualitative effects, introducing e-government, like any other project, should be assessed for its quantitative cost.

Obviously, with “normal” projects you have at least the theoretical option of cancelling the project, an option that is not available with e-government.

In 2013, e-government has been confirmed to be more intrusive than it was expected, also if the regulatory framework is still a work-in-progress.

The options you should first identify are:

  • to what extent should e-government be introduced inside your organization
  • by when you should roll-out each new requirement
  • is there any flexibility, and for how long
  • could the e-government-related changes be kept aside from the company, or should be embedded in business processes
  • how can you compartmentalize information to avoid disclosing sensitive business information

The minimal cost categories to consider are:

  • compliance: is the direct cost of producing the information required
  • infrastructure: is the cost associated to storing and processing the information, along with any new infrastructure cost (e.g. paying a monthly fee, or buying digital certificate)
  • delivery: is not only the cost to deliver, but also to manage the delivery process (e.g. storing the feed-back, re-sending, managing the production of updated information)
  • maintenance: is the cost to support the previous three.

Let’s see an example: electronic filing of payroll information.

Law requires delivering a certain amount of information with a stated frequency and keeping track for a certain timespan.

Assessing costs should be quite easy in this case, as it is just a normal project to produce and deliver some files, but once you introduce transparency and ICT as a communication medium with government agencies, consider that they could make some assumptions on how your company works to produce that information.

A customer in Continental Europe reported some twenty years ago that they were requested statistics on payroll from the government agency collecting the monthly information; problem: the statistics’ contents extended beyond the statutory time limits; legally, the government agency could not require the old data, but legally, there was not statute of limitation on the statistics.

Once they delivered the payroll statistics, the government agency called back and said: “as obviously you have the underlying information, could you deliver that information as well?”.

The reason? A technical and organizational glitch resulted in losing and/or misplacing data tapes, and somebody at the government agency came out with a creative way to solve the problem.

In the future, constantly increasing transparency could result in further integration, and therefore when costing the introduction of e-government consider all the side-effects of related regulations, not each item separately.

Also, e-government makes more sense for the government if, once assumed that certain processes are carried out inside the information providers (the companies) and work properly, a certain degree of redundancy is removed by consolidating services, and maybe the government agencies focus on becoming just the “knowledge manager” for the specific set of rules, outsourcing all the data processing to a central unit that, also for privacy/security/etc. reasons, will have no clue about the data they process.

As in other projects, the longer the time some resources go unused, the easier is that they come to be considered “redundant” .

More so if on the receiving end you have not one organization that knows the meaning of the information that it is processing, but some low-cost, centralized unit, whose internal budget allocation will be linked to further constraints, and that will make decisions on the basis of the internal knowledge available (documentation, etc.).

When introducing e-government processes you have to take further precautionary steps while defining the SLAs (Service Level Agreements), because e-government is, in the end, something whose evolution is outside your control, but the deeper it affects your own internal business processes, the greater the loss of flexibility in your managing the evolution of your own organization.

Overall, the suggestion is: outsourcing requires assessing both the financial savings and the impact on business continuity.

BFM2013_4_11_Deploying e-government in your organization

The first step is therefore adopting the method described in issue01, to identify knowledge boundaries .

Consider the boundaries between your organization and each government organization and institution you have to report to, so that you can streamline communication processes and identify any additional requirements of investment, while defining roll-out priorities.

When allowed, institutions themselves apply this methodology, to reduce their own cost of delivery and to focus on real information, instead of collating information that could be easily fixed before being delivered; as an example, the Bank of Italy, that has overall oversight authority on banking in Italy, already in the early 1990s coordinated all the requests related to different regulations into a set of validation tools, delivered to banks or their IT providers that unified the data delivery.

Some of the e-government requirements are for immediate delivery, and therefore should be managed as both a stop-gap delivery and a long-term solution.

Anyway, consider that e-government will be like ERP and similar “vertical/horizontal process-replacement schemes”: if you drop your own processes and replace them with external ones, you will lose your own uniqueness, and “customization” is not an option with e-government.

The suggested phases are:

  • assessment and priority setting: assess impacts and needs to deliver short-term compliance, using this phase to prioritize and identify which core or non-core parts of your own way of doing business are affected
  • make-or-buy: carry out a make-or-buy decision, i.e. see if it is better to use a standard, external process, whose evolution you would be unable to control, or to interface your internal process with the external ones, or, finally, to embed inside your internal processes the new ones
  • deliver: according to the results, deliver the processes.

Remember: e-government is both a technical and political issue, and therefore you should assume that its evolution mirrors more political “horse-trading” realities than any theoretical framework, all while keeping a face-saving theoretical framework justification for any choice.

Do not expect a “logical” evolution of constraints, and therefore avoid “planning ahead”, i.e. building new requirements into processes or software that seem to be expected as the next requirement.

As with any political process, e-government might one day jump ahead and run as a leopard, and the following day walk like a crab- backward.

BFM2013_4_12_Increasing e-government benefits

Is e-government just a cost and a threat to your own way of doing business that you have to comply with due to law?

Most of the benefits declared by the governments and institutions proposing e-government are real, but some just are not available unless you invest some time and efforts in determining how to embed e-government in your organization, and re-invent your own way of delivering certain results.

Generally, as for any other compulsory compliance, you can see both costs and opportunities, but only if you move beyond the mere afterthought compliance.

A simple example of benefits delivered by e-government: if you knew which e-government disclosure rules apply to your suppliers and customers, you could make better informed credit decisions, by including in contracts exchanges of information already mandated by e-government- also if originally you did not consider that information.

As compliance to produce that information would be anyway required by law, you would avoid re-inventing the wheel, streamlining your own decision-making processes.

Furthermore: e-government will allow both you and governments balance credit and debits; eventually you could expect every government becoming like any other customer/supplier, introducing different ways of paying duties and taxes.


By now, it should be quite clear that our approach to e-government is quite straightforward: e-government is part of a common trend toward creating a level playing field, as required by market economy.

This trend started centuries ago with the creation of financial instruments, and what we are observing is a mere acceleration, due to the spreading of ICT, and the interoperability allowed by internet.

What is interoperability? A working definition is: the possibility of every organization to communicate with any other organization at any time, without the need of establishing a custom communication link.

E-government is a work in progress, and its spreading will accelerate the trend toward further transparency, with wide impacts on our assumptions on what is proprietary or confidential.

To have a coherent idea of what would mean managing a transparent company, we suggest reading an old science-fiction book on how technology could affect privacy .

Consider e-government as part of your own business development activities, by adopting a “monitoring” approach, also in smaller organizations; this approach could extend into lobbying, instead of simply reacting to e-government.

Smaller organizations would certainly benefit by coordinating their efforts to present industry consensus at the same level of organizational complexity, making easier to give visibility to their negotiating position while talking with government agencies.

Usually lobbying is seen as something for larger companies, but probably smaller companies could be the ones obtaining more benefits from e-government, as they could use government free services to replace services that are currently delivered by external resources, as they lack the structure to justify building in-house expertise.

Therefore, smaller companies will have probably opposite interests, when compared with larger ones, as what would be a benefit for the former (e.g. removing the need for auditors, as anyway their figures are small enough to remove any “creative accounting” value), would be a straitjacket to the latter.

The same applies for smaller local authorities: while towns with more than 800,000 residents have both structure and resources, smaller towns will be required to provide the same services, but without the administrative or technical resources required, and therefore could be more interested in giving value not to custom-built applications, but to the use of government-sponsored standard applications, that allow them to use their scarce resources to promote the unique content that their town can deliver to visitors and investors, using “virtual malls” as containers to publish the content