Resource Allocation

At the firm, resource allocation is usually performed through a team responsible – a team leader or coordinator. Resources are regularly negotiated during the weekly and monthly meetings, where the maintenance, support, and internal tasks as well as the ongoing projects are being reviewed and discussed with the parties involved. Where available, also the competences needed for future projects in the portfolio are brought up. Decisions regarding all resource assignments are recorded in a spreadsheet, reflecting the allocation.

Besides the meetings, resource allocation obviously has to respond to more irregular events. One possible case is the request by sales for a pre-sale person, which is assigned in negotiation between sales, the team responsible, and the staff. In addition, miscellaneous activity planning often needs additional resources, e.g. for urgent customer support cases. Project resource planning can similarly discover that previously allocated resources have been inappropriate, and consequently either request more or release resources.

Within the negotiation and allocation steps, the team responsible ensures that the assigned staff can dedicate time to team development, such as qualification measures, either by assigning training or non-time-critical tasks. The reporting of workload and capacity, in different categories, to the general management also takes place. While the distinction between negotiation and allocation is sometimes difficult to perceive, this planning process is mainly traceable in our reference.

However, resource allocation also occurs in other forms. First of all, a sales person allocates resources directly, when not taking the approach of asking the team respon- sible, but instead attempting to locate the person with the appropriate competences themselves. Moreover, escalating support calls can be addressed directly to experts, such as solution architects. The same applies to project management, which some- times acquires additional expertise outside of the already-assigned resources. In all of these cases, the interviews indicate that such unplanned allocations are colliding with other assignments, but negotiation with the team responsible and any other affected planning instance is left to the person performing the task (i.e. the allocated resource).

Some interviews further indicated that solution architects, other project leaders, and various other team members allocate resources outside of the regular meetings as well. Since they are part of competence teams, we can nevertheless assume that this

allocation is mostly negotiated with the team responsible. Only when tasks are

team-spanning, it could be that another team responsible is not informed.

Furthermore, descriptions of regular as well as irregular allocation procedures sug- gested that often, there is a request for specific resources instead of competences.

As long as the team responsible has the opportunity and necessary knowledge for intervention, a different resource can be assigned instead. This is however often not the case, and likely to cause more necessary allocation and negotiation steps. In order to counter the possible problems emerging from direct resource allocation and move towards a competence-based specification of resource needs, it takes sufficient information. Our theoretical model only partially reflects the useful aspects of competence information, which could be provided to other planning instances. When it comes to the regular allocation, the information system seems to support the activities sufficiently. Since the resource allocation is not done on a per-activity- basis, resources usually have some additional time for tasks, even when ‘fully’ planned. This planned slack time is inevitable for any operation under uncertainty. However, while this flexibility allows for changes without major renegotiation and releasing resources from other tasks, it is hard to limit these additional allocations to the ‘planned slack’. The interviews with the solution architect and the project managers indicate that especially experts mostly have to rely on their gut feeling to determine if the slack is exceeded, requiring postponement of other activities beyond the plan. It is difficult to counter this problem in the information system, as the specification raises a dilemma: If experts such as architects are essential for many projects and maintenance tasks, their continuous information of availability and current allocation would be useful; but the more accurate this information should be recorded and followed, the less flexible the allocation process is. At the same time, this means more time spent for the experts or team responsible on updating it. A too close surveillance of staff activity is also ethically questionable. Generally, not only concerning the solution architects, a highly formalized system of allocation would likely undermine the practice of individual self-organization to an extent, where the cost outweighs the benefits.

Partially, the high workload can possibly be reduced with the aforementioned ad- vancement of competence-based resource allocation. Additionally, a possible approach would be, to monitor how often and in what intensity scarce resources are withdrawn from their originally planned allocation. Based on this information, the reserved slack time can be adjusted systematically. This also means a refinement to our model in order to better reflect the practical needs of these resources. Nonetheless, this information can only support allocation decisions if the unplanned allocations are made explicit in the organization.

Another approach would be, to reduce the amount of instances the resource allocation has to respond to. Practically, this means to divide the teams in units, for example, only performing tasks either for project resource planning or support activities for miscellaneous activity planning, but not both. Consequently, the resource allocation instance has to respond to less resource needs, which lowers the complexity of potential negotiation. This is however a trade-off with flexibility, as in case of shortages in one allocation instance, less resources can be used.