The trouble with tenders: Unrealistic expectations in digital delivery
I’ve written previously about the challenges that the tender process poses for agencies and for the organisations running them and as we’re in full swing of response season writing multiple responses per week at the moment, I want to highlight a little more about my perception that invitations to tender (ITT) often include unrealistic expectations and limited understanding of the delivery process of technical projects.
The recent ITTs we’ve been responding to have been decent sized projects, to be delivered over a six-month period. None of the requirements were particularly groundbreaking, but each specified a concrete set of requirements around things like the CMS, third-party integrations, customer facing functionality and content publication workflows. Fixed scope work. Of course, we must submit a competitive price for the project too and so set an expectation with the client that X=£Y – creating a fixed price, fixed scope project. The twist is, at least a couple of ITTs I’ve seen recently have included that the projects must be delivered following the Agile methodology – is that just a buzzword being used or an actual requirement?
Given the choice, I expect most web developers would prefer to work on projects that follow the Agile project management philosophy. It’s a way of delivering projects with emphasis on iteration, collaboration and adaptability, that allows them to work on smaller chunks of functionality and release code quicker. Being Agile means being flexible with the ability to change course mid-project. Not concepts associated with fixed price, fixed scope work. In fact, if tenderers spoke in terms of flexible timelines and differing requirements, I don’t expect they’d process to the later stages.
What’s the real requirement?
Do I think the ask is true Agile delivery? No. In these cases, Agile is being used as a tool to reduce the risk to the organisation through increased collaboration and transparency, though ironically increasing the risk of the project not delivering to their expectations if it was to be delivered in a truly Agile way.
I appreciate that budgets are tight, and every organisation wants to maximise their investment while minimising risk on a project of this scale. Agile delivery often seems like a safe bet - more transparency, better communication, and frequent releases, all with the flexibility to adjust along the way. However, unless your development costs are fixed - no matter how much time is used - or your requirements are fully defined upfront, the risks can actually be higher. You could end up with incomplete features, misaligned expectations on delivery, and increased timelines and costs.
Delivery options
There is a perception if you’re not building in Agile, you’re not doing it properly, which comes from teams building a single product, but I’ve always believed agency development teams need to work differently.
Waterfall lends itself perfectly to fixed price, fixed scope work but has an image problem and seen to be slow and inflexible. It has its place, but with a fixed order delivery and less frequent ‘big bang’ releases, clients are nervous about what’s happening on their project in the weeks / months between each milestone.
WAgile is my preferred delivery method for agency development teams. It combines the structure and documentation of Waterfall with the iterative release cycle and open communication of Agile.
When WAgile is coupled with a defined change management process that sets clear guidelines for how changes will be evaluated, approved, and incorporated into the project plan, changes are managed effectively without compromising the project's scope, budget or timelines, and does the job of protecting both the client and agency from risks:
Scopecreep
Un-delivered functionality
Missed deadlines
Conclusion
By understanding how different delivery methodologies impact outcomes, I disagreed with the inclusion of an Agile delivery being part of the requirements of the ITTs. Its inclusion highlighted again that some of the briefs we see lack foundational knowledge of how a digital product is delivered and most of all lack the ability for us to properly challenge the requirement within the process.
Should our response have been a box ticking exercise, say yes we’ll deliver in an Agile way and work out the details after the contract was won? Or should we risk missing out on scoring criteria by offering a different delivery method and trust we can communicate our vision within the 500-word limit?