Procure to Pay Process – Making Procure-to-pay Agile: Part Two

This is the second post in a series of posts about making procurement and accounts payable more agile focusing on how to continuously improve processes.

In the first post we looked at the “why”. In summary, making procurement and accounts payable more agile helps you continuously capture new cost savings opportunities and improve job satisfaction of the teams involved.

The next posts are all about the “how”. I will cover 3 specific areas:

1. How to continuously improve the process (this article)

2. How to best organise the team

3. How the team can stay agile on a daily basis

Why continuously improving the process is key

The first “how” that needs to be considered is how agile teams can continuously improve their processes. I start there because it is the very essence of agile. If there were to be only one test of how agile a team is it would be how effective they are in improving their own processes.

Most efforts to make an organisation more agile focus on what I would call “ceremony”. In software development, that ceremony could be organising the work in “sprints” and having “daily standups”. In teams that wish to emulate the Spotify model that could be organising in “Tribes” and “Squads”.

These things are important, but if a team is not able to improve its own processes quickly they won’t make a big difference.

In agile, improvement is delivered frequently and in small iterations. Short feedback loops are used to adjust quickly based on real-world feedback. If the team cannot adjust their own processes quickly, they can therefore not be agile.

The way in which most agile teams improve their own processes are through bi-weekly or monthly “retrospective” meetings with all team members. In these meetings the team reviews what went well and what didn’t go well lately. They then celebrate the things that went well and decide how to address the things that didn’t go well.

How to continuously improve the process

As with everything agile, the team should decide on their own format for these retrospective meetings, but the following agenda has worked very well for me in the past:

– Review past improvements

– What went well and what didn’t go well

– Deciding new process improvements

Let’s look at each of these in a bit more detail.

The meeting starts with a review of improvements agreed in the past to see if they have been successful or not. I used to classify the improvements in three categories:

– “Acquired” which means we no longer need to discuss them every meeting

– “In progress” which means we need to continue to keep an eye on them and maybe adjust them a little

– “Abort” which means we cancel them because they didn’t have the desired effect or were too onerous.

It is useful to have a central, online place where all process improvements are kept. This will make the meeting more effective and it will also serve as a central repository where everyone can always see what they are supposed to do.

In the second part of the meeting all team members get to voice what went well and what didn’t go well lately. I always start with people writing their feedback on (anonymous) post-it notes which are then stuck on a big whiteboard. This allows even the more junior or introverted members to voice their delights and concerns which is very important for a good team dynamic. Once all suggestions are put on the whiteboard, they are grouped by topic which helps in prioritising and making the discussion more efficient.

For all areas identified as not going well, process improvements are brainstormed in the third part of the meeting. We are looking for improvements that the team can implement and that do not negatively impact other processes.

Most importantly (and this requires a strong moderator) many alternative solutions should be heard and nobody should be able to veto an improvement just because they don’t like it. Either someone has a strong argument why it wouldn’t work, or they can’t object. Always keep in mind, it is better to try something and review it next meetings than to not try it at all.

Pre-conditions for continuously improving the process

This process works really well provided two things are in place:

1. The team has sufficient freedom and skills to allow them to identify and implement improvements for most of the problems they face

2. The team has clear targets to measure progress against so their improvements benefit the whole organisation and not just the team itself


In summary, to create a well-functioning agile team they have to be able to continuously improve their own processes. This requires that the team reviews progress and identifies improvement potential in a structured and regular way.

It also requires that the team can improve their own processes and knows what good looks like. How to best organise the team to make sure that is the case will be the topic of the next post.