How to procure a digital project well

Procuring digital projects is hard. It can be riddled with catch 22s, the fear of failure and not getting the best from the agencies you will come into contact with.  Many people will only manage one major digital procurement project in their tenure at an organisation. 

The common problems we see are:

  • There's a tension between how a major digital project should be run, and how traditional procurement processes run.
  • The first part of the project often shapes subsequent phases, but this seems impossible to procure as one.
  • You never undertake a large digital project that isn't part of a wider organisational strategy, yet keeping these connections alive is difficult.
  • Digital projects are controlled by IT departments because they're 'about computers'


A useful exercise is to think about which of these questions can you answer.

Why is this project required?

This typically will link with a larger organisational programme of change. For example, your organisation may have a strategic business objective that has a number of strands, one of which is a digital project.  Think about how the top level strategic objectives genuinely connect with a digital projects aims. Also think about how these various strands interact and feed off each other. Digital is rarely a silo.

What is it?

You need to be very careful with this.  If you are expecting to work with a company to bring their expertise to help suggest how you may solve your problem, you may not want to specify how they may do this. The counter argument to this is that if you need to judge tenders like for like, then this is more difficult if you've left room for a range of responses- particularly if you lack the experience to judge the value and risk of each approach.

What does success look like?

What are The Most Important Things this project needs to achieve within a year?  Are they increases in audience, decreases in support calls, new markets, or new behaviours?  How will you be measuring success as a KPI?

What are the constraints?

You will probably have some things that need to be fixed.  This may be for example, using the same CMS used elsewhere in the organisation, or at the very least the same technical foundation. Are there integrations with other systems for example? Is there a budget ceiling (see Budgets)

Who are your users?

Do you know who the users of the site or service will be? If so, what are their needs and have you created personas that can be useful for visualising who the audience are and what they want?

Who are the internal stakeholders for this project?

This may not be as straightforward as who owns the budget.  There are likely to be 4 quadrants. People who can help make this a success (you need their knowledge) People who can stop it happening (you need their buy-in) People who have things you need (budget/data/influence) People who want what this project will achieve (you want their support and requirements).

Read our guide to stakeholder workshops.

When is it due?

The drivers for a project deadline are often political rather than practical; year-end budgets, or departmental commitments. It's likely that if this is part of a larger programme, there will be dependencies with other projects. Add contingency to these dependencies.

Consider splitting the project into several stages so that there is progress that can be shared with your stakeholders and users and this can influence the course of the project.  You and the agency are then aiming for the same things at the same time and this is visible and transparent. Also consider content deadlines and dependencies.  If you need to populate a website with new content that has to be written internally, take that into account and double any timings you've been given by colleagues.

How will it look?

You'll want to get the agency to input heavily on this, but you can focus their efforts by providing brand guidelines, or even just a set of adjectives. For some insight into how we work, you can read our guide to design by our Lead Designer, Colin Grist.

How will it work?

It may be that you have a fully worked up specification for your platform, service or site.  If this is the case, you're likely to be imposing solutions that reduce the innovation to solving the problem.  If you are providing a specification however, you will receive quotes that are more comparable. 

Often, you may want to work with a specialist to work with you to produce a specification or scope that has enough room for innovation, but ensures you're largely comparing 'like with like'.


If you don't know this, then you're wasting your time running a procurement process.  If your organisation cannot put a value on this project, or genuinely haven't been assigned a budget then many of the questions above have not been answered.  A procurement process is a terribly ineffective way to work out how much something will cost that will simply point out that you haven't  got clear answers to these questions.

If you do have a budget, you must make a choice as to whether you reveal that to prospective bidders.  Now,  there's an understandable the dilemma here; "If we specify a budget then all the prices will be within £10 of it"  Well yes, so let's run through the scenarios of why that may be: 

That budgets have been 'padded'

You should not be running this process unless you have enough knowledge to know whether this is the case. Get an expert on your marking panel.  Actually, in our experience, It's more likely that respondents have reduced their estimate to get to your budget and don't want to lose more margin than they have to.

If you do not release your budget you will receive proposals that lack the necessary quality but are underneath your budget.  You will also receive excellent quality proposals that are over your budget.  In both of these scenarios, you've wasted somebody's time by not giving people a guide to work to. You can easily apply a weighting for value for money in tender scoring systems.

Knowns and Unknowns - the conundrum

The biggest problem we see is that digital projects managers instinctively know that whilst some aspects of the project are fixed- the what it needs to achieve for example.  However, how this can be achieved is open to interpretation, based on experience, user testing and data.  In order to run a project like this, then you have to try things out at a small scale and then use this evidence to form an approach.  This is notoriously difficult to procure as a single project. How can you procure a project when you don't have a fixed set of deliverables?

You can procure the project in a series of stages.  The first part of the project can help answer the questions contained in this guide, using workshops, user research and low-risk prototypes. The output of this will be a firmer set of requirements, and an understanding of value and priority, which in turn will be the basis of a brief that will return comparable responses. 

UK Government, led by the GOV.UK team have recognised that traditional procurement process are not fit for purpose for digital projects, and have a range of options for 'agile procurement'  such as G-Cloud (for use by Public Sector oragnisations).  Although it' an excellent concept, many procurement managers do not understand how it works.  We've written a guide on how to use Gcloud here…..

Procuring digital projects is hard. It can be riddled with catch 22s, the fear of failure and not getting the best from the agencies you will come into contact with.  Many people will only manage one major digital procurement project in their tenure at an organisation. Here's our guide to doing it well.