Running a GDPR project – Top tips

With 12 years experience working in Business Analysis and Project Management, I have built up a broad network of change management professionals, many of whom have voluntarily and involuntarily landed themselves on GDPR projects in the last couple of months. With my regular posts mentioning GDPR, my connections know I have been deep in the detail for some time and that I am passionate about it, so I often get calls or invites for coffee and the question everyone asks is:

What is the best way to run a GDPR programme? What are your top tips?

In the interest of sparing people the pain of taking me for coffee I have put together this blog, the first part focuses on top tips, based on my experiences of what works and what doesn’t work, the second part will be practical steps to implementing.

Top tips

1. My greatest piece of advice is don’t get bogged down with discussing details until you know how important they are to your organisation. If you do not have a good understanding of GDPR, it is really easy to lose hours talking about or analysing details of your business and still reach no conclusion. I have known of organisations spending months discussing the practicalities of consent only to realise they don’t need consent. I have seen people focus on use cases which would at best happen as an exception, but ignoring ones they face daily. There is a real danger of analysis paralysis. As an analyst I love detail, but on GDPR I have learned that it is best to follow a top down approach to ensure you are tackling the big issues first and the smaller issues later. If any organisations out there are planning on documenting any as-is status in significant detail before they baseline their to-be model, my advice is don’t. You will lose months and realise you have to redo everything because your implementation will make your work redundant. People think that they need the detail of all of their as-is to define the to-be, but this can done at a much higher level than one would anticipate, you can then go down to the detail when you need to.
2. Don’t solutionise until you have a firm understanding of your requirements. I know of a company who bought a portability tool a month into their GDPR programme only to realise that none of their processing of personal data was in scope for the right to portability. True story (not really but it illustrates the point).
3. Treat this as a project rather than a programme. By this I mean that usually a programme has individual workstreams which can run more or less independently of one another without great dependencies, whilst a project is usually run by one person overseeing a number of activities with interdependencies. Most GDPR workstreams are intrinsically linked with deep connections and dependencies, it is essential that they all really understand one another. So if it is a programme rather than a project, then ensure you have a programme manager who has an excellent hold on each workstream – you need a common denominator who can put the puzzle together and understand if the shapes don’t fit.
4. Define roles and decision makers very early on and make sure they are the right people with real ownership or you will be stuck every time you need a decision. On this note, ideally your sponsor will be either 100 % on the programme, a detailed orientated person with knowledge of the regs or be willing to delegate decision making authority and trust to someone else who does. The reason for this is if they are making a decision, it usually impacts several other parts of the programme, so the sponsor needs to have the time and commitment to understanding this, if they don’t, the project team is going to spend a disproportionate amount of time trying to explain things every time a discussion takes place. It is essential for the decision maker to have a good subject matter expertise, this will make or break the project.
5. Have a high level plan early but not a detailed one. Define your deliverables and critical path early for the whole project and expect to refine it. It is paramount to have a high level plan with key GDPR deliverables and milestones. Without this you will drift and have no way to monitor your progress. Better to baseline your deliverables, monitor against those and refine as you understand more. Don’t do a detailed plan until you have at least documented your requirements. You will waste weeks getting stuck discussing details which you may find to be irrelevant once you have understood a bit more (see top tip 1) .
6. Build a really good team. Without the right people you will fail, this is true of any project but even more pertinent to GDPR. Good Business Analysts really make or break the project. Hire self-starters with good analytical skills, willing to read and absorb the regulation, but also able to think outside the box helping the business define pragmatic outcomes. Interview wisely. My stance has always been that they don’t need to have GDPR knowledge but they need to demonstrate they are great Business Analysts, that said it would be good to have at least two GDPR SMEs* on the project (see my point about the sponsor and programme manager above).

*A note on GPDR SMEs

Be very careful of people claiming to be a GDPR expert. GDPR is the buzzword on CVs right now and I have met few people who can back up their claims. I know a lot about GDPR but I would not call myself an expert, especially whilst the landscape is evolving with the UK Data Protection Bill. If you are interviewing Business Analysts or Project Mangers ask a few key questions and see how well they articulate their response.

See my GDPR practical implementation guide for steps by step activities. I hope you have enjoyed this article, please feel free to share your tips