User stories not requirements will give us better outcomes – discuss

I pitched a session at #procurementunconference19 boldly titled ‘User stories not requirements will give us better outcomes’

I wanted to find out if other people had experiences to share about how we move away from long lists of requirements, developed in silos, then given to suppliers – to a more collaborative, outcome focused way of doing things. 

At HackIT we use the digital marketplace where we can, and make wide use of CCS frameworks. I used a recent example of a procurement for ‘printing as a service’ where we’ve tried hard to give the suppliers space to tell us what they think the solution might be for us, rather than specifying every detail in advance. 

The discussion around the table was incredibly useful – a host of examples of where people are trying new things, facing challenges and being bold with their approaches.

Here’s the top 5 things I wrote down during the discussion:

Too often we’re trying to buy something where we’ve got uncertainty– and instead of trying to make it more certain (by locking down requirements) we need a way of embracing the uncertainty and using it to get better outcomes overall. Otherwise we risk buying the wrong thing.

Procurement works best when you have the right people working together at the right time, who understand the problem you’re trying to solve. This means having product groups and multi-disciplinary teams in place, and break down professional silos where documents are passed from team to team.

Can we use experiments to understand the problem – and if so, how do we make experiments as small as possible? The smaller they are the less risk you have, which means you can fail faster. For example – we’ve added in a 6 month pilot of our new ‘printing as a service’ solution, but could we have made this smaller and more iterative? How can we involve suppliers and users during our experiments?

Can we use KPIs that measure delivery against culture and approachwhere we might usually only use outputs (eg availability), and if we could do this what would our measures be and would it drive innovation and engagement?

There was an example of teams using story points or dev pointsas an agreed deliverable in a statement of work – and of teams planning in advance to create iterative statements of work in collaboration with suppliers, rather than fixing an overall statement of work at the start.

Notes from #procurement unconference19, Session 1 – Bear

Originally published at madebycate.mclaur.in

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.