Monday, April 24, 2017

Learning From How a Toyota Supplier Saved $1 million by Updating Its Tech Infrastructure

Production floor  
My second post in an on-going series of blogs on lessons we can learn from commercial sector technology implementations.


A recent article on TechRepublic shows how Toyota supplier, AW North Carolina (AWNC) spent $1.2m on new Cisco equipment, which has led to significant savings for them. Few charities will invest that amount in a new CRM system, but some of the approach which AWNC took provides us with very useful ideas for the benefits which charities may get from new CRM implementations, often regardless of size.


1) "Downtime at AWNC costs $272,000 an hour, so it's crucial to get systems up and running as quickly as possible. Any downtime, particularly in shipping, is incredibly detrimental."

Okay, so it's unlikely that a CRM system being down for an hour at a charity would have quite such high costs! However, downtime due to a poor or unsupported system or inadequate IT infrastructure is not always factored in to a charity's view on whether they need a new CRM/fundraising system.

So consider: what would it mean to your staff if they couldn't access their database for an hour? Probably, it wouldn't be terrible for most fundraisers/staff, they could cope for that time, although Supporter Services would no doubt find it awkward for managing in-coming phone calls. But what about half a day? Now staff will be getting more anxious, a backlog of income processing might build up, supporter services are finding it more difficult and major donor fundraisers can't see their contacts' details. What about a full day? Much harder now: thank you letters might be delayed, management for a forthcoming event becomes much harder, and what would happen if that day happened to be the day when you were due to do your Direct Debit claim?

So it's not just the cost of a new CRM system - all this needs to be considered when looking at investment.

2) "As a result of the new technology, AWNC avoided maintenance costs on the old equipment of $1 million in the first nine months the system was in place"

Again, unlikely for most charities that they will save $1m in nine months due to replacing a CRM/fundraising system, but I have come across several NFPs who are paying existing suppliers ridiculously high annual maintenance costs for what they are getting, even without upgrades and developments. And/or they have to have specialist, higher paid staff for their current, old system because there are so few people who can support it. So even if it is going to cost you £x to invest in a new CRM system, what are your savings going to be in the first 12 months? (In the next 5 years?) Forget "possible extra income" benefits for a moment, these figures are hard cost savings.

3) "About 40% of the savings will be ongoing and realized annually."

We forget this sometimes, that savings (and benefits of course) will not just be the first year, but over the following five to seven years. So in addition to point (2) above on immediate savings, what other costs will be lowered or made more efficient by a new system? Lower staff costs? Or maybe, the same staff costs but those staff being far more efficient, productive and proactive? Time-savings from quicker processes? Time-savings (and better productivity) from simpler, quicker development tools? Development you can do in-house now rather than having to always go to an expensive software supplier?

4) "It was very clear... that the infrastructure was not keeping current with where the world had gone."

We're all aware that digital is where fundraising is going. Yes, there will still be plenty of 'traditional' or offline income coming in for some years to come, but that appears to be declining, and GDPR/DP issues could be forcing our hand in terms of reducing direct marketing. There is a point when you do need to review how and whether your existing CRM/fundraising system can support you and provide additional benefits with your future fundraising plans because of changes in the outside world.

5) "It's common in a manufacturing plant to avoid buying new equipment in a misguided attempt to save money, with IT teams not realizing that the operational costs to troubleshoot problems and the associated downtime in a factory environment can result in even higher costs."

I love this! How many of you have suffered from this problem with your antiquated or unsupported fundraising databases?! (And it's kind of reassuring that commercial organisations have this problem too!)

6) "The big push for last year was solidifying the environment, and this year is all about pushing out into the applications and into the manufacturing space to impact yield inventory."

This is just a small point to show that any new CRM implementation does not have to be rolled out to everyone or to manage all potential benefits immediately. Plan for future expansions in the subsequent years after your immediate go-live - you don't need to, and shouldn't try to do everything on day one.

Monday, March 13, 2017

What we can learn from large, failed IT Projects

HOLMES system (Home Office Large Major Enquiry System) 
This is the first blog I am planning in an occasional series on lessons we can learn – good and bad - from commercial/public sector system implementations; looking outside the charity sector for best practice and alternative approaches we might take.


On Computing's website last week, there was an interesting article which says how “Accenture 'underestimated the complexity' of failed [£50m] national IT system for Police Scotland”. Whilst this is clearly on a different scale to all NFP CRM projects, there are some good lessons to consider regardless of what size project you are managing.1 The following are some of the key lessons I think we can take:

“Early disagreements between Police Scotland and Accenture led to a breakdown in relationships and a loss of trust that never fully recovered”.

This is a classic problem and shows how important client-supplier relationships are and supplier management for the client. One of the few things we can say with (99%!) certainty is that something will go wrong sometime during any CRM implementation, and therefore if you have set off on the right foot and started developing good relationships with your supplier, then when the beep hits the fan, you should be in a better place to manage such instances far more appropriately.

“Within weeks [of the contract award], and despite 18 months of pre-award discussions, Accenture and Police Scotland disagreed about whether the proposed system would deliver the requirements set out in the contract.”

First, if you are really arguing about scope and requirements “within weeks” of a contract award, then you have probably not managed the procurement appropriately for your requirements, and/or you are kicking off the project in the wrong way. And/or you have not created an appropriate Business Case pre-project which should have declared what the benefits were which you were expecting, and thus what you were looking for from a system.

In addition to initiating the implementation correctly, it shows how difficult and yet how important your procurement process and any associated tender (ITT) document can be. You should be able to define the fundamental requirements and scope enough so that you are not arguing so early, but I am not convinced that a long, complicated ITT document would necessarily mean you would avoid such issues.

For most CRM projects for charities, the procurement process should be about finding the right supplier, the right business partner for you, and their software/solution is part of that. But I do not think that, for most charities with their resources and needs, that a tender document can be certain to (or even should) cover the whole scope, encompass all functional and non-functional requirements, and do it to such a level that no disagreements will come later.

There are increasingly good reasons, therefore, especially for larger CRM projects and especially when building on CRM platforms, for doing an initial ‘discovery’ phase after the initial contract award which will spend more, detailed time detailing what is required from the rest of the project: what, when, how and who is responsible. To a certain level at least. And at least so that the client and supplier know more than they did pre-sale and so the supplier can refine and provide more accurate cost/time estimates on the agreed scope/requirements. Even if you are planning an Agile implementation thereafter, this ‘waterfall’ part of the implementation is well worth while.

“The programme was complicated and highly ambitious [and] the idea was to merge more than 130 legacy systems.”

Any IT/CRM programme where you know it is going to be ‘complicated and highly ambitious’ needs to be thought through more carefully before implementation. Can you really manage such a project in ‘one go’? Should you instead break it down into blocks/smaller sub-projects (regardless of project management methodology), thus considering how some aspects of it could be de-risked and the different blocks made less complex?

If you are going to merge several/many legacy systems, then this is a wonderful opportunity to break down the implementation into multiple blocks, prototype, do early go-lives for limited users/functionality, learn lessons as you go along. Even if those lessons show the project will be more complex than first thought, then get this lesson sooner rather than later.

You can still be considering ‘the overall’ project at the same time (e.g. considering how you can do merging/de-duping from each legacy system into one, looking at overall visions/benefits) whilst you are doing one or two of the early migrations.


"The two parties had initially believed that the majority of the system could be based on an existing IT system that Accenture had delivered elsewhere. But… as the design and development process developed, it became apparent that Accenture would need to develop significantly more than what had originally been anticipated."

If a supplier says the majority of their system can be based on an existing system they have, well, if that is the case, couldn’t you be shown that system up-front? And if so, then both sides could tell far sooner (i.e. pre-sale) if it really is viable to be re-used? Similarly, if it is that good, then couldn’t a simpler ‘fit gap analysis’ help in the first place? If that shows it is a larger gap than expected then, again, find out early.

If you are buying a CRM system based on a platform and you are being told there is 'an existing system' you can use, then ask for more evidence, do more work on investigations, plan how you are going to run the project accordingly and ideally, consider if the contract can reflect that.

And if your supplier does not have experience in your sector, with your requirements, then although that certainly does not necessarily mean that they could not do it, it does show that you need to be more careful about the procurement process.


“After Police Scotland tested the system, Accenture estimated that meeting the requirements of the contract would take an additional two-and-a-half years, with the live date pushed back to April 2018, almost four years later than originally planned. [And] Police officers found 12 critical errors that made the system unusable, with 76 defects in total that required more work.”

This shows that ideally you do not wait until UAT to test such fundamental issues. Ask how the design is being done earlier. Are there critical factors you can test earlier, even in a waterfall project? An ‘agile’ or iterative approach (even a hybrid waterfall/agile methodology) can also help mitigate some of the risks of doing UAT close to a go-live which might mean that only then will you find issues that could push back go-live so significantly.


“Accenture underestimated the complexity [of the project].”

This sums it all up and it is sadly something I have seen on a number of charity CRM implementations by (large and small) suppliers and business partners. Maybe they don’t know your business/sector well enough, maybe they have under-quoted even if they do know it, maybe you as a client didn’t explain the complexity well enough. I hope that all the above points should help mitigate some of this possibility.


1. I want to emphasise that this blog post is in no way suggesting that only Accenture have issues such as this! Clearly you could have the same issues with any supplier. And, of course, I don’t have any knowledge of this specific project except for what the article provided – but I do think there are generic points we can learn.

Thursday, February 16, 2017

What Small Charities Need to Know About CRM Systems – 2nd Version

I have updated my free ebook, What Small Charities Need to Know About CRM Systems. Buying a new CRM system or fundraising database can be a daunting experience for any NFP organisation, let alone a small charity. So although I publish a lot of information on my blog which I hope is useful for all charities, this book contains some points which I think smaller not-for-profit organisations need to particularly be aware of or specifically consider.

As before, this book has been produced for people whose day job is not the procurement or implementation of new databases – which for small charities is probably almost everyone! And you do not have to be technical to understand it. It is for fundraising managers, chief executives, trustees and fundraisers, but of course I hope it is equally useful for database staff and charity IT staff too.

This second version has a brand new section on System Development and updates throughout the rest of the book to reflect my latest thoughts and the software options now available to the sector.

Click here to download the PDF for free.

Tuesday, December 20, 2016

12 Key Lessons From My Last CRM Project

On the twelfth day of Christmas, my truelove gave to me... Twelve Key Lessons I Learned From Managing My Last CRM Project


I thought I would finish this set of blog posts with a quick-fire set of some of the most important lessons I learned from the last CRM project I managed. Each point really deserves its own dedicated blog post, but I hope they provide a succinct set of tips in themselves:

  • Configuration not Customisation where possible: I have blogged about this before and it remains true. The more you can Configure and use the software's built-in tools and GUI to configure and define your system, the better. Each bit of Customised code will add cost, time, risk, pain and something you should try to avoid unless you can see real benefits, at least during implementation.
  • Don't try to re-create your existing database: It is so easy to go down the path of replicating exactly what you do now but just in a new CRM system, when what you should be trying to do is use the functionality and approach and benefits of the new CRM system. If you have bought system X then use it as it was meant to be used. Long-term that will set you up so much better.
  • Yes, ask users what they want, but then start with a simple base configuration and go from there: i.e. don't try to do every little single thing which users ask for, don't try to change every form on every screen for n different teams, don't bend and change the software in complicated ways when you are still learning and building it. Instead, get the basic requirements, use the software in as simple way as possible to get a starting point and then show the users that - if there are then things which you really have to change then you can consider them at that point or even post-live.
  • Don’t under-estimate the challenge of data integration: Integration is hard, no matter how you do it. Think of all those external data sources you need to import, that other system you want to share data with/update from your new system. It takes time, effort and money. Some suppliers may have starting points for some things such as JustGiving etc and that's good, but you may still need to change things.
  • Treat reporting as its own workstream: Reports are always one of the things in a project where you start off with great intentions and then as the project goes on, you can find they slip down the order of priority. I would recommend managing them in a dedicated workstream, with a dedicated member of staff leading on them. Remember: reports are one of the key reasons you have a fundraising/CRM system in the first place!
  • Work hard at supplier relationships: At some point in your implementation, it is highly likely that something will go wrong and you will need to discuss something painful with your supplier. The better your relationship with your supplier at that point, the more likely you will be able to come to a mutually satisfactory conclusion. It needs work but it's worth it.
  • Consider a Product Owner/Solution Owner: In a large CRM project with a significant timeline and budget, consider including a role of Solution Owner (aka Product Owner). This is a role for someone who understands not only the charity's requirements and strategies but also fundraising/charity requirements more generally, as well as CRM software and technology. The reason for this is because the implementation of sophisticated, flexible (and often expensive) CRM software systems is of course not just about the software but about building/configuring and using it with the people and processes in mind - and understanding the whole approach, design, dependencies and implications of design. The role provides a central point of contact for design understanding and fundamental decision making.
  • You will always need more people on your team: As the project progresses, you will no doubt find that you could do with more people working on your project, although it could be that you don't know all the exact roles when you start the project. So think about this up-front, budget for it and bring on some roles as you go through the project. Ideally, have a budget for future roles but have an agreement with your project board that you can define the actual roles later. And backfill if you can - always good to up-skill both the people you bring on to the project and the staff who step-up to do the BAU whilst those other people are on the CRM team.
  • Think about the post-live structure of your database support team ahead of time: It could well be that the roles you have in your current database support/CRM team will be different to those which you will need with your new CRM/fundraising system, especially if you are moving from a traditional/proprietary software to a CRM Platform,  Think about this as far ahead as possible and make plans.
  • You can mix-and-match your approaches to cost within the project: There is always the question of whether you should go for a Time and Materials (T and M) or a Fixed Cost budget. In fact, you could mix and match even in the same project. For example, some of the development work might be T and M but the data migration could be a fixed cost. Etc.
  • Post-Live: Use a Roadmap, not Phases. I will point you to my older blog post on this as the principle still stands. I believe that having a roadmap approach to post-live development is far better and more efficient than the concept of Phase 2, Phase 3 etc.
  • The importance of fun in internal comms: When you are engaging all your users, staff and stakeholders with your regular communications (which you have planned, yes?), then think of the one word which many people would describe such comms. Go on, close your eyes now and do it... Okay, got that word? Was it... "Boring"?! Sorry, that is often how it is! So make your internal comms more fun: whether it is with more innovative emails, interactive demos, screens in the staff room, lunchtime meetings with food, competitions with chocolate... It doesn't matter so much what it is, but try to think what would make you read something you didn't want to read and do that.

Monday, December 19, 2016

Supplier Catchphrase Bingo!

On the eleventh day of Christmas, my truelove gave to me... Eleven Things Which Suppliers Say at Demos Which You Can Use to Play Supplier Catchphrase Bingo!


So this is mainly for fun but with a serious(ish) message. The next time you have a software demonstration from a supplier or set of suppliers, listen to their spiels and see how many of the following phrases they say which you can tick-off in each presentation...

We offer the best support in the sector Our system provides a 360 degree view We want to be a partner with you
This is a Game Changer You must be in the Cloud Our system is completely Future-Proofed
We’re specialists in sorting out other suppliers' problems You don’t need any documentation (We do) Agile...
You should never buy… (e.g.) a CRM Platform/proprietary fundraising software…
X isn’t difficult (e.g. data migration, integration, reconciliation with your finance system, security)

Of course, some suppliers may say some of the above things and genuinely mean them. Some companies of course implement CRM systems using an Agile project methodology and may well do it well (I'm just sceptical of what exactly they mean by that or if it is just a buzzword they are using); some will truly believe that Cloud is best (for them at least); and some may well have sorted out another supplier's "problems" at another charity - but by the time you've met a few, each one of them will be claiming they have sorted out another's problems...

My point here is not to ridicule suppliers, but to emphasise that they are, understandably, selling to you. You need to ask questions, dig down into specifics, request examples, ask them to show you specific elements of their software, talk to their implementation and support staff, have second meetings and so on and so on.

And always take with a pinch of salt any company that says their software is completely future-proofed.