Nicely done Nick!

Oh, for that project we found a solution that wasn’t to put 12 line items on the PO, which was going to create a lot of work elsewhere in the organisation – the PO had “true” line items about the expected deliverables, and the procurement system was able to track estimates of accrued work separately, linked in to the service receipting, with no extra (BAU) work for anyone.

An example from a recent project for me, to put a procurement system (applications and processes) in place:

X: We need to be able to raise purchase orders with 12 line items.
A: Why?
X: Because we have to have one line per month on each purchase order.
A: Why?
X: So that we can receipt services received each month.
A: Why?
X: So we can run a report of anomalies between services receipted this month and the line item.
A: Why?

And so on (of course, not being so rude and blunt as to just ask “why?” each time!) until you get to the real reasons – so that they can make sure they’ve not overlooked any services that were expected to be done this month, so they can check the quality of the forecasting over the year, to act as trigger for redistributing the approved spend of a different timescale, and a few others.
Depending on the project, you might want to pop those a bit further, but for us this project that’s where we were hitting our “value” layer, as those items were part of the business environment into which our project was to fit (not things we had a brief to change.).

Nick