The Tender Art of Process Re-Evaluation

Data protection is a topic commonly pushed out to tender. And I understand why: depending on how far forward into the future you’re looking, it may be a multi-million dollar exercise (or much more). It affects much of your IT systems, and increasingly, has to straddle on-premises and the public-cloud.

And that’s why most businesses run tender processes for data protection completely wrong.

1. Tell me which of these criteria you can meet. (Functional, and non-functional requirements.)
2. Tell me how much time it will take to have it ready.
3. Tell me how much it will cost.
4. Tell me all this with extreme haste.
5. Tell me all this with extreme accuracy.
6. Tell me all this with extreme brevity.

This isn’t the way to get the best result. At best, it’s a way to evolve the status quo.

Let’s look at the Extreme Haste/Extreme Accuracy/Extreme Brevity (4, 5 and 6) aspects first. This is like the so-called ‘golden triangle’ business rule: “You can have it fast, cheap, or good. Pick two.”

“You people respond to tenders all the time. So it doesn’t matter that we issue the [190 page] tender at the start of Easter with a 10 day deadline. You’ll have all the answers [to the 450+ questions] already.”

Actual statement.

Perhaps unsurprisingly, while there is a lot of overlap between questions asked in tenders, even in industry verticals, that doesn’t mean all such answers are to hand immediately. It also doesn’t mean that people have all the time in the world to answer. So, my honest advice here is: if you’re after accurate answers, ditch the haste. If you’re after accurate answers with nuance, ditch the brevity. (If all you’re after is haste, the onus is on you to be brief, and accurate, with what you want.)

(Oh, and everyone deserves their free time. Everyone has weekends, family time, plans and a general need to have downtime. Eating into that time isn’t productive.)

So now let’s look at the rest of the tender process.

Tenders are, for the most part, a laundry list of functions you’d like. I’m going to suggest something controversial here: who cares?

Sure, everyone cares. Your people who write the questions care. The respondents who write the answers care. Your people who read the answers care. But, respectfully, why?

To see what I’m driving to, we need to understand the difference between syntax and semantics.

[T]he main difference between syntax and semantics is that syntax is concerned with structure while semantics is concerned with meaning.

Pediaa, October 12 2015, https://pediaa.com/difference-between-syntax-and-semantics/

You see, asking about functions, time and money is trying to reduce your problem to one of syntactical accuracy, when your outcome needs to be semantically accurate.

While it’s true that many tenders include non-functional requirements as well as the functional ones, the non-functional requirements usually lack the context required to achieve true meaning.

And now we get to the most important word in the title of this blog post:

Process

Tendering for a new data protection solution should be laser focused on process. Technology, cost and time should flow from process, not the other way around.

When preparing for a tender, there are three things you should be asking yourself about your processes:

1. What business processes do we have that must be adhered to by any new data protection solution?
2. What business processes do we have that have evolved to suit our current data protection solution, and could change?
3. What business processes do we have that have been forced on us by our current data protection solution, and we want to change?

You’ll note in each case I’m stating business processes, not IT processes. Why? IT processes exist to serve business processes. In the same way that you should plan your business continuity for business, not IT functions, you should likewise make sure you plan for a new data protection solution with a first order priority being evaluation against your business processes.

That means you start by thinking about all the businesses processes that you can’t change, could change, and want to change with a new data protection solution. Once you’ve got those identified, then you can move on to asking the same can’t/could/want questions for IT processes. I.e.

1. What IT processes do we have that must be adhered to by any new data protection solution?
2. What IT processes do we have that have evolved to suit our current data protection solution, and could change?
3. What IT processes do we have that have been forced on us by our current data protection solution, and we want to change?

Now, this is not to say that syntactical questions in tenders aren’t important. They are. As I explain in my book, it’s Never About the Technology and it’s Always About the Technology. In short, you can’t solve a problem by only thinking about the technology, just as you can’t solve a problem by only thinking about the process.

Chances are your business is probably very good at writing syntactically accurate tenders — and ones that cover both functional and non-functional requirements. Yet, syntactically accurate tenders simply result in syntactically accurate responses. Moving forward, it’s time to make sure you’re writing semantically accurate tenders. The great thing is, good syntax contributes towards semantic quality, so it’s not a case of starting from scratch. This is an additive process.

A colleague of mine regularly uses the phrase, “add colour”, or “add nuance”. That’s what a semantically accurate tender is about. Think of a syntactically accurate tender as being high resolution greyscale. Imagine how much richer it would be if you could introduce colour to it by providing nuance to the why of what you’re asking for.

Tenders try to add nuance with non-functional requirements, but in our syntax vs semantics discussion, non-functional requirements without a broader scope of process or intent are just a form of meta-syntax. You might think of the way non-functional requirements are typically stated as being sentences, when paragraphs are required. The paragraphs give you that why.

To add why, you have to start with asking yourself (your business), why. To get a more nuanced response that addresses both the syntactical elements of your tender request and addresses the meaning of what you want to achieve, you need to provide insight into your processes. This allows respondents to provide true nuance in their responses. To do that properly, you need to have answers to those questions I mentioned before: what business processes can’t change, what business processes could change, and what business processes should change? You might even go one further and consider what business processes must change.

There is absolutely no benefit in investing in new technology solutions if you’re going to shoe-horn them into exactly the same way you’ve been doing things for the last ten years. Or, to be more accurate, there is very little chance of benefit by following this approach. Sure, there may be some edge case businesses where the processes are already so {chef’s kiss} that there’s nothing to refine any more. But how often can we look at the business environments around us and think “there’s nothing here that could be changed for the better”?

So let’s say you isolate those processes and process types as part of a review. And you know:

1. What business (and IT) processes must be preserved?
2. What business (and IT) processes could change?
3. What business (and IT) processes would you like to change?
4. What business (and IT) processes must change?

The next step is critical: share them. Make sure they’re available within the tender for your respondents to read and absorb. Provide the context — the nuance to allow semantically accurate answers to your requirements. Answers that go beyond your stated functional and non-functional requirements, and move into the realm of truly speaking to the way you want to evolve your processes.

If you get the process right, everything else can fall into place with true contextual meaning.