You may have noticed: when I do market research on software vendors and products, I always approach my topics from the business point of view – not a technology category/label only familiar to product managers in software companies, or analysts at Gartner or Forrester. I name a business process (or family of processes) that I know marketers are thinking about. After all, marketing executives don’t buy software because they are collectors, they want to make their processes more efficient and expect an automation project will help.
Over the years, their list of processes to be automated has become longer but also more business centric. Way back when, marketing was only about sales support, lead generation and literature. Now, thankfully, modern CMOs or Marketing Directors are now responsible for a more extensive operation, some of them even measured on revenue contribution. And so, as with any business executive, they have full responsibility for the planning and effectiveness of all their business resources.
For a marketing executive, those resources fall into these categories: money, people, content assets and brand. And the process to manage these resources is therefore being called “Marketing Resource Management” (MRM).
I would propose that now the time has come for many more CMOs and Marketing Directors to acquire their own “ERP system” and implement a serious MRM project, taking full control over what can make a marketing organization successful – especially the financials.
Content and brand resources are already marketing-specific and many CMS and Brand Content Management systems include resource management for those resource types. Digital assets are managed in DAM and PIM systems. But using the corporate ERP software to manage people resources is not good enough as a typical CMO-led organization increasingly includes external contributors (agencies, freelancers, analysts), all to be accounted for as an ongoing marketing-people resource. Lastly, the spending of marketing budgets is now so dynamic and digital that executives can no longer rely on monthly or quarterly batched financial reports with historical data – if anything, they need a dashboard that forecasts, predicts and recommends.
By definition, the MRM system should be marketing-centric – one that has the right language or terminology, reporting structure and cadence. Marketers think in terms of campaigns, not financial quarters, and they need a planning calendar. It should provide marketing professionals at all levels in the hierarchy with an ideal experience and support decisions about marketing investments. For that reason, the ideal solution would often be one that is grown out of an existing management system used within marketing.
But a relevant MRM must be more than just a planning/budgeting system: database plus reporting. It needs to able to be state of the art in that it can:
- Take inputs from all players in the marketing ecosystem – for many companies this can include geographic entities or subsidiaries and even business partners
- Collect live data in real-time to support decision-making
- Provide recommendations and insights based on AI.
MRM is still in its adoption infancy. Capterra has some 50 MRM Software offerings in its directory. And my esteemed ex-colleagues at Forrester produced a NowTech report on MRM in Q1 this year that focused on the needs of enterprise B2C organizations above $1 billion in revenue and identified 28 vendors.
But what is the market saying?
Well, I have now fielded my 2022 global survey of marketers’ experience with MRM solutions and am talking to the vendors to complete my research. This is the list of the Top 15 vendors from the survey (in alphabetical order).
ALLOCADIA, APRIMO, BRANDMAKER, BRANDMASTER, BRANDSYSTEMS, CONTENTSERV, ELATERAL, INFOR, LYTHO, MARMIND, PERCOLATE, SITECORE, WEDIA, WELCOME, WORKFRONT
Curiously, a significant number of vendors who marketers cite as their MRM solution are telling me that they do not want to “position the offering as MRM”. Who says that the customer is always right?
Always keeping you informed! Peter O’Neill
Many years ago, working at HP, I quickly learned to schedule my vacations according to the marketplace. Common practice was, when customers (well, prospects) went on their vacation, they first dumped some work on my colleagues and myself, sending us a thick envelope (no Email in those days) containing a “Request for Proposal” or even worse (sounds so uncommitted!) a “Request for Information” — long, detailed documents laying out a series of specifications and functions that they wanted to see in our product.
We’d be expected to process/answer many detailed questions and submit a response when they came back from vacation. Most RFPs were issued, especially here in Germany, during the summer and just before Christmas.
I got the impression that creating these RFP documents, and then processing the vendor replies, was the main event for many buyers. It wasn’t necessarily about picking the right solution. The later stages (presentation, demo, negotiation, sales) seemed to happen very quickly afterwards.
Further work experience also taught me that the famous adage that “70% of IT projects fail” is very true and continues to be so. I would suggest that one reason for this is the above process. Many companies assume that the most important component of any process automation project is the Vendor Selection Process (VSP). Once that’s done, it is easy sailing – just install it, configure it, (perhaps) train the users and run the system.
Well, I’ve now assisted many a client through their VSP and sat in on their meetings with potential suppliers to provide my input as “an outsider”. I trust that my assessment of the vendors’ offerings and potential to fit into their planned technical architecture was useful. But still, I’ve often left the meetings with the feeling that the client wasn’t really prepared for the full project. I would notice that many aspects of the project were not yet thought through. There were often:
- No sample business workflows (much of which is outside the software they’ll buy)
- No profile of their potential users (devices, competencies, preferences)
- No sample reports or dashboards designed
- No prioritization in their list of requirements – all was equally important.
Process automation projects fail because of a bad fit between project solution and requirements. And when I say “project” I mean much more than the software product. The solution must cover the complete business scenario to be improved, which is usually only partly through technology – process and organization always needs to be tuned as well.
I suggest that it is now time to reconsider the role of the VSP – it should not be “the means to an end” – better to turn it into the kick-off for a process transformation project.
In 2009, the Hasso Plattner Institute of Design at Stanford came up with the concept of “design thinking” which has been adopted by many IT organizations and software vendors as the basis for their development projects. The associated meeting/communications method, SCRUM, has now even been adopted by modern marketing departments. The Stanford School process proposes these steps in a project:
Empathize – Define – Ideate – Prototype – Test.
So here is what I envisage in a modern marketing process automation project:
Empathize. Collect and describe the requirements based not on technical specifications but by describing real business scenarios – improved workflows that marketers care about. Include persona profiles and the desired “usage tone” (marketing- or IT-centric, advanced or casual user, terminology known or not, device preferred, location of task, reporting requirements, millennials!). A scenario documentation should resemble the briefings given to marketing agencies – not an RFP spreadsheet.
Define. Based on the make-up of the user-team and other requirements such as integrations and services, you should be able to easily segment the vendors and arrive at a shortlist. Provide the scenario documentation to those vendors and gather their responses as a first selection phase. Allow them to be creative – they may even be able to propose process improvements that you had not yet identified.
Ideate. Invest time here to engage with three to five vendors to explore how they would help you to automate the scenarios. If you want to restrict this phase, limit how many scenarios each vendor works on – one will probably suffice for you to form an impression of the vendor’s suitability as a business partner.
Prototype. The people at Stanford would love you to be putting Post-It notes on the wall in this phase, but you should probably expect your vendors to be able to demonstrate how they would support your scenarios with their software. You should now be down to one or perhaps two vendors. As well as checking whether they have realistic expectations, also use this phase to observe how the project members will work together – vendor people with your colleagues but perhaps you are also bringing together colleagues who are strange to each other. Create a conflict situation by changing a scenario and see how all players react.
Test. After selecting your technology provider, you now move into the project roll-out phase, which is usually focused on just one team, location, or business area to generate success and then a more expansive roll-out. Continue to expect the vendor to treat you as a business partner and working to ensure your success.
The test phase should never end. Wise project managers will maintain a running, live doc of the business requirements, because they’ll change over time. Display it in a flexible and editable spot to allow you to constantly re-check what you need, and the costs associated with it. Also, ask yourself periodically what can you cut? Or what hasn’t been used in months? Who is now using the software – is that different than initially assumed?
Something to think about the next time you plan an automation project.
Always keeping you informed! Peter O’Neill