Every IT professional knows that marketers are flash, impulsive and disastrously superficial. Every marketer knows that IT types are plodding, picky and hopelessly unimaginative. However exaggerated these stereotypes there is enough truth in them to make it worth taking extra precautions when IT implements a marketing systems project.
When Marks & Spencer Financial Services replaced its outsourced customer intelligence system, customer intelligence and analysis manager Martin Squires was brought in to liaise between marketing and IT staff, having worked in both departments.
"I am a hybrid manager," he says. "I sat in the marketing department to do the technical stuff, and I own the relationship with IT."
Before any attempt was made to start selecting a system supplier, Squires and the IT project manager made sure that marketing staff understood what customer intelligence technology was capable of - and what they expected it to deliver.
"For the three months before the invitation to tender we looked at suppliers and non-competing firms, such as telcos or utilities, that were using marketing databases, to find out what the state-of-play was and draw our thoughts together," says Squires.
The invitation to tender was "very non-technical," says Squires. "It said, 'This is what we want to do - how can you best meet these requirements?'"
As the bids came in IT evaluated each proposal as to how it would fit in with Marks & Spencer's IT architecture and corporate business requirements.
Squires also insisted that IT and marketing personnel went to visit reference sites and meet both marketing and IT staff.
"We discussed the marketing users' experience and the impact of that software on IT," says Squires.
This gave marketing first-hand understanding of what customer intelligence software could do, and made them appreciate some of the IT issues that telling Marks &Spencer's IT department "We want this" and "We want that" would raise.
At software selection, IT had the right to veto software that was non-compliant with the company's architecture and marketing could veto software that did not meet its requirements.
Overall, says Squires, marketing and IT were like "two circles moving together to create an overlap" where agreement could be achieved to the satisfaction of both departments.
However, one of the tendencies of marketers, perhaps, says Squires, is to say, "Put the system in and then we'll see what we can do with it." He says, "They're not the most process-driven people."
So before a final choice was made the shortlisted suppliers were each asked to build a heavy-duty proof-of-concept prototype to experiment with. It would be far more robust than a demo could be, and this was important, Squires points out.
Although, "marketers like to see something visible," says Squires, they can be easily impressed by a fluent demo shown by skilled salesmen (who speak the persuasive language of marketing) even though it is only manipulating a meagre 1,000 records on a laptop.
Instead, each shortlisted supplier had to build a prototype in six weeks that would use 80% of the data that the final system would need to use. Marketing was asked to develop about 200 scenarios, such as customer profiling, statistical analyses and campaign management, to put through the prototype.
"We would then be able to evaluate the flexibility of the solution, its user-friendliness, and its speed," says Squires.
Having made the selection and installed the software - Cedar and Unica supplied the core of the system - Squires also had to handle the marketing staff's reluctance to do formal user acceptance testing. Their attitude was, he says, "Give it to us and we'll make changes to it later once it's in."
"We had to explain the logic of user acceptance testing to them gently," he says. User acceptance testing was essential for a system taking data feeds from 10 legacy systems to present a single customer view of a central data repository of five million customers and 10 million prospects, which is then fed to a number of different data marts running applications such as campaign management and geographical information systems.
Fortunately, because the previous system had been regarded as inadequate by marketing, Squires was able to persuade staff in the department that unless user acceptance testing was carefully and thoroughly performed, they could end up with another unsatisfactory system on their hands.
"That's why it had gone wrong, we told them."
However smooth the relationship between marketing and IT systems development, Squires knows he also has to ensure a good relationship with IT operations, especially when the system is rolled out beyond the current core of power users.
"We'll interface [non-power users] to IT, so we can manage 80% of their queries about the system ourselves, and only go back to IT with 'sensible' questions," says Squires.
"Liaising with IT operations will be an interesting challenge, and require a new set of relationships. If we build them right there will be few issues - but it's a bridge to cross."
Golden rules for smooth IT/marketing projects
- Have someone on the project whose specific job it is to liaise between the IT systems builders and the marketing users. Marketing should see them as a marketer, but they should have sufficient "solidity" to reassure IT
- Have an IT project manager who understands the user community that will use the system
- Don't rush into software selection. Give marketing enough time to understand what the current technology can achieve. Projects seldom arrive out of the blue, and once they are announced there should be time, even informally, for this learning process
- IT and marketing must check out the technology together, so that each gains an understanding of what is important to the other, and marketing understands the impact its requirements have on IT
- Both IT and marketing should visit reference sites and meet their counterparts, so each side of the project team can then hear what is important to the other from what they discuss with their site peers
- Marketers prefer hands-on trying out rather than abstract system design, but to avoid them being too easily swayed by a convincing but light-weight demo, insist on a heavy-duty prototype which has to perform with a substantial amount of the data that the live system will use, and run all the applications that users will want to run
- Marketers may need to be convinced of the need for formal user acceptance testing, rather than just trying out the system once it has been rolled out
- However good relations are between marketing and systems development, the same good relations have to be created with IT operations when the system goes into production.