Implementation plan
From TriasWiki
|
| This page could use improvement |
This page is filled with fragments from the chapter Implementation in Juridical organizations from the book Legal Knowledge Management by Tom van Engers and Alexander Boer (to be published). The fragments are chosen to support students making an implementation plan for the module Testing and designing eGovernment services. Important for those students: In case of time pressure read only the parts about:
- Managing Change
- Creating Stakeholder Commitment during the Project
- Project Phases
- Coping with Resistance.
Definition/short description
Introductory
Implementation in Juridical organizations
This chapter describes some social and organizational issues that one typically encounters when designing and implementing juridical knowledge management systems. Examples from different projects will be given and typical situations will be explained. Some of these issues are not specifically different from implementing change in general. A vast volume of books on organizational change in general has been published (see e.g. E. Schein. Organizational culture and leadership. Jessey-Bass, San Francisco, California, 1992, ISBN 1-55542-487-2). As will become clear in this chapter implementing juridical knowledge management systems relates to several organizational change perspectives. We deliberately speak of organizational change rather then another term frequently used in management literature, Business Process Redesign, in short BPR, although the introduction of knowledge management systems often is part of a BPR process. BPR became popular just before knowledge management had its glorious hours, i.e. the late 1980's, and was seen as the way to get competitive advantage by designing smarter (and especially more cost effective) processes. BPR should reduce cost prices and enhance response time to customers' requests. As explained in the introductory chapter knowledge management was introduced as a solution to the deadlock caused by the fact that competitors will also look for potential cost reduction measurements. Merely focusing on cost reduction consequently doesn't improve an organizations' competitive advantage, while distinguishing ones services or products by their intrinsic value (by putting in the best knowledge available) does. Secondly the name BPR suggests that it is focused on the (re)design rather then on effectuating the design, and consequently on changing the processes and the organization that executes these processes.
Knowledge management projects are never done in isolation. People involved
in such projects, being in the role of project manager, knowledge analyst,
knowledge engineer, ICT specialist, domain expert or other, have to cope
with the many different aspects of organizational change. When responsible
for the results of such projects one has to pay specific attention to managing the whole. This activity is also called organizational change management. Organizational
change management can be defined as the process of effectuating changes in a
controlled manner, enabling changes with minimum disruption. Introducing innovative
technology such as knowledge management systems is always
disruptive in a sense, but it shouldn't be more disruptive than necessary.
If activities aimed at coping with these matters are included in the project
plans and executed during the design and development phases of projects,
the chances that the results are taken up are much higher, with less costs and efforts.
We will explain the different implementation issues and use examples from
practice to show what one can encounter when dealing with the most
challenging aspect of conducting juridical knowledge management projects;
making things work. But before we will do so, we will have another look into
the management aspects of juridical knowledge management.
In depth and the relevance to eGovernment
Managing Change
In the introduction chapter we explained the concept knowledge productivity as the key concept in knowledge management. (Knowledge productivity can be explained in two ways, one, as the amount of knowledge produced by a human or organization, two, as merely another word for performance; addition PK). Knowledge productivity and performance are correlated concepts. Knowledge productivity is the result of the effectiveness of learning and application of new and existing knowledge. This result has its effect in overall task performance. We don't deny that in some tasks other forms of competences, like physical strength, also have their effects on task performance, but in juridical organizations (organizations that are professionally involved with the understanding, exposition, science, administration or practice of law, e.g. a law firm; addition PK) such physical aspects do not play a significant role. For sake of simplicity we therefore equal (team) performance to knowledge productivity.
With respect to performance we can take two perspectives, the performance of
individuals (employees or managers) or the performance of co-operating
groups. Organizations can be considered to be a specific example of a
co-operating group (see e.g. I. Nonaka, The knowledge-creating company. Harvard Business Review, nov-dec, pp 312-320, 1991). The
importance of taking co-operating aspects within groups into account when
(re)designing systems is stressed by Van der Veer and others (see e.g. G. van der Veer and M. van Welie. Task based groupware design: putting theory into practice. In Proceedings of DIS 2000, New York, 2000).
The introduction of a (new) knowledge management solution in a juridical
organization is not limited to introducing the ICT components of such
systems and training staff. Research shows that instruments that support
knowledge dissemination and knowledge application can only become effective
if the right preconditions are created (see e.g. T. van Engers. Management issues in complex systems design. International Publication for COST, 1997). Creating such preconditions is a management job.
Focussing on a specific aspect of organizations, knowledge management has to
control activities that stimulate knowledge development, knowledge dissemination and knowledge
application. Knowledge management does not imply that
new, additional management tasks have to be performed since knowledge is an
inalienable asset that comes unavoidably with human labour. Management has
always been concerned with e.g. the allocation of human (and other)
resources, and knowledge management therefore does not necessarily imply that
new tasks have to be executed although a new emphasis may be needed. The
focus on the aspect knowledge implies a focus on the aspects `organization',
`personnel' and `information', but also other aspects have to be managed. These aspects are present in the acronym COPAFIJTH. Here we look at the aspects from an implementation point of view.
Communication:
Every change in organizations' processes may have impact on the relationships with the world outside of that organization. It is important to adapt communication strategy to the new situation. This includes the relationships with clients, suppliers and other stakeholders.
Organization:
Introducing a (new) system requires adaptations of the (structure of the) organization. Adaptations may have to be made at task level (individual employee), team or department level (or any other form of organizational unit). Questions to be asked are e.g. who (and what organizational unit) is responsible for what and who will deliver what to whom.
Personnel:
When we (re)design parts of an organization we need to answer questions like what are the (newly) required competences, how do we keep up with our knowledge, are we still aligned with the labour market, how can we fulfil legal obligations with respect to the labour circumstances etc.
Administration:
This aspect includes the (administrative) control mechanisms. Are there not too many interaction points between departments, can we manage the processes, who will report to whom about what, are amongst the questions to be answered.
Financial:
This includes all financial aspects (costs and profits) of the new system. In the implementation phase one should specifically look at the costs of ownership of the new system (since maintenance is often much more expensive then development) and monitor these costs in order to decide when renewal would be the most beneficial.
Information:
Introduction of new systems may require new information flows and storage. ICT projects tend to focus on this aspect (sometimes neglecting the other aspects in this list). When implementing ICT systems one should not forget to take care of a proper roll-out process including introducing the system to its users and provide education of the user if necessary.
Juridical:
New systems may bring along new legal obligations. Having a new registration might e.g. give the organization the obligation to fulfil certain demands from privacy regulations and to report to their clients about the data stored.
Technology:
In the implementation phase one has to organize that the new system fits in the required technical infrastructure without frustrating other system.
Housing:
New systems may reduce the demand on some housing factors, as employees are for instance less bound to their paper office and the number of different workplaces required may shrink. Other houding factors may be introduced: maybe the organization needs to increase the capacity of its internet connection? \end{description}
Mental Models
Introduction of new systems requires that the involved stakeholders adapt their `mental models' someway to these new systems. The term mental model\mi{mental model} originates in cognitive science and is a container term for the ideas, preferences, norms, values, goals etc. in the minds of people. People need these mental models to understand their world and plan actions. The organizational aspects (COPAFIJTH) are also dimensions of those mental models.
Before explaining the role of mental models in organizational change
management, we will give some other definitions of what a `mental model' is
exist. Johnson-Laird (P. Johnson-Laird, Mental models, Coambridge University Press, Cambridge, 1983) for instance states:
It is now plausible to suppose that
mental models play a central and unifying role in representing objects,
states of affairs, sequences of events, the way the world is, and the social
and psychological actions of daily life. They enable individuals to make
inferences and predictions, to understand phenomena, to decide what action
to take and to control its execution, and above all to experience events by
proxy; they allow language to be used to create representations comparable
to those deriving from direct acquaintance with the world; and they relate
words to the world by way of conception and perception.
Rouse end Morris (W. Rouse and N. Morris. On looking into the black box: Prospects an dlimits in the search for mental models. Psychological Bulletin, 100:3:349-363, 1986) state:
Mental models are the mechanisms whereby humans are able to generate descriptions of system purpose and form, explanations of system functioning and observed system states, and predictions of future system states. It is important to emphasize that this definition does not differentiate between knowledge that is simply retrieved and knowledge that involves some type of calculation. Thus, mental models are not necessarily computational models.
Norman (D. Norman. Some observations on mental models. In: Genter and Stevens (editors)), Mental Models, pages 7-14, NJ, Erlbaum, 1983) defines a mental model as:
A mental model denotes the knowledge structure that the user applies in planning his actions, guiding the interaction with the system and the execution of the planned tasks, evaluating the results and the expectations the user has about the results and interpreting the systems action.
Norman also presents an even simpler definition:
A mental model is an internal representation that people use when interacting with a system.
According to Norman mental models evolve when people interact with the environment; it is the result of (an often unconscious and) a natural process.
In an organizational change process the mental models of the stakeholders involved play a very important role. It is especially important to allow people to accommodate their mental models in order to take action, as Rosenhead (J. Rosenhead. Introduction: old and new paradigms al analysis. In: Rational Analysis for a Problematic World: Problem Structuring Methods for Complexity, Uncertainty and Conflict, Chichester, John Wiley and Sons, 1989) and others have pointed out. Rosenhead states that decisions and actions emerge out of interactions between a variety of actors:
Each may, indeed will, have an individual perspective or world-view
(Weltanschauung) through which the actions and statements of others are
interpreted. What the constraints are, what the priorities should be, what
the problem actually is, may be perceived quite differently. A process of
accommodation between participants is necessary before a problem focus can
emerge which will carry assent and commitment to consequential actions.
At this point it must be stressed that in organizational change processes there is a big difference between being `committed' or `involved'. There is a famous poverb about it: A pig and a chicken decide to produce ham and eggs. The chicken is involved but the pig is committed.
What you want is commitment. That is what Rosenhead is talking about.
We started this section with explaining the reasons for paying attention to
organizational change management. This reason is not that we want to
establish change as a value in itself, but we want to change in order to
enhance knowledge productivity (which is as we explained equal to
performance in juridical organizations). We also stated that managing change
intends to realise this change in a non-disruptive way. Practice has shown
that this can best realised if the stakeholders are involved in an early
stage, allowing them to adapt (accommodate their mental models) to the new
situation.
A well known problem in organizational change management is dealing with resistance. This resistance is often caused by the (perceived) change agent (often a senior manager, or a project manager responsible for bringing the news) who surprises the stakeholders with a rather tight change process, leaving no time for acceptance, nor room for having influence on the process to these stakeholders. In order to prevent resistance, perhaps even creating enthusiasm, but at least support for the change process we need to pay attention to the stakeholders' mental models. Knowledge about their mental models can be used to plan interventions (no change without intervention) and to develop strategies that create commitment.
Creating Stakeholder Commitment during the Project
Several methods exist to extract information from individuals' mental models. These techniques belong to the knowledge acquisition tools. In this section we limit ourselves to explaining the process of creating stakeholder commitment in general terms, without explaining the methods and techniques that can be used in too much detail.
The stakeholders are all people you can think of who have a legitimate interest in the new organization.
The employees that have to work in it are always stakeholders, but so is management and
sometimes the clients of the organization. In a democracy the people are also stakeholders in public administration.
Although the title of this chapter suggest that it is about implementing
rather than designing juridical knowledge management systems we also have to
talk about the other development phases starting with the project start up,
since implementation should be prepared from the beginning of a project.
A project can only become successfully designed, realized, and implemented if
the stakeholders involved are committed to it. These stakeholders may have
quite different aims, preferences, opinions and so on. The stakeholders must be
involved thoughout the process.
These stakeholders, although having different roles and backgrounds, have to
work together in order to get the job done. We will describe the
different project phases and the activities that should be carried out in
order to create stakeholders' commitment in the next section.
Stakeholder involvement is a necessity for having a smooth implementation of
the system to be created.
Project Phases
In general a project has the following phases:
Initialisation:
In the initialisation phase the goals (what is to be achieved) and the conditions are determined. If the urgency is high enough one might consider starting a project. A project should have a clear set of goals and a clear time line (so it should be clear when the project ends). Other characteristics of projects are that they consist of people that come from different parts of the organization and that the project is managed differently in different operational parts of the organization.
The client of such project is not necessarily the intended user of the
system.
The board of directors e.g. can decide that the company needs a groupware
system to enhance inter-department co-operation. This doesn't imply that the
members of the board themselves are going to use that system.
In order to enable the project members to fulfil their task (and find the
best solution) each member should not only state his/her aims and
requirements, but also explain these aims by providing background
information, the context of the problems to be solved, the hypotheses etc.
A frequently made error is that the aims are expressed in terms of the
desired solution. By getting to a solution in a too early stage, the project
members are not challenged to come up with the best possible solution, nor
does this stimulate them to apply their knowledge. It is very
unlikely that outsiders has better knowledge with respect to designing
the system then the specialists that are usually working in the projects.
The initialisation phase ends with allocating budget and finding the project
manager that will organize the project. Finding this person is not just a
matter of finding someone who is available. The project manager should not
only possess the right competences and personality: Key factor to the
project success is the project managers' own commitment to the project aims.
Project start-up:
The project start-up is organized by the project manager. Finding the right resources for the project is one of the most important tasks. Unfortunately in many situations the authorizing party has already decided for the project manager (and the project members) that they should work on the project. The project team will then have to create a project plan based on the requirements formulated in the initialisation stage. It is important to include project members with the competences to cover all COPAFIJTH aspects. Experiences with working in previous projects, knowing the target organization the system to be developed should be implemented in and profound expertise in one or more design aspects really help to create the project success. It must be stressed that although it is useful to have these competences available from the start, this doesn't mean that all activities should start at the same time. Knowing what activities to start when and establishing the relationships between different project activities (concerning different COPAFIJTH aspects) however is part of the project start-up and should be describe, at least to some extend in the project plan.
An example: suppose a law firm is going to introduce a new groupware system
to enhance service to its clients and learn form problems that are met in
the front offices of the organization (the law firm has several units
throughout the country and employs several hundreds of employees). In the
project start-up the project team member responsible for human resources
(the P aspect) might come up with the fact that the intended users have
insufficient computer experience for working with the advanced technology
one plans to design. He has noticed that the budget limitations hardly leave
any room for including additional training within the projects' activities
and suggests that one could perhaps use the general education and training
budget for solving this problem. If the responsible director does agree one
could organize a course during the summer period, a period that is known to
be a reasonably quiet period for the front office employees.
The example given above is typical for the type of discussions that happen during project start-up. The project team members discuss the different aspects and their interaction as part of a `mental preparation' to the real actions. In their heads a shared perspective on the world as is and as it will be is created.
Feasibility study:
In some cases the problem to be solved is too vague or the potential solutions to the problems to be solved are still to unclear to start the design phase. In such cases a feasibility study\mi{feasibility study} can be started to reduce uncertainty and to provide the project team and its members a better insight in the potential solution that should solve the problems. A feasibility study can be conducted almost the same way as a normal project (i.e. it follows the same phases) except for the phases implementation and evaluation.
Design:
In the design stage the system that provides the solution to the problem is described. This design should include all COPAFIJTH aspects. Usually more than just one option exist to find a solution for the problem. Since these options may have different consequences, not only in time and budget, but also in e.g. technical complexity, impact of the required competences etc., choosing between options is often a strategic issue. For that reason projects often also consist of a steering board which takes the responsibility for such decisions. Such steering boards can also take care of the political grounding of the project within the organization (having the important decision makers as their members).
Realisation:
In the realisation phase all components described in the design phase are implemented and become operational.
Test:
In the test phase all components are tested. Different tests can be distinguished. The most important distinction is between testing against specifications and testing against desired functionality.
In ICT a common distinction is between technical, functional and acceptation tests, the latter corresponding to testing against desired functionality. In some case the system is \emph{functionally} speaking exacty what the organization asked for, but the organization or the future users srill don't like it.
The final
test is always acceptation by the user organization, i.e. the organization
that is intended to use the system.
Implementation:
The implementation phase is the phase where the rubber hits the road, i.e. in this phase all components are rolled out and used in the environment where the new system is intended to become operational. Educating the users of the system is part of the implementation phase.
Evaluation:
The evaluation phase is the period after implementation. Monitoring the system and comparing its functioning with the original aims and requirements will provide the information that allows decision making about the systems maintenance or renewal.
The different phases described here not necessarily are conducted in a
strict sequential order. Techniques such as rapid application development(RAD) or other forms of cyclic
development are frequently used. The aims of these approaches is not only to
have insight in the (technical) feasibility of the solution to the problem
in an early development phase, but they also allow quick returns on
investment (ROI) and give the stakeholders the opportunity to adapt gradually to
the system while the system grows. Experiences with working with the new
system can be used as input for the design thus improving the usability of
the system. Showing the users of the system that their input is used to
improve the system helps to build trust and enhances acceptance of the
system.
Coping with Resistance
In the case described below as well as in many other cases a knowledge management system contains of li{legal knowledge based system} components (as well as other components). People with a law degree often come up with objections against this type of systems. These arguments are put forward so many times that we will pay special attention to them, since they are likely to become a source of resistance against change if not tackled properly.
The core of the argument against a knowledge engineering approach to solving
legal problems is the fact that laws contain many open evaluative terms,
like good practice, or beyond reasonable doubt. Norms would be hard to
formalize as a consequence of this characteristic and therefore information
systems cannot cope with solving legal problems. One could use as a
counter argument that legislation that contains such open norms is not
sound, but that would not solve the problem of course. One could also
counter that the organization responsible for executing the law should
choose an interpretation, which would result in closing the open norm. But
this will not be desirable in all cases; in such cases human judgement will
remain necessary. Our application -- as many others in the past -- solves
the issue by presenting open evaluative terms to the user.
Background information should help the user in deciding these issues.
In a way, this argument is related to the attitude of the legal experts who
focus on the rare exceptions when validating our application. The general
idea seems to be: There is no such thing as a clear case! Theoretically this may be
true, but in practice the vast majority of legal transactions never becomes
a case; they are solved by the parties. Of the remaining set that comes to
an arbitrator or judge, again the majority merits no legal debate whatsoever
(H. Hart. The concept of Law, Clarendon Press, Osford, 1961). Of course, the target population of the
LSC may need assistance with even the simplest of cases, and the employees
may need assistance with slightly more complex ones, but this kind of
support can very well be delivered by knowledge systems. One has to take
care that potentially dangerous cases are always being reviewed by a legal
expert as well. Protocols may take care of that, e.g. For all dismissal
cases make an appointment with one of the legal experts.
In the specific context of the LSCs one should also take into account the
specific characteristics of their clients. The problems of these clients are
not limited to strict juridical or legal ones. Sometimes it will not be
possible to achieve the desired result (e.g. in case of dismissal or
eviction) but the employee (or the application) can still explain the legal
and practical consequences of the case at hand. This social counselling role
used to be very important in the Legal Aid and Advice Centres and it will
probably remain important in the new organization. The LSC has chosen to introduce a multi-channel strategy, in which not just a
virtual office is created, but call-centre technology and personal contacts
will be equally important.
Examples
Case Study: The Legal Service Counter (in Dutch: Het Juridisch Loket)
In the Netherlands people with low income are entitled to receive legal aid. In almost every big city in the Netherlands centres for delivering this legal aid are present. Researchers of the Leibniz Center for Law,part of the University of Amsterdam, were involved in a very early stage of development. The involvement started with a meeting with the responsible Director for reforming these centres into a Legal Services Counter (LSC). He explained that this reform process had several aims, including improving accessibility, improving the quality and standardisation of legal aid throughout the country, and improving efficiency and consequently diminishing operational costs. To achieve this, he would like to turn the organization into a more service oriented one and use new technologies, like call centre technology and Internet.
The researchers of the Leibniz Center for Law explained what the current state
of knowledge management and supporting technology was and how it could be
used to support both future employees of the legal services counters as well
as their clients. The next step (still initialisation phase) was to write a
concept project proposal (not a project plan!) describing the approach that
would be taken in order to realise a system that would fit the specific
situation. Obviously the solution would have to cover all COPAFIJTH aspects.
A complicating factor was that this project should become part of a bridging
project which was already started. This super project was to cover all
aspects of reorganising the existing organization, including creating basic
technical infrastructure etc. while the level of services of the existing
organization should not suffer from the projects activities.
This is similar to rebuilding the super market without closing the shop down. This is very hard to do. A reorganization often makes productivity drop and costs rise initially.
Before writing
the project proposal a list of requirements was handed over. This list
included technical requirements, such as the kinds of software that should
be used etc., but also the parts of the organization that should be involved
and what their intended role in the future would be. Therefore it was clear
from the beginning which part of the organization would be responsible for
testing the system, which department would be responsible for maintenance,
etc..
After the proposal was accepted we could
start the project start-up. Before describing that phase we will first
explain a bit about the solution we had in mind (and finally realised) and
its' context.
That context is a development called eGovernment. This development started
when governments became aware the potential use of the internet. The
internet has become an unavoidable means of communication and together with
mobile phones established an enormous market growth. The internet hype that
started in the nineties of the last century was caused by the opportunities
that were seen to use this communications facility to create new forms of
services (so-called e-services). Successful applications can for instance be
found in postal order business where different products are offered, varying
from books to computers systems.
But also governments have discovered the internet as a powerful means to
communicate to its citizens. This development became known as eGovernment
(while business models where businesses use the internet as a commercial
channel is called eBusiness). In the Netherlands as in other European
countries citizens can e.g. send their tax returns via the Web,while a number of Dutch cities support
electronic requests for a housing permit. International studies however show that both citizens and businesses are
not yet satisfied with the level of support offered by their governments
(see e.g. M. Botterman. E.Ettedgui, I. Graafland and A.Ligtvoet. Citizens and e-government: An international comparison. In: Electronic Government, Second International congerence. EGOV2003. Lecture Notes in Computer Science, Springer, 2003). The same study shows that the Dutch
government is not playing a leading role in using internet for providing
e-services.
High volumes of electronic documents might have become available via the Web
due to measurements of the Dutch Government, but citizens don't consider
this to be a service to them. Most citizens are relative laymen in the legal
domain and therefore don't want access to legal sources. They rather want
answers to questions like I want to rebuild my house by extending it with
a garage, is that allowed? or I want to close a contract for this
pension arrangement, is this pension arrangement acceptable according to the
tax law (which will make the premium paid deductible from the Dutch wage
tax; J. Breuker. On Legal Information Serving. In: C.Grutters, J. Breuker, H. van den Herik, A. Schmidt and C. de Vey Mestdagh, editors, Legal Knowledge Based Systems: Information technology and law, pages 93-102, Koninklijke Vermande).
This type of questions can be answered by so-called knowledge-based systems,
sometimes made available on the Web. We will describe the specific features
of these systems and the way to design them in detail in one of the next
chapters. An example of such applications is the life insurance application
of the Dutch Tax and Customs Administration. That application calculates the
amount of money that can be deducted from the wage tax. The knowledge that
is put in that (and other knowledge based) application(s) springs from the
regulations that are related to the legal problem to be solved, completed
with expert knowledge (especially needed to resolve legal interpretations).
The Knowledge Management System
When citizens are involved in legal procedures they similarly want to be
able to present their case and subsequently receive advice or a judgement
about it. Typical cases citizens might want to be advised about are divorce,
coping with rental debts and being fired. Citizens are likely to rely on
trade unions, consumer organizations and law firms for legal assistance.
In the Netherlands, citizens belonging to the lowest income categories are
entitled to legal aid. When we started the project that help was given by
Legal Aid and Advice Centres (Bureaus voor Rechtshulp), governed by the Legal Aid Boards (Raden voor de Rechtsbijstand). These
Legal Aid and Advice Centres were to be replaced by the LSC. While the old
centres could handle client cases all the way up to the court room, the new
organization is meant to focus on first legal aid. Cases that are too
complex or not within the aims of the LSC, should be forwarded to other
organizations as soon as possible. It was foreseen that the employees of the
new organization will gradually have a different background than the present
ones. The level of legal expertise will probably diminish in the future, at
least in depth. The typical LSC employee will be a generalist more than a
legal specialist. Therefore the Legal Aid Boards wanted the proposed
knowledge management solution to support (future) employees and clients of
the LSCs in solving legal problems.
One of the components of the proposed knowledge management system is a
knowledge management application called clarification of legal questions(vraagverheldering in Dutch). This knowledge-based application is part of a virtual front
office that is aimed to automatically support legal aid as much as possible.
The prospective users are both clients and employees of the LSCs. The
information stored within that application and the way this information can
be accessed is designed for reuse. Therefore the application's
functionality supports the physical and the virtual office equally.
Basically the system offers the following functionalities:
- Clarification of a legal assistance request by the client;
- Legal advice to the client.
One of the aims of the LSC is to enhance accessibility. Furthermore the
first virtual client contacts should form a basis for creating an electronic
client file which will be used for more elaborate forms of assistance.
An equally important goal is the reduction of the operational costs of legal
aid by reducing the number of physical contacts with clients (and
consequently by reducing the number of staff as well as their educational
level and the related labour costs).
The use of internet for establishing contacts with the LSC system clients could
have big impact on the future level of easy accessible legal aid for the
target group of the current Legal Aid and Advice Centres.
We will describe the development of this knowledge management application
from different perspectives, focussing on the organizational perspective,
because it is easy to imagine that the impact of the organizational change
was to be quite dramatic for the employees. This would of course have its
impact on the design teams.
The Project Startup
The proposal contained a phase in which the project environment and the
existing situation were explored. This stage served many purposes. First of
all the information that was available from the initialisation phase was too
limited to base a detailed project plan on. The general direction was clear
enough but since many Legal Aid and Advice Centres existed, all having
different cultures, it was necessary to have a grasp of the difference
between the future users of the system, their current problems, their
expectations etc.. For this purpose we visited some of these Legal Aid and
Advice Centres.
Secondly we used these visits to explain about our intensions, the general
direction of the project and the contributions that we expected from the
future users that were also to be involved in the role of domain expert,
writer of documentation, tester of the system etc.. We asked representatives
of the organization if the would like to commit themselves to certain tasks
(although their management already promised that they would be available for
the project, we wanted to be sure that they really wanted the project to
become successful). For the same reason we visited other departments in the
organization with which we would co-operate during the project.
We consequently set up a kick-off meeting with the project members and created a project
plan. The fact that this project was part of a bigger project and that some
sub-projects already had started had some advantages. We could e.g. use the
communication channels already available (e.g. by the reports of meetings
with the project managers of the different sub-projects), and the future
users already were told about the general picture of the organizational
change.
Designing the Application
The general idea behind the knowledge management application is to
standardise in large extend the client handling process. To achieve this,
the knowledge that is proven to be useful is modelled and made available
through a knowledge based system. The aims of this application, called the
application for clarification of legal questions, is to support employees of
the LSC to determine the legal question(s) behind the posed problem. Based
upon the legal questions identified this way a standardised series of
products should be offered.
The functionality described here has great impact on the existing working
procedures. Especially the discretionary power of the frontline workers is
limited due to this highly standardized client handling process. Especially
the legal experts that used to handle cases up to the level of court
procedures might experience deterioration of the level of expertise
needed for the task. To prevent resistance against change we designed a new
task for these experts. In the future situation their task would be focused
on keeping up with knowledge developments in their legal domain and
translating this expertise into the knowledge component that contains the
systems' knowledge. In order to enhance this type of knowledge creation,
thematic knowledge groups were to be designed. Other tasks for these experts
are specialist support in the back office processes and in training and
coaching inexperienced new staff.
The experts were involved in designing the knowledge based system. We set up
expert sessions with them and asked them to decide on a suitable
categorization of the legal domain. We also elicited their knowledge about
prototypical cases. This way we identified the most suitable service to their
clients given a certain category of legal problem. A more detailed
description of this knowledge acquisition process is given in another
section of this book. Important to mention at this point is the impact that
this process has on the experts involved. By exchanging their knowledge and
having discussions about the best way to design the system (e.g. discussing
what would work and what not) and making their requirements explicit, a
shared conceptualisation of the domain was created. The experts could also
gradually build their expectations and adapt their working procedures to the
new way of working.
Since these experts had hardly an idea of the
technological possibilities to support their future work we chose to work
with a rapid application development strategy, i.e. after each session with
the experts a new version of the system was build and shown to the experts
in the next session. This way the experts were not only able to give better
feedback, but they could also easily adapt their mental models towards the
new system. In the short cyclic approaches such as the rapid application
development strategy followed here the design and realization stage are
inseparable.
The application that we created leads the user to an increasingly detailed
description of a legal issue by letting him choose between a number of possible
answers to a question or by asking for specific answers to a question
(e.g. At what date did the contract expire). This way the user can work
his way to questions that have a one-to-one relationship with a set of
products of the LSC. These products could be information products, for
example an electronic brochure on alimony payments, but also a referral to a
lawyer or another organization than the LSC, or an appointment for an
extended (face-to-face) consultation with an LSC employee. The LSC products
can be categorised in three types: information, referrals or
appointments.
The design of the clarification of legal questions module was guided by
the following considerations:
- It should serve as a kind of check list for the LSC employee or client;
- The user is not obliged to answer questions or to be forced to answer them in a specific order;
- Easy problems can be handled quickly, more complex problems should allow for a more detailed exchange of information (cf. JURICAS advice systems that allowed `deepening' at certain moments; C. van Noortwijk, P.A.W. Piepers, J.G.L. van der Wees and R.V.D. de Mulder, The juricas-system: new applications and future development. In ICAIL '91: Proceedings of the Third international conference on AI and Law, pages 201-206, ACM Press, 1991).
Typically, the user of the application, especially the LSC employee, already
has a general idea of the legal domain to which the question belongs.
Therefore we present an overview of the legal areas the user can choose from
(left column in figure 3.1, in Dutch). Some legal areas however are rather
broad and therefore a further division in sub-areas is necessary. After
choosing a legal area, the user can select a sub-category by picking it from
a list. In some cases a problem can be related to more then one legal area.
In that case the user can select more than one area and switch between them
as he or she likes. Answers to questions are globally available, so users
never have to answers questions more than once; these answers will be reused
when relevant for other legal areas (Assuming the questions and
answers have the seem meaning in the other area).
Figure 3.1: Subcategories of legal domains in the application
Explanation of figure: The
user first makes a choice for a certain legal domain and next refines
his/her question by selecting one of its sub-categories. Here the user has
selected Rent/Let as main category and can now choose between House
exchange, Termination of tenancy by owner, Is the tenant obliged to
evict the apartment? and termination of tenancy by tenant.
While the user provides answers to the questions posed by the system, potentially relevant information and other products appear (see figure 3.2 at the right side of the screen). As long as the system has not concluded these products are certainly relevant, a question mark is presented in front of them; otherwise a red exclamation mark will be shown.
Figure 3.2: Question answering in the application
If the user is not able to provide an answer to a question the user may
choose unknown (in Dutch onbekend). The system then responds by presenting a list
of questions that together, when answered, will provide an answer to the
original question (see figure 3.2).
The user may change the answers to questions at any time, as long as this
does not lead to inconsistencies in the data given. Should an inconsistency
arise, the user is told he cannot change the answer because of this reason,
and all questions that are involved in the inconsistency are indicated with
a red triangle in front of them. These inconsistencies may also arise from
answers given in other legal areas.
At any time the user may decide to end the question answering dialogue and
continue with either one of the presented products, another legal area, or
to submit the gathered data to the rest of the system and e.g. plan an
appointment with a lawyer. The user can also get an overview of all answer
provided during the consultation session. These answers can be stored on
request and reused in succeeding consultations. This might be useful if the
user wants to temporarily terminate the session and restart it again, e.g.
after collecting some relevant data.
If the client is not an anonymous contact, and further action is taken, the
client data will be stored in a small electronic file. This e-dossier can
later on be used during subsequent consultations or by the lawyer who is
going to handle the case. Figure 3.3. presents a schematic overview of the flow
of data through the system.
Figure 3.3.: Data flow in the application
The description of the functional design shows that we decided to build the
system in such way that the dialogue with the user allows them to follow
their preferences to a large extent, although the paths from legal problem
to solution is standardized. This approach has also the advantage that the
impact on communication process with the LSC clients is as less disruptive
as possible. It is important to stress that the users of the system can be
the LSC clients or an employee of the LSC. The latter can have a dialogue
with the client in a face to face consultation, but also over the phone.
Especially a phone contact (call centre) is demanding a rather flexible
dialogue, because the client can't see that the employee of the LSC is busy
trying to find out the legal problem by using a computer interface. In some
cases a client has more then one legal problem, but some elements of these
problems may have impact on elements of others, so we designed the dialogue
in such way that we can prevent repeating questions. These factors (and
others like using standard data entry modalities) are determining factors
for the systems usability. The usability of a system is a key factor for the
willingness of users to accept the system and therefore crucial to
implementation.
We stated before that one of the aims of the application is to streamline
and increase uniformity of the client handling processes. Clients are to
receive legal advice as efficiently as possible. Consequently, the
application should play a central role in the client handling processes of
the organization. The creation, maintenance and control of the knowledge
(models) is in an approach as depicted of utmost importance. It will be
necessary to adapt handling strategies from time to time, e.g. as a result
of changed legal procedures or changes in the law. The system should
therefore be rather adaptive and both the time needed for adapting the
system as well as the costs of maintenance play an important role. Maintenance
is in fact one of the biggest parts
of the total costs of ownership, or TCO. Besides
this it would be desirable if small changes could be implemented by the
domain experts themselves rather then involving knowledge engineers to do
the implementation for them. This has implications for the way in which we
structured and represented the knowledge contained in the system. These
aspects will be discussed in a next chapter.
The experts' role was limited to:
- Determining the derivation path from legal problem to service
- Determining the question texts
- Determining the texts used for explanation (or giving the reference to the relevant documents containing this information).
An example of an explanation text is:
The period of notice is three month plus one year for every full rental year, with a maximum of six months. This is also valid if the tenancy contract contains a different clause, such a clause is illegal. (SOKI; BW7 art. 271, sub 5b).
(A frequently consulted source for the employees of the Lscs is the Almanac for the Social Bar (Almanak voor de Sociale Advocatuur (SOKI)); the other reference is to the Dutch civil code).
An explicit connection to external sources is important from the perspective
of maintenance, because when the law changes the systems that need to be
adapted are much easier to trace.
The users also define the selection lists that are presented in the dialogue
and from which the user of the system has to select (most questions
correspond to Boolean attributes but nominal attributes are also frequently
used).
Furthermore (without going into too much detail here) the knowledge used for
reasoning is separated from the representation in order to make adaptation
by the user easy. This way the users can choose and adapt the `language' of
the interface, thus allowing them to adapt the system to their language
culture. This way we can also have several (personalised) interfaces, it
would even be possible to have several language versions (e.g. a version for
the Dutch and a version for the English language).
Testing the Application
We mentioned before that since we used the rapid application development strategy the design phase and realization stage were inseparable. The next phase testing the application is always a very exiting phase for the design team. The different components the system consist of not only have to work separately but also when they are `glued' together. By work we understand, both in technical as well as in a functional sense. In other words, the system should work without problems and it should do what it is supposed to do. In this section we will focus on the content of the knowledge base, since this is the most significant part of the knowledge management solution. The knowledge base in this case had the form of a rule set, but the general structure of the rule is an if -then construction).
A rule set should be tested by a verification and validation process.
Verification, which means in this context checking for internal consistency and correctness, is
supported by automated tools. Validation, which means in this context checking whether the rules are
correct from a functional (in this case legal) perspective and checking whether
they comply with the organization's aims, has to be done by human experts.
Earlier studies show that not all knowledge representation formats can
easily be validated by non technical human experts (rule sets are rather
hard to validate by non technical experts, while decision trees with the
same meaning are much easier to validate (see e.g.
T. van Engers, L. van Driel and M. Boekenoogen. The effect of formal representation formats on the quality of legsl decision-making. In: T. Bench-Capon, A. Daskalopulu and R. Winkels, editors. Legal Knowledge and Information Systems, Jurix 2002: The fifteenth Annual Conference, pages 63-71, Amsterdam 2002. IOS Press). Sometimes it therefore is necessary to
transform the knowledge representation into a better testable form (of course
you then have to be able to guarantee that the new knowledge base
corresponds exactly with the original one).
As is the case for designing the knowledge base, testing the knowledge base
is also best done with a group (i.e. at least more than one) of experts. The
reason behind this is that sometimes the expert proves to be not an as good
expert as believed (the other real experts have the role to expose the
non-expert. Secondly if the knowledge base would contain errors you can
immediately try to find a remedy (as stated before we used a rapid
application development strategy). So in this case all question trees were
validated by a group of LSC legal experts and their comments were used
to adapt the rules when possible and desirable.
The latter deserves some
explanation. That change requests can not always result in actual changes in
the system for technological reasons or limitations in time and budget is
obvious. But can a change request be undesirable?
Yes, for two reasons.
First of all, the application was not intended to solve all legal subtleties, even if such a level of support were possible. The main goal was to
support the majority of cases (the standard or prototypical ones) and to
serve as a kind of checklist for the employees of the LSCs or their clients.
This checklist can prevent users from making mistakes and present solutions
that otherwise could be easily overseen. Experienced lawyers that are
validating the application sometimes focus too much on exotic legal
exceptions and consequently want these incorporated in the system. If these
requests would be honoured, the system would still not be finished, but it
would also be much harder to maintain and difficult to explain to less
experienced users. Secondly, the aims of the new organization are quite
different from the old one as we have seen. The legal experts are all coming
from the old organization and consequently are used to a working routine
that is quite different from the new one.
The final validation, of course, is in actual use of the system. All software
developed for the LSC was tested for several days by users from the
organization under the guidance of an external auditor. The latter had the
job to give advice to the customer on whether to discharge the project team. Of
course testing the system continues when the system is used in practice, but
we then call it evaluation.
As an implementation strategy the system was rolled out at two LSC offices first,
while only the functionality for the employees was activated. The aims of
this prudent strategy is to allow the employees time to get used to working
with the system and spread the possible risks (as stated before the change
had to be implemented with as less as possible disruption). These early
adopters can be used for the next stage in which the system is rolled out to
others. These future users can be invited to have a look at those early
adopter units so they are mentally prepared when the system is rolled out in
their own unit.
Conclusions Example LCS
We developed the application described before within the context of an organizational change programme. The aim of that programme was the introduction of a new model of interaction between the organization and its clients that should reduce operational cost while maintaining a certain minimum level of legal support for their target group, i.e. relatively poor citizens. The business model consequently would have to change from a craftsmanship oriented one to a system level bureaucracy. According to Zuurmond (A. Zuurmond and I. Snellen. From bureaucracy to infocracy. In J. Talyor, I. Snellen and A. zuurmond (editors), Beyond BPR in Public Administration: Institutional Transformation in an Information Age, pages 205-255, Amsterdam, 1996. IOS Press) such a bureaucracy can be characterized by the concentration of the experts that are responsible for system's design and the reduction of skills in the front-line of the organization. In big governmental organizations like tax administrations an important argument in favour of the latter is the need to guarantee equality before the law. This equality can best be achieved by a high level of standardisation. Economy of scale can furthermore help to reduce operational costs.
The employees of the newly created LSC organization come for a substantial
part from the Legal Aid and Advice Centres in which craftsmanship was highly
appreciated. In the new situation the level of professional freedom
(especially for the high-skilled legal professionals) will be limited and
this of course was (and still is) a source of resistance. The role of the
experts that used to work in the organization's front line will change.
These experts in the new organization will have the role of system designer,
a role that may require different skills.
We needed not only the full cooperation but also the commitment of the legal experts, since in the end it is their knowledge that needs to be captured, their tasks that have to be supported, and it is their working environment that had to be (re)designed. These experts were very aware that by cooperating they would help to create a new way of working, a way many of them had serious doubts about when the project started. We were confronted with this tension during the whole development process. In such a complex political situation a successful implementation (including organizational change) can only be achieved if the process is managed by a leader with a clear strategic vision and the power and willingness to overcome these problems and who can arrange a change process in which the different stakeholders can gradually adapt their mental models.
In this specific case as in many others, there were many stakeholders within
and outside of the organization responsible for getting the job done, all
having their own political agenda. We experienced again that dealing with
the political agenda was as important as dealing with the more technical
issues. Sometimes the design team was used to communicate the organizational
change to the employees of the new organization, consequently bringing the
team in a situation it wasn't suitably equipped to handle.
To cope with the complexity of the new organization's design (including
supporting systems) the design process was decomposed. Different
functionalities were to be realized by different organizations. These
organizations needed to develop ways of cooperating while aiming at an ever
moving target. A lesson that apparently has to be learned over and over
again is that developing a shared conceptual framework (i.e. a means of
communication, a commonly shared strategy etc.) is time consuming and needs
specific management attention (see also T. van Engers and E. Glassee. Facilitating the legislation process using a shared conceptual model. IEEE Intelligent Systems, Januari, 50-57, 2001). With
respect to the design of the LSC organization a start has been made, but the
turnaround still has to be completed, not only technically and
organizationally speaking, but especially mentally (i.e. the organizational
change will only be successfully implemented in full extend, if a
substantial part of its employees have adapted their mind set to it, which
is not the case yet).
When designing knowledge management systems, (re)designing the organization
and paying attention to organizational change, coping with power conflicts amongst others is very important. These power conflicts (potentially
dangerous for the project's results) occur easily, because knowledge
management systems are very intrusive to organizations and the way people
work within them.
It is obvious that the knowledge contained in those systems has to be
frequently updated. By structuring and explicitly describing the knowledge
necessary for the organizations' operations we can reduce both maintenance
costs and improve the organizations' adaptability in the same time. Knowledge
management remains the key to organizational success.
Organizational change issues however, shouldn't be neglected. Especially
when developing highly intrusive technology such as the knowledge based system
support that was created in the LSC project, one might expect resistance to
change. Dealing with this is as important as managing the technical aspects
of a project and preparing implementation should start from the very
beginning of knowledge management projects.
