General Training

Database Team Structures

I’ve been involved in analysing database team arrangements across organisations as a follow-up to my article on database personnel. When building fundraising teams, one element that is frequently overlooked is the infrastructure required to support the expansion. So I decided to discuss how I attempt to determine what is necessary.

Understanding the team’s requirements, both present and future, should be your first priority. Hopefully, your company has a list of routine duties, such as: Weekly or monthly events could include processing Direct Debits or importing JustGiving data. This is what I would refer to as “business as usual” (BAU) material. Once you get the list, you must indicate how long each task takes so that you can determine how much time is spent on BAU work each month. As part of this, I would also include monthly team meetings, mailing choices (if they are regular, like once a month’s worth of Enews), training sessions, and support.

Then there is project work, whether it be an analysis, a new product, an innovation, or a study of your CRM system that requires improvements. Once more, you should keep a track of how much time the team spends on this kind of work. This is what I would consider project work, and I would also include scheduled yet sporadic mailings, such as if you send out appeal mailings on a quarterly or biennial basis. Additionally, I would advise you to regularly check in with system users to make sure everything is still going well. I advise creating a super user group that can discuss how their respective teams use the database. and anything that irritates them or prevents them from doing their job.

You now have a rough idea of how long projects that you are aware of are taking.

Last but not least, there is Emergency Response work. Either something has gone wrong and needs to be fixed, or Blackbaud is withdrawing the office integration, in which case a patch needs to be found. The organisation won’t be aware of this kind of situation, but there is no way around the need to have a response. You’ll need to be aware of how much time you spend on this kind of work, just like you would with the other kinds.

In an ideal world, it should look something like this:

BAU – 50-60%

Project work – 25-30%

Emergencies -5-10%

The amount of real days that people can work must then be taken into consideration, along with any holidays. I assume there are 200 working days in a year because I am a consultant.

With these estimates, you ought to now have a better idea of what the team’s requirements are.

Most organisations with fundraising revenues exceeding £5 million should require more than one individual to work on their database team, in my opinion (So long as the database team is just responsible for the database and not the whole IT infrastructure stuff) Just to be clear, I’ve worked with several organisations that rely on one or two superusers to fill the role of database management because they don’t have one. With the information above, hopefully it was clear why having a database person was necessary.

So, let’s go back to business. You’ll have a better idea of the activities that are necessary and, consequently, what you’ll need in a team, based on the time split required between BAU and projects. I’m assuming you’ll need someone to handle imports, mailing selections, insight and report production, as well as project-related deliverables. Now, just as you don’t want knowledge silos in your database, you also don’t want them in your teams, as this can cause issues with things like succession planning.According to the size of your organisation, you may need project managers who collaborate with the database team or business analysts who can translate user needs into briefs for the database team to implement change. In an ideal world, all database teams would have at least two members so there is coverage for things like holidays and illness.

Digital strategy is one of the topics I’m hearing about increasingly frequently. I understand that many organisations are still embracing digital technology, and I believe that the impact of digital strategy on database teams appears to be broad. A new strategy of any kind should involve your database team early on so that the database can be set up in a way that allows you to report on the success of your programmes. It also appears to have different success metrics than what the majority of people are used to. Every strategy should include a list of specific success metrics. As always, start small. Consider the top 3 factors that contribute to success and grow from there.

And now that I’m just looking ahead, I would love to see more heads of data sitting on leadership teams. Although the database team’s primary responsibility is to serve its users, having a voice at the table at the beginning of strategic discussions and being aware of how data is affected by process, governance, or insight means that we are on board for the journey and have a clearer understanding of the WHY behind what we are doing.

Instead than just being a place to store things or a liability, organisations need to view their data as an asset. If you’re interested in learning more, I recently read a book called Leverage that goes into this topic in further detail.

I therefore expect that this will be helpful to individuals who are having trouble figuring out new team structures, and I anticipate seeing more database professionals on leadership teams in the industry. Reach out to other database managers in the industry as much as possible. Our industry is great at sharing information; long may it continue.

There are a variety of different types of structures that database teams in the UK charity sector may use. Some common structures include:

  1. Centralised database team: In this structure, all of the organization’s databases are managed by a single database team. This group may be in charge of data modelling, analysis, integration, and storage.
  2. Decentralized database teams: In this organisational structure, there are various database teams, each of which is in charge of managing a particular collection of databases. These teams may be set up according to location or function (such as financing, programme delivery, or fundraising).
  3. Hybrid structure: In this structure, centralised and decentralised database teams are combined; some databases are managed by a central database team, while others are managed by decentralised teams.
  4. Database team is provided by an external vendor or service provider rather than being handled internally in this arrangement.

The appropriate structure for a database team in the UK charity sector will be determined by the organization’s size and complexity, as well as its specific needs and goals. Depending on their changing needs and priorities, organisations may choose to adopt different structures at different times.