Situational Factors

The Situational Factors Affecting the Use of EKD

Project factors Organisational factor Problem factors Human factors Other Factors

The use of the EKD Methodology is strongly dependent on a large and complex set of situational factors such as:

Quality assessment of EKD models

The quality of a specific instance of EKD Model can only be measured against the requirements which were defined for its creation and the expectations of the prospective users of that model. These requirements and expectations regard the product (the model) as well as the process by which the model was created.
The ideal situation before entering into any type of modelling work is that requirements and expectations on the modelling result are well known and agreed upon so that the most suitable approach can be selected for the purpose. This is probably seldom the case. However, let us assume that we know the requirements and expectations and hence have chosen the “perfect” method to match them. Can we then be assured that the quality and utility of the result will be high? Probably not. The utility of an EKD Model is clearly influenced by the quality of the model in question. The quality of a specific instance of EKD Model is influenced by a number of factors. The contents of the meta-model of the EKD Modelling method being used is one of them, but not the most important. Much research is being put into the development of new and more elaborate meta-models, in an attempt to achieve Enterprise Models with a high degree of expressive power. Experience has shown however, that management of the specific modelling situation has a far greater impact on the quality of a model.
Below we briefly discuss some situational factors which we have found strongly influence the "quality" of an EKD Model.
These factors fall into four categories:

Influences caused by project factors
Influences caused by the actual type of organization involved
Influences caused by the actual type of problem involved
Influences caused by human constraints
Other Factors

[Top of Page]

Project factors

EKD Modelling is always performed as part of a larger context of some sort. This, for instance can be a business development project, a systems development project or a project concerning both. Projects have constraints which influence the quality of an Enterprise Model. We are here specifically concerned with resource constraints and access to management support.

The common resources of any kind of project are money, time and personnel. If we want to use EKD Modelling and we want the models to be reliable and detailed enough to be of use to the project, we need to put some time and effort into modelling work. However, time is a scarce resource for most projects today. In order to fulfil high expectations on the quality of Enterprise Models there must be an awareness amongst decision makers that modelling must be allowed to take some time. Of course results can be achieved also with quick and “sketchy” modelling efforts, but the requirements on such models can not be as high as for models which have been given time to develop and “mature”. In order to model at all, we need access to people who can do the work, which means that we need method experts as well as domain experts. For high quality results we do not need just any people. We need the right people and they can be difficult to get access to.
Another aspect of the project factor is management support. If there is a high degree of active support for a project from management, resources normally follow. However, support for the whole project (where EKD is used as a component of work) does not automatically mean support for the EKD Modelling effort.

[Top of Page]

Organisational factors

Every situation where EKD Modelling is used is unique and one aspect of this is that organisations are never identical.
The type of organisation we deal with is one important influence on the process of EKD Modelling. Participative methods can be more or less suitable, depending on the structure of an organisation. In hierarchical organisations, for instance, it is more difficult to achieve reliable modelling results from participative modelling. People in these organisations seem to be reluctant to really open up in groups, where their superiors or subordinates are present. Mixing groups is much easier in a non-hierarchical organisation.

The culture of an organisation can also influence the modelling result. If, for example, the people in the organisation are not used to working in groups in a participative way, they would feel awkward in such a situation and not be able to contribute as intended. Other cultural factors are the degree to which participants independently "dare" to make decisions, implement them, and take the consequences.

[Top of Page]

Problem factors

The type of problem that we try to apply Enterprise Modelling on, also has an influence on the quality of the resulting models. We can categorise problems as follows:

“Solvable” problems, complex or simple. For this type of problem there is perceived solution and it can be defined if reasonable resources are allocated.
“Wicked” problems. For this type of problem there is no clearly perceived solution and even if reasonable resources are allocated a solution may not be found or only limited parts of the problems are solved.

If we are faced with a “solvable” problem we can perceive the future solution and judge EKD Models according to this perception. If we are faced with a “wicked” problem we do not have a “stopping rule” in the form of a perceived solution. Hence the participants must rely on their own judgement for deciding when to stop modelling. This requires highly skilled participants, modelling experts as well as domain experts.
Another problem factor is the degree of agreement among participants on the nature of the problem and on the goals for its solution. A high degree of mismatch between participants means more time for negotiation and conflict resolution. This is time-consuming, which means that we use up resources. The more serious impact is, however, that if we can only achieve a minor degree of agreement we might not be able to solve the problem at all.

[Top of Page]

Human factors

Factors which concern the knowledge and abilities of human beings, i.e. the participants of modelling sessions, have perhaps the greatest impact on the result of modelling.

Technical knowledge

By technical knowledge we here mean domain knowledge as well as method knowledge. That access to domain knowledge is critical for successful EKD Modelling as well as for systems development is a well known fact. Therefore, we confine our discussion here to method knowledge.

The utility of the EKD Modelling method and hence its resulting models is very much judged on the basis of how it is used. This makes the user of a method a critical success factor. To discuss this issue we first need to define the term “method user”. One obvious category is analysts, who in most cases do the actual modelling work and who, in most cases, also are the method experts. However, if we intend to perform modelling together with other stakeholders or to validate models with other stakeholders, these must also be considered to be method users.

What requirements can we define on an “analyst user” of a method? We can find two types:

1. Requirements on knowledge about the method. This means that the analyst user of the method must have a good understanding of the method. By good understanding we do not mean just an understanding of how the meta-model of the method is used for constructing particular EKD Models. It also means that in order to use the method as intended, a good understanding for the underlying philosophy of the method as well as for its modelling process is required.

2. Requirements on the ability to use the method. Having knowledge about something and being able to apply that knowledge are two different things. In our opinion access to skilled analyst users of a method is critical for the success and utility of EKD Modelling.

How do we obtain “analyst users” which fulfil both these requirements? Teaching the meta-model, the philosophy and the process is one step, but here we immediately encounter problems. It is very difficult to make a person really encompass the philosophy behind a method. When we learn new things we try to fit this new knowledge into the frame of our old knowledge. For a completely new idea to catch on we must rely on people’s willingness to accept and try out new ideas. We have trained people in the F3 Enterprise Modelling method as well as in the EKD Modelling approach. Our experience is that this issue is perhaps one of the more difficult aspects of a method to teach to someone. Regarding the second requirement, there can be only one answer, namely “learning by doing”. Reports from Enterprise Modelling method users as well as our own experience show that a trainee approach to teaching gives the best results.

What requirements can we then define which concern the "non-analyst user" of a method? It is our view, that the requirements defined above are not applicable to them, for several reasons. We find these stakeholders in various settings in the modelling process. Some participate in the actual modelling work and some do not. When they are not modelling participants, they are typically involved in situations where previously created models need validation or they may encounter EKD Models as part of a decision-making process. The issue of method training for this group can be approached in two ways; there is training or there is no training. We have experienced both approaches with regard to the EKD and F3 Enterprise Modelling methods. We have no evidence that one is better than the other. The modelling results achieved with method-trained participants have not been notably better than with participants which have not been trained. For other methods the difference may be more significant, but it is difficult for us to judge since we have not made any experiments with other methods.

Authority of involved actors

EKD Models make an important part of the decision process in the development process where they are used. Therefore the models must reflect the views of the key players within the domain in question. Preferably they will also reflect the views of the involved decision makers. If the actors involved in modelling do not have enough authority, there is a definite risk that the produced models will not be taken seriously by decision makers. The modelling effort will then have taken resources from the project in question and not produced results which contribute to the development process. Hence the effort will have been futile.

Social skills and consensus attitudes

If we choose to utilise participative group modelling as our way of working with EKD Modelling, the social skills of the participants, facilitators as well as of other stakeholders, become a critical success factor since the results rely on how a particular group of people function together socially. In contrast; in an interviewing situation we mainly rely on the social skills of the interviewer/analyst. Conflicts between individuals and groups of individuals within the group complicate the situation and this complication also affects the result of modelling.
It is not unusual, in hierarchical, authoritative organisations, that the participants behave radically different in individual interviews and in participative modelling sessions. Typically they are more outspoken and critical in private interviews. In modelling sessions, where their superiors are present, they tend to agree to almost everything what is suggested by the "boss". A situation like this makes it difficult to use interviews as reliable information for conducting modelling sessions. Models produced in such sessions merely reflect the view of one person, the boss.

Method acceptance and understanding

Let us imagine a situation where we can assemble the “perfect set of” stakeholders for modelling a certain problem, that we have the necessary resources, that the problem is “solvable”, and that the stakeholders agree on its nature and on the goals for solving it. We decide to apply a certain Enterprise Modelling method to the problem.

The successful application of a method on a problem is dependent on the acceptance for the method amongst the modelling participants. Previous, negative experiences of modelling with other methods may cause the participants to mistrust the technique and hence not to engage in the modelling effort. Too high expectations in the method's ability to solve the problem may also cause problems, maybe not during the first modelling session, but later in the process when more concrete results from modelling emerge. Modelling participants, facilitators as well as other stakeholders, need to properly understand the possibilities and limitations of a method in order to make the best use of the method and to produce useful models.

[Top of Page]

Other Factors

Existing organisational "vision" (none, limited, long-term, …)
Organisational "culture" (hierarchical, flat, network, …)
Organisational “maturity” of methods and method use (low, medium ,high, …)
Existing methods in the company and elsewhere having the same or similar scope.
Stakeholder qualifications and experience in modelling (none, low, medium, …)
Modelling stakeholder authority (low, medium, ….)
Type of “contract agreement” (in-house, consulting, etc.)
Type of problem (technical, economical, social, …)
Degree of clarity of problem (well-defined, wicked, …)
Scope of problem (limited, organisation-wide, …)
Degree of consensus and common view-points (in the organisation) of the issue at hand
Degree of consensus and common view-points (in the modelling group) of the issue at hand
Relevance of existing systems, components, or solutions
Urgency (or time available) of getting the problem analysed or solved.
Project resources and time available for method, training, use, and modelling.
Type of result expected (action plans, consensus and understanding, system proposal, …)
Type of services or products of the organisation (stable, changing, …)
External pressures and competition (known, possible to foresee, …

[Top of Page]