De nition of base concepts

In order to describe the information to be exchanged within planning, ambiguous terms from the previous section 3.6.1 are discussed and defined in this section. They are used as underlying concepts for providing the information concepts, prior to presenting the process design.

3.6.2.1 Competence and skill level

The differentiation of competence is necessary, for appointing team members with tasks appropriately. What we refer to as competence, more narrow in comparison to common concepts (e.g. Cohen & Levinthal, 1990), is personal knowledge in a certain domain, providing a set of capabilities or expertise within IT, such as database administration (product-specific or -independent) or development in a particular programming language.

From the discussion in section 3.2.3 (Learning perspective), we also take into con- sideration that personal experience of employees in a particular competence field improves their performance over time, which we refer to as skill level. More precisely, we refer to the personal efficiency, in which the tasks are being performed, and not the effectiveness. Therefore, we assume employees with the same competence but different skill level, to be capable of ultimately performing the same task, but at different paces. This concept also implies that each employee has a set of multiple competences.

Skill levels are likely to be developed further and rise over time. While we expect it to be difficult to quantify skill levels, we might only find it necessary to point out relative differences as far as necessary for determining, who should handle time-critical tasks. This notion creates a more intuitive perceivable view, but also reduces the risk of ethically questionable personal efficiency measures.

3.6.2.2 Projects and project portfolio

In our case of an IT consultancy, projects are usually client projects in terms of the definition by the Project Management Institute (2004) and the process sketched out in section 3.5.3, but also internal projects are possible and taken into consideration during resource planning. Although project resource limits could be expressed in other ways than a financial budget, this is typically the delimitation as negotiated with the client. Another potential limitation are human resources, which is the main issue of the coordination activities.

The project portfolio (see section 3.4.4) is a managed set of projects, which are being planned and conducted simultaneously. Projects, which are partially or completely planned, but not sure to be performed, are referred to as potential projects. There can be multiple portfolios in a firm.

3.6.2.3 Tasks and activities

The total workload of a project should be divided into smaller units more suitable for planning. By the definition of the Project Management Institute (2004), single project time management does not include activities, which do not lie in the project scope. While this is quite straightforward for a project manager, we wish to maintain a holistic view on the organization along with maintenance, support, and all other activities. Therefore, we use a more abstract concept of tasks (also related to Platje et al., 1994) with less specifics of project management, although there are similarities to the above-mentioned definition:

Tasks and objectives are complementary and hierarchical elements. That means, a task is planned to achieve a defined set of objectives in- or outside of a project. It is divided into more concrete subobjectives and subtasks for more planning accuracy and better understanding. Performance of a (sub)task has one or more dependencies on other tasks, constraints, and workload for a certain competence.

The smallest subtask should be performed with specified prerequisites by a definite group or individual, where a further break down step would not be beneficial for planning purposes. This could also be seen in analogy to the work breakdown structure of the Project Management Institute (2004). However, decomposition into work packages is a highly variable and detailed issue of project management, which lies outside our scope of analysis. Thus, when we discuss task assignment and performance, we consider the smallest useful unit as given.

3.6.2.4 Priorities, time constraints, and exibility

We could consider projects as a whole and tasks (inside or outside of projects) to have a defined priority, which expresses a general sense of urgency. Constraints, as also used in project time management (Project Management Institute, 2004), could be used in addition to define certain frame conditions to be fulfilled.

Constraints can be expressed in many different ways. As examples which are commonly used in PMIS, a task could be directed to start not before a certain date (e.g. project kick-off), not end before a certain date (deadline), reoccur at least in a certain frequency (e.g. meetings, training), or not start before the end of another

certain task (see e.g. Harris, 2011). Additionally, constraints can also stipulate monetary boundaries (budget).

However, if there are many combined constraints, unreflected fulfilment of all such conditions can limit planning capability more than intended. For example, moving a task beyond a deadline for the benefit of progress on another project for the same client would possibly only be a matter of discussion with the customer. Therefore, although it is difficult to quantify violations of such ‘soft’ constraints, it should be done as far as possible to facilitate prioritization. The sequential dependency of one task on another can also be a constraint, but ‘hard’, as it cannot be resolved without changing the contents of the task.

In our meta-design, we suggest different concepts for different purposes. Every project and task, where appropriate and feasible, should be assigned constraints, but with three varying settings:

• constraints, which have either a priority, or quantification on violation; • constraints, which are not directly quantified or prioritized, but instead consider

the dependency of another task;

• constraints, which are not prioritized or quantified; instead the priority is expressed for the task.

Constraints of once-occurring tasks should either be quantified or be assigned a priority level (e.g. “critical”, “high”, “normal”, “low”). A constraint for reoccurring events is usually impossible to quantify on violation, since missing out on fulfilment often has no direct severe consequences (e.g. staff training can be rescheduled). Therefore, instead the task itself should be assigned with a priority, which expresses the meaning and urgency for the firm (e.g. “strategic”, “critical”, “normal”). For reducing complexity, a task with further dependent tasks should not directly ‘inherit’ quantification and priorities of those; however, the decision-maker should be made aware of critical dependencies.

It should be expected that the assignments of such constraints is still quite difficult. Aforementioned appropriateness and feasibility are vague criteria, and should be seen in context of usefulness of this information during planning processes. As it would exceed the scope of our study, we do not specify where each constraint type should be used. Furthermore, such constraints should be based on realistic and justified estimates.