• No results found

Process view of IT consulting

In lack of a reference model or best-practices for information system requirements, we attempt to get insights from a simplified process view of the consulting business. There are more detailed reference process models available, for example a consulting process of a small business (Bruckman & Iman, 1980). However, our main focus is not on the client-consultant interaction. Instead, we attempt to capture the processes which are relevant for planning. The two models discussed further do not contradict one another or Bruckman and Iman (1980) and can complement this view.

3.5.1 Basic phase model

A basic phase model has been used by Nikolova, Reihlen, and Schlapfner (2009) for analyzing the interaction between clients and consultants, and could be adapted for disseminating the different needs and interests of actors in the consulting firm. The scheme consists of the following main components:

• Consulting practices • Communicating results • Coordinating expectations

The first three components constitute a process, whereas the latter is conducted in parallel with those. Acquiring projects describes the sales activities of general market- ing efforts and convincing potential customers of the consulting firm’s competence. During Consulting practices, consultants are working together with the client to analyze the situation, suggest solutions, and assist in implementing them. This sums up the main part of the project, until results are delivered. Finally, Communicating

results is the act of presenting the solutions, as suggested or implemented to different

audiences. During a project, consultants are coordinating expectations between themselves, several internal stakeholders, and the clients’ actors.

3.5.2 Phases of a governance theory framework

Niehaves, Klose, and Becker (2006) provide a more detailed phase model, which comprises the following phases:

1. Pre-Project System Analysis 2. Project Initialization

3. Problem Analysis

4. Solution to the Problem 5. Solution Implementation 6. Project Close

7. Post-Project System Analysis and Design

Within the Pre-Project System Analysis, the current situation is analyzed for speci- fying the project boundaries in preparation to contracting. Depending on the degree of required expertise, project managers and competence team members could be involved in this step. Project Initialization describes the activities of contract negoti- ation and the ‘launch’ of the project. Actors involved are a sales representative and typically leading representatives of the client. Further actors from the consultancy can be present. The steps of Problem Analysis, Solution to the Problem, and Solution

Implementation are activities of intensive interaction between consultant project

managers, other consultancy staff, and various client representatives. During Project

Close and Post-Project System Analysis and Design, the project results are evaluated

Acquiring projects Pre-project

analysis / Initiation Consulting practices Coordination

Maintenance, support

Internal

Management

Figure 3-5 Main processes of an IT consulting firm

3.5.3 IT consultancy processes

The aforementioned phase models, combined with further knowledge on other business activities of an IT consultancy firm, can be combined to a model of main processes, shown in figure 3-5. In the following, these processes are discussed.

In extension to the activities summarized by Nikolova et al. (2009) as acquiring

projects, it is likely to be common practice at consultant companies, that earlier

business relationships provide a reference, and therefore customers decide to contract without major marketing efforts. This step is not further referred to by Niehaves et al. (2006).

The Pre-project analysis and Project Initialization phases, as described by Niehaves et al. (2006), are mostly consistent with actions of Acquiring projects by Nikolova et al. (2009), where the outlines of the project are defined and negotiated with the client. Within this phase, preliminary project planning activities take place. Therefore, we can assume that mainly sales, project managers, and competence team members will participate.

What Niehaves et al. (2006) refer to as Problem Analysis, Solution to the Problem, and Solution Implementation, is corresponding with Consulting practices of Nikolova et al. (2009). This is the critical point, where efficiency of the consultant work affects the business performance, as described in section 3.2.1. It involves several iterations of planning and performance. Therefore, project managers and other consultancy staff will frequently interact with each other, monitor the progress, and readjust plans as necessary.

The phase of Communicating results, as described by Nikolova et al. (2009), and further divided into Project Close and Post-Project System Analysis and Design by Niehaves et al. (2006), are not discussed in more depth here. These phases are arguably essential for evaluating the project outcomes and and communicating them to the client, but more important in context of the relationship view, which is the

emphasis of both quoted studies. They are not likely to have any other implications for resource planning and allocation than aforementioned consulting practices. In parallel to the first three phases, the process of Coordinating expectations, as outlined by Nikolova et al. (2009) and encapsulated in all phases of the framework by Niehaves et al. (2006), has a different emphasis in our study: Rather than negotiating the process and outcome between consultants and clients, a system of internal interests of the multi-project organization is assumed. The parties involved in this negotiation are sales, project management, departments or competence teams (represented by a team manager), and the general management. This process is yet

to be defined further.

Finally, it should not be forgotten that an IT consultant business, within its area of expert competence, also contracts for reoccurring activities or has to perform addi- tional tasks for clients without direct reference to a project. These will furthermore be referred to as maintenance and support (see section 1.1.3.3 – Organizational structure

with project orientation). They should not be confused with the differentiation by

Nikolova et al. (2009) between exploitive and explorative consulting, which merely expresses the degree to which projects are based on established standard routines. In fact, we do not consider this set of fragmented activities as projects at all, since their repetitive character or unplanned occurrence contradicts the definition of project work (e.g. Project Management Institute, 2004). Nevertheless, they are a relevant factor in resource planning and allocation. The same applies to internal activities, which are not part of any project. These can involve staff training, fragmented internal research and development, or administration routines. General management decisions are reflected in a separate process.