CXO

Are your tender requirements killing your IT project?

Plenty of organizations have well-formed procedures for procurement on large projects, but when the projects are small, the contracts are short-term, or the budget is low, those same procedures can easily become a crippling overhead to both sides of the procurement process.

Plenty of organizations have well-formed procedures for procurement on large projects, but when the projects are small, the contracts are short-term, or the budget is low, those same procedures can easily become a crippling overhead to both sides of the procurement process.

Whether you're sourcing training, software, hosting or bespoke development, an RFT (Request For Tender) with unnecessary, unrealistic, or just over-the-top requirements can make it too hard for some companies to commit the time required just to do the paperwork. In extreme cases you end up with vendors that specialize in meeting tender requirements instead of specializing in the service they're pitching to provide.

Here are my five tips for reducing the pain of running a tender process for smaller projects:

1. Focus on the outcomes not the how to's

You may have a solution in mind when penning a RFT, especially if you've worked on similar projects in the past. However, treating the solution you'd expect as a requirement can be a mistake. Remember that the whole point of a tender is that it lets suppliers pitch on price and solution. Concentrate on the specific outcomes the project has to achieve and the standards that need to be met, and leave the "how" for the vendors to figure out; it's their job anyway.

2. Avoid legacy and CYA requirements

Be careful of setting standards and requirements based on past vendors rather than the current project. It's easy to do and not always deliberate as people will associate particular skills/resources/approaches etc with previous success without even realizing it. Also be wary of requirements intended to make sure that any successful tender will be easy to defend to upper management. Such requirements may seem like a good idea but they can exclude companies with better solutions from entering your vendor pool. If the tender is good you won't have trouble defending its selection.

3. Don't make writing the tender a job in its own right

Asking too much from a vendor in the tender process can make your tender less appealing. Asking a vender to supply an example financial statement with its tender is fine if you really need to ensure the long term financial stability of the vendor, but it penalizes and offends some smaller vendors unnecessarily. Asking for too much material as part of the tender itself can also be seen as a sink of non-income-generating-time for your vendors. A good litmus test is to not ask for anything you aren't going to read fully. If you plan on just skimming something, then ask for the summary not a book.

4. Don't discount LVV (low value vendors)

Small companies don't necessarily mean lower quality. They can be small because they cater to a specialization or a particular niche. Take the time to separate your expectations of the project from your mental image of the perfect vendor. The same goes with new companies and start ups, they may have other ways to satisfy concerns over capacity and quality other than being the biggest or oldest company on the list.

5. Carefully review the IP requirements

Intellectual Property is a huge issue in IT project and the default position in most RFTs is that the client wants to own everything. While it sounds like the logical thing to ask, it's often not necessary. Do you really need to own all the IP? Or do you simply need the full rights to use and modify it without attribution? Are you going to market the system or just use it in house? Does it need to be proprietary code or can some libraries/components be open source? Not insisting on total ownership when it's not needed can drastically increase what a vendor can do within a budget. Take the time to look through the creative commons licensing definitions if you need inspiration.

Bottom line

If your project is small in budget or scale then you need to make sure that your RFT is small-vendor friendly. The demands you make of large vendors may be impractical on smaller projects and end up costing time and money you don't have. However, if you take the time to be clear on what you really need and step away from your preconceptions you'll find your vendor pool is fresher and more competitive. Just keep in mind that for the vender, getting a tender accepted should be the start of the hard work not the end of it.

About

Ben Evans is a consultant, an IT pro, occasional CTO, system architect, JavaScript Jedi, and blogger. Ben has run his own business, been a program manager at Microsoft, a tech director for a London design agency, a contractor on the BBC iPlayer proje...

2 comments
Slayer_
Slayer_

We have an on going example. Merging domains, we have two companies joining. the bought company is merging in their domain. About 15 workstations and about 8 servers. 2 years and counting, they still haven't even done a test run, they are still documenting things. Getting approvals, etc.

robinfgoldsmith
robinfgoldsmith

Indeed too many organizations confuse paperwork overhead with meaningful procurement. Content is critical, and form should serve the content rather than take on a life of its own. Unfortunately, people repeatedly mislead themselves into skipping acquisition processes, which may not make a difference if the processes are ineffective anyhow. Regardless, failing to follow effective acquisition processes can turn those small short-term projects into large longer-term and possibly never-completed projects that fail to provide needed value. Your guidelines are on target. The keys are accurately discovering your REAL business requirements that the vendor must satisfy, keeping the legal burden of responsibility on the vendor for satisfying them, and incorporating suitable testing to help the vendor assure they’ve delivered correctly.