We often describe our starting point for a client project as ‘sprint zero’, but of course it rarely or never is. As a supplier, our engagement may be just beginning but we are joining in with a conversation that has been going on in your organisation for months, if not years. As a result, we need to ask you for some things to help us catch up on what we’ve missed.
Before we start working with you, in the time between procurement confirmation and start date, we’ll ask you to share any existing documentation to answer these questions with us so that we can make the most of our time on site — whether that's in person or virtually.
How does your organisation work?
In the office of one of our clients, there is a sign above the shared desks telling me what each team does, which came in very handy when we first started working together. Unfortunately, this isn’t replicated online, and we need more of a helping hand.
These documents can help us get up to speed with who needs to be looped in and when would be a good time to talk with them:
- Organisation chart – at least for the relevant department(s)
- Stakeholder map – identifying who has a vested interest in this work
- Any standard meetings – so that we can piggyback on them for updates
It can also be helpful to understand any change control or comms processes you have in place that we’ll need to follow, to enable us to plan around those timelines and get the relevant evidence ready. This might be things like a risk assessment, an outline of when we'll be making changes and the expected impact, or a recovery plan.
What’s the ‘as is’?
Understanding the current state of your technology and services is often the first stage of our work. If we’re able to accelerate that with existing documents – even better. We’re likely to ask for things like:
- Technical architecture documentation
- Service blueprints
- Process maps
It doesn’t have to be fancy, and it’s usually helpful for it to be visual – a hand drawn diagram with a bit of comment can work wonders. Screenshots or videos are another good shortcut.
What’s been done already?
Have you already started researching this subject area? If there have been earlier phases, we’d expect to see:
- Discovery report
- Identified pain points and/or user stories
- User personas
- Technology options
For many of our public sector clients, summaries reports are publicly available, but there is additional underlying data that can be useful to inform our decisions. It can be helpful to see indirectly related reports, too, to better understand the problem space.
Even if no formal work has been undertaken so far, it’s good to give us a sense of the conversation around this — has anything been committed to? What questions come up around the topic? Where are the points of tension? And of course, we’ll be wanting to start with a problem statement of what we’re hoping to fix, which we can craft with you if it’s not yet written down.
What are your tools?
One thing that can help to make sure that your organisation keeps ownership of knowledge gained during the engagement is for us to work with your tools where possible. So we’re going to need to know what those are, and in most cases get accounts set up. This will save time and effort on some of the later back and forth of scheduling meetings, sharing files etc.
Where we want to use other tools — especially those that aren’t yet commonplace in client organisations, such as transcript generators, retrospective boards and digital whiteboards — we'll need to know if you have any rules around this. For example, some clients only allow those hosted in Europe; others anywhere except one or two regions.
To work out what we can and can’t use during the project, we’ll need:
- Information security requirements
- Accessibility requirements
- Legal requirements
- Procurement requirements
These will also be used to shape our recommendations and decisions for technology and design, which will speed up any sign off required further down the line.
We'll figure it out
If you don’t have these documents, then it's not a problem — we can of course figure it all out when we start working with you. But we’d rather spend that time talking with your users or designing your new deployment pipeline.
If it seems like a lot of information to pull together, then it's worth remembering that this kind of documentation will also be useful for your in-house team, helping new members get up to speed with how things work and enabling people to see how a change might affect other parts of the system or organisation.
You don't need to remember all of this by heart, we’ll talk you through what we need in advance of getting started, and again in our kick-off meeting. But I hope this has helped to demonstrate that by preparing for the work in advance, you’ll get the most from our team. It’s a bit like what my parents used to tell me about taking part — the more you put in, the more you get out.
Our recent insights
Getting started with your Drupal 7 to Drupal 9 migration
Our Lead Software Engineer recommends the best ways to take on the Drupal 7 to Drupal 9 upgrade.
5 Benefits of Drupal 9
If you’re still using Drupal 7, it’s time to think about migrating to Drupal 9. While this might seem like a daunting task, the benefits of Drupal 9 are well worth it.
How to design good services
Neil Clark, Planet Officer and Service Designer, looks at how to implement good service design more effectively.