Eight to Late

Sensemaking and Analytics for Organizations

The resource allocation syndrome in multi-project environments

with 19 comments

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.

Written by K

April 27, 2011 at 5:20 am

19 Responses

Subscribe to comments with RSS.

  1. This was good sir. We just had an organizational discussion at my company related to this very issue.

    I assume the answer to this issue is situational based on the organization?

    Like

    Chris Poteet

    April 27, 2011 at 11:45 am

  2. Hi Chris,

    Thanks for your comment. Yes, the answer is based on the specifics of an organisation. As Engwall and Jerbrant conclude, the existence of the problem points to flawed organisational practices (incentive systems, billing practices etc). Resolving these is usually not within the realm of control of project or portfolio managers.

    Regards,

    Kailash.

    Like

    K

    April 27, 2011 at 8:34 pm

  3. […] Scheduling and resource allocation is a critical part of project planning in multi-project environme…. In this blog post, Kailash Await explains that resource allocation issues are a consequence of flawed organisational procedures rather than poor project management practices. […]

    Like

  4. I suggest that the problems are both organizational and project based. At the core is treatment of individuals as “resources” to be exchanged among projects. This harms project performance, and organizational performance in several ways.

    First, staff will not assume a personal commitment to the project. This will stifle creativity and willingness to “go that extra mile” go get the job done. Rather it becomes “management’s problem”.

    Second, the project schedule problems often in part come from overestimating the staff productivity. When staffed on multiple projects, one has considerable project overhead. Staff meetings, reports, communication and the like usually consume a minimum of several hours per week. This is before we consider the problems of task switching. When I measure direct hours on tasks that directly contribute to progress (staff meetings don’t count, a user document does), total available direct hours are usually less than 20 hours per week, often less than 15. Several hours becomes a 20% effect rather than a 7% cost.

    The cost to projects is not calculated and reported back to management. When I was a team lead, I had a rule that I would not accept someone with less than half time on my project. a 1/3 time person was a net drain who complicated task dependencies. I once successfully traded three 1/2 time staff for one full time and came out ahead. (by my using my team’s collected data)

    In short, self directed teams tracking direct time can make the problem visible to management. If they do not track direct time, nothing will change.

    BTW, I agree on the accounting problem. I have seldom seen an employee exceed 20 hours per week direct time on a project. If you staff someone up to 40 hours of project time per week, you will likely get no more than 5 direct hours per week, the remainder being consumed with added project overhead. All you change are the charge strings.

    Like

    Bill Nichols

    May 1, 2011 at 10:51 am

  5. Bill,

    Thanks for your comments.

    The point you make about commitments is a key one. IMO the question is: why will staff not make these commitments? In my experience people are loathe to make commitments because their points of view have not been taken into account in the first place (especially in the early stages of projects, where most of the key decisions regarding scheduling etc. are made). I believe this is more indicative of an organisational problem than poor PM practice.

    As far as overestimation of productivity is concerned, in many organisations, project and portfolio managers are overwhelmed by projects and just don’t have the people to deal with them. The easy “solution” is to overlook overhead and make assumptions of ideal efficiency. IMO, the question here is: why is the portfolio overloaded at all? Here too, I think the answer lies in the organisation rather than the project or portfolio.

    Of course, at the project level accurate data collection and reporting is critical. The key here – as emphasised by many methodologies – is to assure staff that the data will not be used against them. This too, comes down to organisational culture rather than project/portolio processes.

    You have way more experience than I in implementing PM processes in organisations. What is your take on the role of organisational culture in the successful implementation of portfolio/project management processes? It would be great to hear what you think.

    Regards,

    Kailash.

    Like

    K

    May 1, 2011 at 9:35 pm

  6. K,

    In my own limited experience, yes, it is organizational culture, but it is both organization and PM. If we want to change the way the organization behaves, it needs data that can only be gathered at the individual and team level. Of course, the teams and individuals need a supportive environment. Piecemeal change is likely to fail. This is a systems problem. Some may prefer to call it “holistic”.

    I’ve been to places where they tracked assigned time pretty well and still explicitly over committed people. I’ve worked in programs where project staffing was hardly more than notional. In my current role, I haven’t seen examples where everything is working just fine, but we (TSP team at SEI) get called in because there are problems.

    Our TSP (Team Software Process) is not intended to replace project management, but we include some basic PM and gather some data, the direct hours, that most PM do not have access to. Even when people know something intuitively, having the facts rather than opinion can make a difference. Also, as part of our commitment process, individuals commit to a level of project effort, based on their own data not an external directive. It becomes clear fairly soon what is and is not achievable. Project status and conflicts preventing allocated effort bubble up quickly.

    And yes, not only how the data is used, but how it is perceived data might be used is critical. We have the same discussions with developers and multiple levels of management that some data is purely personal, some will be aggregated and reported and if you want the data to be useful, how management reacts to the reports matter critically.

    I’ve worked primarily with developers, but also with testers, documenters, business analysts, systems engineers, and other engineers. Most react well to gaining some autonomy over their work. We usually find that project time increases by about 25% as people learn some basic time management. Because of the transparency of the process, we have much discussion, but based on fact not opinion or perception.

    Typically, only scarce skills remain assigned to more than two projects.

    Like

    Bill Nichols

    May 2, 2011 at 1:41 am

  7. Bill,

    Thanks for the detailed response. TSP’s focus on individual commitments makes good sense (I really must read some of the TSP references you mentioned in an earlier comment). I think gaining genuine commitment is the key to successful project management. Once you have that, it matters little which PM methodology one uses -they will all work.

    You mentioned that your team gets called in when there are problems. I’m curious to know the the most common problems you have encountered and their main causes.

    Thanks again for your response.

    Regards,

    Kailash.

    Like

    K

    May 2, 2011 at 10:12 pm

  8. K,
    No that you mention “most common” I really should compile and track the management goals when we are called. However, I don’t think it’s a stretch to say their immediate concerns are failure to meet schedule commitments and the accompanying costs. As we drill down, we usually see that schedule and cost goals are dictated rather than rationally estimated. More than once I have been asked “so what if the team can provide a better estimate now, I’ve already committed to the customer?”

    My answer is twofold.
    1) you know now, so you can take actions to mitigate the damage.
    2) We will deliver sooner than if nothing changes. Under short term pressure quality will suffer. Quality problems will hurt not just in the long term, but the near term when your product is stuck in test rather than shipping. I can show you the data and models. High levels of quality will accelerate the work, but that requires careful planning and disciplined use process. Quality will not happen by accident.

    We then move on to engagement over compliance.

    There is not much new in what we do. Much of it was done at IBM, other parts follow Deming and Shewhart.

    Like

    Bill Nichols

    May 2, 2011 at 11:03 pm

  9. […] in a recent blog post over at the Eight to Late blog, Kailash Awati reviews and summarizes a research study into this interesting and ubiquitous […]

    Like

  10. […] The first assumption is moot because stakeholders view a project in terms of their priorities and these rarely coincide with those of other stakeholder groups. Hence the mismatch of expectations between, say, development and marketing groups in product development companies. The second assumption is problematic for reasons that I have discussed at length in my post on the resource allocation syndrome. […]

    Like

  11. Hi K
    I came across your blog by chance and this post has really helped me understand the issues that impact on resource allocation.

    I am researching for a question “How do companies plan and manage R&D resources? What best practices are there?”
    Can you flag up any best practices used in R&D environments to deal with the issues that you mention above?
    Are there any case studies out there?

    Keep up the good work – I’m going to dip into the other posts too.

    Like

    Liz Kamei

    June 25, 2011 at 2:43 am

    • Hi Liz,

      Thanks for your comment; I’m glad you found the post useful.

      I’m not too familiar with the resource allocation issues in R&D environments. However, I imagine the problems would be much the same as in other environments, though perhaps exacerbated by the scarcity of skills and longer durations of projects. It may be worth following up some of the references in the Engwall-Jerbrant paper, especially the ones on new product development. Although somewhat dated, they may give you a good starting point.

      Regards,

      Kailash.

      Like

      K

      June 27, 2011 at 5:24 am

  12. Hi Kailash, Thanks for sharing the paper on “resource allocation syndrome”. I’ve recently completed Microsoft’s project management training and reading such case studies, white papers really help to understand core issues. You have summarized it so well, it was interesting read. I completely agree with you that the resource allocation issues are a consequence of flawed organizational procedures rather than poor project management practices. Would like to read more such papers and case studies. Cheers.

    Like

    Denis

    July 31, 2011 at 12:07 am

    • Thanks Denis,

      I’m glad you liked the article and truly appreciate your taking the time to comment.

      I had a situation that was a classic case of the resource allocation syndrome: not a single team member was on the project full-time; they were all juggling project responsibilities with their day jobs. The only reason things moved at all was their willingness and motivation to go “beyond the call of duty.” Such situations are not right but, unfortunately, they are reality.

      In case you are interested, I have written a number of other, pieces based on research papers in PM – see the paper review category on the right for more.

      Thanks again.

      Regards,

      Kailash.

      Like

      K

      July 31, 2011 at 6:05 am

  13. In an organization where some skills are short and resource sharing is inevitable. How would someone develop an incentive schemes where project managers would be tempted to share those resources

    Like

    Muhammad Waqas

    December 27, 2011 at 11:14 pm

  14. Scheduling resources can be a real nightmare. I’ve worked in quite a few marketing agencies where they use a spreadsheet to try and track resource availability. And it’s always a real headache. That’s why we are developing a dedicated web app that will help companies schedule resources. It’s a cloud-based solution so it helps companies see live availability and avoid conflicts. You can check it out at http://resourceguruapp.com.

    Like

    Andrew

    January 9, 2012 at 6:41 am

  15. Reblogged this on Project Management Quotes and commented:
    An interesting article which I am sure most PMs can relate to…additionally the multitasking/matricing of individuals requires an environment where individuals can speak openly about when they are overloaded, they are listening to and action is taken by their line manager.

    Like

    trewinpa

    September 25, 2013 at 8:44 pm

  16. […] allocation (see my article on the resource allocation syndrome for much more on […]

    Like


Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.