Discovering the Requirements – When and how will the solution be delivered?

In the last posting we looked at discovering a complete view of the data sources & data feeds to a granular level, as well as an understanding of data management requirements needed to support the delivery of your customer marketing solution. We will now discuss the non-functional elements of the customer marketing solution and how these can impact when and how the solution will be delivered.

In the previous postings we spent a lot of time looking at how initial goals and objectives can be met through the delivery of the following key aspects of a Customer Marketing solution:

• Understanding your communication needs.
• Reviewing the analysis scenarios and reports required.
• Discussing the data required to underpin your Customer Marketing solution.

This covers the functional elements (a requirement that the solution must do) of a solution but not the non-functional elements (a requirement that defines how a solution must behave and can often be classed as a constraint on the system) such as a solution deployment model for the solution, is it required to be in-house (on-premise or insourced), hosted (outsourced) or a combination of the two (hybrid or shared)?

Looking at the non-functional elements of a Customer Marketing solution there are several key areas which cover when and how the solution will be delivered:

• Solution Deployment – Using a solution architecture type diagram confirm how the key elements (For example, Single Customer View, Analytical Platform, Campaign Management including items such as Email delivery) of the solution are required to be deployed:
  • In-House – Deployed at client controlled locations.
  • Shared – Deployed across client and supplier locations.
  • Outsourced – Deployed at supplier controlled locations.
• Data Availability – Using the information on the data sources and feeds looked at in the sixth posting “How much data will I need?”, the frequency and availability of data should be understood. It is however worth reviewing and checking on the processes utilised to deliver the data and any dependencies on previous processes or individuals to deliver this information. This will inform you of when the data is available, but not when it will need to be accessible, which is a critical question to the eventual users of the solution and will drive how the solution is designed and implemented to meet the required update and availability windows.
• Capacity – Look at the required life of the solution, in particular the projected growth of solution data to ensure the solution is big enough to meet those needs, as well as providing a scalable capability.
• User Community – The previous three points looked at how the solution will be built and maintained, but understanding who will access the solution and which parts they utilise, will build a set of requirements to cover:
  • Product Access (Licence and Functionality).
  • Training Needs.
  • Security (Data Accessibility, Functional Capability (e.g. Read Only Access, Read, Write and Delete Access))
• Recovery – Look at the allowable amount of downtime allowed within the solution and the recovery timescales required to support the business in the event of a critical solution failure. This element should look at recovery needs from the view point:
  • Infrastructure failure (Server and Network Communications).
  • Data failure (Source data, Single Customer View, etc).
  • Product failure.

In addition to these items there are several other areas to consider when looking at non-functional requirements, including:

• Performance – Review key performance metrics around response times; refresh timescales; campaign execution timescales; etc.
• Auditability – Define required audit requirements, to enable solution activity to be reviewed and analysed.
• Support Service – Understand the required support service levels and how differing levels of incident severity should be responded to:
  • Level 1 – Critical Failure with no access to whole of solution.
  • Level 2 – Significant Failure with no access to or failure of part of the solution, including significant solution performance degradation.
  • Level 3 – Minor Failure with single user impacted.
  • Level 4 – Cosmetic Failure with solution working, but minor element requiring resolution or identified solution enhancement request.

Please join me in the next installment of this series of blogs when I will discuss the validation of the customer marketing solution and how you ensure the initial objectives and requirements have been delivered. (Week 8: How do I evaluate success?)

If you have any further questions or would like support / guidance in discovering or defining your Database Marketing solution, please contact me through the BlacklerRoberts Ltd “Contact Us” page and I will be happy to discuss your needs. You can also follow @BlacklerRoberts on twitter for further insights.