Considering an outcome-driven approach to software specifications

Yes or No, focus on the outcome not the noise

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.

Columbo: "Ahhh... Just one more thing..."

Even the most meticulous research will face inevitable Columbo moments. Those unexpected last minute surprises that can traditionally derail the best laid plans…

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.

A typical iterative deisgn cycle. Learn, Plan, Act, Test.
A typical iterative improvement cycle.

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.

Your place in the universe. You are insignificant.

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.

Wheels through the ages, from a siimple stone wheel to a modern pneumatic road wheel.
A wheel’s materials and construction may change but fundamentally remains the same.

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.

A document of A4 paper stacked to above the knee
Say farewell to the traditional and exhaustive RFP documents.

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.

Outcomes, Collaboration, Learning and iteration,Test early and fail fast, Avoid customisations, Long-term thinking

A step-by-step approach

The actual phases can be broken down into six key stages.

User workshops and interviews, Software research and analysis, Initla vendor quesitonaire, Formal vendor demos, SOlution selection, Implementation

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. The Request for Information (RFI) stage is where the real process begins.

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).

By using an online questionnaire we can do things that would be impossible with a traditional spreadsheet:

  • We can achieve more consistent responses by considering the format of each question. E.g. multiple-choice, short- or long-text, file upload, URL, etc.
  • We can score each vendor on completion and attention to detail (by making some but not all questions mandatory to see how thorough they are).
  • We can also apply logic to avoid unnecessary questions. I.e. if they don’t have a feature, they won’t be asked to provide details about it.
  • We can view analytics. e.g. monitored time to complete and time taken to answer.

Open and friendly questions about them and their solutions are the order of the day.

We try to reduce the potential for bias by redacting any identifying details from the answers. We also give each solution a letter to identify it.

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.

This informal pitch should evaluate the speed, simplicity, and ease of use of the solutions. This is where we start to consider which software and vendor might be the best fit.

It might seem a little unfair to be testing them this actively in a friendly initial meeting. But we want their solution to work for us out of the box with the minimum of configuration and little to no customisation. So they should be able to demonstrate most of what we want to see with a standard sandbox or demo environment.

4. Formal vendor demos

The finalists can now be invited to make a formal pitch. A Request for Proposal is issued in the form of a set of outcome based tasks created to test all core requirements.

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. They should as a combination fulfill each of our core outcomes. They should give us confidence in their system being able to meet our user’s needs.

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.

In this pitch we are keen to see branded demos. That they have each made an attempt to create elements of the configurations that we will need, e.g. workflows. To go further than the scenarios and try to understand our users and where they can add value.

  • 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.