Strategic Purchasing for Transformation — turbo charge procurement to accelerate delivery

So you are in a large organisation or government department, and you find that you need some software to help you on your digital transformation journey. What’s your first step?

If the answer to that is to create a very detailed list of specific requirements, and take them out to tender — you could be doing it all wrong, and end up spending millions over budget and focusing on all the wrong things.

This could be you and your suppliers

OK, so that’s a bold statement. What would you advise?

Start with High Level Requirements

First — the detail in the requirements is often way over-specified at this stage. If you can summarise the main system users, their jobs to be done, and any integrations needed, that’s a decent starting point. But most important is to really hone in on the value to be created — why is this project even being started?

These days, we see three main areas of value:

1. Customer experience — to improve sales, engagement, or satisfaction; growth is the primary focus here, along with a desire to be “modern” — but that should be tied to growth! Get specific on what market share you have now, and what the expected improvement should be, and what value that has for the organisation.
2. Workplace efficiency— these areas focus on eliminating waste internally. Typically these involve joining up systems to avoid repeat data entry, automating tasks that are boring, repetitive, or error-prone. Invariably there is more work to do than people to do it, and automation ensures that people are adding value rather than just entering data. But it is worth calculating time savings targets to show the improvement as capacity that can be freed for higher value activity.
3. Legacy Modernisation — where an old system is running out of date, or the hardware / software is no longer fit for purpose, we see many projects start from this basis. For the purpose of this article, let’s assume that no amount of software or hardware updates, nor cloud migration will cut it — you’re going to have to replace it. But that in itself is an opportunity — we should look at the business value as above, and make sure we improve as we replace.

Plan your Architecture

Next, you need to consult your architecture team. Is this new solution something that can be bought off the shelf, or does it need to be built from scratch? What custom software do you already have, and which languages, frameworks, hosting options, and suppliers do you have engaged? How well do those existing paradigms work — can you go better, faster, or cheaper?

If you don’t know that part of the market, engage a consultant to do some research across your team, and create some strategic principles.

When I worked for P&G early in my career, I loved the clarity that the architecture team brought. There were principles like “We buy for market parity, and we build for competitive advantage” — meaning that the vast majority of the ERP and logistics world I worked in used internally hosted COTS software, with SAP as the named primary solution globally. We had to go a long way to justify a non-SAP solution in that space at that time.

But every organisation is different, and technology moves on, so it’s worth having a strategic direction in place, updated every few years. There are so many possible options out there to solve problems, that aligning on a hosting, platform, language, and support model that fits can narrow down the field when it comes to procurement later.

Explore the Market

Now, if at this point you find an off-the-shelf solution that closely matches your needs, then great! That’s a good time to get into a software purchasing cycle. But again, don’t fall into the trap of listing every requirement in minute detail. If I look at the ERP space again, everyone can do a purchase-to-pay cycle, or manage inventory. You won’t learn much by putting out a huge RFI for commodity capabilities.

Instead, focus on your pain points — why doesn’t your current solution work? What features seem difficult, or challenging? What makes your business unique?

Ask for the hard demo, not the canned video, and make sure they address your specific areas of interest that translate to business value. Focus on the areas that seem hard. In a SaaS world, customising solutions can be particularly difficult, and hard to maintain — try to keep that down to 5% or less of the project scope.

For COTS purchases, use buyer’s guides and consulting from neutral sources, and consider both functional and non-functional requirements — you can move a lot faster with SaaS subscription-based products, but they may not be customisable. But if they’re self-hosted, then maintenance and updates can be painful in the long run.

Often these questions help you narrow down your long list to a set of 3–5 solutions that you can get into properly.

Plan for Custom Code

Now, if more than 5–10% of the project is going to have bespoke requirements, we’re into software development patterns. At this point any RFP you put out will get a bunch of responses that say “we will build software that does it” — and a conservative estimate.

If the COTS solution is big and complex, and still adds value, then we can look at software extensions — where we connect to the vanilla version and manage the bespoke solution separately. In a world of challenges like SAP S4/HANA upgrades, that can be a powerful tool in accelerating a core system update for example.

However, if it’s more than just an extension, consider a fully bespoke solution. While that can seem daunting, most problems have been solved before, at least in part — so the challenge often has demos or accelerators available in the public domain, so you don’t have to start from scratch.

At this point you need to look at your long term needs — what skills do have in house, or do you want to build, versus what can you buy from a software consultancy. What is your comfort level with cloud hosting and storage, and managing software via a code repository? Do you have a preference for Microsoft, AWS, or Google Cloud?

If you’ve tried managing bespoke solutions before, but haven’t got the speed you want — or if you prefer a structured platform solution to build on — a low code solution may be an option- I’ve written about that here so I won’t get into that in this article.

Buy development capability over functional requirements

Eventually, when you are reaching out to buy a software development service, judge suppliers on how they build software, not how well they say they can meet your requirements. Everything can be built — it’s how they go about it that you should prioritise.

Three things I’d look for:

1. History of developing similar scale solutions, ideally in a similar sector — look for 2–3 examples with metrics like the number of users, project duration, team size, and data migrated.
2. A robust process, with quality checks built in — everyone can describe agile development methodologies — so extend that and ask for examples of where some risk management or delivery assurance has proactively identified and handled a serious challenge.
3. Supporting your team — being a product owner on the buyer side is not easy. You’ve got a set of requirements to describe, approve, and prioritise, and a set of solutions coming every couple of weeks to check, test, and approve — ask what support the development team provide to keep you on track, and look for examples of it.

Of course, a suggested team size, ballpark estimation, and rate card are part of a normal process. But put guidelines there too — ask for an estimated duration in months not days. Give a sample team for rate comparison. Give a budget and ask if it can be done inside of that. Ask about part time resources outside that team. Ask about governance and early indicators of slippage.

For bonus marks, set this up as a framework — let several companies succeed in being candidates to build your solutions on your chosen technology stack. And call them off sensibly, rewarding good performance with more work.

But please, don’t ask software development companies if they can build a solution that meets your very detailed list of needs. The answer is always yes, and that doesn’t help at this stage.

Requirements are part of the project

The first thing any supplier of any software or development service will want to do will be to go through your requirements in detail.

No matter how much time you spend up front (and I’ve seen millions of pounds of effort spent pre-procurement) — a professional service provider with direction on the technology will have a different lens on your business.

Not only will they ask better, more specific questions — they’ll also capture them in a way that works for the implementation team, with potential ambiguity thrashed out in review.

That discovery process will also be part of the onboarding and help ensure everyone is on the same page from business goals down to team member actions — and so will create better outcomes for the eventual end users.

Over-specifying in procurement, especially with agile processes, means that decisions made by the product owner mid-flight get challenged by the contract manager on landing.

So consider this as a rule of thumb — high level process flow and organisation breakdowns are enough to procure, low level detail is just part of the project.

Take-aways

1. Determine the high level business processes that are to be supported on a potential new systems landscape
2. Decide on the technical architecture around a high level set of business capabilities required for those processes
3. Choose an appropriate procurement path for the architecture — one that is different for COTS/SaaS software vs bespoke development
4. Determine the right level of requirements to differentiate between potential suppliers
5. Let detailed requirement evaluation be part of the solution, involving the selected supplier

About the Author:
Andy Borthwick is a Solutions Architect in the Advisory Services Practice at Version 1.