Project Organization and Roles

Abstract

The ability to carry out Enterprise Modeling in practice requires not only the basic methodological knowledge covered in Chaps. 7 and 8, but also suitable project organization in the enterprise in question. This chapter describes how a 4EM project should be set up in practice, including both the roles involved in the project team and the organizational prerequisites in the enterprise in question. It also illustrates typical project phases and discusses options for implementing the participatory approach. The principles and recommendations presented here apply to other EM approaches that share the same overlying philosophy of multi-perspective and participatory modeling.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

The ability to carry out Enterprise Modeling in practice requires not only the basic methodological knowledge covered in Chaps. 7 and 8, but also suitable project organization in the enterprise in question. This chapter describes how a 4EM project should be set up in practice, including both the roles involved in the project team and the organizational prerequisites in the enterprise in question. It also illustrates typical project phases and discusses options for implementing the participatory approach. The principles and recommendations presented here also apply to other EM approaches that share the same overlying philosophy of multi-perspective and participatory modeling.

The chapter begins with an overview of the project phases in Sect. 9.1 and then deals with the most important phases in Sects. 9.2–9.8. Change management in EM projects is briefly discussed in Sect. 9.9.

9.1 Overview of Project Phases

The 4EM approach is not merely intended to produce an enterprise model, but to serve as the basis for problem solving, organizational development, and change decisions. The success of the method and its result also depend on how the approach is introduced in an enterprise and how the modeling process is carried out. This chapter will set out guidelines for introducing and using the approach in an organization. Even though this approach and its predecessors have been used and documented for several years, the practical implementation of a method by its users (e.g., work distribution, procedure, component selection, etc.) changes over time. These guidelines should therefore be considered as knowledge that is subject to constant development and expansion.

Among those who have used the 4EM method in past projects, the method has a reputation for offering the following benefits :

• The method gives structure and comprehensibility to the modeling process

• The method adds clarity and rigor to the model representation

• The method supports organizational learning and helps to preserve organizational knowledge

• The method helps to make changes and restructuring in an organization easier to achieve

In practice, it has also been observed that 4EM is difficult to explain due to its high level of flexibility in individual cases, because false expectations can be raised particularly at the start of a problem solving process. The risk of “overestimating and simplifying” often leads to the belief that the 4EM approach can “magically” solve hard problems. Despite its versatility, it is important to ensure that the various phases and modeling activities are consistently integrated when using 4EM.

This chapter will primarily describe the structure and progression of an EM project in an organization using the 4EM method. In doing so, it will set out prerequisite, goal definition, and communication guidelines for conducting a modeling project, as well as basic principles for organizing modeling projects.

A modeling project usually involves a number of phases . The next sections of this chapter explain the typical main phases of such a project as well as the issues and problems that arise in the process, and propose suitable solutions:

• 1. Define scope and objectives of the project (Sect. 9.2)

• 2. Plan for project activities and resources (Sect. 9.3)

• 3. Plan for modeling session (Sect. 9.4)

• 4. Prepare modeling session (Sect. 9.5)

• 5. Conduct modeling session (Sect. 9.6)

• 6. Analyze and refine models (Sect. 9.7)

• 7. Present results to stakeholders (Sect. 9.8)

Figure 9.1 describes the project phases in the form of a process model. It should be considered as a stereotype process, which needs to be adapted to fit each individual project because in real-life projects the actual steps and information sets might differ slightly. It is also possible that additional steps are needed, e.g., to ensure integration with other development projects or to involve a broad group of stakeholders.

Fig. 9.1

The EM process model showing processes and information sets (Persson and Stirna 2010)

The EM process follows generic principles of carrying out projects for various purposes. This is because we strongly believe that aligning EM activities with the general project activities improves stakeholder acceptance of the modeling way of working.

Table 9.1 shows how different actors are involved in the steps of the EM process. More about the actors involved can be found in Chap. 10.

Table 9.1 Actor involvement in the EM process steps

Throughout this chapter, references will be made to processes and information sets in this model. In the beginning of each second level section, an overview of the subprocess in question is provided, before it is discussed in more detail.

9.2 Define Scope and Objectives of the EM Project

We assume that the EM project is commissioned either as a result of selling consulting services or that another in-house development project has decided to address a specific problem area by a modeling approach. In either case, there usually exists an initial problem statement (information set 1 in Fig. 9.1) and an organizational actor that will benefit from solving the problem—the problem owner.

At this stage the problem owner and the EM project leader should discuss the problem to find its boundaries, what the likely ways of solving it might be, and what the expected outcomes are. This would form a project definition (information set 3 in Fig. 9.1). In this process model we assume that the organization has already assessed its suitability for using the participative approach to EM, but if it has not been done, or some doubts arise (e.g., a strong sense of hidden agendas) then the EM project leader should assess the situation in the organization.

The problem should also be assessed for being suitable for EM. More about assessing the organization and the problem at hand is available in, e.g., Nilsson et al. (1999), Persson (2001), as well as Stirna et al. (2007). If the organization or the problem is found to be unsuitable for EM, then the problem owner and the project leader should choose other ways of solving the problem, e.g., by the consultative approach or by brainstorming. When dealing with complex and/or wicked problems (Rittel and Webber 1984) it might be difficult to formulate a clear problem definition. In such cases the project might organize a modeling session with an objective to find out what the real problem is and how to tackle it.

9.2.1 Establishing the Project in the Enterprise

Conducting an Enterprise Modeling project only makes sense if it meets with approval and support in the enterprise. This requires executives or budget managers and those responsible for the divisions in question to be convinced that the project is beneficial to their areas of responsibility as well as to the organization as whole. In order to justify the human and monetary resources required for a modeling project, it is often necessary to discuss the expected benefits during project initiation .

The following aspects can generally be used when highlighting benefits:

• The project creates value that contributes to the overall success of the enterprise

• Cost savings through process efficiency and structural improvements

• Enhanced competitive advantages

• More efficient IT support for critical business processes

• Improvements in the documentation and transparency of organizational processes

• Expansion into new markets

Preparation for a 4EM project should involve not only executives, but also employees, specialists, and user groups. When changes are initiated that affect our status quo, it is human nature to be rather cautious and often distrustful if we cannot assess the potential changes. It is therefore important to establish trust by briefing those concerned according to their initial situation and interests—in other words, motivation points should be produced for the parties involved. These motivation points may take very different forms depending on the individual’s role and position. For instance, executives are motivated more by the project’s value contribution to the overall success of the enterprise, but staff members may instead be motivated by work process improvements which they have initiated. The enterprise stakeholders who are relevant to the project should (be made to) feel confident that the modeling project is not a threat to their employment or positions, but in fact is intended to support and improve day-to-day work. Concrete examples from previous successful projects within the enterprise or elsewhere should be used as a rationale.

Stakeholder analysis is intended to assist in identifying project participants, their interests, and potential motivation points. To this end, the following questions should be answered:

• Who has an influence on the project?

• Who is affected by it?

• What expectations does the individual/group have of the project?

• What is the attitude towards the project (positive, negative, or neutral)?

• What degree of influence does the individual/group have (low, medium, high, or crucial)?

• Are there are any competing projects (in terms of the results, budget, or political power)?

The potential effects on those involved should be classified according to level (none, low, medium, high, or very high) and type (positive, negative, or neutral).

From the project goal, the time frame for implementing changes, and the stakeholder analysis, it is possible to identify the project type or the significance of the project for the enterprise. Firstly, enterprise policy projects and strategic projects can be distinguished. Both are highly interdisciplinary and interdepartmental, and hence offer potential for conflicts. Enterprise policy projects are often marked by a specific task (e.g., software rollout), while strategic projects may feature alternative scenarios (reorganization) and a longer duration. It is also possible to identify operational and innovation projects, which, as a rule, are less socially complex (e.g., due to being limited to certain departments or teams) and have shorter implementation timescales. Operational projects have a very limited solution scope and usually are rather short.

At the end of the preparatory phase, the project team should be able to answer the following questions:

• Who instigated the project and why?

• Who is and who must be informed of the project goals/the problem at hand?

• Who is needed to initiate the project and who is impacted by the effects of the project?

• Have the answers to these questions been documented in a project description and approved in a project order by the appropriate managers?

• Are there any aspects of the project that cannot be mentioned or documented openly (pointing to hidden agendas)?

9.2.2 Project Goal

There can be a wide variety of reasons for using an EM approach to solve a certain problem in the organization. Regardless of the reason for the project or its trigger, however, the project goal should be defined at the start of the modeling project. This also involves establishing the expected outcome, or what the result should be at the end of the modeling project—“What problem is the method intended to solve, and what benefit will it provide?” In the course of the modeling project, the project goal is generally further refined by a Goals Model and made more concrete by other sub-models, such as modeling goal-related business processes.

Definition of the project goal requires some initial knowledge about the nature of the problem at hand. 4EM provides methodological support for this through goal/problem modeling. By analyzing the problems that have been observed and identifying subproblems and the affected or associated processes and organizational units, it is necessary here to determine which parts of the enterprise should be included in a model of the actual situation because they are affected by the problems or the solution, and what areas need not be investigated. Although the goal/problem model is the focus here, it should be supplemented by initial versions of the business process model or stakeholder/resource model.

The process of defining the project goal could take the following form:

• Preparing for goal and problem modeling by selecting participants from the enterprise (enterprise employees who know both the problems that have emerged and the processes and organizational units affected), filling the modeling team roles (particularly the role of moderator), agreeing deadlines, and booking rooms. At this stage, the employees selected should be the project commissioner or other relevant stakeholders on the management/problem owner level because the focus of modeling at this stage is to negotiate the project goal with the commissioner.

• Conducting a modeling session to create a goal/problem model, often using conventional tools and plastic sheets. This stage includes identifying relevant business processes (without refining them) and relevant stakeholders or resources

• Editing the results after the session

• Holding a workshop with the modeling session participants to present the results and discuss their factual accuracy

• Deriving and documenting the project goals together with the modeling workshop participants and those responsible for the pre-project planning in the enterprise

The following example is intended to illustrate how a project goal can be gradually edited and thus refined by using various sub-models.

Example 9.1. Gradual Development and Refinement of a Goal Model

The case study company A4Y wishes to develop a strategy for its long-term development of their human resource capital. This application will initially concentrate on the Goals Model.

• What are the company’s long-term goals in general?

• Which goals regarding human resources are recognized and how are these goals related to the company’s long-term goals?

• Which problems are experienced and which external threats and constraints do exist, etc.?

This type of analysis and goal modeling may very well also introduce the need for improved conceptual analysis and modeling of concepts essential for the problem at hand, e.g.,

• What do we mean by “human resource”?

• How can we measure the current status regarding human resources?

• What do we mean by “competence” and how do we measure competence?

• What kind of competencies may we need in the future regarding the stated goals?

The above questions will help identifying concepts and creating a Concept Model. The analysis of goals and concepts may also lead to the development of a Business Processes Model.

• What qualification measures will be offered to the employees, how can these measures be booked and how are they implemented, and what support for competence development is realized by these processes?

• Which capabilities are required for implementing and performing these processes?

• What kinds of future competences are required to reach the goals defined?

• Should we be interested in developing a future “system” for developing and maintaining human resources in the company in the future? New types of positions, roles, and skills may require developing further the Actors and Resources Model.

Regarding the information system support, the overall question to be addressed may be formulated as: “Does our current set of information systems satisfy the need for information support for the long-term strategy of the company, and—if not—what has been changed to arrive at a satisfactory solution?”. This question involves, more or less, all the models described in Chap. 8. First, the goals of the future situation must be analyzed, as described above. Next, based on this set of goals, the set of business rules and processes must be examined and redesigned. A new Actors and Resources Model will most probably be developed. The established information systems must be described with their properties in a Technical Components and Requirements Model (TCRM version 1). Afterwards, a model of the future set of required technical components and their requirements (TCRM version 2) must be developed based on documented goals, rules, processes, concepts, and actors for the future business system. A comparison between the properties of the current technical system (TCRM version 1) and requirements of the future set of information systems (TCRM version 2) provides here the basis for analyzing needs for changes and further developments. Clearly, in many cases different alternatives of future information systems may be analyzed.

The above example shows that a relatively unpretentious application case, like the strategy for long-term development of human resource management, requires different perspectives of the enterprise and nearly all 4EM sub-models. A 4EM project has to start from clearly defined scope, task, and expectations with respect to the results of the project. The tasks and expected results have to be clear to the stakeholders involved in the project. In this context, the following questions can support defining a project’s targets completely and concisely:

• What is the goal of the modeling project, i.e., which problem has to be solved and which goals shall be reached?

• What is outside the scope of the project, i.e., what is not to be considered within the project?

• Which benefits have to be reached at what point in time for what stakeholder group?

• Who is/are the target group/s of the project results? Who is the recipient of the final deliverables of the project?

• How does the project support the enterprise strategy and which goals are supported?

• Which priority does the project have for the enterprise?

• What is the intended time frame for the project?

• Which frame conditions, budget frames, and expectations exist with respect to the project?

• Which risks exist and difficulties have to be expected?

• Which milestones have to be reached and which deliverables have to be produced at what point in time?

In Chap. 8 we have formulated a set of general driving questions for each of the 4EM sub-models. The example discussed here shows more concrete operationalization of those questions with respect to the particular modeling problem. The modeling facilitator prepares an initial set of such questions during process 6 in Fig. 9.1.

There are two alternative views when it comes to defining the problem at hand. One stresses the importance of obtaining a clear problem definition, assuming that it is possible to acquire such a clear definition. The other assumes that clearly defined problems in most cases are illusions. Rather they are detected as the project progresses. This has to do with the fact that problems are different in terms of complexity.

Problem complexity influences the project planning in terms of necessary activities and resources. Three types of problems can be observed:

• Fairly simple problems

  These problems are possible to clearly define and they often have a perceivable solution. They do not require the coordination of a large number of different preconditions, activities, actors, and resources.

• Complex problems

  These problems have a fairly clear definition. They often have a perceivable solution, but they require the coordination of a large number of different preconditions, activities, actors, and resources.

• Wicked problems

  These problems are ill-structured. They have no clear problem definition and there is no way of measuring that the problem has been solved.

In case of simple and complex problems, planning of the project can proceed. Note, however, that the complex problem will need an experienced project manager and extra resources for coordination activities. If the problem is considered wicked, the project should be carried out in three phases:

• 1. A pre-study phase where 4EM modeling, particularly goal modeling, is used to negotiate agreement to the main scope of the project. This is described in the example above.

• 2. A negotiation phase, where the actual project is negotiated and planned. Since a wicked problem comprises many unknown factors, the customer must be made aware of them and related risks.

• 3. A completion phase, where the defined problem is solved as best can be done. Preferably, the project plan should contain a number of evaluation steps, where the results of the project are continuously evaluated and the overall scope is reconsidered before continuing.

9.3 Plan for Project Activities and Resources

At this stage the EM project leader, problem owner, and facilitator plan specific activities to be carried out. This includes the overall number and schedule of modeling sessions, the issues addressed in them (information set 5 in Fig. 9.1), as well as indicating relevant domain experts to be involved in the modeling sessions later (information set 6 in Fig. 9.1). Additional issues to pay attention to at this stage are risk assessment, resource allocation, both for the modeling expert team and for the domain experts, and establishing project groups’ overall authority, i.e., mandate to solve the problem.

9.3.1 Project Activities

The exact activities of a modeling project should be set out in a project plan that identifies the modeling activities to be carried out and defines work packages from them. A work package groups together modeling tasks with related content and defines the deadline by which they should be completed, the necessary effort, and the result to be produced. The content relationships between work packages can be used to establish the order in which they should be handled, or whether certain work packages should be completed in parallel. This chronological order is defined in the project plan, which should also define the work package responsibilities. Further general information on project planning techniques and the definition and use of work packages can be found in project management literature.

The project goal determines what modeling activities are required in a project, and therefore also which work packages are needed. This means that it is impossible to generalize for all projects.

9.3.2 Project Organization

The project organization generally specifies what roles are involved in carrying out the project and what tasks and responsibilities these roles entail. Experience from previously completed 4EM projects recommends a project structure for Enterprise Modeling that contains both roles specific to modeling projects and roles that are generally found in project organization. The roles specific to modeling projects include the moderator and the modeling group featuring domain experts and method experts. General project organization roles are the project leader, the steering committee, the quality manager, and the reference group.

In a large-scale modeling project, the steering committee is the project’s topmost decision-making body, to which the project managers report. The quality manager’s role supports the steering committee by reviewing the project results. The project team may include multiple modeling teams. Each team should be led by a moderator and is also made up of domain and modeling experts. In addition to the modeling teams, there usually is a method manager, who is responsible for method and tool selection and coordination of individual activities. Reasonably large projects need a documentation manager who is responsible for documenting and versioning the modeling results.

In smaller projects, the steering committee is usually omitted. The manager that commissions the project within the enterprise, and the project leader who is in charge of the modeling activities frequently assume these duties. The domain experts involved in the modeling, rather than being specifically assigned to a separate role for the project, perform quality assurance. Tool and documentation management roles are also incorporated into the modeling team.

These project organization roles are briefly introduced below. Further information on general project organization roles can be found in the standard literature on this subject.

• Project management in large-scale projects often consists of two project managers: the manager from the commissioning enterprise, often called the internal project manager or customer representative, and the manager of the modeling activities, often called the project manager for modeling.

  Jointly, these two project managers are responsible for:

  • Project planning

  • The day-to-day project management (incl. supervision of time plans, resource consumption, and costs)

  • Reporting to the steering committee

  The internal project manager is responsible for and has to coordinate

  • Provision of documents required for the modeling project

  • Selection of domain experts required for the modeling and releasing them from their regular duties to allow their participation in modeling activities

  • Communication of project goals, expected results, and achievements within the enterprise

  • Providing facilities and technical infrastructure for the modeling activities in case they are performed within the enterprise

  The project manager for modeling is responsible for

  • Planning and organization of all modeling activities following the selected method

  • Reaching high-quality modeling results, e.g., by organizing workshops for presentation and validation of the models and results

  • Assigning modeling experts to roles and to modeling activities, and

  • Achieving the defined project goals and results.

  In small to medium size projects the project manager for modeling may also be fulfilling the role of modeling facilitator.

• The steering committee typically includes members from different areas or departments of the enterprise who are involved in reaching the project’s objectives or have an interest in the value the project intends to create. This could be heads of departments, budget responsible managers, or employee representatives. The steering committee will typically be responsible for:

  • Supporting and “selling” the project within the organization, i.e., internal communication of project goals,

  • Deciding on the final project plan,

  • Obtaining official acceptance of milestones and deliverables based on the results of quality control measures.

  • Deciding about changes in project plans in case of new requirements and delays in project work,

  • Supporting the acquisition of resources and assigning them to the project, and

  • Deciding about resource allocation

• The quality assurance is responsible for systematically ensuring the quality of project results. This includes:

  • Definition of quality criteria for the different kinds of project results (see Chap. 12 with respect to the quality of enterprise models),

  • Development of a quality plan (which quality result will be evaluated at what point in time according to what criteria?)

  • Documentation of the results of quality control activities,

  • Reporting to project management and steering committee.

• The reference group typically consists of domain experts and experienced employees of the enterprise who are familiar with structures and processes in the enterprise. The reference group is responsible for:

  • Supplying domain knowledge, knowledge about organization units involved, expertise, and information,

  • Examining and evaluating the results, and

  • Integration of modeling results of different teams into a consistent whole.

• The modeling group are the persons participating in modeling activities, i.e., there can be different modeling groups for different modeling activities depending on the purpose of modeling. The tasks of the modeling group are to:

  • Actively participate in the modeling sessions,

  • Contribute with domain knowledge,

  • Ensuring that the models contain relevant and valid domain knowledge, and

  • Assist the facilitators with structuring and describing the models.

  The composition of the modeling group should meet a number of criteria:

  • There are persons from various parts of the enterprise enabling the broadest range of knowledge and views to be available,

  • The group has adequate domain knowledge,

  • The group has the necessary authority to suggest organizational change and

  • The group comprises enthusiastic, open-minded, and cooperative people.

• The facilitator ’s task is to direct and guide workshops and modeling session, which includes several tasks:

  • Prepare modeling sessions

  • Manage sessions in accordance with the method used

  • Manage the modeling process

  • Make sure that all participants are included in the modeling process

  • Make sure that the goals of the modeling activities are reached

  • Support the modeling group in acquiring knowledge and ideas from each other

Like other types of projects, a modeling project can also be unsuccessful without sufficient resources and skills. The individuals involved must be expressly allowed time to participate. Moreover, provisions with regard to modeling tools, e.g., modeling kit, rooms, IT, and (if applicable) external domain experts, must be organized and made available by the enterprise.

The project managers and participants who are involved in the modeling process must know and understand the goals and expected results of the project. The purpose, goals, and scope of the project must be documented by the time that the project organization and project plan are set, which should also include the allocation of resources (staff, responsibilities, time, money, IT, and other resources). The type of quality assurance with regard to the quality of the results, adherence to milestones, and the validation process must also be defined, generally in a separate quality assurance plan. The outcome of the quality assurance activities should also be documented.

Once the project organization has been established, it should be possible to answer the following questions:

• Who is directing the project, and who is part of the project team?

• Have the initiators, commissioner, other authorizers, committees, and reference groups been identified, informed, and involved?

• Have the modeling group participants been identified and involved?

• Are the necessary resources available?

• Has an appropriate reporting system been defined?

• What modeling sessions should be conducted, when, with what goals?

• What skills and which domain knowledge are required?

• What roles are required for which of these sessions?

The project organization has to be established on the basis of the project goal, which means all of the roles required for the project are filled. The roles that are generally required in participatory modeling are covered in Sect. 9.5. The project plan for the modeling project is created, including the schedule and an estimate of the effort involved. Provision of the necessary resources must be agreed with the enterprise. Tools and other necessary aids must be made available or procured.

A typical mistake in planning for resources in an EM project is to underestimate the resources needed for preparing as well as documenting and reporting on modeling sessions. We suggest distributing effort as follows: preparing for modeling sessions ~40 %, carrying out modeling seminars ~30 %, and documenting/reporting ~30 % of the total effort (Persson 2001). This distribution of resources is only given as an indication; depending on the project’s aim and duration they may actually vary by up to 10 %. For example some very short projects might not require extensive documentation and more complex projects might require even more in-depth preparation.

9.4 Plan for Modeling Session

The first modeling session in a modeling project simply must not fail. This is the time to show to the participants that it is worthwhile to invest time and effort in participating. At this stage there are no second chance, i.e., there is no chance to come back for a second try after a failure. Every outcome that can be perceived as failure by some modeling participants will significantly hamper the future modeling efforts. Preparing for the first session is therefore of utmost importance.

The objective is to plan a specific modeling session, i.e., to set its overall objective and questions to be addressed (information set 8 in Fig. 9.1). Existing models produced in previous modeling sessions of the project or earlier projects in the organization and/or other supporting information might also be analyzed. The initial list of relevant domain experts (information set 6 in Fig. 9.1) should be analyzed and candidates to involve in the modeling session should be selected (information set 9 in Fig. 9.1).

The modeling facilitator usually needs to obtain additional information to learn more about the organization and the background of the problem at hand (Process 4 Gather and analyze background information). Some of this information can be gathered from documents, e.g., policy documents. Also, essential enterprise data, e.g., balanced scorecard data, can also be useful. However, the most powerful instrument in planning for the session is interviewing the domain experts that are selected to participate in the modeling sessions.

The candidate modeling participants (information set 9 in Fig. 9.1) are interviewed individually in order to learn more about their views on the problem at hand (information set 11 in Fig. 9.1) and to assess the participant’s potential contribution at the modeling session (information set 12 in Fig. 9.1). A benefit for the candidate is that he/she is able to learn about the project and the upcoming modeling session in advance. In some projects it is beneficial to interview more people than the participants to be involved in the modeling sessions, because this allows the project team to learn more about the organization and, indirectly, to spread the word about the project and the coming change in the organization.

9.4.1 Setting the Goals for the Session

A modeling session is often one instance of series of modeling sessions, which all have their own goals, that are intended to contribute to the overall modeling project goal. The important thing here is that there is a goal for each modeling session. Just gathering a number of people in a room and starting modeling without a clear goal for the session and a plan for the flow of activities within a session will in most cases be disastrous and a waste of effort and resources.

Setting the goal for a modeling session is part of the planning for the overall modeling project. It should be clear what should be produced in the session, which other project results that are input to the session, and how the result of the modeling session is intended to contribute to the overall project.

9.4.2 Selecting the Right Domain Experts to Participate in the Seminar

Domain experts should be familiar with the problem assigned to the project. Sometimes it may be beneficial to have both the “producer” and the “consumer” side represented to broaden the view. In some stages of the project, it may be necessary to associate specialists in certain areas to the project. These specialists may have the role to suggest organizational or IT solutions to satisfy specific goals stated (e.g., reengineering of some business processes, or development of some types of IT solutions).

Who the right domain experts are depends on the goal of the session and which models that are to be produced. For example if a goal model is to be developed the right domain experts are those who are directly involved in, or have knowledge of, decision-making and goal formulation at the pertinent level of the organization, whether it be operational or strategic. If the goal is to restructure a process it may not require involvement by formal decision-makers. In all situations, however, it may be necessary to change members of a group as the discussions and models move from one area to another and require people with different knowledge.

9.4.3 Composing the Modeling Group

The composition of the modeling group, i.e., the participants in a modeling session, is instrumental to the achievement of the goals for the modeling session. It should therefore be carefully composed based on the goals for the session. It is highly desirable that modeling experts have a strong influence on the composition of the modeling group. Otherwise the members of the modeling group will not be able to take full responsibility for the results of the modeling session.

An ideal modeling group has the following characteristics:

• The knowledge represented in the group covers the full scope of the problem domain as well as detail and overview.

• The group is authorized to have an opinion about the problem at hand and to suggest a suitable solution to the problem.

• The number of modeling participants is 4–8.

• The group consists only of people that are expected to actively contribute to the modeling work.

• The group consists of people without personal animosity between themselves.

The ideal number of participants is 4–8. If there are less than four people the discussions tend to become less productive because the number of viewpoints becomes too small. If the number of participants exceeds eight some individual participants often tend to become less active. It also becomes difficult for the facilitator to manage the group process. Having more than ten people in a modeling group may work if the facilitator is very experienced and the plan for the session allows the facilitator to manage the session in a rather strict way. Alternatively, two modeling facilitators can support each other during the session and take turns as facilitator and observer. In such situations it is a good idea to plan for frequent short breaks to enable the facilitators to refocus and remedy any problems.

The “direction” of the analysis, i.e., if the analysis concerns the current state of affairs or the future state, also defines requirements for the group’s composition. People deeply involved in a process can often describe the current state very well. However, when moving towards the future state, a different type of domain experts may be needed, i.e., visionary and creative people who are able to look at the process from a more holistic perspective e.g., how it relates to other processes and changes outside the organization.

When composing the group it is essential to make sure that the domain experts will be given sufficient time to participate in the session. This is related to the issue of resources, in particular with regard to management support and time resources.

Another aspect to make sure is that the domain experts participate with the intention of actually contributing to solving the problem at hand. For example having people in the group who are there to learn or observe will hamper the modeling process. “Everyone contributes!” should be the motto of a modeling session.

The status or rank of certain stakeholders can also restrict the possibilities of composing a group that represents the best available competency. Some people may sometimes falsely be considered highly competent both by themselves and others. To exclude such persons can sometimes be difficult.

9.4.4 Interviewing Domain Experts

Before planning for the modeling session it is strongly recommended to interview the domain experts individually. In most cases, one hour is a reasonable amount of time to spend on the interview, at least to begin with. In preparation for follow-up modeling sessions it may be necessary to carry out additional shorter interviews, if deemed necessary for preparing a session properly.

The domain experts need to be prepared for what will happen during the session. This is particularly critical in organizations where the employees are not used to modeling in general and particularly to modeling in a group session. Lindström (1999) recommends that before the modeling session each individual modeling participant has to:

• Understand the goal of the modeling session,

• Agree upon the importance of this goal,

• Feel personally capable to contribute to a positive result, and

• Be comfortable with the rest of the team (including the facilitator).

There are several goals with these interviews. They fall into three categories related to the problem at hand, the motivation of domain experts, and the group process.

9.4.4.1 Goals Related to the Problem at Hand

In order to prepare the modeling session in terms of issues to cover, driving questions, etc. the modeling expert needs to understand the views of the modeling participants regarding the problem, particularly, focusing on goals and possible obstacles to achieve the goals. Their views regarding how other stakeholders might think about the problem at hand are also important. This might reveal potential conflicts of interest and also personal animosities between stakeholders and stakeholder groups. If resolution of potential conflicts of interest is essential for solving the problem at hand, driving questions can be posed to the group during the modeling session, in order to make the conflict surface. However, bringing personal conflicts to the surface during a modeling session should be avoided.

9.4.4.2 Goals Related to the Motivation of the Modeling Participants

In order for the goals of the modeling session to be accomplished, the group process should have the highest possible quality so as to capitalize on the fullest potential of the competencies in the group. Therefore, one goal is to prepare the domain experts with regard to what will happen during the modeling session and why. It is also necessary that they understand in what way their particular competency contributes to the goals of the session and of the project, i.e., why they are important. This clarifies what is expected from them during the session and motivates them to participate actively. To ensure motivation, the attitudes of the domain experts towards the modeling method and the participative approach should also be investigated.

9.4.4.3 Goals Related to the Group Process

The personalities in a group govern how the facilitator runs the modeling session. The facilitator will e.g. need to neutralize dominant persons and to encourage more introvert persons in order to accomplish full and consensus-driven participation from everyone. The facilitator will also need to ensure that the models produced are the result of consensus between the views represented in the session. Therefore, the modeling expert/facilitator will try to understand as much as possible of each individual’s personality during the interview. She/he will then be better prepared to facilitate the communication between the members of the modeling group.

Below we suggest a sample of interview questions assuming a company named COMP, a division of the company named DIV, and a particular function of DIV named F. It is assumed here that the purpose of the project is to analyze F and suggest different possible improvements.

After an initial round of mutual presentations, the modeling expert should explain the role of the interview and what will happen in the modeling session. Here it is important to pick up any signs of the domain expert feeling uncomfortable and discuss it up front, e.g., starting by saying: “I see that you are a bit uncomfortable with what I say. Can you comment?” In general it is important to make it clear that the information given by the domain expert will only be used to prepare for the session, e.g., for formulating driving questions. It is unprofessional to make remarks in the modeling session about who said what in the interviews. The following questions about the problem at hand could be considered, using our example:

• How would you describe the function F, its role, and current activities within DIV and within COMP?

• Describe some, in your opinion, important issues within F to be addressed in the next 3–5 years.

• Describe some problems currently experienced by DIV with the function F.

• Give some long-term as well as short-term goals of the function F.

• What makes F a necessary function within DIV?

• What are, in your opinion, the current strengths and weaknesses of function F?

• Which opportunities exist in the area of F?

• Which external constraints would you like to mention regarding F?

• Which external trends may influence the operation of F? How?

• Which management should be particularly concerned with the operation of F?

• Which important decisions, with long-range consequences, will we have to make within a year regarding F?

• Do you see any problems in carrying out these decisions?

• Which opinions do you think other stakeholders could have about the problems of F?

• What should we not talk about at the modeling session?

The interviews give the project management and the facilitators an improved view of the persons who will participate in the modeling sessions and of their visions, problems, hopes, prejudices, and fears. This gives the facilitator a possibility to plan how to start the modeling session, how to conduct it, and how to handle possible upcoming situations. The interviews may give some hints on organizing the first modeling session depending on situations and opinions revealed in the interviews.

9.5 Prepare Modeling Session

A detailed plan for the modeling session (information set 14 in Fig. 9.1) is elaborated by analyzing the background material and findings from the interviews. This plan should include specific objectives of the modeling session, specific questions to be addressed, preliminary set of enterprise models to be developed (e.g., goal models, concepts models, actor models), a set of driving questions for starting the discussion, and the expected level of model quality. The modeling facilitator should also assess various risks and scenarios of how the modeling session might develop. For example what are the topics that the participants will not talk willingly, what are the topics that might lead the discussion astray, what can cause conflicts, and how to act in case of a conflict. This should be done in collaboration with the problem owner and project leader. The practicalities of the meeting (information set 13 in Fig. 9.1) should also be organized, which includes location, agenda, travel plans, etc.

The first modeling session should be organized in a way that promotes concentrated work. This may be achieved by convening in a special room not usually used by the participants or even at other premises, e.g., a conference facility. Such a choice of location may provide a more relaxing atmosphere and make interruptions unlikely. Needless to say, mobile phones should be switched off.

Apart from four to eight participants, only a limited number of others should be present:

• One or two facilitators. The number depends on the perceived complexity of the issues to be discussed as well as the number of participants.

• The modeling project leader as an observer who needs an overall knowledge of the modeling work

• A secretary as an observer with the following tasks:

  • To take care of the practicalities of the plastic sheet, arranging coffee breaks, etc.

  • To document the process of the modeling session.

9.5.1 Setting up the Room for Modeling

The room must contain at least one large (3 m × 2 m) wall clear of all decoration, to attach a plastic sheet on. There should be precisely enough chairs and tables for the participants. It should be large enough so that nobody could “hide” or make him or her unavailable. There should not be any distractions such as refreshments, telephones, etc.

9.5.2 Equipment

In the room there should be the following equipment:

• At least one plastic sheet

  • Thick

  • Two meters wide, on a roll

• Pens

• Non-permanent to enable erasure from plastic sheet

  • Medium point

  • At least one for each participant

• Paper

  • Preprinted with components’ names

    • (a) Each component type has a different color to enable easy identification

    • (b) An A4 page cut into four quarters gives a satisfactory size

  • A4 papers of different colors

• Wet rag

  • To wipe off pen drawings from the plastic sheet

• Adhesive putty

  • Two small blobs attached to the back of each piece of paper ensure that these stay attached to the plastic sheet when required while allowing them to be easily transferred

• Scissors

• An overhead projection machine or a beamer connected to a laptop

  • For presenting introduction material and other information necessary to run the session

9.6 Conduct Modeling Session

The modeling session is conducted according to the plans made initially. Here we will not describe details of how a modeling session is conducted. Recommendations of what to do and what not to do are included in Sect. 9.5 and, for example, in Stirna et al. (2007), Sandkuhl and Lillehagen (2008), Jørgensen (2009), Stirna and Persson (2009), and Willars (1999). The tangible outcome of the modeling session are the models produced (information set 16 in Fig. 9.1) and an additional list of actions for implementing the decisions made during the modeling session (information set 15 in Fig. 9.1). Additional intangible outcomes of modeling are participants’ improved understanding of the problem area and a firmer commitment to the decisions made (Persson 2001; Lindström 1999).

After the modeling session it is recommended to write minutes of the meeting (information set 17 in Fig. 9.1) which includes the models as in the state were produced at the modeling seminar and action list. At this stage the models should not be more refined because the main purpose of this activity is to send notes to the participants, which might also serve as a reminder of the actions that they have agreed to be responsible for.

In the following, we provide a set of practical tips to help the modeling team to effectively carry out the session.

9.6.1 Introducing the Session to the Participants

A short introduction is to be given of each of the following:

• All those present

• The agenda of the session

• The topic(s) for discussion

• The ground rules for modeling

  These are necessary since these are not self-evident and are necessary for maximal productivity. They explain the accepted social interactions and means of furthering creativity:

  • Everybody participates—no spectators

  • Everybody contributes constructively—differentiate between person and subject matter

  • Everything of importance is written down—talk disappears, the plastic sheet counts

  • Better overexplicit than implied

  • Better half-done here and now than completely brilliant next week

  • Write complete sentences rather than keywords

  • Listen to each other and think individually

  • Build further on each others thoughts

  • Strive for balance and consensus in the result

  • Search after missing threads of thought

9.6.2 Stimulating and Structuring the Modeling Activity

The goal of EM is, of course, not only the Enterprise Model as such. The Enterprise Model is just a description and representation technique. To obtain an improved understanding, to solve problems, and to develop the enterprise we should be directed by a critical and analytical study of the Enterprise Model and its internal relationships. This should be based on good understanding of the principles of EM as they have been presented previously in this book. It is particularly important that relationships between sub-models of 4EM are used as drivers in this work. This may be achieved, to some extent, with the aid of driving questions of the following type:

• Is each goal supported by a process in the Business Process Model? If not, why not?

• Should we then introduce such a process?

• Who in the Actors and Resources Model should be responsible for this process?

• Are they already responsible for a similar process or is there someone else?

• Should we invest in a new resource to help us run this process?

• Does this resource need a new or improved information system?

• Can we identify in the technical and requirements model, the requirements for the information system?

• Are there business rules that may put constraints on the requirements?

• Do we have a common enterprise definition of what these constraints and requirements mean, in the Concepts Model?

By searching for relationships and inconsistencies, and discovering gaps, we can increase our knowledge and understanding of the enterprise. The search for knowledge must be made on an individual and group basis in the context of the situation, given the particular intentions of the participants. 4EM will help you in the right direction, by giving you the graphical, structured representation technique in the form of the Enterprise Model, making the cognitive process of analysis easier. Hence, the lists of driving questions mentioned in previous sections are not complete, but only examples that should be further expanded when applicable.

9.6.3 What to Avoid

There are many pitfalls when one is involved in the communication of ideas between humans, which is what we are dealing with. In the specific case of 4EM these include:

• Avoid beginning modeling with long explanations of abstract concepts.

• Begin with well-known practical or physical activities, processes, or goals.

• Avoid, if possible, creating unstructured models. This does not mean that the initial model must always be structured. It can be done in such a way that at first, modeling components are simply grouped together according to some criteria and relationships are introduced later in the modeling session. In fact, the session often involves idea generation and restructuring iterations.

• Conduct additional restructuring and clarification activities as soon as possible after the modeling session; otherwise a lot the information inherent in the unstructured model will be forgotten.

• Avoid having few-worded formulations of modeling components that are not intuitively understood.

• Do not have goals that do not contribute to the overall objectives of the enterprise.

• All goals must be connected so that they contribute to each other. No loose ends should exist.

• Avoid composite statements that have many in and out relationships so that they do not allow for easy understanding and analysis.

• Try to break down statements to the last point at which they are relevant to the issues at hand.

• Avoid detailing attributes before an overall conceptual structure is established.

• Not all attributes are relevant.

• Do not verbalize what is apparent in the model.

• Avoid having concepts that you are unsure why you have them.

• When choosing particular words, confusion and missing concepts may be avoided by creating new words.

9.7 Analyze and Refine Models

Enterprise Models created at a modeling session usually need further refinement in terms of presentation and layout, as well as content. The result of the modeling session should also be analyzed with respect to the objectives of the session and the project. This either leads the project team to a conclusion that the expected result is achieved and can be presented to the organization (information set 18). Otherwise the team identifies a set of issues for further development and modeling (information set 19 in Fig. 9.1) and proceeds with planning subsequent project activities (process 2 in Fig. 9.1). In many cases information sets 18 and 19 are reports of the project activities.

After the first modeling session, the modeling experts document the models using a computer-based tool (Chap. 5). The first session is often mainly a brainstorming activity. Hence the state of the model is such that:

• It is lacking a clear structure, making it difficult to get an overall picture.

• There are redundant components, for example, there may be two goals stating roughly the same thing.

• There may be missing components

• Relationships are lacking showing how components are connected to each other

• The terminology written by domain experts may be ambiguous.

The overall objective of structuring and analyzing the results of the first session is, therefore, to “make sense of the mess.” It is to systematically go through all the models, components, and relationships and make them presentable as a basis for further deliberation by the participants in the following session. That is, by clarification, abstraction, structure, simplification, derivation, deduction, and induction.

To achieve progress in terms of structure and clarity of the models the following strategies can be useful:

• Organize the model to make it more readable

  For instance, crossing arrows should be reduced and grouping of components can be made.

• Introduce relationships

  The models are given meaning by drawing relationships so that, if possible, all components in the models are connected to at least one more component. Implicit, undesirable, or overlapping relationships may be discovered and adjusted. Missing components may be discovered. Since the analysts may not have the requisite knowledge, it may be necessary to consult with stakeholders to get a better understanding of the relationships.

• Clarify terminology

  Concepts, terms, and abbreviations that are unclear or ambiguous need to be clarified. Domain experts often need to be consulted to explain and define concepts.

After the models produced in the modeling session have been documented it is time to make sure that they live up to expectation and correctly capture what has been modeled, i.e., they need to be accepted by the modeling group that participated in the session. This can be done in at least two ways that we discuss here: by interviewing stakeholders and by organizing walk-through sessions.

Interviewing stakeholders may seem as a feasible way ahead, since it is easier to schedule an interview with a person than to organize a session with several people. Particularly if the people concerned are managers. However, this often proves to cause problems later on. One important purpose of having a walk-through session is, like in participative modeling session, to ensure that different views on the problems are represented in the same room, allowing for quality enhancing discussions between domain experts.

At the walk-through session, the analysts present work done since the first session and the rationale behind the work and enhance the models. The session should aim to achieve all the following:

• Review the work from the first session

• Make corrections and/or additions to the models and descriptions

• Narrow the field of discussion and specify the domain

• Expand previous models

• Suggest further work and future directions

The resulting models from the first modeling session should be presented to the modeling group precisely as it was. To present the refined model to the modeling group requires careful planning. The group must be able to trace the results of their efforts, from the original plastic sheet model through the analysis stage to models presented at the next stage, the walk-through session. They must be able to recognize what they have done in the modeling session. A description must acknowledge and give credit to the first session by a verbal description of the results.

At this stage, models produced by computerized tools have replaced models on plastic sheets. Since it is impractical for up to eight people to gather around a normal sized computer screen, the model should be projected using a beamer. As well as the computerized presentation equipment required, all the equipment necessary for modeling as mentioned in Sect. 9.5 is also needed. This may entail the use of a larger room or possibly two rooms, one for projection and one for modeling.

A large screen allows all the participants to view the computer-generated models. In theory, continued modeling directly on the screen together with a tool expert is possible. However, this is not advised as the focus of the group may move from the issues to be discussed to small improvements and/or technical finesses of the modeling tool.

The presentation is a balancing act. The analysts must actually do an analysis, while at the same time not discarding the group work that has been. When interpretation, change, or deletion is done, it must be explained and justified. This is to ensure that the group will continue to be motivated to contribute. Otherwise, credibility of the analysts and eventually the models is lost.

The results of the first walk-through should be a validation and adjustment of the models being discussed.

Sometimes the modeling project is very small. In fact, sometimes one modeling session is enough. In most cases more sessions are needed to achieve the modeling project goals. Then the process starts all over with preparations and carries through to validation of models.

9.8 Present the Results to Stakeholders

The modeling project ends with presenting the results to the problem owner and relevant stakeholders. A part of this presentation is decision making on how the results should be implemented or taken up by the organization. It might also be that the stakeholders identify issues that are not resolved and require further development (information set 19 in Fig. 9.1).

The EM process we have outlined ends when the problem owner and the involved stakeholders feel that they have a result that can be implemented. In practice the EM project results will most likely serve as input for another development project, including an IT or IS development project.

The EM process described in this section may appear easy to conduct on the outset. In reality, however, there are many challenges to succeed and pitfalls to avoid, particularly in the project preparation phase (processes 1–6). Much of this knowledge is related to organizational and social issues and hence is not easily formalizable.

9.9 Change Management in Enterprise Modeling Projects

Enterprise modeling projects, particularly in development situations, typically go through a series of modeling sessions where modeling of the current state of the problem is followed by definition of change requirements. These change requirements are the basis for modeling future state models, which are then used as “blueprints” for development of, for instance, business processes and/or information system.

9.9.1 Modeling and Analyzing the Current Situation

As a rule, all 4EM sub-models are required to comprehensively model the current situation. Each sub-model is developed in an iterative process, which may include the following steps:

• Modeling starts in a moderated modeling session. Additional sessions may be required for extensive processes or structures

• The results of the session(s) are documented in the chosen modeling tool

• The models created with the tool are presented at a workshop with the participants from the initial modeling session(s) and checked for factual accuracy

• The models are enhanced in workshops of this kind until they reach a state of elaboration that the modeling group and the project manager are comfortable with moving onwards to implementation of the model.

• The relationships between the various sub-models are reviewed and expanded if necessary

9.9.2 Setting Out Change Requirements

Modeling the current situation will have identified the processes, structures, systems, or rules that must be changed in order to remedy the problems that have occurred. There often are several possible ways how changes can be made, and conflicts between enterprise goals often become clear in the goal/problem model. This means that the urgency and priority of the set goals must be decided here before creating a future state model, and an agreement must be reached as to which of the viable potential changes should be chosen. If it is not possible to decide which potential changes are the most suitable ones based on the goal priorities, multiple versions should be developed in the stage of future state modeling. The result of this step, which generally takes place in a joint workshop involving a representative of the commissioning party, the project leader is to obtain an agreement as to which versions should be developed in future state modeling.

9.9.3 Creating Future State Models

The future situation that should be brought about in order to remedy the observed problems is generally defined based on the actual situation. This step therefore mostly involves refining the models of the actual situation so that they describe future processes, structures, systems, rules, and concepts. Models need only be completely recreated in the event that changes are required due to the introduction of completely new processes or structures in the enterprise, or due to radical alterations to processes or structures.

This step produces a description of the enterprise’s future situation in the form of a future state model. The future state models can then be used as a “blueprint” for organizational change or as part of the specification of requirements for any necessary software developments.