We’ve run many data-driven marketing technology projects over the years, both large and small. Heres a simplified version of the methodology we use, and some hints around getting your project up and running!
1. Project Feasibility – an informal review to scope the potential project and set some expectations. This process might be no more than a short internal meeting, but at this stage youll not only be able to roughly size the project, but you’ll also have a good handle on the costs youre currently incurring. Look at the organisations current levels of marketing activity, not only in departments carrying out marketing, but also Sales and other functions. Try and come up with some metrics such as spend (internal, number of activities, overall number of touches), and the programme objectives; customer acquisition, retention, up-sell/cross-sell. Dont forget softer marketing activities such as newsletters sent by product or customer service groups.
You also need to get a rough idea of the data available, again don’t forget to look outside the main marketing teams as well as internally. This usually means Sales, Finance (if there is no data warehouse), Customer Services and product management teams.
Add into the mix your organisation’s future needs, growth strategies, new products, desired improvement in customer experiences, structural acquisitions, as well as any predictable internal factors around people or structural changes.
Activity + Costs + Data Resource + Business Objectives are the inputs youll need do outline the project scope.
2. Initiate Project – you might have an internal project initiation process or it might be a more informal set of actions. But any successful project will need most of these components in place:
- Business Buy-in – Your project is going to need or catalyse change in your business. Now is the time to get your directors or SVPs on board. And don’t forget to keep up a dialogue with the guys in IT!
- Project Champion (Board) – Someone with a stake in the project’s success and with enough political weight to fight your corner for resource and support
- Project Manager – A good PM combines a detailed technical understanding with the oleaginous charm of a diplomat and the motivational skills of Madame Whiplash! They can be either from marketing or from IT or both. At times it’s going to be a full time job, so make sure they have the bandwidth.
- Success Definition – Develop meaningful indicators of success; these might include reduction in costs, improvement in productivity or trends in conversion costs. Keep them simple (at least what you share with the business) and realistic.
3. 1st Stage Requirements Definition and Data Audit Documentation
- A high quality piece of work at this stage is vital to the success of the project; investment in time here will be repaid by a successful implementation many fold. When you start writing the cheques is too late to be figuring out that what is being delivered doesn’t meet your needs.
- Clearly prioritise all key features; essential/desirable/optional. On any requirements document the nice-to-haves tend to take up the same amount of space as the need-to-haves.
- Think about phasing; its likely any substantial project will be delivered (and paid for) in a number of stages; prioritise key deliverables, but you also need to work out the optimum structure to meet operational constraints.
- Identify any internal process changes needed, this is another area that is easy to overlook or underestimate. Does this need to be a vendor deliverable or can the business handle it themselves?
- The Data audit doesnt need to be exhaustive at this stage; but you need to have a very good handle on the inputs the system will need, files layouts where applicable, approximate record quantities, and source system dependencies. In any complex organisation it’s easy to underestimate the number of data sources needed for build and production. On one recent project the estimate was 18. The real number once an exhaustive process was complete? 61!
4. RFI/RFP to vendors (and internal Technology Group) – You may or may not have an internal IT resource who feel they can deliver a Marketing automation/CRM project. One way to cut through the politics of this is to ask them to respond like the other vendors making sure they price internal IT resources realistically.
5. Response evaluation and contract negotiation
- Allow plenty of time for this stage; there’s nothing like seeing the figures on the table to focus the mind, and the solution provider will be looking to safeguard their position. A successful negotiation will allow both parties to apportion the risk
- Usually there will be a significant up-front cost for development. A guaranteed contract term will allow the vendor to amortise the development costs over the the period of the contract.
6. Project Plan and Timeline setting – Make this realistic but not too long. You need to be able to keep the momentum going, but its not great to forever be announcing delays. Try and structure the project to allow early wins; for example you may not need every single data feed to start gaining value from a single customer view.
7. Detailed Requirements and Data discovery
- This should be straightforward process if youve got a good requirements price, but the vendor should respond to your functional prioritisation, allowing you to make informed choices before agreeing the statement of work.
- Allow plenty of engagement time for data discovery. You’ve probably lived with this data for a long period of time, but any external consultant or specialist is starting from scratch. You;ll also have to make knowledgeable internal data specialists available to the vendor; if you’ve got complete documentation on all internal systems and feeds, congratulations that’s a first!
8. Development Ensure configuration and customisation adhere to the agreed requirements and specification, without suffering from scope-creep (constant additions to the original functionality). Any such development should be minimised and every process or function scrutinised to gauge its real priority and whether out of the box functionality will suffice. Conduct regular review sessions with key stakeholders to demonstrate functionality and ensure it is on track.
9. Implementation and migration Develop data migration and cut-over alongside functional development. Ensuring the right data is available in the new system from day one is critical and users will be unforgiving if it is not. Many CRM implementations fail due to data issues, including data quality. Will you migrate all data from legacy systems, or apply rules and filters? What is the data model of the new system compared to previous ones, will there need to be a mapping process.
10. Training Go-Live Don’t overlook training and plan well in advance of go-live. Avoid the temptation to just let users loose on a new system and learn it for themselves, but develop a proper training programme, with hands-on usage (even if its a late beta version) and plenty of exercises and review sessions. Aim to have training deliverables available (documentation, process guides or screen tutorials). Run post go-live sessions to re-cap key functions and answer any questions on general functionality arising as users start utilising the system.
11. Evaluation and On-going development Conduct reviews to ensure the system is delivering the required functionality. Survey users for their opinion on usability, how much they’re using the system and any key missing functions. Does it make their job easier? Put aside resources to make enhancements post go-live dont expect the job to be complete at this stage.