Great conversations with digital partners

Use this page to build a great relationship with digital partners.

When you are working with a partner to help you build, develop or manage new software, the relationship is important. Different styles of working, pressures and approaches to making decisions can cause problems. If you are not careful this can lead to expensive consequences.

Use this guide to talk to your digital partners about the best way to work together.

Broadly, the process follows these questions: Who are we, and how are we going to work together? Who owns what and how can we maximise its value?

To make this helpful you need to use these question lists to start conversations and discussions. Never take this list and send it to a partner and ask them to fill in replies.

• Who will be the team working on your project day-to-day? What are the key roles and responsibilities?
• Who are the senior stakeholders? How, and how regularly, will they be involved in the work?
• How often will the organisation and digital partner communicate? Will it be via messaging (for example Slack, email), phone/video calls or face-to-face? How quickly should a response be received?
• What is the escalation process if the day-to-day team can’t agree?
• How will the project be managed and who is the main person responsible in each party (the organisation and digital partner)?
• What tools will be used for project management? What are the expectations of each team to use of these tools? Is there any training of the team to use new tools (including to reduce post-project dependencies)?

• What is the sign-off process for decision making? Who signs off internally and how long will this take? If a deliverable isn’t accepted, how many rounds of amendments are acceptable?
• How long will the voluntary organisation get to sign off on decisions, and what happens if timelines slip?
• What happens if you disagree on the way forward? How will it be resolved?
• Change requests (changes to the agreed scope) may be needed (eg to respond to new research/insight) but may have consequences for budget and timing. What flexibility do you have built in to this partnership? What’s the best process for identifying the implications for change requests?
• What are the main timelines for the project? While this partnership may only be for a specific project there may be implications to other work if these timelines are changed. Are there important dates/activities/busy periods worth sharing between the teams?

• Who will own the code or configurations you produce during this work and who will have what rights to use and share it after this funding period (it may be expected that the digital partner will own code and provide an unlimited license unless agreed differently)?
• Who will own the assets (eg images, logos, designs) and who will have what rights to use and share them after this project?
• Who will own the user research (including where will it be documented) and who will have rights to use and share it after?
• If needed after this project, what is the cost/difficulty of transferring the product between different agencies to maintain/build on an existing codebase. Who owns/has access to the passwords?
• How is this work funded (eg philanthropy/grant/contract)? What implications does this bring to the project (eg ownership, reporting, milestones, deliverables)?
• Is there any open source code that is being used within this project? Are you looking to openly share the code using an open source license?

• Who is responsible for data collected during the partnership? Does the data come under GDPR?
• Who is responsible for recruiting ‘users’ for interviews and securing consent for use of their data?

• If there is already a contract, what are the differences between what is in a tender document and what is in a contract?
• What testing will be performed within the contracted period to guarantee performance of the product?
• Beta launch: is there a 30, 60 or 90 day period for bug-fixing and updates?
• Post launch: what are the costs for hosting and ongoing upgrades? What are the likely maintenance costs once the project is complete?

• What level of accessibility are you working towards and who is responsible for ensuring compliance with accessibility standards?
• What do you know about the audience and how does that affect the requirements for accessibility and technology compatibility (for example browser compatibility, but may be other technologies affected)?

Use our introduction to digital accessibility.

What is each organisation involved allowed to say about the project publicly during development of, upon launch of, and after the launch of the project? What can/can’t the agency say about the project in marketing activities? What can/can’t the voluntary organisation say about the work that is being done?

If you’ve got this far you’ll be on a stronger footing to make the relationship work and to create useful, and meaningful, digital products and services. To support this, we’d recommend identifying principles for ways of working together to ensure the work is user-led and driven by testing. Think about ideas such as open documentation and communication. Decide how you will work together to follow good digital design principles.

Read more about the digital design principles for charities.