Groundwork

Groundwork is a term of art in community organising for the early stages of an organising drive, including elements of relationship building (like one to ones), power mapping, planning and research. At Common Knowledge we use the same term to describe this first stage of the project, where we are preparing for the rest of the work.

We are doing three things in this phase:

• Learning about the collaborator and building trust needed for the rest of the project
• Removing risks for the rest of the project, especially technical risks
• Learning how the rest of the project will proceed and making a plan

It is probably the most important phase of the project. We start as we mean to go on. Often we can avoid later difficulties if we do a good job of Groundwork.

Kick-Off Meeting

We begin every project with a Kick-Off Meeting between our team and key stakeholders from the collaborator. This is usually conducted remotely and generally facilitated by the Project Steward.

There is a lot going on in the Kick-Off Meeting, so it has a page dedicated to it.

Elements of Groundwork

This is the research needed to set up the rest of the project.

• User interviews - running formal user interviews with people to find out how the work might proceed and how the design might look
• Looking at analytics - checking out the analytics and deciding how they might inform the project
• Wider desk research - looking around at for information that is relevant
• Technical discovery - for technically challenging aspects of the work, rounding off any sharp edges before we begin. A classic one is "how are we going to migrate from tool A to tool B?". At the end of Groundwork, we want to have this as clear as possible, without actually doing the work until the end
• Prototyping - there is a section on this below
• Getting access to logins we need - for example, hosting credentials and so on. We want everything in hand that will make a launch easy
• If there is a visual design element to the project, we will be:
  • Reviewing their existing identity
  • Plotting their desires for a new identity on a spectrum, or identifying key words to describe the new identity
  • Understanding visual elements to avoid
  • Collecting references (from both us and them) that sketch out the new direction they want to go in
  • Running interviews with their staff or community members to understand their organisation and desires better
• Brand strategy and building out the brand as needed - often collaborators won't have a fully worked out brand, so building this out enough to work on the project. Sometimes we are developing a sub-brand for a particular campaign or micro-site. As a bonus, they now have an improved brand

Prototyping in Groundwork

An important element of Groundwork might be prototyping.

This can take a number of different forms, depending on the project: either low-fidelity interactive wireframes, or something built using code or existing digital services. We might produce a Wizard of Oz or concierge prototype to consider detailed service designs or learn more about particular interactions.

We design for user flows, rather than individual screens. We try to keep our prototypes as lightweight as possible, so we can move quickly to testing our assumptions. As was emphasised when talking about the Kick-Off Meeting, we strongly recommend working with real content during this phase, as this will be a key part of the user testing.

User testing sessions after prototyping always bring great deal of insight, which is why we encourage testing as early as possible.

After we do user testing, we will share what we've learned from these sessions with collaborators during the presentation at the end of the Groundwork phase. We'll use these learnings to iterate on the prototype and inform our work moving forward.

Technical discovery

Technical discovery is usually done by the software engineer on the project from Common Knowledge. It usually has three main aspects.

• Taking a look at what the collaborator already has from a technical standpoint
• Working out what technology and tools we are going to use to build the project
• Working out any rough technical edges we aren't sure about in the project, so we can reduce technical risks

Taking a look at what the collaborator already has

In some projects, the collaborator will already have a set of systems they want us to interoperate with, or an existing website on which they want the tool or content to sit. Its really important to get access to these things, take a look around and work out how hard it is going to be to execute the project given this technical situation. We want to reduce risks some existing system is going to be especially complex, and if it is, have a clear strategy for dealing with this.

Often organisations we work with don't have a good sense of where their existing technology is at. So something valuable for us to do is simply to find it and document it for them. Along the way we can even make some recommendations, where there is an obvious improvement that can be made.

Working out what technology and tools we are going to use to build the project

Common Knowledge is pretty agnostic when it comes to what technology to use to work on a project. We don't just stick to building everything in one paradigm, and even when it comes to content management system we take a view between Wagtail, WordPress and something else on a project by project basis. We want the right technology and tooling that accompanies it to serve the goals of the project, the collaborator's theory of change and ultimately the ability to bring about change.

If the project is intended to last some time after it is completed, we need to ask important questions about the maintainability of software produced. Movement organisations are often very financially constrained and the work needs to remain working for some time. The support team and plan that is going to maintain it, potentially in a situation where we are not going to be in the mix and even in some situations, where a volunteer or member of staff from the collaborator will be maintaining things. Cost of the software, hosting and maintenance should be a consideration in making choices too.

For this reason, we bias towards using Boring Technology. This essay suggests that organisations should use their "innovation tokens" - their limited capacity for adopting innovative technologies and techniques - judiciously and therefore mostly stick to well-understood, well maintained and "boring" technology. In most projects we do, the "innovation tokens" we have are best spent on user experience, innovating in the technical space of winning campaigns for working people or tooling to bring about day to day radical change. They aren't going to be well spent on using a novel form of database, or an furthering an exotic combination of technologies. Boring Technology also tends to open up a host of low cost options for hosting too and means someone other than us has a chance of maintaining things.

However in some situations, some form of technical advantage or innovation in technical means is going to serve the goals of the collaborator and the project. For example, making some aspect of the software extremely fast, because this conveys some sort of political advantage, might mean it is advantageous to use a lower level language like Rust or Go to build some element of the system. We should be careful here, because we don't want to go beyond the capabilities of our software engineers in a way that brings risk to the project because engineers are working with unfamiliar technology. We absolutely don't want to choose a technology only because it would be fun to work in it for the software engineers involved. But we might need to consider something out of the ordinary because this will make for a better outcome.

There might be specific things that the project needs to do. For example, it might need to be translated into multiple languages. It might need to interoperate with a third party system, like Action Network. Working out roughly what translation platform or service should be used, or if we know clearly how to interoperate with Action Network (we do!) would be good things to find out in technical discovery.

Working out any rough technical edges we aren't sure about in the project, so we can reduce technical risks

Some aspects of the project will be especially technically tricky or complex, so during Groundwork,it is important to work this out. For example, migrations, complex data cleaning, fixing some system which is broken, working out if some API genuinely works. Here it might be useful to do a short technical prototype. This can be seen as analogous to a spike within usual agile software development: a timeboxed amount of time to try something out roughly, learn more and report the findings back. This is an important risk mitigation. We should be open with collaborators if things are difficult. It is one of our roles in the movement to understand digital technology and help organisations and organisers make better informed decisions about what they have and are capable of.

A classic version of this is migration of systems, from system A to system B. There are probably already tools to do this sort of thing, for example moving from Drupal to Wagtail. However, will they work in this situation, with this database setup, and result in a good outcome? What we want at the end of this is an impression of how hard things are going to be and what we might need to do to overcome these difficulties. For example, we might learn that some automated migration script works for the 80% case, but we are going to have to do more for 5% of the content and it isn't fully clear how. It is important though that we are learning how to do something, not doing the whole thing, as doing the whole thing will prevent the Groundwork phase from ending relatively promptly. We want to have a map to follow for the work, without actually walking along it. Indeed one outcome of this type of technical discovery will be that this is extremely hard and we are going to have to sacrifice other features for this migration. Here, might it be best if we simply didn't do it and prioritised other aspects of the work, making a manual migration where needed?

Training on tools

We bring a lot of tools into projects - Linear and Productive at minimum, then Figma for showing off designs and perhaps more. We should offer the collaborators training on these tools if they want it, or seem to be struggling. We have some training Loom videos that the Project Steward can send over.

Not only will the rest of the project be more effective because of this, they will also learn a new tool they can bring to their other work.

Leaving Groundwork

Eventually questions that were unclear will have been answered, we will have some plans for the rest of the project and design work will have been begun. It is time to leave the Groundwork phase.

Ending Groundwork with a presentation

It is really important to signal a clear end of this phase to the collaborator. At the minimum, sending a summary email which explains what we've done and what we now think, especially where it differs from what we thought when we began the work.

Preferably, this would be a presentation, where we explain in an interactive way, with a deck, what we have found out and how we are going to approach the rest of the project. This keeps the momentum up and also makes sure we continuously deliver valuable things to the collaborator. It is also an early opportunity to have a celebration of the work done so far.

Invite the same people who came to the Kick-Off Meeting to this presentation, but also encourage the team to invite other wider stakeholders. This might be to keep them in the loop, it might be to demonstrate how cool and useful the project is or it might be to persuade them of the salience of a particular finding of the Discovery element of this work. The invite is open!

Making sure we go into Design and Build with a clear backlog

When this presentation is done, we should also have a nice clear and prioritised backlog of work on Linear of things to to be done and should roughly know how we are going to approach the rest of the project.

This is another great point to be emphasising that if in the day to day you want to see things moving along, Linear is the place to look. Screensharing Linear itself and going through the backlog can will be useful.

Don't forget that the terms of agile project management like backlog aren't especially familiar to people, so don't be afraid to explain them. Especially explaining why making priority clear is so important, given the uncertainties of digital projects.

Confirming with collaborator the wider project plan

We use Groundwork to gather facts, reduce risk and build confidence and relationships. On exiting the phase we need informed and enthusiastic consent from collaborators on the plan going forwards.

Some things to consider might be:

• Timelines
• Where the risk of project delivery will be and how to mitigate it
  • For example, launch day might feel like the end of the world, so can we do a 5% split test for a month to verify, after manual testing?
• Budget for build/design
• Budget for ongoing costs (e.g. hosting)
• Implications for the organisation
  • E.g. team changes or staff time required for the new tech and tech responsibilities (e.g. moderation pipeline)
  • Change of peoples' jobs or workflows or relationships because of the tech — how will transition and training happen?
  • Impact on revenue and other business-critical stuff
  • Impact on other important things (e.g. Communications processes)

Making sure it is clear what is going to be built

It should be very unambiguous to the collaborator what we are going to build together, but potentially more crucially what we are not going to build, because the Groundwork has revealed this is too hard, too complex or too costly to do. No one should leave the Groundwork phase ambiguous as to what the end result will be. Over summarising what we won't do and why is something useful, especially if that thing was initially thought to be a core element of the work.

We want to exit Groundwork with a shared understanding between everyone involved in the project.

Avoiding long lags between Kick-off and further work

When doing a Kick-Off Meeting is important to keep the pace up. Sometimes we've done the Kick-Off Meeting, then gone quite quiet for a while, even if we have been doing important work. After the Kick-Off Meeting the enthusiasm and attention to the project are high, so it is important to avoid simply kicking off then going away for too long. We want to keep the communication up while the project is going on.

Projects where we hard pause after Groundwork

Sometimes, Groundwork has revealed that we've got the estimate for the project drastically wrong in terms of the time taken to build the thing. Sometimes we think this is likely, so have build in a hard pause after the groundwork phase, even within the contract. It's really important if it feels like we aren't going to be able to do what we've initially said we would be able to communicate this very clearly and the implications of this. Sometimes it might even be the case we aren't the right people for the project entirely. For example, we don't have the right mix of technical skills to do the best work for the collaborator. This can be a hard situation but the we always want the best for the collaborator. In the case where we don't have the right skills, we should always make efforts to find people who do, who understand the collaborator and will get the project done in the best way for them.

For projects where we feel there is an especially high level of technical risk (i.e. its a hard technical thing to do) or levels of trust are not high and need to be especially so, then we might even make the Groundwork phase a self-contained project.

In the typical project phases, after Groundwork comes Design and Build.