What makes a great database manager? (Part 1)

I have been fortunate to have worked with some great Database Managers at some of the charities I have consulted for. At least, I think they were great. But I have often wondered what it is which makes a great database manager. Why is it that some people have really stood out when I worked with them? Can we actually define what makes a database manager "great"?

Here’s my thoughts on that - and it's a 2 part post because (as usual!) I have quite a lot to say...

My Definition of a Database Manager

First off, for the purpose of this post, I thought I should try to define the sort of role/person I am writing about. This is because the job role of “Database Manager” can mean a number of different things depending on the type of database, size of organisation and database team, the specific tasks they are expected to do and so on. So here's what/who I am thinking of:

• I am presuming that the role is not purely for a “techie” who would only look after the “back end” of the database and who would rarely come into contact with end-users, application users, business users et al. As such, for the sort of Database Manager I am considering, it shouldn’t matter too much if your database uses SQL Server, Oracle, MySQL, Access or whatever.
• They are someone who is more likely to be working with the “application” than the back-end; e.g. they would know (or could learn) The Raiser's Edge, an IRIS system, Salesforce, DonorPerfect, ThankQ etc. 
• They are therefore highly likely to be someone who would have regular interaction with end-users and business users, so they need more than just technical skills. They need some technical skills, but how much depends on each specific organisation.
• It is likely that they would not be part of the IT department in a charity – although that isn’t critical.

I do recognise that when it comes to a Database Manager, the size of an organisation can have a significant impact on their role and responsibilities. For smaller charities, they could well be looking after the fundraising database package, trying to write a temporary Access system and do the daily backups, whereas in a larger organisation there might even be a team of people who “manage” the database, which could mean that each individual could have different roles (e.g. data loading, support desk) and the head of that team might be far more of a “classic manager” than simply a database person.

And there are more ways of defining such posts too; I’m absolutely sure that for every person who agrees with one of my statements above, there will be someone else who disagrees! And that’s fine! All the above is not to try to enforce a structure on you or your charity, but to help you understand the sort of person/role I am considering when writing this post.


Experience

Okay, let’s start with the most obvious of statements but one which we should never ignore: experience is great! You can read lots of books, go on a training course and even get a degree but experience and learning and using software every day and working with end-users of all sorts and presenting to Trustees and doing things right and making huge mistakes… is all the sort of stuff which really means someone can become a great Database Manager.

Of course, having experience alone does not make someone a great Database Manager. If someone has 10 years of experience in one product but can’t hold a conversation with a business manager then they may not be right for you.

But let’s not forget how important experience is throughout every topic I list below.


Technical Skills

Clearly, a Database Manager would have some technical skills. (I detail below what I mean by technical). To what degree does depend on the system, the users, the size of the database team, even the type of fundraising etc. I know quite a few arts organisations who have a part-time database manager for their development database, and whilst I don’t think that is the best idea, they do get by, and in many such instances I am sure that the database manager does not describe themselves as technical!

• Application skills. If your organisation uses The Raiser's Edge, Salesforce, DonorPerfect etc, then your Database Manager should have a solid understanding of that system. And if they are the sole individual looking after that system then they will need to know or be able to learn in-depth knowledge. My only caveat is where the Database Manager is actually a manager of other people in their team, in which case, if such people are the “do-ers” then as long as the Database Manager knows what is possible, understands the implications, can discuss it at a good level and so on, then even if they can’t do it themselves that may not be so critical.
• Other technical skills. All the following could come in useful:
• Excel and Access. For the sole Database Manager who might have to import data, clean data, extract data for mailing houses, review data outside their database, present data differently for managers etc etc, Excel and Access are great tools.
• SQL. Whilst many packages do not require a Database Manager to have SQL skills, there are increasingly more systems where if they do have SQL skills, it can add an extra dimension to their data extraction/reporting capabilities. And for some systems which don’t have built-in query tools (or weak query tools), it is almost essential.
• PC/Windows skills, Network-savvy. It’s always useful to for a Database Manager to have at least a fundamental knowledge of Windows and at least the benefits of what a network brings (!) as they will no doubt get involved at some time with installation issues, security rights etc. I wouldn’t expect them to be able to resolve such problems but to understand the implications is a good thing.
• “Web skills”. As above, most Database Managers wouldn’t be expected to have to program in HTML or JavaScript, but again a solid appreciation of web knowledge, database/web connectivity issues and so on can help.
• Report Writer skills; e.g. Crystal Reports, SQL Server Reporting Services, Access report writer. Important if your database system uses such packages to create reports and you are expecting the Database Manager to be able to design or upkeep reports.

• You don’t need a degree in IT. It will give you a good base of understanding but I would never worry about employing anyone because they didn’t have one!

Data Skills

I have separated Data Skills from Technical Skills, but some data skills are no doubt a sub-set of Technical skills.

• Data Quality. It’s vital that a Database Manager understands and appreciates Data Quality needs and issues and why it is so important: data accuracy and data integrity (and everything that infers), data cleanliness and consistency, up-to-date data and trust in the data; how to encourage and improve data quality, what can be achieved and what can’t be enforced, business issues and requirements, legal implications, financial implications and so on and so on.
• The specific ability to consider and understand impact and dependency. It is quite a skill when someone can consider and understand what the impact would be if a user asks for a change or addition to a database. How would it impact existing data? Could it affect reports? Would other users find it useful as well? Could it be ambiguous? Are there security issues? And so on. It’s a key thing for a great Database Manager.
• Data Models/Data Structure. I think it is important that a Database Manager understands the basics of data models and definitely “gets” data structures. For example, they must know why different data types are important and relevant (i.e. free text, look-up tables, currency fields etc) and the difference, relevance and importance of “one to one” and “one to many” data structures, even if they don’t think of them in those terms. i.e. a “one to one” data item is something like a First Name or Date of Birth, where each person only has one of each, whereas a “one to many” are entities such as donations, communication records, hobbies and interests, where each supporter could have multiple such records.
• Entity Relationship (ER) Diagrams. Going a step further, should a Database Manager understand ER diagrams? Possibly if they are using a database where they will be regularly running SQL queries or if they are going to be involved in designing a system.
• Data transfer skills. If your Database Manager is going to be involved with transferring data into, and to a slightly lesser extent, out of the database, then having good knowledge of Data Transfer issues can be a real benefit. Not just on a pure technical level but understanding how data files “link together” when importing them, the issues and implications of updating one-to-one and one-to-many fields, auditing, why URNs (Unique Reference Numbers) are so important, data integrity (again!), testing… and more. Larger organisations may have a dedicated resource to do this, but if you just have one person managing your database then they need to understand Data transfer – there’s no easier way to ruin your data than import thousands of records incorrectly!

In Part 2 of this post, I will look at a how a great database manager needs Subject/Business Knowledge, Soft Skills and the X Factor...

(This post is an extract from my free, downloadable eBook, "How to Interview and Employ a Great Database Manager").

What Should be in a Business Case for CRM software?

Many charities do not create a proper business case before procuring a new database. And by a business case, I don’t simply mean a few bullet points which show why a new database is needed – I mean a comprehensive document, structured in an appropriate way which addresses all aspects of a business decision. If you do this, then you will be far more likely to succeed: you will understand your key requirements, success criteria, user involvement, constraints, risks and more; and when the project is completed, you will be able to measure its success against the criteria laid out in your business case.

So, what should a full business case encompass? Consider including the following:

• Management Summary 
• Project Background
• Document Purpose
• Document Audience
• Business Problem / Key Issues
• Project Objectives
• Alignment with Strategic Objectives
• Benefits
• Scope (inclusions and exclusions)
• Project Approach
• Project Deliverables
• Stakeholders
• Budget
• Timings
• Risk Assessment
• Resources
• Assumptions
• Constraints

Whether all these areas are needed and how much detail you need to include will depend on your specific project: it’s size, complexity, reach, risks, potential impact and so on. But do one – it is one of the best things you can do to focus senior managers’ minds on the real and fundamental issues involved. Especially when you ultimately ask for a budget.

(The above text is taken from my ebook, "101 Tips  on How to Buy Fundraising Software and Charity CRM Systems". To read another 100 tips, you can purchase the book here).

Getting Discounts on CRM Software: It's Usually Good News But Be Careful...

If you watch The Apprentice on the BBC then you will have seen the would-be apprentices desparately bargain for discounts in last week's episode. (1p off a top hat was a record low discount for any series, I think!) And quite understandably, some of the suppliers in the program refused to give any discount at all: this is the price of our product, they said, so pay it. Fortunately, in in the "B2B" world of commerce, discounts are more readily expected and sometimes given. Although it is an interesting point: if a software company is selling their database for x then that is obviously what they think it is worth, isn't it? And if they are prepared to offer a discount, then why wasn't that the price in the first place?

So if you are buying a new CRM database for your charity then do keep a few things in mind if you expect or even get offered a discounted price:

1. Purchase time is the best time to get discounts, so if you expect to increase the number of your licenses later, bargain at that time!

Suppliers will often give discounts when you are actually buying their system, whereas once you are a client, it will be far harder for you to bargain at that time to get discounts on further licenses. So, if you know that even though you are going to start with n concurrent users but you feel you may well increase that number within, say, 6 to 12 months, then see if you can negotiate a discount on those additional licenses at the time of your purchase. You need to agree a timescale for when any such discount structure is valid – it’s not fair to expect a supplier to offer an open-ended deal on that.

2. If a supplier provides a discount on a previous quote, check you are still getting the same software and services

If you do get an initial quote and then, for whatever reason, the supplier offers you a second quote at a discounted amount, then the first thing you should do (unless you know you are getting a different proposal) is check with a fine toothcomb if you are getting exactly the same proposal as you did first time around – exactly the same software with the same licenses and modules, and exactly the same services with the same number of days, level of support staff and so on. And if so, great – that’s a proper and decent discount. But if not then go back and point that out to the supplier – a discount that has actually cut down on software or services isn’t a discount at all, it’s a revised quote for a different solution. Give them a chance to explain or make amends but if they won’t then you need to consider whether the new quote is really what you want. Don’t get hoodwinked!

One other thing to consider around discounts is if a supplier offers you a huge discount and it is pretty much for the same solution as they were previously proposing. Especially if they have done this unprompted because you have just told them that you don’t want their database. This may sound like a wonderful occurrence (!) but do take a few moments just to consider why they are doing that. Is there a genuine reason that they are offering you such a large discount or is there some desperation on their behalf?

I would suggest that you do consider carefully before you sit down with them again. I do know of instances where this has happened and it has worked because the supplier has been able to explain the commercial reasons for such a difference but in general I have found that clients are quite suspicious of such instances and even a little disgruntled. (Why didn’t they offer me that price in the first place? How much profit were they making originally?)  So just tread carefully, research other sales they have done, discuss it closely with the supplier. And if at the end of that you are not comfortable then walk away – it isn’t worth the risk; but if at that point you believe beyond any reasonable doubt that you really are getting a good deal from a good supplier then go for it!

3. Why and when should you expect a discount as a buyer?

Of course, there are very good reasons for suppliers to offer discounts: for a new supplier in the market, they may want to encourage early adoption - also helps justify the higher risk for you as a client; for a salesperson who is trying to meet their quota, there may be times when they are prepared to take a hit on the price; for competitive reasons to beat a signficant competitor for a significant bid; as a final piece of encouragement for you to sign before a given date; in recognition of entering a new sector for the supplier and so on. And of course, if the supplier normally sells to for-profit companies then they may give a discount to charities and nonprofits, which is obviously fair and great to have.

What I don't think is so valid for buyers to do is to just say, "Give us a discount and we'll be a reference site for you". I would hope that whatever the case, if the supplier ultimately does a good job, then you would consider being a reference site anyway.

I think discounts work well when, as a buyer, you have selected a preferred supplier but that supplier might have quoted a significantly higher cost than your second choice. In which case, it is perfectly fair to go back to your preferred supplier and ask them for a discount. Even then, depending on the cost difference, I wouldn't necessarily expect them to meet the cheaper supplier's quote - after all, they might cost more because they are better - but you could certainly expect some allowance to be made.

FaceTwitFlashSpace: A Personal Rant

There are one or two vendors at the moment who are saying some amazing things about their “fundraising software” (and yes, I have deliberately put those words in quotes) so that if you believe their hype then you would think that you could implement their systems more cheaply, more quickly and oh so much better then any of those old-hat fundraising databases that have been around for years; and you’d be completely mad not to buy them now. Now! Apparently time is up for the old guard because they just can’t offer our WonderfulNewFunction (and we’re so much simpler to use) or they don’t run on TheNextBigThing.com platform or they don’t integrate with FaceTwitFlashSpace – which everyone knows is where every nonprofit has to be these days because they are raising, um, some money on it…  And it’s starting to drive me up the wall a bit.

So, good charity folk, listen up. Do not buy a new database because a vendor tells you they are simpler/cheaper/easier. Do not buy a new database just because a vendor tells you that you must must must use the Cloud. And do not buy a new database simply because it has a link to 3 social networking tools.

Now, before my face turns red with anger and steam comes out of my ears, let me clarify one thing: I am a very much a fan of SAAS. I believe in Open Source. I really think the new, more ‘generic’ CRM systems will give the traditional fundraising package suppliers a run for their money. I do. But I am also very much a fan of fundraising packages. I believe that proprietary software can be good. And, guess what, I am fan of systems which do what nonprofits want them to do. I think that (most of) the guys that have been around for years and years and who are still providing fundraising software are here for a reason. They are not selling still simply because there are no other options. Some of the functionality you will find in the better, package solutions has had thousands and thousands of man hours of development over years of real time. A new kid on the block may be able to replicate some of that more quickly, which is great, really I think it is, but it’s also common business sense to realise that they maybe cannot do everything which a longer-standing supplier can in such a short space of time.

So what should you do? Well, buy a new database because it is the right system for you. And if it turns out that the best system for you is cloud-based then fantastic, you’ll get all the benefits of that. And the downsides. And if you end up hosting a Windows-based system on your own server – fantastic; you’ll get all the benefits of doing that. And the concerns and issues. And if it can’t integrate with FaceTwitEtc then how much does that matter? I mean really matter? Is your fundraising going to fall apart because you can’t do such integration? Or actually, more likely, is your fundraising going to fall apart because you can’t process income efficiently, you can’t segment your database in the way in which you really want to, you can’t support your major giving team, your events team, your DM and telemarketing teams. And you can’t analyse your data and use it to make the most informed decisions for your charity.

So do your system assessments based on your requirements and the benefits you will get. Of course technology will be part of that – the technology which is available now and that which will be in the future, which of course includes the web and social media. Of course, cost is important, very important, but it’s not just software cost, it is the Total Cost of Ownership, and that over (say) a 5 year period. And of course you should look at new options on the market – every now and then a new system will come along which really is fantastic and will, if not quite blow all the other systems out of the water, then they will certainly give them a damn good run for their money. But at the end of the day, you make procurement decisions based on the benefits the software will give you. It’s not one thing and it’s not that simple. And please, remember that your fundraising software has to still do all the fundamentals that you need it to do. Now.

Lessons Learned from Implementing Single Supporter Systems (Part 2)

This is the second part of a blog post on the lessons I've learned as a project manager, implementing single supporter systems at a number of charities over the last few years. You can see part one here if you haven't already read it.
 

Lesson 5: Four Technology Lessons

As I mentioned, the technology within your new system may be the simpler bit, but that doesn’t mean to say it is always simple! And, as per a common theme of this post, there are of course many, many technological lessons to learn from implementing Single Supporter Systems; but here are 4 key lessons:

i)                    Keep it Vanilla. Fundamentally, what this 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. There are just so many great benefits which you will get from doing this, such as: improving the simplicity of implementation, lower risk, a faster implementation, a lower cost implementation and much more. I have written a whole separate blog post on Keeping it Vanilla, so please do go read it if you want to learn more!

ii)                   Data Migration is tough, but it is just technology. Again, I have written a brief, separate post with my top 3 data migration lessons, but because you could be migrating data from multiple source systems into your new single system, it has to be something you take very seriously.

iii)                 Integration is tough. In fact, it can be the most difficult technology part of some Single Supporter Systems. Everything from database/web integration and integrating with third party software, through to integrating data feeds in from other sources (e.g. fulfilment houses, third party web sites) and passing data through to other systems (e.g. finance systems). So, my advice is start on these as early as possible in the project, get your supplier involved or a dedicated expert who can work on this, and see such integration as a specific work item within your implementation; i.e. do not treat it just as yet another task which has to be done. It is of course, but it is highly likely to be a much harder one.

iv)                 Implement reporting in the initial implementation. I have been part of projects where this has been done and where it has not been done, and there is no doubt that the better approach is where it was actioned. It is such an important part of the initial implementation and of having the system at all – after all, there is no point in having a database if you can’t get the data out! But, it is often easy to overlook or forget. I would even consider having the reporting requirements as a separate workstream within the project.

Lessons 6: You need a Project Manager

I’m hoping this is something I shouldn’t need to say, but just to make sure: you need a Project Manager. And unless your Single Supporter System is remarkably small, you need a dedicated Project Manager. Because your implementation will take time, effort, co-ordination, liaison with many interested people and parties and a heck of a lot of work; and it just isn’t possible to do that for any significant system without a dedicated individual.

For more thoughts, on this, read my post on the Top 10 Benefits of Project Management.

Lesson 7: Just because you now have a joined-up, Single Supporter CRM system, does not mean you can now do joined-up CRM.

So you have your completed Single Supporter System, which of course means you are ready to “do” centralised CRM, yes? Well, no. Because although your new system will of course give you the tools to manage your contacts centrally, it does not mean you are ready and have the processes and protocols in place to implement this.

It’s all about the Change Management.

The best example I can give is this: if previously, your different departments or teams were all writing to and emailing their contacts without worrying about what the other departments/teams were doing, then this won’t change automatically just because you have a new system. You will still need to literally sit down and discuss this and plan your communications and contact management strategy from a centralised point of view. And it won’t necessarily be easy!

So, again, plan ahead, plan separate Change Management streams within the project, recognising that the technology is the deliverer and driver and not the creator of answers. That is down to that good ol’ fashioned thing called human decision. Although of course we hope that the new system can support and implement such decisions – that would certainly be quite nice…

Lessons Learned from Implementing Single Supporter Systems (Part 1)

I have helped implement and been the project manager on a number of Single Supporter Systems over the last few years, and last week, I gave a presentation about some of the lessons I have learned from doing so at the Institute of Fundraising Technology Group conference. This post incorporates the details I discussed at that session plus a bit more. 

I have split the post into 2 parts because there is quite a lot to say, although as I mentioned at the conference, I can sum up my lessons learned thus: it’s the people and processes which are the difficult parts, the technology is the simpler bit. Although do note I said simpler, not simple…

Lesson 1: What is a Single Supporter System?

For the purposes of this blog, I am going to define a Single Supporter System as something which enables you to see everything about a defined set of constituents in one place. I use those words carefully as the actual system (the 'something') could be a single database or it might be a ‘marketing view’ of several source databases. I’m not going to go into the technical issues and the pros and cons of all such approaches in this post, but the heart of my lessons learned will be the same regardless of how you do it technically.

I also have a slight assumption that if you are building a Single Supporter System then you have, or have had multiple existing systems, or you may have one system but you are now implementing it with new and different departments or teams who have never used it before. That said, if you are planning a new CRM system which is just for one team, such as Fundraising, then most of these lessons will be equally applicable.

It is interesting that it can be difficult to define a Single Supporter System and there are many similar terms and words which we could use instead, all of which could be easily inter-changeable. For a bit of fun, click on this diagram and you will see what I mean! My favourite is “360 degree customer relationship management database”; that’s some TLA…

That said, there is also a serious point to mentioning all these buzzwords, because one lesson I have learned is that it is often better to give the system a more “user friendly” name than The Single Supporter System or the name of the software package you are using. A short, well-understood moniker can help users’ understanding and acceptance, especially if it is an organisation-wide database and not just in one department such as fundraising.

The other key point which you need to define immediately is that middle word in all these phrases: is it supporter, donor, contact etc. Again, this is important from a comprehension and acceptance point of view amongst all the users, but more critically, we have to define just what records are going to be stored on the system and which are not. That may sound obvious but if you do not define your scope right at the start of the project then you will heading down a long, dark path of confusion.

Lesson 2: Define a (Strong) Business Case

Following on from my last point, let’s take a step back. Not only do we need to define the make-up of the system but there are lots more things we need to define and agree on first. And for this, we need a Business Case – i.e. not just something we say, but a properly structured and well defined document.

There are many reasons why and it requires a whole separate blog post to discuss [and indeed at the IoF conference, there was a separate seminar examining this] but for me, and especially from my experience as a project manager, one of the key reasons for having a Business Case for a Single Supporter System is so that we can absolutely define the scope and benefits of the project; so that if, during the implementation, someone in the organisation says that their database should also be included in the new system, then, if it wasn’t in the original Business Case then I can very simply say that isn’t something we are doing. Or, if they really think it should be, then they can ask for the Business Case to be reviewed, and if that is agreed to, then, if the Business Case subsequently changes, then we can decide if the Business Case still holds water and thus if the project should still continue.

So my three key reasons for having a business case for such projects are:

-         To define the scope of contacts/records being held in the system (as discussed above);

-         To define the functionality;

-         To set the objectives and measurable benefits we are aiming to get from the system;

The Business Case also needs to have top level management support, the more senior the better.

A quick word on the fact I said the benefits should be measurable. I know this is difficult but we have to do it. If we don't then how can we truly say if a project is successful or if it has reached the goals and benefits it set out to achieve.

Please note that there are many more reasons for having a Business Case and many other things which should be included in a Business Case – this post is just to emphasise the key ones I think are useful for a Single Supporter System. For a very interesting discussion on this very point, have a look at the IoF Technology Group’s LinkedIn Group discussion board.

Lesson 3: Manage User Engagement

So if I think that the people are the harder aspect of implementing such systems, then what can we do to manage user engagement?

I have actually written several other blog posts about this, so I am going to sign-post to them here:

-         16 Ways to Improve User Buy-in, and

-         The Next Time Someone Says, But They’re My Records…

I do want to emphasise the second post. Because when it comes to Single Supporter Systems, we cannot afford for individuals to be maintaining their own data silos (typically, spreadsheets…). They may well have good reasons for wanting to ensure they control communication to their contacts (e.g. VIPs, major donors, MPs etc) but this does not mean they should not store their data centrally. The fundamental reason being that if they don't store their contacts on the central database then, in actual fact, it will be impossible for them to stop anyone else contacting them - assuming that such contacts have - or will have - other relationships with your organisation which are already stored on the central database. In addition, more and more, organisations are understanding that the concept of "my records" is not helping the charity holistically – and the end of the day, it is the organisation’s data, not yours.

Lesson 4: We need to Define our Business Processes

This is a classic, now quite old “cartoon” which shows the evolvement of IT practises. Click on it and have a look if you have never seen it before! It is frighteningly accurate too many times!

And it emphasises an important point: it isn’t easy defining business processes but it is necessary in order to implement a new system – especially a Single Supporter System where it is imperative that everyone uses the system in the same way. It is also very hard sometimes for users to sign-off processes when they are written-up and given back to them, especially if/when they are written up in “tech speak” and/or “system-specific speak” even if the document detailing the processes tries not to be technical. We have to recognise this and need to work very hard to make such documents as understandable as possible to such users. I have also found that mocking-up the system to actually show users how it will look can help this process.

We also have to remember that a new system gives us the chance to ask the question, “Why do we do the following process as we do now anyway…?” And in my experience, it is likely that the answer will fall into one of 3 categories:

i)                    We investigated and it is the best way of doing the process;

ii)                   Er, dunno, we’ve just always done it that way…;

iii)                 Because our existing computer system made us do it that way.

A new system is thus a great catalyst for us to address the above and decide on what is the best approach for the new system. And over the years, I have come round to thinking that the following works best: you should, where possible, fit your business processes around the database you buy – and not fit the database around your processes. This does presume that you are implementing a package of some sort and not creating a bespoke solution.

Why? Many reasons again, but the key benefits are:

-         The database has been designed (hopefully) using good practise and has evolved over the years for many other organisations to use, so why can’t you use it that way too?

-         You’ve bought the software, so use it! If you decide to start customising and changing it left, right and centre then is it the right system anyway?

-         It is more future-proofed; when new releases come out, there are no customisations to break, no bespoke practises to change.

-         It is (usually) cheaper and quicker to change your processes than the software. Usually…

-         And, for Single Supporter Systems, you are likely to have many different views from lots of different people as to how we should be doing something; so having a base of ‘this is how we do it’ can be useful.

I also realise that rules are there to be broken so although the above is always my opening gambit, it does not mean you should always follow this rigidly. I recognise that there are some business processes which really have to follow certain processes (e.g. batch entry, gift aid processing) but I have to presume at this point that your initial procurement was good enough to have ensured that such important processes could be done as you needed them to be. So, if you haven’t done your procurement yet and you are reading this, then take note!

Part 2 of this post will cover the following areas: Technology,  Project Management and a final key point which brings it altogether.