Ad International Academy of Design & Technology
A colleague and I recently investigated a product that would allow us to change the content of an email once it was deployed. The system had some compelling bells and whistles, and we spent significant time trying to figure out how we could use the product.
But upon further consideration, I think our analysis was misdirected.
First, there were no requirements or needs from the business side addressed by the product, nor was the business side involved in the review process.
Second, we were more interested in the underlying technology and how it worked than in the product’s impact on how we interfaced with the targets of our email campaigns.
Joint Application Requirements
There’s a clear solution to such business-technology disconnects: it’s called a Joint Application Requirements, or JAR, and is part of what’s known as Joint Application Development (JAD).
As marketers, we have a laser focus on generating content that defines how our solution can solve business needs. As a driver in the charge of leveraging technology to optimize interactions with customers and prospects, we sometimes lose that focus, as my colleague and I did in this case.
Marketing leaders need to gather businesses requirements first before evaluating and implementing new technology. When action is taken without the benefit of this connection to customers and business needs, the ripple effect within the marketing organization and the company can include loss of competitive position, slowed pipeline and sales and angry customers.
But defining requirements is not always easy. Building consensus between diverse stakeholders can seem arduous, as can uncovering and communicating expected benefits. JAR sessions are a great solution.
Holding JAR Sessions
JARs are highly structured, facilitated meetings between multiple functional groups within the organization to uncover and define requirements. JARs are managed discussions in which all attendees state what they want while a facilitator drives toward a cohesive solution that is greater than the individual needs of the participants.
JAR sessions can be conducted in person or via a conference bridge. They can last for several hours or several days, depending on the complexity of the requirements.
Some JARs are structured to be agile – which means the requirements evolve over time — while others follow a traditional path in which all requirements are defined up front. The latter option is often better when selecting an existing product to fit into the marketing technology stack.
The JAR facilitator should be unbiased and experienced at identifying the needs of the participants, even if they’re unable to state them clearly. A consultant or business analyst from the IT department is typically a good facilitator.
Factors For The Facilitator To Consider
The facilitator will focus first on understanding why a system is being considered and the benefits expected for customers and/or prospects. Once these factors are understood, other points that should be addressed include:
Functional Impact: What impact will the new solution have on the marketing organization and existing processes? What new processes will be needed? Will there be a need for new staff? What impact will there be on other organizations within the company? Has that impact been communicated and committed to?
ROI: What ROI is required to yield success? In what timeframe does the ROI need to be achieved?
Risks: What risks are associated with the new solution? What are the risks if the new solution is not pursued?
Configurability: How flexible and easy to modify does the solution need to be?
Ease of Use: How easy is the solution to use? How do you want to access the solution (SaaS, private cloud, network)? How much resource availability do you have to maintain the application? What customer support do you need from the solution provider?
Analytics/Reporting: What type of reports do you need? How do you want to access reports?
Robustness: How many transactions do you need to process daily? How many do you need to process concurrently? How many users do you need to access the system?
Integration and Security: Do you need a solution that will integrate with existing solutions in the marketing stack? What are your security standards?
While not all requirements that evolve from a JAR have equal weight in the selection process, knowing all conditions and constraints will lead to the optimal selection. Other benefits of a JAR include:
More accurate cost and impact estimates
Mitigation of risk that not all requirements have been considered
Faster implementation
Increased adoption
The marketing organization is at the forefront of driving digitization of the business. Selecting the right technology platform will impact how leads and customers interact with the business.
Understanding the requirements and likely impact on the business through JAR sessions will result in improved competitive position, growth in the pipeline and of sales, and high customer satisfaction.
Comments