Archive for the ‘Paper Review’ Category
The resource allocation syndrome in multi-project environments
Introduction
In many organisations, employee workloads consist of a mix of project and operational assignments. Due to endemic shortfalls in staffing, such folks – particularly those who have key skills and knowledge – generally have little or no spare capacity to take on more work. However, soon comes along another “important” project in urgent need of staffing and the rest, as they say, is tragedy: folks who are up to their necks in work are assigned to work on the new project. This phenomenon is a manifestation of the resource allocation syndrome, discussed at length in a paper by Mats Engwall and Anna Jerbrant entitled, The resource allocation syndrome: the prime challenge of multi-project management?. The present post is a summary of the paper.
Background
Scheduling and resource allocation is a critical part of project planning in multi-project environments. Those who work in such settings know (often from bitter experience) that, despite the best laid plans, it is easy to be over-allocated to multiple projects. Engwall and Jerbrant’s work delves into the factors behind resource over-allocation via a comparative case study involving two very different environments: the contracts department of a railway signalling equipment firm and an R&D division of a telecoms company.
Specifically, the work addresses the following questions:
- Are there any (resource allocation) issues that are common to multi-project / portfolio environments?
- What are the mechanisms behind these issues?
As they point out, there are several articles and papers that deal with the issue of resource allocation on concurrent projects. However, there are relatively few that tackle the question of why problems arise. Their aim is to shed light on this question.
Methodology and the case studies
As mentioned above, the authors’ aim was surface factors that are common to multi-project environments. To this end, they gathered qualitative data from a variety of sources at both sites. This included interviews, studies of project and technical documentation, company procedures and direct observation of work practices.
The first study was carried out at the contract division of a mid-sized railway signalling equipment firm. The division was well-established and had a long history of successful projects in this domain. As might be expected given the history of the organisation, there was a mature project management methodology in place. The organisation had a matrix management structure with 200 employees who were involved in executing various projects around the world. The work was managed by 20 project managers. Most of the projects were executed for external clients. Further, most projects involved little innovation: they were based on proven technologies that project teams were familiar with. However, although the projects were based on known technologies, they were complex and of a relatively long duration (1 to 5 years).
The second study was done in the R&D division of a telecom operator. The division, which had just been established, had 50 employees who worked within a matrix structure that was organised into five specialist departments. Since the division was new, the project management procedures used were quite unsophisticated. Projects were run by 7 project managers, and often involved employees from multiple departments. Most of the projects run by the division were for internal customers – other divisions of the company. Also in contrast to the first study, most projects involved a high degree of innovation as they were aimed at developing cutting-edge technologies that would attract new subscribers. However, even though the projects involved new technologies, they were of relatively short duration (0.5 to 2 years).
Important, from the point of view of the study, was the fact that most employees in both organisations were engaged in more than one project at any given time.
For those interested, the paper contains more detail on the methodology and case studies.
Results
As might be expected from a study of this nature, there were differences and similarities between the two organisations that were studied. The differences were mainly in the client base (external for the contract division, internal for the other), project complexity (complex vs. simple) and organisational maturity (older and mature vs. newly instituted and immature).
Despite the differences, however, both organisations suffered from similar problems. Firstly, both organisations had portfolios with extensive project interdependencies. As a consequence, priority setting and resource (re)allocation was a major management issue. Another issue was that of internal competition between projects – for financial and human resources. In fact, the latter was one of the most significant challenges faced by both organisations. Finally, in both organisations, problems were dealt with in an ad-hoc way, often resulting in solutions that caused more issues down the line.
From the common problems identified, it was clear that:
In both organizations, the primary management issue revolved around resources. The portfolio management was overwhelmed issues concerning prioritization of projects and, distribution of personnel from one project to another, and the search for slack resources. However, there were no resources available. Furthermore, when resources were redistributed it often produced negative effects on other projects of the portfolio. This forced the management to continuous fire fighting, resulting in reactive behavior and short-term problem solving. However, the primary lever for portfolio management to affect an ongoing project in trouble was resource re-allocation.
There are a couple of points to note here. Firstly, resource re-allocation did not work. Secondly, despite major differences in between the two organisations, both suffered from similar resource allocation issues. This suggests that this resource allocation syndrome is a common problem in multi-project environments.
Understanding the syndrome
Based on data gathered, the authors identify a number of factors that affect resource allocation. These are:
- Failure in scheduling: this attributes the resource allocation syndrome to improper scheduling rather than problems of coordination and transition. The fact of the matter is that it is impossible for people to shift seamlessly from one project to another. There is – at the very least – the overhead of context switching. Further, projects rarely run on schedule, and delays caused by this are difficult to take into account before they occur.
- Over commitment of resources: This is another common problem in multi-project environments: there are always more projects than can be handled by available personnel. This problem arises because there is always pressure to win new business or respond to unexpected changes in the business environment.
- Effect of accounting methods: project organisations often bill based on hours spent by personnel on projects. In contrast, time spent on internal activities such as meetings are viewed as costs. In such situations there is an in-built incentive for management to keep as many people as possible working on projects. A side-effect of this is the lack of availability of resources for new projects.
- Opportunistic management behaviour: In many matrix organisations, the allocation of resources is based on project priority. In such cases there is an incentive for project sponsors and senior managers to get a high priority assigned by any means possible. On the other hand, those who already have resources assigned to their projects would want to protect them from being poached to work on other projects.
The above factors were identified based on observations and from comments made by interviewees in both organisations.
Resource allocation (as taught in project management courses) focuses on the first two points noted above: scheduling and over-commitment. The problem is thus seen as a pure project management issue – one that deals with assigning of available resources to meet demand in the most efficient (i.e. optimal) way. In reality, however, the latter two points (which have little to do with project management per se) play a bigger role. As the author’s state:
Instead of more scheduling, progress reports, or more time spent on review meetings, the whole system of managerial procedures has to be reconceptualized from its roots. As current findings indicate: the resource allocation syndrome of multi-project management is not an issue in itself; it is rather an expression of many other, more profound, organizational problems of the multi-project setting.
The syndrome is thus a symptom of flawed organisational procedures. Consequently, dealing with it is beyond the scope of project management.
Conclusion
The key takeaway from the paper is that the resource allocation issues are a consequence of flawed organisational procedures rather than poor project management practices. Project and portfolio managers responsible for resource allocation are only too aware of this. However, they are powerless to do anything about it because, as Engwall and Jerbrant suggest, addressing the root cause of this syndrome is a task for executive management.
Value judgements in system design
Introduction
How do we choose between competing design proposals for information systems? In principle this should be done using an evaluation process based on objective criteria. In practice, though, people generally make choices based on their interests and preferences. These can differ widely, so decisions are often made on the basis of criteria that do not satisfy the interests of all stakeholders. Consequently, once a system becomes operational, complaints from stakeholder groups whose interests were overlooked are almost inevitable (Just think back to any system implementation that you were involved in…).
The point is: choosing between designs is not a purely technical issue; it also involves value judgements – what’s right and what’s wrong – or even, what’s good and what’s not. Problem is, this is a deeply personal matter – different folks have different values and, consequently, differing ideas of which design ideal is best (Note: the term ideal refers to the value judgements associated with a design). Ten years ago, Heinz Klein and Rudy Hirschheim addressed this issue in a landmark paper entitled, Choosing Between Competing Design Ideals in Information Systems Development. This post is a summary of the main ideas presented in their paper.
Design ideals and deliberation
A design ideal is not an abstract, philosophical concept. The notion of good and bad or right and wrong can be applied to the technical, economic and social aspects of a system. For example, a choice between building and buying a system has different economic and social consequences for stakeholder groups within and outside the organisation. What’s more, the competing ideals may be in conflict – developers employed in the organisation would obviously prefer to build rather than buy because their employment depends on it; management, however, may have a very different take on the issue.
The essential point that Hirschheim and Klein make is that differences in values can be reconciled only through honest discussion. They propose a deliberative approach wherein all stakeholders discuss issues in order to come to an agreement. To this end, they draw on the theories of argumentation and communicative rationality to come up with a rational framework for comparing design ideals. Since these terms are new, I’ll spend a couple of paragraphs in describing them briefly.
Argumentation is essentially reasoned debate – i.e. the process of reaching conclusions via arguments that use informal logic – which, according to the definition in the foregoing link, is the attempt to develop a logic to assess, analyse and improve ordinary language (or “everyday”) reasoning. Hirschheim and Klein use the argumentation framework proposed by Stephen Toulmin, to illustrate their approach.
The basic premise of communicative rationality is that rationality (or reason) is tied to social interactions and dialogue. In other words, the exercise of reason can occur only through dialogue. Such communication, or mutual deliberation, ought to result in a general agreement about the issues under discussion. Only once such agreement is achieved can there be a consensus on actions that need to be taken. See my article on rational dialogue in project environments for more on communicative rationality.
Obstacles to rational dialogue and how to overcome them
The key point about communicative rationality is that it assumes the following conditions hold:
- Inclusion: includes all stakeholders.
- Autonomy: all participants should be able to present and criticise views without fear of reprisals.
- Empathy: participants must be willing to listen to and understand claims made by others.
- Power neutrality: power differences (levels of authority) between participants should not affect the discussion.
- Transparency: participants must not indulge in strategic actions (i.e. lying!).
Clearly these are idealistic conditions, difficult to achieve in any real organisation. Klein and Hirschheim acknowledge this point, and note the following barriers to rationality in organisational decision making:
- Social barriers: These include inequalities (between individuals) in power, status, education and resources.
- Motivational barriers: This refers to the psychological cost of prolonged debate. After a period of sustained debate, people will often cave in just to stop arguing even though they may have the better argument.
- Economic barriers: Time is money: most organisations cannot afford a prolonged debate on contentious issues.
- Personality differences: How often is it that the most charismatic or articulate person gets their way, and the quiet guy in the corner (with a good idea or two) is completely overlooked?
- Linguistic barriers: This refers to the difficulty of formulating arguments in a way that makes sense to the listener. This involves, among other things, the ability to present ideas in a way that is succinct, without glossing over the important issue – a skill not possessed by many.
These barriers will come as no surprise to most readers. It will be just as unsurprising that it is difficult to overcome them. Klein and Hirschheim offer the usual solutions including:
- Encourage open debate – They suggest the use of technologies that support collaboration. They can be forgiven for their optimism given that the paper was written a decade ago, but the fact of the matter is that all the technologies that have sprouted since have done little to encourage open debate.
- Implement group decision techniques – these include arrangements such as quality circles, nominal groups and constructive controversy. However, these too will not work unless people feel safe enough to articulate their opinions freely.
Even though the barriers to open dialogue are daunting, it behooves system designers to strive towards reducing or removing them. There are effective ways to do this, but that’s a topic I won’t go into here as it has been dealt with at length elsewhere.
Principles for arguments about value judgements
So, assuming the environment is right, how should we debate value judgements? Klein and Hirschheim recommend using informal logic supplemented with ethical principles. Let’s look at these two elements briefly.
Informal logic is a means to reason about human concerns. Typically, in these issues there is no clear cut notion of truth and falsity. Toulmin’s argumentation framework (mentioned earlier in this post) tells us how arguments about such issues should be constructed. It consists of the following elements:
- Claim: A statement that one party asks another to accept as true. An example would be my claim that I did not show up to work yesterday because I was not well.
- Data (Evidence): The basis on which one party expects to other to accept a claim as true. To back the claim made in the previous line, I might draw attention to my runny nose and hoarse voice.
- Warrant: The bridge between the data and the claim. Again, using the same example, a warrant would be that I look drawn today, so it is likely that I really was sick yesterday.
- Backing: Further evidence, if the warrant should prove insufficient. If my boss is unconvinced by my appearance he may insist on a doctor certificate.
- Qualifier: These are words that express a degree of certainty about the claim. For instance, to emphasise just how sick I was, I might tell my boss that I stayed in bed all day because I had high fever.
This is all quite theoretical: when we debate issues we do not stop to think whether a statement is a warrant or a backing or something else; we just get on with the argument. Nevertheless, knowledge of informal logic can help us construct better arguments for our positions. Further, at the practical level there are computer supported deliberative techniques such as argument mapping and dialogue mapping which can assist in structuring and capturing such arguments.
The other element is ethics: Klein and Hirschheim contend that moral and ethical principles ought to be considered when value judgements are being evaluated. These principles include:
- Ought implies can – which essentially means that one morally ought to do something only if one can do it (see this paper for an interesting counterview of this principle). Taking the negation of this statement, one gets “Cannot implies ought not” which means that a design can be criticised if it involves doing something that is (demonstrably) impossible – or makes impossible demands on certain parties.
- Conflicting principles – This is best explained via an example. Consider a system that saves an organisation money but involves putting a large number of people out of work. In this case we would have an economic principle coming up against a social one. According to the principle, a design ideal based on an economic imperative can be criticised on social grounds.
- The principle of reconsideration – This implies reconsidering decisions if relevant new information becomes available. For example, if it is found that a particular design overlooked a certain group of users, then the design should be reconsidered in the light of their needs.
They also mention that new ethical and moral theories may trigger the principle of reconsideration. In my opinion, however, this is a relatively rare occurrence: how often are new ethical or moral theories proposed?
Summarising
The main point made by the authors is that system design involves value judgements. Since these are largely subjective, open debate using the principles of informal logic is the best way to deal with conflicting values. Moreover, since such issues are not entirely technical, one has to use ethical principles to guide debate. These principles – not asking people to do the impossible; taking everyone’s interests into account and reconsidering decisions in the light of new information – are reasonable if not self-evident. However, as obvious as they are, they are often ignored in design deliberations. Hirschheim and Klein do us a great service by reminding us of their importance.
Making sense of sensemaking – the dimensions of participatory design rationale
Introduction
Over the last year or so, I’ve used IBIS (Issue-Based Information System) to map a variety of discussions at work, ranging from design deliberations to project meetings [Note: see this post for an introduction to IBIS and this one for an example of mapping dialogues using IBIS]. Feedback from participants indicated that IBIS helps to keep the discussion focused on the key issues, thus leading to better outcomes and decisions. Some participants even took the time to learn the notation (which doesn’t take long) and try it out in their own meetings. Yet, despite their initial enthusiasm, most of them gave it up after a session or two. Their reasons are well summed up by a colleague who said, “It is just too hard to build a coherent map on the fly while keeping track of the discussion.”
My colleague’s comment points to a truth about the technique: the success of a sense-making session depends rather critically on the skill of the practitioner. The question is: how do experienced practitioners engage their audience and build a coherent map whilst keeping the discussion moving in productive directions? Al Selvin, Simon Buckingham-Shum and Mark Aakhus provide a part answer to this question in their paper entitled, The Practice Level in Participatory Design Rationale : Studying Practitioner Moves and Choices. Specifically, they describe a general framework within which the practice of participatory design rationale (PDR) can be analysed (Note: more on PDR in the next section). This post is a discussion of some aspects of the framework and some personal reflections based on my (limited) experience.
A couple of caveats are in order before I proceed. Firstly, my discussion focuses on understanding the dimensions (or variables) that describe the act of creating design representations in real-time. Secondly, my comments and reflections on the model are based on my experiences with a specific design rationale technique – IBIS.
Background
First up, it is worth clarifying the meaning of participatory design rationale (PDR). The term refers to the collective reasoning behind decisions that are made when a group designs an artifact. Generally such rationale involves consideration of various alternatives and why they were or weren’t chosen by the group. Typically this involves several people with differing views. Participatory design is thus an argumentative process, often with political overtones.
Clearly, since design involves deliberation and may also involve a healthy dose of politics, the process will work more effectively if it is structured. The structure should, however, be flexible: it must not constrain the choices and creativity of those involved. This is where the notation and practitioner (facilitator) come in: the notation lends structure to the discussion and the practitioner keeps it going in productive directions, yet in a way that sustains a coherent narrative. The latter is a creative process, much like an art. The representation (such as IBIS) – through its minimalist notation and grammar – helps keep the key issues, ideas and arguments firmly in focus. As Selvin noted in an earlier paper, this encourages collective creativity because it forces participants to think through their arguments more carefully than they would otherwise. Selvin coined the term knowledge art to refer to this process of developing and engaging with design representations. Indeed, the present paper is a detailed look at how practitioners create knowledge art – i.e. creative, expressive representations of the essence of design discussions. Quoting from the paper:
…we are looking at the experience of people in the role of caretakers or facilitators of such events – those who have some responsibility for the functioning of the group and session as a whole. Collaborative DR practitioners craft expressive representations on the fly with groups of people. They invite participant engagement, employing techniques like analysis, modeling, dialogue mapping, creative exploration, and rationale capture as appropriate. Practitioners inhabit this role and respond to discontinuities with a wide variety of styles and modes of action. Surfacing and describing this variety are our interests here.
The authors have significant experience in leading deliberations using IBIS and other design rationale methods. They propose a theoretical framework to identify and analyse various moves that practitioners make in order to keep the discussion moving in productive direction. They also describe various tools that they used to analyse discussions, and specific instances of the use of these tools. In the remainder of this post, I’ll focus on their theoretical framework rather than the specific case studies, as the former (I think) will be of more interest to readers. Further, I will focus on aspects of the framework that pertain to the practice – i.e. the things the practitioner does in order to keep the design representation coherent, the participants engaged and the discussion useful, i.e. moving in productive directions.
The dimensions of design rationale practice
So what do facilitators do when they lead deliberations? The key actions they undertake are best summed up in the authors’ words:
…when people act as PDR practitioners, they inherently make choices about how to proceed, give form to the visual and other representational products , help establish meanings, motives, and causality and respond when something breaks the expected flow of events , often having to invent fresh and creative responses on the spot.
This sentence summarises the important dimensions of the practice. Let’s look at each of the dimensions in brief:
- Ethics: At key points in the discussion, the practitioner is required to make decisions on how to proceed. These decisions cannot (should not!) be dispassionate or objective (as is often assumed), they need to be made with due consideration of “what is good and what is not good” from the perspective of the entire group.
- Aesthetics: This refers to the representation (map) of the discussion. As the authors put it, “All diagrammatic DR approaches have explicit and implicit rules about what constitutes a clear and expressive representation. People conversant with the approaches can quickly tell whether a particular artifact is a “good” example. This is the province of aesthetics.” In participatory design, representations are created as the discussion unfolds. The aesthetic responsibility of the practitioner is to create a map that is syntactically correct and expressive. Another aspect of the aesthetic dimension is that a “beautiful” map will engage the audience, much like a work of art.
- Narrative: One of the key responsibilities of the practitioner is to construct a coherent narrative from the diverse contributions made by the participants. Skilled practitioners pick up connections between different contributions and weave these into a coherent narrative. That said, the narrative isn’t just the practitioner’s interpretation; the practitioner has to ensure that everyone in the group is happy with the story; the story is to the group’ s story. A coherent narrative helps the group make sense of the discussion: specifically the issues canvassed, ideas offered and arguments for and against each of them. Building such a narrative can be challenging because design discussions often head off in unexpected directions.
- Sensemaking: During deliberations it is quite common that the group gets stuck. Progress can be blocked for a variety of reasons ranging from a lack of ideas on how to make progress to apparently irreconcilable differences of opinion on the best way to move forward. At these junctures the role of the practitioner is to break the impasse. Typically this involves conversational moves that open new ground (not considered by the group up to that point) or find ways around obstacles (perhaps by suggesting compromises or new choices). The key skill in sensemaking is the ability to improvise, which segues rather nicely into the next variable.
- Improvisation: Books such as Jeff Conklin’s classic on dialogue mapping describe some standard moves and good practices in PDR practice. In reality, however, a practitioner will inevitably encounter situations that cannot be tackled using standard techniques. In such situations the practitioner has to improvise. This could involve making unconventional moves within the representation or even using another representation altogether. These improvisations are limited only by the practitioner’s creativity and experience.
Using case studies, the authors illustrate how design rationale sessions can be analysed along the aforementioned dimensions, both at a micro and macro level. The former involves a detailed move-by-move study of the session and the latter an aggregated view, based on the overall tenor of episodes consisting of several moves. I won’t say any more about the analyses here, instead I’ll discuss the relevance of the model to the actual practice of design rationale techniques such as dialogue mapping.
Some reflections on the model
When I first heard about dialogue mapping, I felt the claims made about the technique were exaggerated: it seemed impossible that a simple notation like IBIS (which consists of just three elements and a simple grammar) could actually enhance collaboration and collective creativity of a group. With a bit of experience, I began to see that it actually did do what it claimed to do. However, I was unable to explain to others how or why it worked. In one conversation with a manager, I found myself offering hand-waving explanations about the technique – which he (quite rightly) found unconvincing. It seemed that the only way to see how or why it worked was to use it oneself. In short: I realised that the technique involved tacit rather than explicit knowledge.
Now, most practices– even the most mundane ones – involve a degree of tacitness. In fact, in an earlier post I have argued that the concept of best practice is flawed because it assumes that the knowledge involved in a practice can be extracted in its entirety and codified in a manner that others can understand and reproduce. This assumption is incorrect because the procedural aspects of a practice (which can be codified) do not capture everything – they miss aspects such as context and environmental influences, for instance. As a result a practice that works in a given situation may not work in another, even though the two may be similar. So it is with PDR techniques – they work only when tailored on the fly to the situation at hand. Context is king. In contrast the procedural aspects of PDR techniques– syntax, grammar etc – are trivial and can be learnt in a short time.
In my opinion, the value of the model is that it attempts to articulate tacit aspects of PDR techniques. In doing so, it tells us why the techniques work in one particular situation but not in another. How so? Well, the model tells us the things that PDR practitioners worry about when they facilitate PDR sessions – they worry about the form of the map (aesthetics), the story it tells (narrative), helping the group resolve difficult issues (sensemaking), making the right choices (ethics) and stepping outside the box if necessary (improvisation). These are tacit skills- they can’t be taught via textbooks, they can only be learnt by doing. Moreover, when such techniques fail the reason can usually be traced back to a failure (of the facilitator) along one or more of these dimensions.
Wrapping up
Techniques to capture participatory design rationale have been around for a while. Although it is generally acknowledged that such techniques aid the process of collaborative design, it is also known that their usefulness depends rather critically on the skill of the practitioner. This being the case, it is important to know what exactly skilled practitioners do that sets them apart from novices and journeymen. The model is a first step towards this. By identifying the dimensions of PDR practice, the model gives us a means to analyse practitioner moves during PDR sessions – for example, one can say that this was a sensemaking move or that was an improvisation. Awareness of these types of moves and how they work in real life situations can help novices learn the basics of the craft and practitioners master its finer points.

