Resource Conflicts in Projects – Can Agile Planning Reduce Them?

Preventing resource conflicts with agile methods? Sounds good and raises hope. And there is something to it. Agile methods can indeed prevent resource conflicts. Yet, this will only work out on the premise that you can handle the necessary constraints: such as for example the implicit open-ended results.

This article will tell you how to approach this in the following chapters:

• • Relevance and satisfaction are poles apart
  • Resource management is not a by-product of project management
  • Just demanding more will not work
  • Fixed teams – The basis of realistic planning
  • Fewer resource conflicts thanks to open-ended results
  • Agile methods call for optimizing the organization
  • Successful resource planning based on the example of TPG The Project Group
  • Long-term resource planning is a must in both camps
  • Conclusion: The cadence is essential

Relevance and Satisfaction Are Poles Apart

Resource management has many areas and is handled differently from company to company. Yet, what unites all companies is the high relevance of the resource topic.

Times have changed after all: many companies are short of staff with the required qualifications. As a result, too few qualified people have to attend to too many tasks. Whether it be operations or project activities – there is always more to do than can be accomplished.

And another thing: in most companies, the importance of the resource topic is contrasted by high discontent with the management of resource conflicts.

In our perception, this is true of all industries and company sizes.

Rating of resource planning in companies: usually low satisfaction despite high importance

This is where project management is meant to help, for instance by means of detailed work planning. The goal is to optimize the utilization of staff, which would hopefully make it possible to deliver the desired results on time – naturally in accordance with cost and quality goals.

Resource Management Is Not a By-Product of Project Management

Yet, the projects meeting these standards are very few. Here are some examples from everyday project work to demonstrate this:

• Deadlines are impossible to meet due to insufficient resource provision.
• With too few qualified colleagues, project budgets are overrun, as the quality is inadequate.
• The coordination effort for resolving resource conflicts is much too high, and the results are often no more than rotten compromises.
• In the end, new business opportunities cannot be seized, and existing customers are annoyed.

This can have several reasons, such as for instance:

• Workload diagrams that simply do not add up.
• The resource pool is not structured properly, and its maintenance is incomplete.
• Resource requests from projects are never complete, nor are they planned well enough.
• Employees have to carry out too many tasks at once.
• There are no established coordination processes – neither for resource requests nor for cases of conflict.
• Often, there is no prioritization of projects, or it is not common knowledge.
• Due to unsuitable tools, team leaders and project managers do not have their own planning statuses that would enable a well-founded discussion of the respective situation.

Even if the management of individual projects is well established at your company, this will only partly help with resource management in a multi-project environment.

Well-planned individual projects do provide a very good basis for resource requirements. The valid allocation of resources, however, requires overriding processes and methods as well as a central tool with a database.

What you will need above all:

• An appropriate organization
• The involvement of the team leaders
• Prioritization

Just Demanding More and More Will Not Work

At the same time, a little logic and common sense is also necessary: superiors cannot ask more and more of people who are already working to capacity. It is a matter of scoring something off the task list once in a while!

Sounds logical somehow. Yet, accepting this is not always easy when you have the new order, the next delivery date or end-of-the-month billing in mind and commitments to keep.

Anyone assigning new tasks to a fully engaged team will have to remove others first

Let me take you on a mental journey:

You are sitting on a full bus. It pulls up at a stop, and other people want to board. Is that still possible? Let us be honest: if the bus is full, someone will have to get off so that another can get on and sit properly. Experience has shown that another person will always fit into a full bus – standing up, squashed against a door. But how long will they be able to take it?

And let us hope the door will hold out until the next stop at least. That is where you will have to change to another bus anyway. But you do not actually know where it stops exactly, and it is also known to arrive late. Soon you may be getting off the bus network for good anyway – that is you may be leaving the company by your own choice.

Our tip: Rather than overloading your team with evermore tasks – prioritize those tasks and score less important items (temporarily) off the list.

Fixed Teams – The Basis of Realistic Planning and High Quality

Agile methods keep employees from constantly having to take different crowded buses to destinations dictated by others. Together, they get on a bus which has a seat for everyone. Nobody gets on or off – it is a charter bus, only for one project or product. The tour guide is well known as is the destination route.

Together with the tour guide, the team determines how far to go, where to exactly, and also how fast, depending on the experiences they encounter along the road. This takes us to the marginal conditions you will have to deal with if you want to travel in this nice way.

Clearly, the journey is not the reward in the agile world either. It is just that the route and the destination do not have to be completely set from the beginning. However, what will be fixed from the outset is the size of the bus and the amount of fuel.

Moreover, the customer is always on board too, and we always ask him at intermediate stops how he or she likes it. And they are OK with being taken to a destination they may not have known well before.

In agile product development, fixed teams prevent resource conflicts

What this process means for the resource management topic in practice: the majority of problems cannot arise, as the right course is set from the beginning.

Our tip: Bank on a fixed team, i.e. one that is put together only once, rather than on a constant change of staff members between the different projects.

Yet, it can only be that easy if you accept the following points:

All agree that the assembled team will aim to achieve the best possible working result within the allowed time. However, this does not have to be specified in every detail beforehand.

• The team itself estimates the effort for the tasks and therefore knows best what can be accomplished in what time. This means the team is not overextended from the outside.
• Reviews (e.g. bi-weekly) will give all participants an insight into the results hitherto obtained. This gives everyone the reassurance to be doing the right thing. Adjustments can be made in good time.
• Everyone is aware that the final outcome may vary from the original requirement. However, it needs to provide a usable benefit.

Fewer Resource Conflicts Thanks to Open-Ended Results

The process described above ensures that your workload diagrams are always correct and the costs are predictable.

The finish date is set though the result at this time is not. Thus, you trade resource conflicts for open-ended results. Still, the quality is higher, as everyone has been focused on working on one project or product up to this point.

If anyone has to change teams, this should not happen right in the middle. This change takes place between Sprints or iterations, just as it is propagated in the other teams. This makes changing to another bus much easier.

In agile product development, fixed teams prevent resource conflicts

You may be thinking now that this is all very well for the development of software products. But upon opening your eyes after this mental journey your reality tells you that this cannot work in your case.

Wondering about which approach to use? Read article about agile, traditional or hybrid PM.

It is true that you will not be able to build an airport in this way. Yet, there are many other sectors, which are not mere software development, in which you can use agile methods at least for the software component. Software is also omnipresent in all the digitization projects. In addition, any other form of product development can follow agile principles with a fixed team.

Agile Methods Call for Optimizing the Organization

Please note: prerequisites for agile methods to work are:

• The clear availability of the team members.
• Their own estimation regarding the feasibility of the requested deliverables.

Both are fundamental conditions of the agile world, which you can also apply in traditional project management to a large extent. However, not only one project manager but the whole organization must be behind this.

Another option is to employ hybrid methods. This means using agile methods for product development and traditional methods for customer projects. In this way, you could streamline a third to half of your resource management, provided the teams are kept clearly separated.

You could also consider following agile methods only in the specification phase of a project. After five Sprints, everyone is much clearer on the goal and the feasibility. The same goes for the integration of traditionally developed components at the end of a project. If they need to be delivered in working order, you can also employ agile methods for half a year.

Separating the staff for internal product development and for customer projects

Successful Resource Planning Based on the Example of TPG The Project Group

At our company, TPG The Project Group, we have been developing software products according to agile principles for the last eight years. For customer projects, on the other hand, we use traditional methods and work in a matrix organization. Internally, both follow the same cadence of two weeks.

Team members have stopped switching between customer projects and product development a long time ago.

See also Program Management Solutions in Product Development and R&D.

As you can see, we are not struggling with resource planning in product development, only with finding new colleagues.

At TPG, we take great care to come and meet all stakeholders, keep them informed and involve them in the prioritization of the features.

We deliver releases of our products every two months. In release planning, product management makes suggestions of what could go into the next release. The suggestions are based on the points the development team estimated for the effort. These points must match the available capacity.

Due to the fixed team size, the capacity only changes if new employees are hired or if someone is on holiday or unavailable due to sickness.

We include team meetings, training etc. as visible activities in planning to achieve full transparency. All participants can see:

• The amount of time or points available in the following two months.
• How much time or points the team has realistically allocated for what feature.

Development, consulting and sales have a say in determining the coming features; product management has the power of veto, at least on paper.

The release planning meeting ends once a generally accepted decision has been made. With a bit of mental arithmetic, everyone is also entitled to ask for more, but this is on the condition that they state what they can forego.

At our company, a release-planning meeting usually takes from 2pm to 5pm (every two months with five to ten participants per product group). However, there is a buffer entitled open end in the calendar immediately after the meeting. Yet, in all these years, the buffer has been used only once – funnily enough at a meeting before which everyone thought that everything was clear anyway and we would not even take an hour.

Of course, changes in the tasks during development are only permitted if a catastrophe occurs.

Our tip: To achieve an understanding of the priorities, it is important to conduct release planning together in the team. A small inviolable buffer for the unforeseen has proved to be beneficial. If you do not need it, your team can simply select the next points from the prioritized task list in the last Sprint.

Long-Term Resource Planning is a Must in Both Camps

As mentioned at the beginning of this article: the resource management topic has different areas.

We have looked at the core of short to mid-term resource planning including the particularities of the agile point of view. Yet, the long-term shell will always stay the same for agile, traditional and hybrid approaches. Capacity planning according to corporate strategy is indispensable for both worlds.

What this means for product development: with each new product, a new team is put together; or it is disbanded if the product is not developed further. Of course, you can also develop more than one product in a team, provided the Product Owner is the same. After all, someone must set the priorities.

For long-term resource planning, you need a strategy provided by top management and an established PMO controlling the project portfolio for implementing the strategy.

This includes the necessary means such as:

• Standardized methods
• Established processes
• Support of project managers and team leaders with training and coaching
• A role-based tool with a central database

Ever wondered if and how a PMO can be agile, too? Read this insightful article.

Conclusion – Resource Conflicts in Projects: The Cadence Is Essential

In our view, adhering to the cadence in collaboration is the most important factor in avoiding resource conflicts. By this, we are stressing the importance of dealing properly with one another, even if it can get critical at times. And the synchronized cadence of planning, coordination and decision-making across all projects and resources is important.

Find the essential points for avoiding resource conflicts in project management once again below – regardless of the tough discussion on following traditional or agile methods.

• Project resource management must be complete, or it is unserviceable. Rather include all projects with a rough estimate than only a few projects in detail.
• Whoever aims to implement more projects than is possible in terms of resources has to state beforehand what they are willing to forego. In the end, less is usually more.
• Allow the team to make their own estimates. This will make planning realistic.
• Try to keep the make-up of the teams as constant as possible. Every change is a loss.
• Be accurate in planning the basic load; otherwise, you will always assume incorrect availabilities. To achieve this, you need to involve the team leaders successfully in planning.
• Work with a PMO in the same cadence across all teams. This will reduce conflicts.

Depending on company culture, resource management can be a delicate issue or not. The selection of methods, processes and tools plays an important part in this.

In the end, only those involved can establish satisfaction with this topic.

What are the main pain points of resource coordination at your company? We look forward to receiving your comment below.

About the author: Johann Strasser, a certified engineer, has been a managing partner at TPG The Project Group since 2001. After many years as a development engineer in the automotive and energy sectors, Johann Strasser spent a decade as an independent trainer and consultant in the field of project management. During his tenure, he also served as project manager for software projects in the construction industry and provided scheduling and cost management support for large-scale construction projects. At TPG, he applies his expertise in product development and consulting services for international clients. His special focus is on PMO, project portfolios, hybrid project management, and resource management. For many years now, he has shared his knowledge through presentations, seminars, articles, and webinars.

You can read more about Johann Strasser on LinkedIn and XING.

print this article