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:

1.  Are there any (resource allocation) issues that are common to multi-project / portfolio environments?
2. 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:

1. 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.
2. 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.
3. 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.
4. 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.

A thin veneer of process

Some time back I published a post arguing that much of the knowledge relating to organizational practices is tacit – i.e. it is impossible to capture in writing or speech. Consequently, best practices and standards that purportedly codify “best of breed” organizational practices are necessarily incomplete:  they do not (and cannot) detail how a practice should be internalised  and implemented in specific situations.

For a best practice to be successful, it has to be understood and moulded in a way that makes sense in the working culture and environment of the implementing organisation.  One might refer to this process   as “adaptation” or “customization”, but it is much more than   minor tweaking of a standard process or practice.  Tacit knowledge relates to the process of learning, or getting to know.  This necessarily differs from individual to individual, and can’t be picked up by reading best practice manuals.  Building tacit knowledge takes time and, therefore, so does the establishment of new organizational processes. Consequently, there is a lot of  individual on-the-job learning and tinkering  before a newly instituted procedure becomes an organizational practice.

This highlights a gap between how practices are implemented and how they actually work. All too often, an organisation will institute a project to implement a best practice – say a quality management methodology – and declare success as soon as the project is completed. Such a declaration is premature because the new practice is yet to take root in the organisation.   This common approach to best practice implementation does not allow enough time for the learning and dialogue that is so necessary for the establishment of an organizational practice. The practice  remains “a thin veneer of process” that peels off all too easily.

Yet,  despite the fact that it does not work,  the project-oriented approach remains popular. Why is this so? I believe this happens because decision-makers view the implementation of best practices as a purely technical problem –  practices are seen as procedures that can be grafted upon the organization without due regard to culture or context and environment or ethics.   When culture,  context and people  are considered as incidental,   practices are reduced to their mechanical (or bureaucratic) elements –  those that can be captured in documents, workflow diagrams and forms.  These elements are tangible so implementers can point to these as “proof” that the processes have been implemented.

Hence the manager who says:  “We have rolled out our new project management system and all users have undergone training.  The implementation of the new methodology has been completed. ”

Sorry, but it has just begun. Success – if it comes at all – will take a lot more time and effort.

So how should best practice implementations be approached?

It should be clear that a successful implementation cannot come from a cookbook approach that follows textbook or consultant “recipes.”  Rather, it involves the following:

1. Extensive adaptation of techniques to suit the context and environment of the organisation.
2. Involvement of the people who will work with and be affected the processes. This often goes under the banner of “buy-in”, but it is more than that: these people must have a say in what adaptations are made and how they are made. But even before they do that, they must be allowed to play with the process – to tinker – so that they can improve their understanding of its intent and working.
3. An understanding that the process  is not cast in stone – that it must be modified as employees gain insights into how the process can be improved.

All these elements tie into the idea that practices and procedures involve tacit knowledge that sits in people’s heads.  The visible, or explicit, aspects – which are often mistaken for the practice – are but a thin veneer of process.

So, in conclusion, the technical implementation of a best practice is only the beginning – it is the start of the real work of internalizing the practice through learning required to sustain and support it.

What is the make of that car? A tale about tacit knowledge

My son’s fascination with cars started early: the first word he uttered wasn’t “Mama” or “Dada”, it was “Brrrm.”

His interest grew with him; one of the first games we played together as a family was “What’s the make of that car?” – where his mum or I would challenge him to identify the make of a car that had just overtaken us when we were out driving.  The first few times we’d have to tell him what a particular car was (he couldn’t read yet), but soon enough he had a pretty good database in his little head.  Exchanges like the following became pretty common:

“So what’s that one Rohan?”

“Mitsubishi Magna, Dad”

“Are you sure?”

“Yes, it is Mitsubishi,” he’d assert, affronted that I would dare question his ability to identify cars.

He was sometimes wrong about the model (and his mum would order me not to make an issue of it). More often than not, though, he’d be right. Neither his mum nor I are car enthusiasts, so we just assumed he figured it out from the logo and / or the letters inscribing the make on the boot.

Then one day we asked him to identify a car that was much too far away for him to be able to see letters or logos. Needless to say, he got it right…

Astounded, I asked, “Did you see the logo when the car passed us?”

“No Dad”

“How did you know then?”

“From the shapes, of course?”  As though it were the most obvious thing in the world.

“What shapes?” I was truly flummoxed.

“All cars have different shaped lights and bumpers and stuff.” To his credit, he refrained from saying, didn’t you know that.

“Ah, I see…”

But I didn’t really. Somehow Rohan had intuitively figured out that specific makes and models have unique tail-light, boot and bumper designs. He understood, or knew, car makes and models in a completely different way than we did – his knowledge of cars was qualitatively different from ours.

(I should make it clear that he picked up this particular skill because he enjoys learning about cars; he is, therefore, intrinsically motivated to learn about them. In most other areas his abilities are pretty much in line with kids his age)

—

Of course, the cognoscenti are well aware that cars can be identified by their appearance. I wasn’t, and neither was my dear wife. Those who know cars can identify the make (and even the model) from a mere glance.  Moreover, they can’t tell you exactly how they know, they just know – and more often than not they’re right.

This incident came back to me recently, as I was reading Michael Polanyi’s book, The Tacit Dimension, wherein  he explains his concept of tacit knowledge (which differs considerably from what it has come to mean in mainstream knowledge management).   The basic idea is that we know more than we can tell;  that  a significant part of our knowledge cannot be conveyed to others via speech or writing.  At times we  may catch a glimpse of it when the right questions are asked in the right context, but this almost always happens by accident rather than plan. We have to live with the fact that it is impossible for me to understand something you know in the same way that you do. You could explain it to me, I could even practice it under your guidance, but my understanding of it will never be the same as yours.

My point is this:  we do not and cannot fully comprehend how others understand and know things, except through fortuitous occurrences.  If this is true for a relatively simple matter like car makes and models, what implications does it have for more complex issues that organisations deal with everyday?  For example: can we really understand a best practice in the way that folks in the originating organisation do? More generally, are our present methods of capturing and sharing insights (aka Knowledge Management) effective?