Setting up a new project

At dxw we frequently start new projects and work with clients we haven’t worked with before. Delivery leads at dxw are responsible for setting up projects and ensuring all the right things are in place for when the team starts work.

We often find that time is limited and transitioning between projects can be a challenge, for delivery leads and the wider team.

This guide provides advice and tips, as well as a checklist for delivery leads about to start a new project. It can work for large projects (a phase of work like a discovery or a beta) as well as smaller projects which might only be a few weeks long.

Before a project starts #

In most cases, there’s not a very long lead time between winning a piece of work and starting it. We sometimes have a number of days, rather than weeks, for the team to get everything in place. This includes things like contracts, scheduling a team to do the work and making a plan for the first few days.

We’re lucky if the same delivery lead has been involved in the sales work that led to the project being won, because there’s always other work in flight. It’s important that knowledge is shared and the necessary introductions made so we can get the work off to a good start.

It is however worth remembering that most of our sales proposals are produced with limited information about the project, and it’s only once we start that we get a better idea of what the work is and what skills we’ll need to do it.

There are several things that delivery leads should do first, regardless of the shape of the project:

Do some reading #

Get hold of any background materials, such as proposal documents, meeting notes, project documents or email chains. Familiarise yourself with the brief and conversations that have taken place so far.

Speak to the person who has had the most involvement in the work to date #

Find out who led the sales bid, or who has the most knowledge about the project at dxw. This should give you a fairly good understanding of what the project is, what work has been done so far and what dxw is expected to deliver. Find out who’s who in the client organisation, and ask for an introduction to the main point of contact.

Meet the client team #

At the earliest opportunity, arrange a meeting with the client. It might be one person at this stage or everyone that will be involved in the project. Use the time to build rapport and get to know each other, as well as agree a start date and schedule any important meetings that need to be held in the first few weeks. If you can, bring along other team members as it might be useful to have their input.

Ask lots of questions #

Whether you’re talking to the person who led the sales bid, or the client team, ask questions.

• What is the brief? What outputs or outcomes are we expected to deliver?
• Who is the service manager or product owner in the client team?
• Who are the important stakeholders we need to be aware of?
• Who from the client team will be working full-time on the project?
• Are there any deadlines, dependencies or risks that the team need to be aware of?
• What skills and capabilities do the client team have? Are they used to working in agile teams? Have they delivered a digital service before? Are they familiar with user research?

Setting up the project #

Before the project starts there’s also a number of tasks, mostly administrative ones, that need to be done. Below is a checklist of things that need to be in place for a typical project.

• Send out calendar invitations for regular ceremonies:

  • Standups - daily, 10-15 minutes between 10:00-11:00.
  • Sprint planning meetings - fortnightly, for anything between 1-3 hours, usually on the first day of a sprint (a Wednesday).
  • Retrospectives - fortnightly, usually held at the end of a sprint or before planning.
  • Show and tells - fortnightly, at the end of a sprint for most projects. The client can help you identify a suitable time and place (we recommend keeping it to a regular time to maximise attendance).
• Create a Slack channel and add dxw and client team members. Clients and contractors should be set up as single-channel guests.
• Create a Trello board for the project. Use the standard dxw columns or make up your own, depending on the needs of the project and how the team want to work.
• Create a Google Drive folder, under ‘Client work’ for the project. Use this to store any documents, files, week notes and anything else that the team might need access to. Make sure everyone in the team knows where to find it, and give clients and contractors access to individual documents or sub-folders as required.
• Set up a video-call for standups so that anyone working remotely or from another location can join. We like to use appear.in and talky.io.
• Create a week notes document, using the template.
• Organise a kick-off meeting with the client, either a few days before the first sprint or on the first day. The whole team should attend this.
• Check that commercial tasks have been done. It’s worth checking there’s a signed order summary (this should be shared with you ahead of time) and this matches the schedule in Productive. Check invoices have been created in Xero and you know where to find them. Also check Productive early so you’re aware of any upcoming holiday being taken by the team.
• Create a spreadsheet to track days worked against the order summary. This will show you how money is being spent against the forecasted budget, and help you in any conversations with the client about team changes, extending the project or issues with budget.

Kick off meeting #

While the project is being set up, and before it starts, a kick off should happen. This ensures:

• The team get introduced to each other & discuss and agree how they want to work
• The team and client know and understand what the work is all about
• We realise our priorities so we have an initial plan
• We discuss ways of working

You should have everyone working on the project in this meeting (even if they’re part-time).

Introductions #

Use the kick-off to introduce everyone to each other. It might be a good idea to give team members a bit of advance notice about this, so that they can already think and prepare their own intros tailored to this project.

It shouldn’t just be about people’s names, but roles and what each person will be doing on the project. Some further ideas:

• Highlight people’s experience and expertise, particularly if it’s going to benefit the project or subject matter you’re working on
• It is also important to say if any of the team members have worked on a previous phase of the same project/product/service
• Make sure to point out who is full time/part time or if there is any different working pattern (such as compressed hours, any days they are not working, etc…)
• Prep the client about what the day will look like and set expectations. For example who they should bring and what the agenda should be.

Get to a shared understanding of what the work and priorities are #

There are a number of outcomes you should aim to get out of a kick-off. This is important especially if we are working with that client for the first time and there are areas that are not very clear to us, or to them. You can structure a kick-off in the way that works best for you, but some frameworks that will help you get the outcomes you need are below:

• Running a discovery kick-off workshop
• Running a roadmapping workshop

Aim to reach a shared understanding of what’s desired and what’s possible. This can be a Sprint goal, a high level vision, or going through the requirements and getting clarity on each of these points. The scope is flexible, and it varies from project to project, but the main outcome is to make sure the team and the client understand what will be done. You should:

• Set the client’s expectations from the beginning, and help them understand that there are trade-offs in every decision we take
• Make sure the commercial paperwork is aligned to this discussion, and if there are gaps or things that have been missed, bring that up, and go back to the commercial team to inform of any changes. It timing works out, this type of discussion is suitable for the delivery checkpoint forum that happens weekly on Thursdays at 3.30. Gurps, our Commercial Manager, joins these.

Talk about dxw ways of working #

Give an overview of how dxw works. Don’t assume that everyone in the client team has read the original proposal or visited the dxw website. Explain how we work:

• agile mindset
• culture
• our approach to delivery
• GDS Service Manual
• sprint ceremonies
• writing stories
• story workflow (this is different from team to team)
• the code review process (again might be different in each team, and it’s ok for the team to define that in the first Sprint)
• dxw days: we will typically be working on the project for 9 days in a 10 day sprint
• invoicing and finances, we invoice the first day after the end of each sprint, based on the number of days each specialist in the team worked. We might also add travel costs, or research incentives, and other admin costs as per the commercial agreement we have with the client

It is also important to mention that we work with roadmaps, which might change over time as we know more about the project. This is fundamental in an agile project, so that we can react to change as quickly as possible. Therefore, we do have plans, but they are not set in stone.

Tell the client that if, at any point, they have an issue with the way we are working, or with any team member, the first point of contact for them is the dxw Delivery Lead. If the DL is the problem area or if they are a contractor, the Director of Delivery is then the next point of contact.

Discuss how the team want to work #

Clients will have their own way of working on projects and if they’ve used agile approaches before, it may be a different flavour of agile to what the dxw team are used to. Ask the client team to talk about how they’re used to working on projects and agree some principles for how the single team will work together. For example, do they typically follow the GDS Service Manual?

Explain how most dxw teams work, and communicate to the client that we’ve done this successfully with different clients over the years. However, be accommodating and suggest we “test and iterate” approaches. The retros are a perfect avenue to explore these.

There’s always something to discuss here. For example, how will week notes be written and who should they be sent to? Who needs to be invited to show and tells? How will user stories be written? Is there a story template the team want to use, and will developers estimate them?

Talk about co-location #

If you’re going to be co-located with the client, ask to visit the office space and have a look around. Make sure that the team have access to the site (do they need passes) and that you have space to work. This includes space to run sprint meetings and show and tells. Work with the Commercial Operations team to order any equipment or things the team will need. It’s also worth agreeing which days will be spent co-lo and which at dxw in this meeting. Take the teams working patterns into account.

When the team are going to be in different locations, think about technology and how to make sure each team member is able to join meetings and work with others. It might be useful to buy some extra microphones, good headphones or additional screens for the team. Chat to Olivia if you have any questions.

Cover the following tech for collaboration: Slack, Google drive, Trello, Miro boards, Google Hangouts or Go2Meeting, Calendars (team and personal).

Ensuring security from the start #

• We use the service standard from the outset of all projects we do, which includes security considerations. Project leads use this as prompts at the start and throughout projects, so security is considered as part of the process
• Because our projects deliver into client systems (and public sector systems at that) rather than our own, we engage early with their information assurance/governance functions, so we can understand expectations about security and assurance
• Majority of our delivered projects have undergone at least one pen test and round of remediations, with ongoing support arrangements usually requiring an annual check

Last updated: 14 June 2024 (history)