Agile Resource Planning – Can Agile Planning Reduce Resource Conflicts in Projects?

Agile resource planning methods can prevent resource conflicts. In times of scarce resources, most companies struggle with resource management. This article outlines how agile methods can make a difference in this area. It also looks at the prerequisites and constraints this approach involves. For instance, the approach works well for software development projects but would fail in construction projects.

You will learn how to approach agile resource planning in the following chapters:

• Relevance and satisfaction are poles apart
• Fixed teams – The basis of realistic planning and high quality
• Fewer resource conflicts thanks to open-ended results
• Agile resource planning calls for optimizing the organization
• An example of successful agile resource planning
• Long-term resource planning / capacity planning is a must
• Agile resource planning – The cadence is essential
• Conclusion – Agile resource planning

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.

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.

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

With agile methods – to stay with our metaphor – employees will not constantly have 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.

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.

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 Resource Planning Calls 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 approach for this is hybrid project management. 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.

An Example of Successful Agile Resource Planning

At TPG The Project Group, we have been developing software products with agile resource planning and agile methods for the last ten 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 stopped switching between customer projects and product development a long time ago.

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 / Capacity Planning is a Must

As mentioned at the beginning of this article: the management of resources 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 project management office (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.

Agile Resource Planning – 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. Likewise, the synchronized cadence of planning, coordination and decision-making across all projects and resources is important.

Conclusion – Agile Resource Planning

Below, we list the essential points for avoiding resource conflicts in project management once again below – regardless of the discussion of whether to employ traditional or agile methods or both.

• 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 between agile resource planning and traditional projects.

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.

Our final tips:

Get to know the individually adaptable “PPM Paradise” – the optimal environment for your enterprise-wide project, program, portfolio and resource management (PPM). Download the free eBook “The PPM Paradise” now (just click, no form).

And sign up for our bi-weekly blog newsletter with information on more hands-on articles, eBooks, etc. to improve your project management maturity level.

What are the main pain points of resource coordination at your company, and could they be remedied with agile resource planning? We look forward to receiving your comment below.

print this article