Is there an alternative to the traditional tender process?

The challenges of software development

For as long as we can remember, responding to tender documents such as ITTs (Invitations to Tender) and PQQs (Pre-Qualification Questionnaires) has been an established way to generate new business. However, in the inherently changeable world of software development the market can shift rapidly, making the expansive, detailed requirement specifications often included in these tenders quickly out of date and obsolete. Invariably, software projects that begin with ITTs and PQQs suffer from elongated timescales and spiralling costs, and ultimately can result in a product which does not satisfy stakeholders or, more importantly, users. In this post we’ll look at some of the key reasons why these issues occur, and demonstrate how at Box UK we’ve adapted our tender process to maximise productivity, minimise risk and produce better products more quickly, for increased satisfaction at all points.

Why is the tender process broken?

The motivation for companies to provide up-front requirement specifications is clear; they want to instruct companies on the type of software development they’re looking to have delivered, to ensure supplier responses are relevant and practical. However, this level of documentation can often actually hinder the response process, as software companies have limited ability to respond creatively, and the requirements may be underdeveloped or, worse, not validated with reference to real user needs. It also limits time spent communicating with stakeholders, or indeed developing software because emphasis is instead placed on heavyweight documentation, functional specifications, and, in some cases, contracts. This is incredibly counter-productive and counter-intuitive to software companies who want to craft high performance software products.

By providing specifications that are likely to quickly become out of date, the ability for suppliers to provide comparable quotes is reduced and can lead to an arbitrary negotiation of costs which may need to be revised during the development process – affecting return on investment and harming the client/supplier relationship. Additionally, the lack of flexibility with this process means that software cannot be developed in an iterative fashion and testing or validation cannot be undertaken until the entire product is complete. This increases the risk of expensive changes needing to be made, which is often compounded by the rigorous change control procedures employed by software companies following a waterfall approach.

All of these issues may cause the project to be deemed a failure, when in fact a simple change of attitude and process could have removed these obstacles.

Emergence of Agile and Lean

As the benefits of an Agile approach to software development become more visible, widespread and measurable, businesses are waking up to the advantages it offers over traditional waterfall methodologies. At its core Agile promotes an iterative development process coupled with strong communication and feedback loops that enable the client to help shape their solution in partnership with the software company. Examples of this can be seen in many real-world scenarios; rarely does a patient start their clinical consultation by dictating their desired prescription. Instead they discuss various options based on a shared knowledge of the symptoms, in order to make a more informed diagnosis. It’s this shift in the dynamics of the relationship, based upon trust, that makes all the difference.

In Agile software development, ‘diagnosis’ is made through consultative workshops that uncover and define requirements, which are then prioritised according to business value. This supports the creation of an initial estimation and release plan (comprised of short, iterative ‘sprints’ of work); although the product is shaped incrementally as details emerge throughout development, these early plans mean a realistic timescale can be set at the start of the project.

By replacing a reliance on heavy documentation with regular and transparent progress reporting development begins more quickly, and when combined with principles from the Lean Startup methodology such as the production of a Minimum Viable Product (MVP) working products can be released to market as early as possible. Assumptions can validated through user feedback which is incorporated into future development sprints, enabling the product to be shaped and improved iteratively. Not only does this reduce risk and timescales while maintaining quality, but it ensures that the final deliverable effectively reflects the requirements of stakeholders, users and market conditions.

Applying Agile to the tender process

With the increasing popularity of Agile, it’s becoming clear that traditional tender frameworks focusing on detailed and inflexible specifications are not ideally suited to these kinds of projects. So what’s the alternative? While we’re not suggesting that projects shouldn’t be put through a competitive tender process, we do recommend discussing the project and its requirements thoroughly with your prospective suppliers, and at Box UK we insist on having these conversations before responding to a tender, to ensure that what is being quoted for reflects the final product that will be delivered.

To get the most out of these initial consultations, our sales process doesn’t just involve business development, but incorporates User Experience (UX) consultants, project managers, business analysts, developers and more. Working with prospective partners from the outset to really understand their business needs, these specialists help collaboratively shape requirements through a series of short, fast-paced workshops, to ensure the creation of a project plan that meets your true business requirements and user needs. We’ve refined our activities through years of testing and assessment to provide a process that facilitates effective quotations, is easy to understand and addresses all the strategic needs and expectations of our clients, allowing for development to evolve in the truest sense of the word.

This approach also enables our clients to understand the way we operate from their early interactions with us. Successful client relationships are about collaboration and partnership, and you need to make sure your supplier (or as we like to think of it, partner), is credible, worthy and reliable, with a proven history of delivering successful solutions. Working closely with them during the tender process (instead of simply sending out requirements and waiting for the response) is a great way to get a feel for what it’s like to work with someone before committing to a decision that could be pivotal to your business success.

Conclusion

Submitting an ITT or PQQ is a good way of letting the market know you’re looking to court new suppliers, but ultimately it may not be the most effective way of selecting one. Of course adopting a collaborative, strategic and Agile approach to tendering and requirements gathering may not be practical or even desirable for every project or organisation, but when it comes to bespoke development, where the ability to grow products and services in line with strategic plans is paramount, the potential for long-term benefit is obvious.

We’d love to hear what you think: what do you think is the biggest obstacle to successfully selecting a supplier? Have you experimented with more Agile forms of tender process, and what results have you seen? Please let us know your thoughts and experiences in the comments below.