In my last post, I covered both what a roadmap is and why it’s important.  Now, let’s start putting a plan into action to start defining what it looks like.  As technologists, we deal with data on a daily basis – whether it’s supporting databases or manipulating data or even reviewing reports – data is the foundation for our business applications and we use data to make intelligent decisions.  The best application roadmaps are based on a strong foundation of data-driven decisions. What kind of data should you be using as you formulate your plan?    

While there are several different types of data, we’ll focus on two broad categories – qualitative and quantitative data.  Quantitative data can come in the form of results that can typically be answered either systematically or programmatically and expressed in the form of a number. It’s recommended to start your process with quantitative data as it is often the easiest to collect and can then be used later when capturing qualitative data.  Here are some example quantitative questions you can use to start painting a picture of your application:

•         How old is your system? When did it launch? What was the last major upgrade?
•         How many users are supported? How frequently do they use the system? What devices can be used for access?
•         What are the numbers of records, tables or objects used to collect data?
•         How much is spent on licensing, maintenance or subscription costs?
•         How many support tickets are created on a weekly, monthly or quarterly basis?

The answers to these questions won’t help you much when looked at in isolation.  For example, knowing that your application was developed in 2005, doesn’t tell you what needs to happen in 2020.  However, it can give you more context when you start the process of gathering qualitative data.

Think of qualitative data as something that can’t be defined by a number.  If you have ever taken a customer service survey that asks an open-ended question about your experience, that’s an example of qualitative data. Gathering qualitative data can be more difficult and often requires in-person interviews or reviews of organizational or management goals or themes.  To help spot trends and eliminate bias this type of data should be sourced from multiple functional groups of individuals. When formulating your questions the goal is to uncover the “why” or reason behind the commentary. A few ways to gather qualitative feedback include:

•   Conducting survey or hosting interviews with agents, end-users, super-users and business leaders
•   Reviewing the content of application support tickets and/or backlogs to identify trends or commonality
•   Capturing the business goals of the users or groups of users of the system and mapping their process to the features and workflow within the application

Let’s take the quantitative example mentioned previously and combine that with a few qualitative questions to get a better understanding of the needs of the organization.  

“The application has been around since 2005, technology has changed dramatically since then, what might be the processes or functions that need to change?” 

“When dealing with a 15-year old application, what are the challenges you are experiencing as you continue to evolve it?”

Leveraging the data you have gathered, you can then apply that to get the qualitative feedback that can be incorporated into your roadmap planning.  Notice how the question was framed, acknowledging the hard facts you have and then using it as a reference point to invite more critical feedback from the respondent.

After you have catalogued your qualitative feedback and overlaid it with quantitative data, the next step is to start formulating the themes for your roadmap.  Depending on the size of your organization or application, you may have conflicting data, vague or unclear needs, or you may simply be overwhelmed by everything you heard! In my next post, I’ll cover the process for drafting the roadmap and getting buy-in from your organization.