When Users Don't Know What They Want: Keep it Simple

I have previously blogged about my belief that you should keep database implementations as simple as possible, configuring as much as possible and not customising etc. This post is a subtle but important variation on that: this post is based on my observation that much of the time end-users don't actually know what they want or what they could have - or even (completely understandably) what the software can do - and yet we continually ask them. (And even good business analysts may not always get to the crux of the matter). Unsurprisingly, perhaps, we therefore sometimes get a system which, when it goes live, is either far more complex than the user wanted, is not really what they expected, or you even get told, "Oh, actually, that bit wasn't really that important at all. In fact, we don't really do that anymore…"

So: why not give users the basics to start with, the as-close-to-vanilla as possible, and then adapt that later once they do start to really know what they want, once they understand the software and what it can do.

E.g.: Let's keep the forms simple, the data entry straight forward, the processes matching how the software has been designed. And if that means that a user has to do two or three clicks to achieve something rather than one, then that isn't such a terrible thing to have to do in the first place.

This should mean quicker, simpler, less risky, cheaper database implementations. And implementations which are likely to succeed. And happier users.


Thereafter, once we have gone live and the users realise what they have got, then they will realise what they have is either fine or, no, they really could do with process x being streamlined further or data items a and b being linked together. Great. Then do it.

Of course, this approach does require a strong project manager or solution owner, a good project board to support the PM when necessary and a clear, open approach to explain to the users that this is what we are doing.

Do note I'm not suggesting you just say No the whole time and hide all the really funky things the users actually do want and end up giving them the very bare bones possible. You can think a bit past that! Just be open and inclusive.

And of course, as I have written before, if you do take such an approach and if during your analysis and implementation you do find processes which would benefit from more automation or a more sophisticated approach - and which can be proved to have benefits to be that way - then by all means do it. Ultimately that is one of the great benefits of a CRM system so I am not saying don't do it at all. Just keep it under control.

The Immediate Effect of CRM System Change On Staff

 

Recently on LinkedIn, there was a question which asked: "Does anyone have any indicators that would give me a steer in terms of what would be normal to expect when you bring in a new [CRM] system which changes the way people work?" I loved this question as it is so insightful and recognises that clearly this is going to be one of the key impacts and factors in the success or otherwise of the new system. I gave an answer online at the time, but here are my extended thoughts:

• You should expect more calls to your help desk in the short-term. Users will inevitably need to ask how to do things, even if they have had good training. As well as comprehensive and appropriate training, floor-walking during the initial days of go-live can also help.
• There will be more pressure on your Database Team (or equivalent) in the short-term. There is bound to be so much going on that your poor database team will probably have (or feel they have) twice as much to do now with this wonderful new system than they ever did before. Some of that might be true! Hopefully it will calm down as everyone learns the new system and its capabilities, but in some instances it might well be that there is more work for the database team even as the new system progresses.
• It is quite possible to see a drop in productivity in the first instance for some areas such as batch donation processing - this might sound awful and ultimately you of course want it to go the other way, but there's no getting away from the issue that some people might find a new system slower to use at first.
• No matter how much you've tested and re-tested, something will go wrong! And no matter how much you did some great business analysis to get the users' requirements, something may have been forgotten! I say this as a (mostly) serious point because I think it's a good thing to warn users in advance (i.e. during implementation) that this might be the case…
• Some people may not have the functionality they used to have with the legacy system and they especially need careful managing. i.e. there may well be people who actually do lose something they used to have perfectly with the old system. Work with them closely to make the transition as painless as it can be.
• Some processes may not be optimised yet. Not a problem, they can be optimised over the coming weeks - but be aware, don't think every process will immediately be better and be open to reviewing such processes and even having to re-consider if/how some should be managed differently.
• If you do have any areas with many more problems than you expected, encourage users to always report everything to the help desk/database team as appropriate. If they don't then it won't get fixed. I know this sounds obvious but some staff might not bother and either just not use function x or start to find workarounds. And then you're right back to where you started…
• BUT there will hopefully be good things too! Some users will (hopefully) love the new system, so they are great people to use as advocates for some quick-win stories for everyone else. Getting reports, information & insight that you couldn't get before is great.

Oh - and somebody, somewhere is going to say, "I don't know why we had to get rid of the old system…"

What's the first thing you should do if you take over an existing database?

 

It's not an uncommon occurrence that when a database manager leaves a charity, either no-one takes over their role immediately, or someone from outside the organisation comes in with no-one else able to help much with any background to the system they have taken over. If you find yourself in this situation as the new database manager, then what are first few things you should do?

Of course, some of this will depend on the size of the organisation you join, the size of the database team you are now managing (if any), how old  your new database is, if someone has been in post recently and so on. But the heart of my points below are true for most situations:

• Data audit: One of the first things I would do is a comprehensive data audit. Unless you have an existing audit/report which someone trustworthy did recently, don't just take at face value what other people say about the database - find out yourself. Do record counts, table analysis, queries, reports; do this on contact records, gifts, communication/correspondence records, gift aid, ad-hoc fields. If you need to get the data out of the database to do this and do the analysis in Access/another package then fine - that's okay for a one-off exercise such as this. Once you've done the audit, then you can start to see what work is needed.
• Talk: Talk to as many users, managers and senior managers as possible: Ask them about their roles, what they do, if they use the database, what they like about it, what they don't, what they really want. You've no drums to beat about why something does or doesn't work - you're brand new; ask them to tell you the truth, warts and all. This will give you so much knowledge with which to know how the database is really being used, to decide how the system could be used better.
• Quick wins: If you can, do some quick wins thereafter - it's corny to say, but it helps! Especially if you can get it to help any sceptical users…
• Create an internal development roadmap: Once you know what you are going to do, create a roadmap which everyone can see telling them your plans.
• And of course there is lots more you can do…: Review processes, create a data dictionary, instigate a training and learning regime etc.

So, when the time is right for you to one day leave this role, your successor's job will be a doddle!

The Benefit of Documentation When Implementing New Databases

 

So: If you're reading this blog post and wondering why I am even bothering to write it - because of course documentation is important - then great! You can stop reading now! Go and have a laugh at today's Dilbert instead. But if you do doubt the benefit of documentation in database implementations (or if you like the sound of documentation lite…) then read on… Because this is why I think documentation is important:

• Structure for project managers: It gives the people running the project structure - it helps them see what's what, where we are, what we are doing, who's doing it, what needs to be done and so on. I know these are easy words to write and perhaps not tight enough (especially for a blog about documentation!) but this is the heart of the benefits which documentation brings. As a project manager it gives me what I need.
• Structure and assurance for project boards: Following on from the above point, it gives your project board the same assurance and support.
• Accountability: This is important. It means that we have a written record as to what was discussed, decided, agreed (or not), for who, by when and so on. It's especially useful for when disagreements arise between a supplier and client, as we can then have at least a starting point to discuss.
• Blueprints: For projects which do require some up-front consideration of how the database is going to be configured, especially where a third-party supplier is doing that work, blueprints are pretty much essential. This is what was decided by client and supplier, this is what the supplier will deliver, and this will help formalise the project and avoid (a set of) arguments later about this.
• Data dictionaries: I wrote a blog recently about the benefit of data dictionaries - I still believe all that.
• If someone leaves… I've been brought into projects where an organisation is half way through a database implementation and I have needed to catch-up quickly with where they are. The better the documentation - i.e. the more poignant it is, not necessarily the amount of it - the better it is for someone new to be able to get up to speed.
• Agile methodology: I know some Agile evangelists believe that documentation is not so helpful because things can change so quickly in the next sprint anyway. I guess this is something that every Agile implementation needs to consider: is there some space and reason to have relevant documentation? Or do we agree it's not necessary. It might worry me sometimes…
• The more attentive of you will have realised that much of what I am promoting is to do with "clients and suppliers". Yes, that's true. I do think this is where documentation can help. It keeps everyone on track, maintains a level, fair playing field for both parties and I think instils good practise in implementations.

Then of course there are project plans, risk registers, communication strategies, data mapping tables, file formats for data integration and so on. I realise that even fans of documentation lite might see these types of documentation as more useful, but that doesn't always seem to be the case in my experience. Personally, I think we need them.

And just to finish with a couple of caveats: Documentation does not have to mean wreathes of paper - a well structured, online system of "documentation" can be just as useful for many of these issues. As long as it is structured, searchable, auditable, accessible then great, I'm all for that. And I am not saying that you need to follow PRINCE2 to the letter and create Product Descriptions to the nth degree - i.e. I'm not saying you should have documentation for documentation's sake. I realise there are times when keeping documentation to a minimum - or rather, to the amount appropriate for your organisation and your implementation - is right. But I still think documentation is needed.

Why you need to listen to Donald Rumsfeld when implementing CRM systems...

 

Some years ago, Donald Rumsfeld made his now infamous speech about known knowns and known unknowns. He of course got pilloried for it and was even given the Foot in Mouth Award for Bad English. And whilst I understand why he got such criticism, I would like to add one caveat: if he had been talking about CRM software implementations then he would have been lauded a genius!

Why?
Why?! Well, because I think he (unintentionally!) got the absolute essence of the problems you have when implementing databases:

• First, the Known Knowns. Absolutely. We definitely have this - the processes and data we do know we have and we know we have to address in the new system. Tick.
• Then, the Known Unknowns. Right again. These are the areas of our business which we know exist: the spreadsheets which we have heard something about, the small Access database which the trading team use - the data which has been in our database for 15 years and which, although we know it is there, we know nothing else about it! These are the things we know we have to tackle with a different approach when considering the new database.
• And finally, the Unknown Unknowns. Ah yes - these are the horrible but inevitable things that occur in almost all database implementations. The things we didn't even know existed, the problems which no-one had even imagined we should consider, let alone resolve. They will happen - of course they will. And it's no-one's fault, it's just that some things may simply have never reared their head before, or something no-one other than the database manager who left 3 years ago knew about - or the issues which the fundraisers know are a problem but they have never discussed them before. They're lurking there somewhere…

My real point...
I genuinely think these are useful things to consider when implementing a new CRM or fundraising database. If you go into the project with this in mind then at least you can plan for even the Known Unknowns. And you might even be able to come up with some process for how you are going to tackle the Unknown Unknowns when they pop up; e.g. in terms of business analysis, documentation, impact assessment, forewarning users that if this happens then this is how you will approach it.

I'm not saying you should stand up at the kick-off meeting and quote Mr Rumsfeld word for word - but do let him sit quietly on your shoulder so you can call on him when needed.