Application Owner Interviews – Part 2: Approach and Challenges

Following on from the previous blog “Application Owner Interviews – Part 1: Benefits”, this is the second part of the blog detailing both the approach of conducting the interview and some of the common challenges we often face.

Approach

With the assistance of client stakeholders with good business domain knowledge, we need to engage with the owners of the applications identified for discovery to gain an understanding of the tacit knowledge which individuals have gained through use of the application over time. Application owners may be a combination of technical members representing the IT function or purely those from within the operational business directorate which the application is used.

When scheduling and performing the sessions, it is important that all follow the same structure and questioning. Where applicable, expanding on and confirming any knowledge already gained. This increases the consistency of information which can be gathered and will aid in producing the final output. In some cases, knowledge can be gathered from pre-existing application catalogues which has already captured this information, we just need to confirm to ensure that it is not outdated. Post the interview, we can refine any uncertainties with the application owners, providing a summary of outstanding queries unable to be addressed in the session. For example, support costs for an application may not be at the forefront of someone’s mind during a discussion but they may be able to find a supplier invoice if given further time.

All findings can be collated into an application catalogue and dependent upon client requirements, assessed and presented back, with recommendations to address the 6R’s; Replace (or re-purchase), Rehost, Refactor (or re-platform), Redesign (or re-architect), Remain or Retire.

Challenges

The overall discovery process, co-ordinating and performing the interviews themselves can come with its own challenges at different stages. However, challenges are purely things which we need overcome and often present themselves in relation to one of the earlier benefits of conducting interviews, human interaction.

It isn’t always the fault of direct individuals or a collection of, and most of these examples can be easilly overcome by simple techniques, preparation and communication. The examples below are just a few which have been chosen to give an insight and support how the techniques highlighted can overcome these.

  • Lack of internal communication: It becomes quickly obvious at the start of an interview that there is separation between the project team and application owners in attendance. Resulting in uncertainty and questioning “why are we here?”, having had little to no detail of the project or purpose of the discovery prior. This can result in additional time to incorporate further background information at the beginning of an interview but is widely beneficial to participants and presents a clear and transparent understanding of what is required of them.
  • Interviewee assumptions: Participants in the session assume much of the application background and business domain knowledge is, and should already be, known. If this was the case, we would not be having the interview however by performing prior research on the application (if available) and relaying this back to the participants, it shows efforts have been made to bridge this gap and certain aspects need to be confirmed.
  • Cross directorate applications: Certain applications will be used across several directorates within an organisation and interviewing only one business representative will only provide part of the story. Albeit much of the information can be gained from a single individual, we are attempting to gather detailed information with a view to provide recommendations. Several teams using a the same application will often have different use cases and similar but varying usage such as timings and volume of users.
  • Reluctance to share information: This exercise aims to accurately capture information and can often undercover the otherwise unknown truth, ranging from strategic decisions to replace a system to that detailing problems regards strategic fit for operational use. There can be cause for concern that this information will be fed to stakeholders and subsequently, issues will arise as a result with a negative impact. The fear of change can also be a contributor, to being reluctant to share information, so covering this off in the early stages of the interview and detailing the workshop purpose can start to relax participants. The fear of change is often something which you notice through the interview and can usually come from those who have concerns operationally.
  • Organisational fatigue: “we’ve been through this exercise before…” a similar challenge to interviewee’s being reluctant to share information for strategic reasons, they can sometimes be fatigued as a result of what may seem to be the same questions being asked and repeated previously, for similar but differing purposes. Often, it is also the same individuals within a team who participate in these excercise, increasing the fatigue more so.

In summary, the approach and challenges involved with conducting application discoveries are no different to those faced across many other types of engagement. One of the most contributing factors which separates these from others is the volume of people involved, the differing personalities and perspectives.  The resulting output at the end of the discovery which can present to a client a complete application overview of the knowledge gathered certainly outweighs the challenges faced throughout the journey.

As part of the offering within the risual portfolio, the Cloud Application Analysis provides the service to undertake this engagement. Find out more by calling us on 0300 3030 2044 or emailing at enquiries@risual.com

About the author