Let’s be honest. No one likes the procurement process. You are probably bored and slumped on your desk having just read the title. I doubt you have even clicked the link to read this article. But you should.
A bit of background
Selecting software and picking vendors is technical and tedious. It’s filled with complex specifications and lengthy documentation. There must be a better way? Something easier?
Maybe there is…
Agile frameworks
I won’t try and recap what Agile is at this stage. If you do want to find out more then you could try exploring this blog. There are a variety of articles exploring Agile ways of working.
Also a word of caution. For the uninitiated, Agile frameworks can feel a little unpredictable. This is particularity true when they are used to rigid waterfall project approaches. I’d go as far as saying they can feel a bit like people are making stuff up as they go.
That’s half true.
Although the process steps are defined and the approach is clear. What happens within each step can’t be predicted in advance. Nor should it be possible to. That’s where we traditionally go wrong.
Design thinking
Design-thinking isn’t typically applied to software and vendor procurement. But it should be.
The aim is not to solve a problem in one single moment of creativity.
It allows us to embrace unknowns. To make discoveries at each stage of the process. To act accordingly with the insight that this new found knowledge gives us.
You probably aren’t special
Sorry to be so blunt…
Few functions in any business do something truly unique. Sure, there will always be exception. But for the vast majority this holds true.
Most of us are trying to complete tasks that countless others across the globe are also faced with.
The wheel is already invented: So let’s try that first
Starting from that premise. It’s very likely that software already exists that can support the outcomes you are trying to achieve.
To find it we need step away from the idea that our existing processes are set in stone. Instead we need to open ourselves to the idea that so long as we are starting in the same place and ending with the same outcome, there are a variety of ways to reach that goal.
- What are those outcomes?
- How can we distill those down?
- What are the key requirements that need to be built into each outcome (regardless of existing sequences and preconceptions)
Now the challenges becomes finding the solution that best matches the culture of the team.
More importantly asking ourselves:
“Why couldn’t we use this solution?”
Welcome to outcome-driven specifications
This is a more user-focused approach. It leans heavily on tried and tested design-thinking principles and ways of working.
Outcome-based specifications are far more user focused. They have a greater likelihood of getting us to effective results faster.
They may not feel as thorough as a 300+ page Request for Proposal (RFP) document. Yet the greater risk is often encountered when we mistakenly emphasise the importance of the wording of a specification rather than its underlying intent.
We ruthlessly eliminate countless options immediately when we start with complex technical requirements.
- What avenues might we prevent ourselves from exploring?
- What surprises and insights might we have gleaned if we’d remained open to letting them show us how they’d achieve the outcome we want?
- Can we really assume we know the best process?
- What does best practice look like to their clients?
A simple manifesto
This approach can be distilled by this simple manifesto. And yes this is heavily influenced (to the point of blatant plagiarism) from the Agile Manifesto.
A step-by-step approach
The actual phases can be broken down into six key stages.
1. User workshops and interviews
The purpose of these initial activities are to understand the users. A kick-off workshop should set the tone. The senior sponsor should give a clear statement for the vision.
Further workshops and interviews should result in:
- Detailed user personas
- Current frustrations laid out bare
- Existing processes mapped out
- Knowledge and exposure to possible solutions
- etc.
NOTE: You will use a lot of post-it notes.
2. Software research and analysis
Software research and metric scoring takes place in parallel to the user workshops and interviews.
This first stage analysis should focus on market leading solutions in the sector. We should also consider any existing business platforms.
How this research is carried out and where data is sourced is up to the technical specialists. Their aim should be to identify a solid list of contenders to evaluate and explore further.
We should only reject solutions that fail to meet critical requirements at this stage.
3. Initial vendor questionnaire and software discovery
This stage is where the real magic happens. We start by issuing a set of questions to the shortlisted vendors. These questions are focused on them and their solution. Not on us at this stage.
Out with the old. No more spreadsheets for vendor questions. Let’s use more modern tools and provide them with a convenient and responsive digital questionnaire. I really like Typeform for this (but other questionnaire tools are available).
We follow up with an online call with each of the vendors. This is an hour to introduce ourselves. To give them a quick brief on the project we are considering them for. To go through their answers and grill them more thoroughly. We’re looking for them to ignore their usual sales pitch. Instead we want them to bring their solution to life and demonstrate functionality.
4. Formal vendor demos
The finalists can now be invited to make a formal pitch. A brief is issued to each vendor with our distilled project mission statement and a clear mission statement for them.
The tasks are set as stories that link our user outcomes. Output-driven and open ended. The tasks are designed to explore their solution. To let them show us what best-practice looks like for their clients.
- Which would the team be able to embrace most readily?
- Which could the team work most consistently and effectively with?
- Which will blend with the culture of the team and help it mature with the least friction?
5. Solution selection
This last piece is the hardest, or depending on the vendors and their solutions, the easiest.
As a group we review the performance of all the vendor demos. We should be looking at the completion of all the tasks. Their ease of use. Their cultural and business fit. The realities of their short- and long-term impact on costs.
Procurement can then negotiate with each of the final preferences to get us the best possible deal.
Finally, we can look to review with the senior stakeholders for final sign off for implementation.
6. Implementation
This can go however you want it to. It is also where we stray back into familiar territory.
The vendor should provide guidance on how they would handle a project like this. They are the experts on their system and its users. After all, what’s the point in going down the Software as a Service (SaaS) route if you still spend money to shadow and ultimately duplicate their work – are you really saving much money if you do this?
Also it’s vital that you make sure that the plan for hand-over is solid. With training, hypercare, and a phased approach for firmly planting the system and updated ways of working that come with it.
Mess that up and even the best solution in the world won’t stick.
Tips for success
- Challenge acronyms and technobabble from the start and use plain English).
- Be open and honest with the stakeholders and product owners. Tell them how the process will work and what you need from them.
- Representatives from the team should be included at every stage.
- Total transparency and education are vital to buy-in.
- Refer to the mission statement, guiding principles, and user outcomes at every stage.
- Be prepared to be surprised.
- Expect people to want to revert back to what they know when unsure.
And the final twist…
This is not theory. This process works, and can even be fun.
These are lessons we have learned. The process is in fact already iterating with each project it is applied to.
So who knows? You might enjoy the next time you are involved in software or solution procurement.