This is the third post of a series about why and how to make procure-to-pay agile focusing on how to best organise the team.
In the first post I discussed why procure to pay should be agile. In the second post I discussed why an agile team should continuously improve their own processes.
In this post I will look at how to organise the team so they can continuously improve their own processes. I will look at the size, cross-functional skills required, metrics and the role of a manager.
Size
An agile team should not be much larger than 15 people. The process to continuously improve the team’s performance no longer works for teams much larger than that.
Research suggests that team sizes below 10 are ideal, but because of the cross-functional skills required in every team (see the next section) I personally think up to 15 is still OK.
Cross-functional skills required
To explain how cross-functional a team should be, let’s use an example.
Let’s say an Accounts Payable team is measured on the number of invoices they process per month (I will discuss later whether this is a sensible metric or not).
It is unlikely that “number of invoices processed per month” is an important metric for any other team in the company, so this team has to take full responsibility.
It is likely that the most important way the team can improve the number of invoices processed per month, is to implement better IT tools. This means that the team has to be in control of its own tools, otherwise they will not be able to meaningly improve their own processes.
This solution is a logical one, but it goes against everything that companies usually do. They believe that IT people should work in IT teams and that having them scattered throughout the organisation seems highly inefficient.
The goods news is, you don’t always need IT people for a team to control its own IT tools. That means two things:
– You should select “agile” software tools where most development can be done without developer skills
– You need to make sure every team has enough tech savvy members that are able to learn how to configure these tools
Yordex is a good example of such a type of “agile” tool. It is the first software tool that offers full P2P functionality while still allowing Procure-to-Pay teams to configure it themselves.
Metrics
Good agile metrics should meet three criteria:
– The metrics should contribute to the overall good of the organisation. You should avoid the team implements solutions that help themselves but hurt other teams.
– The metrics should allow the team to come up with ground breaking solutions to deliver more meaningful improvements. Usually that means measuring outputs, not inputs.
– The team should have sufficient skills and freedom to identify and implement those ground breaking solutions. Sometimes that means changing the team, not the metric
The best agile metrics are linked to what I call the “ultimate beneficiary”. The ultimate beneficiary will often be the customer, but for a Procure to Pay team it will be the supplier. Internal stakeholders usually aren’t ultimate beneficiaries unless it is an internal service such as HR or management reporting.
Research has shown that focusing on ultimate beneficiaries (customers or suppliers) not only helps them make better decisions, but also increases motivation.
To go back to my earlier example, is “number of invoices processed per month” a good metric for an agile Accounts Payable team?
It is ok, but it could be better. It is linked to an ultimate beneficiary (the supplier in this case), but the ‘% of invoices paid on time’ would be a better metric because that is what suppliers care about more.
In fact, the number of invoices processed may be more suitable as an efficiency metric. An efficiency metric (also referred to as ‘velocity’), is also essential to every team as they serve a unique purpose. This will be discussed further in my next post.
Role of a manager
Agile teams work independently and define their own improvement opportunities. So what is the role of a manager overseeing a number of agile teams?
Agile frees managers up for the tasks that only managers can do. This includes:
– Setting the right metrics for the team and holding the team accountable to them
– Allocating resources to teams and re-grouping teams where required
– Arbitrating situations where the actions of one team hurt another team
– Developing people, e.g. making sure that they get to rotate among teams and roles
Coordinating programs that involve more than one team is also a task of management or program managers that support them. However, if there are a lot of those programs it probably means that the teams aren’t organised in the right way. In a well defined agile organisation, cross-team programs should be the exception and not the rule.
Conclusions
A team of maximum 15 people with the right metrics and the right skills to significantly improve those metrics can continuously improve their own processes and therefore work in an agile way.
The day-to-day processes the team needs to make the most out of this agility will be discussed in the next and last article of this series.