With the Arts Council announcement last week of cuts in funding for many organisations, fundraising is going to become more important in the years to come. So what options to arts and cultural organisations have when it comes to database/CRM technology for fundraising?
To answer this, I am splitting this blog into two posts: first to consider the background to how fundraising software fits in to an arts organisation’s structure and secondly to examine the pros and cons of different approaches and provide some resources which list specific software which organisations could consider.
And why am I doing this, instead of just simply listing software options? Because that is often one of the fundamental mistakes that arts and not-for-profit organisations make: just looking at fundraising software in isolation of other data, other operations and contacts, and other requirements. And as that is where so many organisations can go wrong, I wanted to address that first.
Is Fundraising for the Arts different to other Charities? (And Does this Matter When Buying Software?)
My experience is that the answer to this is Yes and No. Yes in particular because the arts audience is very different: most prospective donors will either have come to an event, visited an exhibition (or sponsored an exhibition), bought a ticket for a show or have a very close link to the arts organisation; and so on. I know that is a slightly sweeping statement but my point is that I don’t find many arts organisations doing large individual giving campaigns, street fundraising etc.
And of course the fundraising for a theatre or arts centre is therefore a different “type of ask” compared to “classic” charities. You are not asking someone to help cure cancer or care for an abused person; you are asking someone to give money to something they have enjoyed (aesthetically) or believe in or want to support for wholly different reasons to health, child care etc.
And Yes-ish in that the type of fundraising is often mostly oriented to big gift fundraising, corporate revenue, trusts/grants and lots of events of all sorts. This isn’t specifically different to other charities, it is more a sub-set of other fundraising.
But of course No, in that the sort of work an arts fundraiser is doing will still be the same as a charity fundraiser: building relationships, recording contacts, making proposals, asking for gifts, claiming gift aid, writing mailshots, using the web and so on and so on.
So does any of that matter when it comes to databases and technology? Only so much in that some elements of the CRM will need to be strong for the key arts requirements and other aspects may not be so critical. But the fundraisers still need good and specialised software of some sort…
But there is one other key point within Arts Organisations which can impact software selection/solutions and that is the Other Areas of Business which an arts organisation is more likely to need to manage.
The Different Areas of Operation in an Arts Organisation
It is highly likely that an arts organisation will have different areas of operation outside the fundraising or development office. For a start, the box office/ticket sales. Then they may do event/room hire; press and PR of course; individual membership for many organisations; corporate membership maybe; patrons. Then there are the lenders, the artists, curators, key funders… and more. And as I mentioned above, many such interactions revolve around events.
Now of course some charities will have “other operations” as opposed to just fundraising, but my experience of arts organisations is that their “operational requirements” in terms of the need for IT/database/CRM systems are wider than most charities of a similar size. And yet, and here is one of the key issues for arts organisations, even though so many of those constituents I list above may be inter-linked and cross-over between different areas, and even though organisations would like to “cross-market” and create an organisation-side CRM strategy, historically, many, many arts organisations have created data silos (i.e. separate databases and systems) for each team and each area of operation.
And that is therefore a key thing which should affect and impact on the decision process in how an arts organisation approaches their fundraising and fundraising software requirements.
The Different Technology Approaches an Arts Organisation Can Take
In the second parts of this blog, I will go into more detail as to what options an arts organisation has in terms of fundraising database/CRM technology, but briefly, here are my two main categories:
i) An integrated database specifically designed for arts organisations (theatres, museums, arts centres etc): this encompasses a single database with multiple functions, usually incorporating features such as fundraising (development), membership, patron management, ticketing/box office functionality, event management and general contact management.
ii) A stand-alone fundraising database. i.e. a system only used by the development office with no functionality for membership, ticketing etc.
There is also a third option which is a “hybrid” approach to the above, whereby you might have a dedicated box office system with a separate “CRM” system for fundraising, membership, event management etc, and then, ideally, a link set-up between the two to share key data. (By the way, if that sounds easy then trust me, it really may not be!) For the purposes of this blog post I am not going to pursue this third option.
And a Final Note: Stop Using Excel!
If you currently use Excel for your “database” then stop! Don’t do it any more! There are packages I am going to list in the next blog posts which cost from £100 upwards. Use them instead! Please.
In the next post, I will discuss the pros and cons of the above approaches and provide some resources listing different software packages.
My views on the database market for charities and NFPs: packages, CRM and bespoke developments. In particular, but not limited to, fundraising and membership.
Thursday, April 07, 2011
Wednesday, January 19, 2011
How to Consider All Costs in Database Procurement
Because most charities will only make a significant investment in a new database system every few years, they don't always consider how they need to compare the costs of such purchases. And it is vital that when comparing costs you don't just look at the cost of the software - you must look at far more than that. One useful approach to help with that is to use the Total Cost of Ownership (TCO) cost model. This post provides a basic introduction to this.
Why is TCO Important?
Firstly, you must remember that the new database software is only one element within all your potential costs for a new system, and secondly, that it is not just the initial cost of the system which you need to cost – you should create a TCO for, say, 5 years.
This therefore involves the comparatively simple task of comparing ‘direct’ costs such as software, the supplier’s implementation services, additional hardware etc, but optionally you could also incorporate the more difficult/complex task of additional cost factors such as internal IT HR support costs, electricity, de-commissioning etc. In practise, most charities will find that even if they just compare the more direct costs, that will still help significantly, and it will probably only be the larger organisations or charities who implement large CRM systems who will incorporate the additional cost factors.
Costs you Should Consider
Below, is a list of ‘direct’ costs which you should definitely be able to calculate when comparing database systems (although different suppliers may of course call them by different terms). Although I would expect most/many to be needed within most CRM projects, you may not need them all or you may of course need other factors not listed here. Use it as an example and basic model – break it down in the best way for you so you can compare and contrast the costs. By doing this, you can compare different suppliers’ costs like-for-like.
The Database Application Software (and associated software)
• Core software / application software (including the number of concurrent users/seats)
• Additional modules
• Customisation / Bespoke programming
• Reporting software
• Web software / web services
Implementation
• Functional Specification / Analysis & Design
• Installation
• System configuration / System build
• Implementation
• System Integration – including synchronisation with your web site if appropriate
• Supplier’s Project Management
• User Acceptance Testing support
• Training (SuperUser training, end-user training, training materials)
• Go-live support
• Data Conversion (estimate or allowance)
Annual Support (Maintenance)
• Application software Annual cost
• Additional software annual costs
• Hosting costs (if applicable)
Third Party software
• E.g. PAF software, banking software, new Office software needed
Underlying Database software
• E.g. SQL Server
• Client Access Licenses
Hardware and associated (operating) software
• Server(s)
• Clients
• Communication links
You might also need/want to add annual maintenance costs for any such hardware and infrastructure.
How to use Your Calculations
Put them all in a spreadsheet, each cost as a row and the different suppliers/options as columns. After doing this, you will have two “broad” costs – a first year cost (initial implementation) and annual costs for each year thereafter. Thus, you can get a 5 year TCO; and thus you may find that what seems to be cheaper/more expensive in the first year may be more expensive/cheaper over the 5 year period!
More Comprehensive TCO
In terms of additional cost factors which help create TCO at a more comprehensive level, you might include the following. Some of these will be the same cost regardless of whichever supplier you select, or they might break-down into a few groups (e.g. hosted vs non-hosted solutions).
• Purchasing process
• Operating Costs
• Project Management
• Internal IT staff
• Internal Database/Marketing staff
• Back-filling for project staff
• Management time
• Electricity and air-conditioning requirements
• Floor space
• Outage costs
• Back-up/Recovery cost
• Risk cost
• Opportunity cost
• Additional hardware such as UPS, racks
And a Final Note on Costs
Cost is of course a significant factor in the decision of any procurement for a charity, but please bear in mind it is not the be-all-and-end-all! You need to weigh it up against all the other important factors of any database implementation from functionality and usability through to the supplier itself and how it meets all your needs.
Why is TCO Important?
Firstly, you must remember that the new database software is only one element within all your potential costs for a new system, and secondly, that it is not just the initial cost of the system which you need to cost – you should create a TCO for, say, 5 years.
This therefore involves the comparatively simple task of comparing ‘direct’ costs such as software, the supplier’s implementation services, additional hardware etc, but optionally you could also incorporate the more difficult/complex task of additional cost factors such as internal IT HR support costs, electricity, de-commissioning etc. In practise, most charities will find that even if they just compare the more direct costs, that will still help significantly, and it will probably only be the larger organisations or charities who implement large CRM systems who will incorporate the additional cost factors.
Costs you Should Consider
Below, is a list of ‘direct’ costs which you should definitely be able to calculate when comparing database systems (although different suppliers may of course call them by different terms). Although I would expect most/many to be needed within most CRM projects, you may not need them all or you may of course need other factors not listed here. Use it as an example and basic model – break it down in the best way for you so you can compare and contrast the costs. By doing this, you can compare different suppliers’ costs like-for-like.
The Database Application Software (and associated software)
• Core software / application software (including the number of concurrent users/seats)
• Additional modules
• Customisation / Bespoke programming
• Reporting software
• Web software / web services
Implementation
• Functional Specification / Analysis & Design
• Installation
• System configuration / System build
• Implementation
• System Integration – including synchronisation with your web site if appropriate
• Supplier’s Project Management
• User Acceptance Testing support
• Training (SuperUser training, end-user training, training materials)
• Go-live support
• Data Conversion (estimate or allowance)
Annual Support (Maintenance)
• Application software Annual cost
• Additional software annual costs
• Hosting costs (if applicable)
Third Party software
• E.g. PAF software, banking software, new Office software needed
Underlying Database software
• E.g. SQL Server
• Client Access Licenses
Hardware and associated (operating) software
• Server(s)
• Clients
• Communication links
You might also need/want to add annual maintenance costs for any such hardware and infrastructure.
How to use Your Calculations
Put them all in a spreadsheet, each cost as a row and the different suppliers/options as columns. After doing this, you will have two “broad” costs – a first year cost (initial implementation) and annual costs for each year thereafter. Thus, you can get a 5 year TCO; and thus you may find that what seems to be cheaper/more expensive in the first year may be more expensive/cheaper over the 5 year period!
More Comprehensive TCO
In terms of additional cost factors which help create TCO at a more comprehensive level, you might include the following. Some of these will be the same cost regardless of whichever supplier you select, or they might break-down into a few groups (e.g. hosted vs non-hosted solutions).
• Purchasing process
• Operating Costs
• Project Management
• Internal IT staff
• Internal Database/Marketing staff
• Back-filling for project staff
• Management time
• Electricity and air-conditioning requirements
• Floor space
• Outage costs
• Back-up/Recovery cost
• Risk cost
• Opportunity cost
• Additional hardware such as UPS, racks
And a Final Note on Costs
Cost is of course a significant factor in the decision of any procurement for a charity, but please bear in mind it is not the be-all-and-end-all! You need to weigh it up against all the other important factors of any database implementation from functionality and usability through to the supplier itself and how it meets all your needs.
Monday, January 10, 2011
5 Innovative Challenges for Your Database Team for 2011
If you manage a database team, or you are part of a database team at a charity, then why not challenge yourself this year and do something a bit different and innovative! The suggestions below will take time and commitment and maybe even some financial input, but I believe that you and your organisation would get excellent benefits out of them (and slightly different from the norm). They are probably best suited to charities who have a bit of manpower in their database team and a reasonable sized user-base, but even if your organisation doesn’t fit that model then you could still adapt them to your own structure.
And even if you don’t like my suggestions, what about thinking of alternative but new and different challenges of your own? Share any you come up with in the Comments section below this post.
Enjoy!
5 innovative challenges for your database team
1) Hold an Internal User Conference. i.e. In the same way that your database supplier might hold an annual conference for their customers. Put aside a day (or a half day if a whole day is too much) and have a couple of 'streams' of seminars, invite users to speak at some sessions, invite a keynote speaker (try your supplier, ask a funder, invite me!), consider workshops or one-to-one "consultancy sessions" and of course put aside time for coffee and networking. Yes it will definitely take some serious organisation, yes it could cost to do it and yes it could be a challenge to get managers to let all your users go, but, hey, it wouldn't be a challenge otherwise!
2) Spend a day in a data/database department at a commercial organisation, learning what they do and how they practise database management. We can be very insular in the charity sector, and although I know plenty of NFPs who run wonderfully good database teams, we could definitely learn from for-profit companies too. Ask your fundraisers if any of their contacts, sponsors, funders etc might be up for helping, or just use your own contacts – we all have friends who work in large companies and other sectors. One thing you could consider is not simply selecting a company “similar” to your charity, i.e. a bank or a retail organisation. Why not try somewhere completely different? A leisure centre, a construction company, a vet! Surely we can learn something from other such industries. And if you have a large enough database team, send different people to companies in different sectors and then compare notes.
3) Think of new ways to use all the data fields which you already store in your database. I have done this a few times (admittedly with varying degrees of success!) but it’s always interesting, even if it’s just as an ice-breaker for a meeting. For example, why do we store an individual's first name? Just so we can write to them? Boring! Think of something else. How else could we benefit from knowing someone’s first name? How could we use that data/information? And what about your other fields - Date of birth? A job title, zip code/postcode, first gift date etc etc. Brainstorm. Who knows what it could lead to.
4) Dedupe your entire database, just for once! Now that would be a challenge… Can we ever say that we have no dupes in our database?!
5) Do some brand new data analysis on areas never looked at before on your database. So often, database teams are asked to do specific data analysis by fundraisers because of specific campaigns, or because we/they know (or we think we know) that tried and tested analysis techniques work. Which is fine and should of course be followed. But try instead, for example, to test whether there is any correlation between 2 or more factors/data items on your database which your fundraisers have never thought of using/comparing. Compare fields and data against each other, against time, against demographics, income and so on. This might well involve a lot of data mining to come up with anything new and useful, but if you do find something then that might create a whole new fundraising opportunity or income stream. Fundraisers are not data or database experts – you are; so don’t rely on just being reactive to their requests, be pro-active and think of some ideas yourself.
And even if you don’t like my suggestions, what about thinking of alternative but new and different challenges of your own? Share any you come up with in the Comments section below this post.
Enjoy!
5 innovative challenges for your database team
1) Hold an Internal User Conference. i.e. In the same way that your database supplier might hold an annual conference for their customers. Put aside a day (or a half day if a whole day is too much) and have a couple of 'streams' of seminars, invite users to speak at some sessions, invite a keynote speaker (try your supplier, ask a funder, invite me!), consider workshops or one-to-one "consultancy sessions" and of course put aside time for coffee and networking. Yes it will definitely take some serious organisation, yes it could cost to do it and yes it could be a challenge to get managers to let all your users go, but, hey, it wouldn't be a challenge otherwise!
2) Spend a day in a data/database department at a commercial organisation, learning what they do and how they practise database management. We can be very insular in the charity sector, and although I know plenty of NFPs who run wonderfully good database teams, we could definitely learn from for-profit companies too. Ask your fundraisers if any of their contacts, sponsors, funders etc might be up for helping, or just use your own contacts – we all have friends who work in large companies and other sectors. One thing you could consider is not simply selecting a company “similar” to your charity, i.e. a bank or a retail organisation. Why not try somewhere completely different? A leisure centre, a construction company, a vet! Surely we can learn something from other such industries. And if you have a large enough database team, send different people to companies in different sectors and then compare notes.
3) Think of new ways to use all the data fields which you already store in your database. I have done this a few times (admittedly with varying degrees of success!) but it’s always interesting, even if it’s just as an ice-breaker for a meeting. For example, why do we store an individual's first name? Just so we can write to them? Boring! Think of something else. How else could we benefit from knowing someone’s first name? How could we use that data/information? And what about your other fields - Date of birth? A job title, zip code/postcode, first gift date etc etc. Brainstorm. Who knows what it could lead to.
4) Dedupe your entire database, just for once! Now that would be a challenge… Can we ever say that we have no dupes in our database?!
5) Do some brand new data analysis on areas never looked at before on your database. So often, database teams are asked to do specific data analysis by fundraisers because of specific campaigns, or because we/they know (or we think we know) that tried and tested analysis techniques work. Which is fine and should of course be followed. But try instead, for example, to test whether there is any correlation between 2 or more factors/data items on your database which your fundraisers have never thought of using/comparing. Compare fields and data against each other, against time, against demographics, income and so on. This might well involve a lot of data mining to come up with anything new and useful, but if you do find something then that might create a whole new fundraising opportunity or income stream. Fundraisers are not data or database experts – you are; so don’t rely on just being reactive to their requests, be pro-active and think of some ideas yourself.
Thursday, January 06, 2011
Should I Use The Cloud for my Charity's CRM Applications in 2011?
The Cloud is currently one of the buzzwords in the IT industry and you may well get great benefits from using it. As such, it makes complete sense for you to consider using it for your (new) database – but not blindly forsaking all other considerations. Treat it in the same way as you would any other technology consideration in your procurement process and if it turns out that your new database will be cloud-based then you will have done that in a proper, structured way.
Possible Benefits
The following list details some of the benefits of using the Cloud for a database application in particular, although as you will see, benefits often have considerations attached to them:
Possible Downsides
But you also need to consider possible issues:
Possible Benefits
The following list details some of the benefits of using the Cloud for a database application in particular, although as you will see, benefits often have considerations attached to them:
- No software installation (although you might still need to do some configuration on your network/PCs, firewall etc to enable your organisation to access the hosting platform);
- Thereafter, easy/automatic (invisible) upgrades, which is a great time-saver. (Although, you might want to consider if that is always a benefit if it means it happens without your knowledge and therefore if you haven’t done any regression testing on your existing system or without the ability to update end-users on changes);
- Richer functionality than has historically been possible with web-based systems: the latest generation of web-based databases are able to utilise far better technology, flexibility and customisation that is starting to really challenge traditional ‘client-based’ database applications that have historically provided richer functionality;
- Access: It will also be easy for anyone in your organisation to access the database from wherever they are (providing they have got at least a broadband connection), so it’s great for charities with multiple/remote offices and home users, and, increasingly now, for those who require mobile access.
- In terms of your IT infrastructure, the Cloud means you don’t need your own database server and all the headaches/upgrades/licensing issues and IT management which comes with that (technological and HR), and can ultimately mean a lower Total Cost of Ownership (though not always!). You can spread the costs more evenly when hosting;
- PC specifications: for “pure” Cloud applications you may not need such high-spec clients as you would do for Windows-based applications, which in turn might mean you can keep your existing PCs for a longer period before needing to upgrade them;
- Scalability: if you need more server space then that can be added in an instant (obviously at a cost!);
- Security: although this has to be a consideration, some data centres will have far better (physical) security than your charity office ever could!
Possible Downsides
But you also need to consider possible issues:
- When thinking of charity-specific requirements, from an application/functionality point of view, you will have less choice of actual databases which are especially written for the Cloud (although you can use your client-based systems and host them off-site instead), and functionality may not be as rich as some of the better client-based/Windows packages – don’t lose sight of this point at any stage;
- Configuration and customisation: hand-in-hand with functionality, but specifically so, is the point that not all web-based solutions will provide the same level of configuration and customisation that can come with Windows packages - of course, some will, and indeed, some Windows-based databases are not that customisable, but if you need this degree of flexibiity then take note;
- Data protection and security does need to be thought through – it isn’t impossible to ensure they are managed but don’t ignore this;
- You will need excellent and fast enough communication links into the Cloud, from all the locations where you want to access the database from - there is nothing more likely to alienate users than a slow database system - and depending on its criticality to you, a high level of service commitment from your comms supplier(s) and maybe even some redundancy;
- Backups: Any good host will not only take backups but probably have mirrored servers and other technology as well to assist when servers do go down. But for good business continuity planning, I wouldn’t just assume that the host will always do back-ups, so instigate your own process even if it is not daily. Plus, if there is a disaster at the host’s site or you run into contractual issues, then you will have a copy of your data – your most valuable asset – to hand if you need it.
Thursday, December 16, 2010
End Thought for 2010: Keeping it Vanilla
There has been a common thread amongst CRM implementations I have been involved with this year, and on various other blogs I have read and conferences I have attended: keeping your CRM implementation Vanilla.
This is an IT/CRM term which may sound vaguely amusing if you have never heard it before, but it is one of the more important things you can consider when procuring and implementing a fundraising/membership database or charity CRM system. What it means is that, as much as possible, you implement the database in the first instance without any - or with minimal - “Customisation”; although “Configuration” is fine. (NB: All packages will allow “Configuration” to some degree and if they don’t then don’t buy them).
Why is Vanilla so Important?
Why is Vanilla so Important?
Why do this? Quite simple: it will improve the simplicity of implementation, lower risk, create a faster implementation, a lower cost implementation, there will be less need for specific/expert resources, it will be a simpler and quicker data mapping from your existing database, enable simpler testing, you’ll avoid scope creep and more. All these things will mean that your initial implementation will be smoother and have a far higher chance of success. If you are buying a powerful or flexible database then it will be immensely tempting to jump straight in and implement lots of exciting Customisations from the word go, but if you do then you may not receive those benefits listed above.
Defining Configuration & Customisation
Defining Configuration & Customisation
So having said that, I should define the two key terms: Configuration and Customisation. These are my definitions below and even if you or some suppliers don’t agree with all my points, the heart of the message is the same. Different suppliers will define these differently and claim different things, so at the end of the day, you need to discuss these issues with any prospective supplier and understand, in some detail if necessary, just what you can and can’t do in each of the following areas.
Configuration. It is Configuration if...
- You use an application’s built-in tools to make changes to the system which every other organisation using this package could do and recognise if they were to start working at your charity.
- If an upgrade/new version of the package was released tomorrow, then you could install it without worrying that any of the Configuration which you had done would mean that the upgrade wouldn’t work, and equally, knowing that the upgrade would not affect any of the Configuration you had done. In practise, some upgrades might still require some such work so if that is the case for your system then do spend time to understand just what that it is. (And of course, whatever the case you always need to test upgrades anyway before going live with them.)
- The changes could probably (if not always) be expected to be done by a “non-techie”. This doesn’t mean an un-trained person and it doesn’t mean a non-database savvy person, but to put it in perspective, I wouldn’t normally expect Configuration to require any programming/coding, i.e. writing code in VBA, XML, C+ etc. This might not always be true but as soon as you do get to this level of “Configuration” then in my experience it is likely that you are starting to get to “Customisation”. Either way, ensure again that you know the impact.
Customisation. It is Customisation if...
- The implementation involves bespoke changes, new modules, hard coded programming etc which the supplier or a third-party does for your organisation for your specific needs.
- If the work does mean that upgrades/new versions are affected (either because it stops them happening or because your Customisation would need additional work to be done on it).
So should you ever consider Customisations during an implementation?
It is of course very easy for me to write this and say that you shouldn’t do Customisations but do I think you should ever consider Customisation during an initial implementation? Of course you can! Consider but always ask yourself if they are definitely needed. But if you have a critical business function which is required immediately on go-live and there is no other way to achieve it, or you will get so much benefit from a Customised approach that it just makes sense, then go ahead, see how you can implement it. In particular, if a Customisation only has an impact on an “isolated” part of the system (or as isolated as one can expect in a CRM system), as opposed to a core area then that should lower the risk. One thing you could also do to mitigate some risk would be to discuss with the supplier whether could they take your proposed Customisation and build it in to their standard product in a future release.
It is of course very easy for me to write this and say that you shouldn’t do Customisations but do I think you should ever consider Customisation during an initial implementation? Of course you can! Consider but always ask yourself if they are definitely needed. But if you have a critical business function which is required immediately on go-live and there is no other way to achieve it, or you will get so much benefit from a Customised approach that it just makes sense, then go ahead, see how you can implement it. In particular, if a Customisation only has an impact on an “isolated” part of the system (or as isolated as one can expect in a CRM system), as opposed to a core area then that should lower the risk. One thing you could also do to mitigate some risk would be to discuss with the supplier whether could they take your proposed Customisation and build it in to their standard product in a future release.
And do remember that you can of course implement Customisations later, after your initial go-live. Why is this better? Because you can implement them in a more structured way, at a better pace, spreading costs, with less risk, increase user adoption and do it as you learn the package and all its capabilities. In fact, as you gain knowledge of the package, you might even find that some complex Customisations which you were planning originally can be greatly simplified or might not even be needed at all. Don’t shy away from those which are needed or which do bring you benefits, just take them on at a pace and structure which you can implement more easily.
Are there downsides to this approach?
All that said, let me also say that if you do follow my suggestions here then there may be downsides, or at least issues to overcome, for example:
- End-users will (hopefully) be excited by the prospect of a new system, and if they have been sold-on and told about all the wonderful new, whizzy things it can do - which require Customisation… - and then find they are not included when they first get to use it, then they might be disappointed and user acceptance could stall; especially if that doesn’t improve their processes or, say, some screens/forms are not as they would ideally want. So you need to address this early on during an implementation and explain to the users exactly what they are going to get and when – and why you are doing this - and ideally give them a roadmap as soon as possible for future developments of the implementation to show when they can expect the elements which do require Customisation.
- Those great Customisations you planned for later never quite seem to happen… This is one of the higher risks of this strategy if you do not build-in a structured approach from the word go, especially for charities, where money is often tight. If you are not careful then what you start with will be seen as perfectly okay and if it's working then why do we need to do more work on the system anyway…? To avoid this, ensure you explain and discuss your proposed approach with your Senior Management Team/budget approvers early on in the procurement or implementation phase and get their full support and a committed budget for the post-live Customisations.
- And just to re-iterate what I said above: if you do require a specific function and Customisation is the only option or the best option, then don't shy away from it.
Subscribe to:
Posts (Atom)