Guidelines for eGovernment Projects

The Agency for Public Management and eGovernment in Norway is currently developing guidelines for IT-projects within the Norwegian governmental sector. The Norwegian Computing Association hosted a presentation and discussion about this work yesterday. I was privileged enough to summarize the comments from one of the three discussion groups at the meeting. For the enjoyment of the internet, I hereby provide a few ideas on eGovernment projects.

Value first

The speaker from The Norwegian Government Agency for Financial Management (SSØ) pointed out that many projects are not sufficiently concerned with satisfying real objectives. Such a project may be a technical success, but still not worth doing. Guidelines for eGovernment projects must first and foremost focus on the value delivered by the project. Beyond the remarks of SSØ, we believe it is important that this value is delivered incrementally. Too often, the idea is that a project represents a substantial investment that hopefully fulfills some objectives. If a project delays long before it proves its promise, the business case may prove to be a mirage. The business case has to be concrete and verifiable. For example, if a project claims to be able to eliminate 100 full-time positions, plans to actually terminate these positions should be within the project scope. When should a project be terminated? Too often, projects are terminated too late. Guidelines for eGovernment projects should provide guidance to allow a project to terminate when it has realized only some of its promise, if there are better uses for future investments. And without incremental deliveries, there is no way of doing this without losing the whole investment.

Focus on experience

If the effort of the Norwegian eGovernment guidelines only result in a static document, it fails. Instead, we need an ongoing conversation where projects can share experience and recommendations. There is much experience from existing eGovernment projects that can be utilized. Some examples from the discussions:

  • During a project start there are some activities that are useful and many that are just a waste of time. Even so, experience about what common activities that provide no value is not widely shared.
  • Some of the discussion participants have much insight into how to terminate projects ahead of plan. This experience can be critical to avoid throwing good money after bad. And to avoid throwing bad money after good.
  • There are a few competing contract standards that are frequently used in eGovernment projects. Often the specific choice of contract is more a matter of personal choice than experience.

The scope and impact of recommendations

Many of my discussion partners were curious about the level of ambition regarding the official guidelines for eGovernment projects. The overall goal of these standards is to create value in eGovernment projects. However, that goal is much too value to be a sufficient vision for the work ahead. It is especially important that the goals of the standard are Specific and Measurable if the end result is to be valuable. During the discussion, it was also unclear what the scope of the recommendations would be. Early work on the standard could benefit from a table-of-contents that articulates what areas the standards will concern themselves with.

Is “project” the right word?

From the discussion, I draw my own conclusion: To create effective eGovernment, it’s insufficient to look at projects in isolation. Instead, the various agencies must concern themselves with the full value proposition of their whole IT- and operational systems. Creating value in the context of a project can be a distraction from the everyday operational concerns of the organization. And the key to the value that can be created is in these everyday concerns. A project runs the danger of becoming detached from the organization that it is created to serve and that will eventually bear the maintenance cost of the project deliveries. The number one concern should be to close this gap.

Comments:

[Glen Farley] - Jun 4, 2009

Very good summation Johannes. I was also at the meeting yesterday. I think the online project guide initiative is excellent and shows a real willingness to address the various project problems presented by the public service leaders at the meeting. My concerns were mostly practical and based on my experience creating and maintaining project guides, checklists and websites in general. they fall roughly into four main areas:

  1. Guides/checklists/template collections tend to grow out of control and become unusable very fast. This guide must be QUALITY and QUANTITY-CONTROLLED, ideally through moderators following general guidelines on what should be included and omitted (or linked to in a secondary way.)
  2. The guide must state clearly WHY each step/deliverable is critical so that users understand the consequences of hopping over/not using them. ALTERNATIVES should be provided for smaller and specialized projects.
  3. Like all websites, adequate time and energy must be spent on creating a positive USER EXPERIENCE. If the guide is hard or frustrating to use, it will not be used.
  4. The sponsor of the guide must not underestimate the BARRIERS TO CONTRIBUTING to, using and discussing the guide online. These barriers can include lack of time, laws and regulations that limit sharing of information between government agencies and the general reluctance of users to contribute to websites in general and work-related websites in particular (failure of so-called Enterprise Web 2.0) These can impact the critical CONVERSATION that you mention Johannes.

[YL] - Jun 5, 2009

Guess that it also might be a major issue that SSØ has a mixed owner structure (partly owned by the state and partly private). This causes different issues, especially, when SSØ has several positions around the table… from business point of view this position is not easy to handle….

I would compare SSØ with Statsbygg - and by this draw comparison ….

[Glen Farley] - Jun 4, 2009

Very good summation Johannes. I was also at the meeting yesterday. I think the online project guide initiative is excellent and shows a real willingness to address the various project problems presented by the public service leaders at the meeting. My concerns were mostly practical and based on my experience creating and maintaining project guides, checklists and websites in general. they fall roughly into four main areas:

  1. Guides/checklists/template collections tend to grow out of control and become unusable very fast. This guide must be QUALITY and QUANTITY-CONTROLLED, ideally through moderators following general guidelines on what should be included and omitted (or linked to in a secondary way.)
  2. The guide must state clearly WHY each step/deliverable is critical so that users understand the consequences of hopping over/not using them. ALTERNATIVES should be provided for smaller and specialized projects.
  3. Like all websites, adequate time and energy must be spent on creating a positive USER EXPERIENCE. If the guide is hard or frustrating to use, it will not be used.
  4. The sponsor of the guide must not underestimate the BARRIERS TO CONTRIBUTING to, using and discussing the guide online. These barriers can include lack of time, laws and regulations that limit sharing of information between government agencies and the general reluctance of users to contribute to websites in general and work-related websites in particular (failure of so-called Enterprise Web 2.0) These can impact the critical CONVERSATION that you mention Johannes.

[Glen Farley] - Jun 4, 2009

Very good summation Johannes. I was also at the meeting yesterday. I think the online project guide initiative is excellent and shows a real willingness to address the various project problems presented by the public service leaders at the meeting. My concerns were mostly practical and based on my experience creating and maintaining project guides, checklists and websites in general. they fall roughly into four main areas:

  1. Guides/checklists/template collections tend to grow out of control and become unusable very fast. This guide must be QUALITY and QUANTITY-CONTROLLED, ideally through moderators following general guidelines on what should be included and omitted (or linked to in a secondary way.)
  2. The guide must state clearly WHY each step/deliverable is critical so that users understand the consequences of hopping over/not using them. ALTERNATIVES should be provided for smaller and specialized projects.
  3. Like all websites, adequate time and energy must be spent on creating a positive USER EXPERIENCE. If the guide is hard or frustrating to use, it will not be used.
  4. The sponsor of the guide must not underestimate the BARRIERS TO CONTRIBUTING to, using and discussing the guide online. These barriers can include lack of time, laws and regulations that limit sharing of information between government agencies and the general reluctance of users to contribute to websites in general and work-related websites in particular (failure of so-called Enterprise Web 2.0) These can impact the critical CONVERSATION that you mention Johannes.

jhannes - Jun 4, 2009

Hi, Glen

Thank you for your follow-up. These are very important issues with a checklist and I agree with your evaluations of all of them.