The Trials and Tribulations of a Tender Process

I hate tenders. There, I’ve said it. This article is all about why, and what I think the better approach is.?

First of all, let me say I used to love a good tender process. Years ago, fairly early on in my Salesforce career, I was a sales person and one year I hit my target just on tenders alone. I was good at them: they’re very similar to exams, and I’ve always been good at going through the process of passing an exam. You’re set a task, you understand the rubric, and have some fairly clear parameters within which to operate. Tick the right boxes, and you’re in with a good chance.?

But that doesn’t make exams a great way to assess intelligence, nor does it make a tender a good way to make a product and/or partner selection.?

For many organisations, the tender process is simply the default one: you have to because the board says so; or you do just because you always have. If your organisation typically goes out to tender, it might surprise you that the vast majority of the organisations we work with take a different approach to selecting a partner and product.

The things we think are important when it comes to choosing a product and partner are hard to assess through a mostly “paper” based exercise. We think a partner’s values and ways of working are the most important indicators of success, along with the client’s flexibility and approach to partnership. These things can’t be assessed through a written response and a few cursory meetings.

Nor will you ever be 100% sure that the product you’ve chosen will deliver to your exact requirements because what’s been written and responded to in a document always leaves room for assumptions to be made (see below).?

Picking a partner to work with is a bit like dating: you both have to agree you’ll work well together. Going through the “sales” process is just as much an opportunity for us to assess you, as it is for you to assess us.??

So here’s why I think tenders suck:

• They take too long?
• People are more important than paper
• Expectations aren’t aligned
• Ways of working impact cost far more than the technology

They take too long

By the time you’ve workshopped the requirements, written the tender, gone out the market; assessed the responses; shortlisted potential partners; seen demos; chosen a platform and a partner; worked your way through negotiations and contracts; and finally agreed a time to kick off, too much time has passed and what you wanted has likely changed.?

At best, the process described above can take 6 months; at worst, it can take over a year. That’s just too long compared to the development lifecycle of most tech products. By the time we get started, what the organisation and the users need has changed. And the platform itself will have changed too.?

Now that doesn't have to be a massive problem unless a) the new requirements can’t be met by the solution you’ve chosen; b) the client or partner insists on sticking to the tender requirements to the letter even if they’re out of date; c) the client expects the estimate based on loose requirements at the tender stage to be the same as the estimate based on actual discovery.?

Which takes me to the next reason I hate a tender process.

Requirements are never detailed enough

I love this quote from a recent Tammy Ven Dange newsletter where she says "I generally put a 30% to 50% contingency on a vendor’s implementation costs".?

I’ve been working on Salesforce implementations in various roles since 2009. I’ve never seen a project perfectly estimated. I’ve seen projects delivered on budget, and on time, but that’s usually been because scope has changed. Compromises have been made.?

People expect house renovations to go over budget: that’s not a surprise. And yet you can quantify a house renovation much better than you can a solution implementation. Once an building architect has done their job, you should know exactly how big the house is going to be. You should know what the bathroom and kitchen will look like. The client will have agreed a budget for tiles and carpet. And so on. Each element of a house renovation can be priced quite accurately at the end of the “discovery” process.?

And yet it is expected that costs will blow out.?

You could argue that at the end of a technology discovery phase, the partner and the client should be in complete agreement as to what is going to be built, but that is rarely the case. And nor should it be. Unlike building a house, you aren’t suddenly going to change what you want because there’s a new shade of blue you’d like to use in the bedrooms (well you might, but it’s unlikely to change the price that much!).??

Change is one of the givens in a technology project: what you want now, will be different to what you want in a year’s time. Heck, it might even be different in 2 months time! Lock yourself into exact requirements at the start of a tender, and you’ll end up with a solution that no longer meets your needs.?

“But,” I hear you cry, “tender requirements are deliberately not that specific to allow for change.”?

And that is partly true, but you can’t both have vague requirements AND accurate pricing. Heisenberg’s Uncertainty Principle might apply here!

Expectations aren’t aligned

As I’ve illustrated above, the first expectation that can cause problems is the estimate of cost. Client expectations are that the detail they’ve provided in the tender is sufficient to provide a robust estimate of effort, and therefore cost, to implement a solution.?

My expectations when I read a tender document is that the requirements give an overall level of complexity. I don’t go through each requirement and exactly cost out what I think it will take to deliver, because I know that a) those requirements are not detailed enough for me to do that; and b) they’re going to change anyway.

Instead, we make an estimate of effort based on what we perceive to be the overall level of complexity. And we have to make a lot of assumptions about what a single sentence in a spreadsheet actually means.?

But let’s assume that two organisations have exactly the same requirements in their tender documentation, the estimates to deliver a solution to both of them will NOT be the same. Let’s go back to our renovation example: a four bedroom, two bathroom house for one family, will not cost the same as a four bedroom, two bathroom house for another family. What impacts the cost the most: the people. Family A might want marble tiles in the bathroom and granite work surfaces in the kitchen. Family B are happy with ceramic tiles and laminate work surfaces. Family A might want to be really involved in the build process, make decisions on the fly and changing things as they go. Family B just wants to get the build done so they can move back in.?

Which takes me to my next point.

People impact cost more than the technology

The greatest indicator of project success is NOT the technology you’ve chosen; it’s the people you’re working with, the relationship they develop, and the ways of working they put in place. That is almost impossible to assess via a paper-based exercise like a tender.

Let’s imagine your tender says “The solution must send a receipt every time a donation is received to the donor by email or mail”. You could imagine that this functionality would cost the same no matter who needed it, right? I mean any organisation that fundraises needs to send receipts. Surely the process is pretty much the same, give or take?

And yet I’ve worked on projects where the receipting process has taken anything from 3 days to 3 weeks to deliver. If the process and the technology used are pretty similar, why the difference?

People. On both sides. This isn’t a client bashing exercise!

We have ways of working and expectations about how things are done: that’s based on years of delivering projects to NFPs, but that doesn’t make it right.?

And sometimes a client can have very fixed ideas about what they need in a solution. If the two aren’t aligned, then we can get into trouble.?

Let’s look at some classic examples taken (with some liberty) from tenders responded to:

• The CRM must be able to produce compiled case notes for clients, merging in client information:?Well this is relatively simple to do using a document generating solution like Conga, or the document generating capabilities of Nonprofit Cloud, but turns out the documents in question could easily be over 500 pages long, and need to pull information from multiple different areas of the CRM. Not what we anticipated during the tender process at all.??
• The CRM must have the ability to record inbound and outbound emails:?well yes, Salesforce does that. But does this requirement mean it needs to be automatic? Does it mean all emails received via Outlook/Gmail/whatever need to be logged in the CRM? What records do you want to log emails against? Do you want to be able to send emails from within the CRM? And so on.

Both simple requirements that for the most part are fairly straightforward to deliver, but both have nuances that might not become apparent during the estimating process. They might not become apparent even during discovery. And when you’ve got over 200 requirements that can all have different levels of detail and complexity behind them, the process becomes very problematic.??

So what’s the alternative?

Well there’s the standard “sales cycle” of working with an organisation through conversations and the sharing of information until you get to a point of agreeing that a) you can work well together, and b) the solution on offer does most of what is expected. But if that’s not rigorous for you, here’s an alternative approach:

1) Define 5-10 high level product requirements (not feature requirements) for the solution you’re looking for. That could be:

• Must be cloud based
• Must have a roadmap of improvements and innovation
• Must be used by a significant number of similar organisations around the world
• Must be flexible enough to meet our needs now and in the future
• Must deliver the following key functionality: fundraising, case management, program management, etc
• Must have a robust support offering
• Must have open APIs to allow for integration to other solutions
• Must be accessible on a mobile device
• And so on (you define what’s important to your organisation)

2) Do a market scan of what products are available and assess them against your high level requirements.

3) Approach each product vendor for partner recommendations and define your ideal partner. Similar to the product requirements, these could be:

• Has significant experience in the NFP sector
• Has staff that have worked for NFPs
• Has a team local to us
• Has values that align to ours

4) Shortlist a small number of partners for each product.

5) Hold introductory meetings with each partner to see if there’s alignment (the first date!).

6) Shortlist down to one partner per product (you may need to have more than one date for this).

7) Undertake a paid Proof of Concept piece of work with each partner (you should have just 2 or 3 at this stage).

8) This POC will both allow you to assess the product as well as the partner. Preferably the POC should be long enough to allow you to see how the partner works, and test particular aspects of the product.?

At the end, you’ll know for certain:

• How each partner works
• What each solution looks like and can do

And the partner will know:

• Whether they want to work with you!
• Whether their product will deliver what you need
• More about you and how you work so they can put together a better estimate of effort for implementation.

In total, with 2 partners to work with, this process shouldn’t take more than 3 months to complete, and at the end, you have a working prototype that you can kick start the actual project with. You’ll also have done some of the discovery process allowing you to move faster and get a return on your investment sooner.?

I call that a win win win!

Next month, we talk to Benjamin Jordan , Development Director at The George Institute for Global Health about their Case for Support and why he thinks every organisation should have one.

I wish you all the success in your mission to make a difference. Keep striving for excellence, and together, lets continue to make a positive impact by sharing expert strategies for changemakers with Not-for-Profit Navigator.

Until next time,

Nicole

Article and Resource Recommendations

• GrantOrb: Use AI to write your next grant application. Try it out with a simple requirement and if you like what you see, there are low-cost subscription options.
• Major Donor Webinar from Donor Republic: Some interesting insights into how you can use a case for support to drive your fundraising outcomes.?
• AMP Impact Quickstart: Portfolio Management and Impact Measurement.
• Data Driven Asks: Using AI to maximise your fundraising.?

Some of the best places to find grants/philanthropic donations:

• The Funding Centre by Our Community
• Grant Connect: Federal Grants
• GEMS: Largest grants portal
• PAF Guide: information on all the private ancillary funds

Find out who’s donating to what:

• Gift Search

Executive with a Cause: If you’re not already subscribed to Tammy Ven Denge’s newsletter, you should be.?

Learning and Growing

Find out how to manage your fundraising on Salesforce by completing these Trails.

Upcoming Events to Attend

• Fundraising Forum: 27 - 29 August at Aerial Function Centre at UTS, Ultimo, Sydney. Check out what’s on the agenda.

Melbourne User Groups

• World Tour Essentials: Come along as Salesforce brings the World Tour jamboree to Melbourne! No we’re not the poor cousin, honest ??
• NFP Group: June 20, 4pm. Attend in person or virtually. We’ve not locked in the content yet! Register here
• Women in Technology Group
• Salesforce Group
• Marketer Group (Pardot)
• Marketing Cloud Developer Group
• Architect Group

On Demand Content from Salesforce

• Slack to onboard and enable volunteers.
• Increasing Donations through personalisation and automation
• APAC Nonprofit Forum: Program and Case Management?
• APAC Nonprofit Forum: Outcome Management