Managing the technical aspects of the project implementation process can be the more complex area of the implementation plan, particularly for managers who are not highly familiar with the technologies supporting the engagement strategy.
There is a risk that lack of technical familiarity or knowledge might, perversely, lead managers to ‘outsource’ the technical side of the process to a private company or IT unit in government. It must, therefore, be emphasised, that maintaining strong control and oversight of this part of the process will be critical in ensuring that the objectives of the eEngagement process are realised.
Although some IT professionals have a very good grasp of the social issues arising at the interface of computer technology and public policy, many have not and the collaboration between policy specialists and technologists can be the most productive and educative part of the implementation process. In many cases, existing relationships and associated business processes governing the provision of IT services to the organisation may require some (re)negotiation (either to determine the ability of the existing provider to undertake this work, or to allow new systems to interact with existing ones).
Technical implementation will require:
Exhibit 22: City of Wellington IT Strategy
In their 2006 IT Strategic Policy Document, the City of Wellington in New Zealand has incorporated electronic democracy as one of the three elements of their IT approach.
The eDemocracy element of the strategy includes four objectives:
The document includes a discussion of the implementation approach and an explicit identification of the need for post implementation assessment of the approach.
The policy can be located at: http://www.wellington.govt.nz/ plans/policies/ict/pdfs/ictpolicy.pdf
The software feature set is the bundle of attributes possessed by the application that achieves the objectives of the engagement process. This is normally constructed as a list of ‘can dos’ – the software can do x, y and z to meet the objectives. Depending on the budget of the organisation and the complexity of the eEngagement process, this may need to be clustered into ‘must have’, ‘should have’ and ‘would like to have’ characteristics, thus supporting an analytical approach to making trade-off decisions (where necessary).
This approach may simply require the development of a list, or may be expressed as an analogy, such as ‘the system should emulate a library, with a check out area, reference table, volumes of texts, etc.’ Do not underestimate the value of drawing analogies: they can generate powerful metaphors that assist in visioning and ease communication between purchasers and providers (and later may be valuable in assisting users to understand the parameters of the interactive environment).
It will be useful to engage the participation of a technical advisor early-on in the process, as some activities that appear difficult or complex to those unfamiliar with the technology may in fact be commonplace and straightforward, or vice-versa. Having early advice can also serve to generate new ideas prior to systems development which the project team may find valuable. This could take the form of new features, or potential features, that will be noted for future iterations of the approach or as contingencies.
Regardless of the approach undertaken, a critical decision point is the determination of who is ultimately responsible for developing the technical package. For various reasons, the implementation process may require, inter alia: a strict level of control by the auspicing agency; IT or communications technology experts having autonomy with respect to decisions about technical issues; or direct hands-on management by a Minister or select committee (e.g. in a Parliamentary process).
Decisions about software acquisition, management and/or modification may entail an explicit choice between close management of the process by the host agency, or devolution of the process to a technical unit, or private firm. It is important to be cognisant of the advantages and limitations of each approach:
One potentially valuable approach to is to place project management outside of government. This may take the form of outsourcing a specific aspect of the project (such as the development and maintenance of the technical infrastructure), or shifting the entire project to an organisation within (or with explicit expertise in) the community of interest, such as an academic body, or a non-government organisation (NGO).
The advantages of this approach include:
The limitations of this approach include:
Exhibit 23: Placing Management of the Participatory Process Outside of Government
In the case of the Hansard Society’s collaboration with the Social Security Select Committee in the United Kingdom’s Uspeak online consultation project, the online consultation process was undertaken by a collaborative umbrella management structure including voluntary organisations with expertise in the specific policy area and target audience, local government organisations capable of providing place-based assistance with recruitment and promotion and private sector providers with capabilities in developing access technologies.
The Department of Human Services (Victoria) uses an external, non-profit organisation to provide moderation skills for their online discussion forums. In this case, the Department benefits from acquiring the necessary skills without long lead-times associated with recruitment and training.
The most fundamental decision in the development of an eEngagement technology platform is choosing the right type of software to meet the project requirements (as discussed in Section 3, Designing the Right Approach). Depending on the specific engagement strategy being undertaken there may be a range of software packages available to host and administer the online engagement activity.
For eEngagement projects that are based on electronic discussion list models, there is a range of existing software packages that allow for these types of discussions to be hosted, either as simple email handling systems, real-time chat facilities, or Web-based bulletin board systems. For more complex or innovative projects, the lack of a large commercial marketplace for electronic democracy software means that there may be few, if any, off-the-shelf software packages available.
A critical early decision will address whether existing software packages can deliver the functionality required for the proposed engagement activity. This will also require consideration of:
These considerations may in turn require further decisions about whether to select an existing software package (which may necessitate a trade-off between availability versus functionality), the re-engineering of existing applications, or the development of wholly new applications to undertake the task.
Even when undertaking a relatively conventional approach – e.g. in which an existing software package is available to the project team – the likelihood exists that some form of customisation or modification will be required to accommodate the agency’s requirements, such as:
Public sector managers are often surprised to learn that their agency (and partner organisations) either possess, or can access under licence, a wide array of applications software capable of supporting eEngagement activities. As part of any assessment of available technologies, it is important to consult an inventory of available software (or undertake an inventory, if none exists) and assess the utility of these packages in meeting the objectives of the eEngagement plan.
This is a useful strategy where resources are limited, or the eEngagement process is not technically complex – it does not imply a process in which the objectives are retrofitted to the tools on hand. Public agencies commonly possess, or have access to technologies like:
In addition, the desktop environment of many public agencies also have an array of potentially useful software, such as:
Alternatively, non-government ‘communities’ tools abound, some of which may be of value, such as:
The decision about whether to ‘buy or build’ software is a complex undertaking and will need to be considered with due reference to the existing agency or whole-of-government policy on software acquisition.[1]
The decision about whether to purchase an existing software package, or to develop a custom-made piece of software will be based on:
Regardless of the approach taken, a clear business case process will be undertaken in line with existing policy in the agency's jurisdiction.
When considering whether to ‘make or buy’, public sector agencies also consider non-commercial software alternatives. During the last 10 years there has been an increasing interest from the public sector in ‘open source software’.
Open source software is provided under a licence that commonly allows for its original source code to be freely distributed and modified by end users. While open source software is often considered to be ‘public domain’ intellectual property,[2] this is not the case. Open source software is often released under a licence that imposes specific restrictions on the end user or modifier. These may include:
The growth of the ‘open source movement’ has stimulated the proliferation of software packages that are available free, or at low cost to the public, as well as encouraging the release of software which may have been developed for specific purposes but does not have a commercial value. As this movement has developed into a strong, collaborative community, the availability of elements of code and whole applications allows new software applications to be developed from existing code, without undertaking complete software development – in other words, elements from one project can be incorporated into another to add functionality.
The advantages of utilising open source software are:
The disadvantages of utilising open source software are:
Open source software can deliver some cost savings to government agencies interested in developing unique packages. However, it is a misconception to consider open source as ‘free’ software. Depending on the type of functionality required, considerable investment may be necessary to develop or modify an existing open source application. In addition, care must be taking when adopting an open source solution, given the variety of licences that may be attached to the original code and the constraints these might place on further development or release of modified versions of the initial software.
The real advantage of open source lies in the ability to redistribute modified versions of the software to organisations with whom your agency may be partnered. For example, you may develop an online consultation system in open source that is of interest to a number of peak industry bodies engaged in the initial consultation, who wish to use the software to consult with their members. Having developed the package in open source may allow your agency to freely release its software to partners/stakeholders and any enhancements that they make to the software can be acquired by your agency for future use.[3]
A common but largely avoidable problem associated with the design of electronic democracy systems arises from the mistaken belief that, because these concepts are new, they will be supported by the latest technology. For example, the capacity of computers and mobile telephones to support interactive multimedia often leads to their being selected to deliver eEngagement solutions. This assumption is often ill-founded and can limit the degree of participation by members of the public.
Over the last decade, the public sector in Australasia has become much more effective at managing issues of technological obsolescence, through systematic hardware and software replacement processes and the use of managed service agreements (equipment licensing). While this has positive benefits in terms of the productivity of public servants, public sector managers need to be cautious when assuming that members of the public have similar technical capacity.
This has a number of dimensions:
Technological solutions need to be matched to the target audience taking into account its general characteristics, like technical skills, technological capabilities and information literacy. Target audiences can be grouped according to a number of archetypical user types (as illustrated in Figure 10).
|
‘Experimenter’ |
‘Sporadic User’ |
‘General User’ |
‘Power User’ |
|
|
|
A common trap for public sector managers is to assume parity between the capacities of government officials and those of the public with whom they engage. Examples include:
When selecting the most appropriate approach to technology, consider the following four questions:
If the answers indicate that the user base is most likely to be served by older or more common technology then work within those limitations. While this may restrict some activities, it does not necessarily prevent the eEngagement process being interactive and compelling. Having users with slower and older software can allow interactivity and complexity of systems design, but may require: