Skip to main content

Author: Tiffany Wiley

BATimes_Sep18_2024

Transition Requirements – The Key To Adoption

The key to adoption. Don’t forget the obvious.

 

As a Business Analyst at heart, requirements play a part in my everyday life. Much to the annoyance of those closest to me, I’m wired to think of everyday activities in terms of requirements 😊

However, transition requirements are sometimes elusive, even to those of us with a couple of decades of experience. But – they are the key to adoption!

A quick little story time…

When my daughter went to her first school, we spent weeks preparing; we got her a backpack and matching lunchbox, new school clothes, new shoes, and a sleeping mat, and we even planned a lunch and snack menu! I even read the school handbook, multiple times! At 3.5 years old; she’s spent her entire life with just the three of us. She never went to a daycare, so this was her first school-like experience, and we were ALL excited! Nevertheless, in all that preparation, we neglected a key piece of information – WE would not stay with her at school.

As we unbuckled her, with excitement beaming from her eyes, she stated “Mommy, we are all going to have so much fun today!”. At that moment, I knew I missed a key piece of information that was going to completely change how the rest of the day went. Oops! And it did…she was distraught! Then I was too!

In all my functional preparation, I neglected to operationalize her new school experience. I completely missed considering my key stakeholder’s transition!

Even with over 18 years of requirements management experience, I forgot the obvious. This is your call to action – don’t forget the obvious!

 

What are transition requirements?

Transition Requirements (or Transitional Requirements) are like NFRs (Non-Functional Requirements), in that they are often missed in the design and development processes.

As the name suggests, these are the requirements that will ensure a successful transition from the current to the future state.

 

Why are they important?

Without a plan to transition from the current state to the future state, adoption will surely slow if not stop entirely. You as the Product/Project Manager may be excited about this change, but excitement alone doesn’t cross the finish line!

A transition (or migration) will likely impact other business units and processes. For example, a customer may need to upgrade a current licensing agreement to transition to a new solution. Do you wait to transition them? What is the impact of waiting? Are there legal implications? Is additional training required?

Additionally, on the softer side of a transition, is understanding the change curve. Especially when it comes to process or culture-related changes, transitions can be very difficult. People are creatures of comfort – i.e., creatures of familiarity. And change is unfamiliar….it is uncomfortable. Having a good understanding of change management can help ensure there aren’t gaps in the transition plan and requirements.

 

How does that tie into overall value?

Value is realized when the solution is adopted. A single transition requirement alone does not generally provide quantitative value. However, the overall plan and requirements’ existence provides a qualitative value by ensuring a successful transition can happen – leading to better adoption and ultimate solution value realization.

 

Advertisement

 

Technique for gathering Transition Requirements?

Transition requirements should only be defined once the final solution is known. It doesn’t need to be fully implemented, but it must be known.

Unlike functional (or stakeholder) requirements, these are typically not willingly disclosed or stated by the business or users. Because of this, my favorite technique to start with is questions; to elicit information to then derive the transition requirements from that information. It is important to have a listing of questions to start with, but also being present in the discussion will help uncover additional questions to minimize gaps and assumptions.

Some sample questions and follow-up questions are noted below:

  • Are there any user skill gaps that need to be filled to operationalize the new solution?
    • Is this a training we can provide, or do we need outside help?
    • What is the cost of this effort?
    • What type of internal messaging is required?
  • Is there any data that needs to be migrated from the current to the future system?
    • If so, how can that be done?
    • Migrate all data? Only some data?
    • Does data need to be transformed?
    • How long to prep? Migrate? Validate?
    • Are there any regulatory requirements for transmitting the data?
    • What are the ideal timelines?
  • What is required to retire the current solution?
    • Can it just be turned off/eliminated?
      • Do user accounts need to be deactivated?
    • Is there a cost associated with terminating (or ending early)?
    • Will data need to be deleted? Can it (contractually) be deleted?
  • What processes need to change to implement the new solution?
    • How/when will this process change happen?
    • How/when will it be communicated?

 

Additionally, think about the differences between the two solutions/states. Then identify some questions, even if they seem silly, to help elicit information. Listed below are a couple of sample projects with a few starting questions:

 

Set your launch up for success by not forgetting the obvious – Transition Requirements.

Business Analysis | Role or Capability?

I love this question! It opens the door for so many different perspectives (which is key in our line of work). Before we answer this, let’s start with a story.

A recent employer pulled me aside after about 2 weeks on the job (as a contractor) and said “We’ve been told that we don’t need business analysts on this project. I’m curious what your thoughts are on this?” Despite my obvious hesitations with wanting to keep my job and income, I said “That’s probably right. However,…” and I went on to explain that while a person sitting in that role/title isn’t necessary, the function is. It is critical to have someone performing the business analysis activities to ensure a successful solution delivery – digging into and understanding the business and user needs, the problems they are facing, understanding the value that they are seeking, etc. Generally speaking, developers are busy developing, QA engineers are typically busy testing, etc., so someone needs to do it.

I do believe this open and honest discussion is a big reason why I was converted from contractor to permanent employee. They trusted me enough to ask the question and I trusted them enough with a thoughtful answer.

What is a Business Analyst and what do they do?

This is sort of a loaded question in my opinion. There are so many variations out there in the job world. Some people have the title of Business Analyst but don’t really perform typical “BA” activities (as outlined in IIBA knowledge areas). While some have different titles but are neck-deep in the strategy analysis, solution assessments, etc.

The IIBA Defines it as:

The Business Analyst is an agent of change. Business Analysis is a disciplined approach to introducing and managing change in organizations, whether they are for-profit businesses, governments, or non-profits.

 The global community on Wikipedia defines it as:

business analyst (BA) is a person who analyzes and documents the market environmentprocesses, or systems of businesses.

When talking to family and friends, I usually describe it as “I work with people and teams to understand what they need, want, and why. What problems they have and how they currently go about solving those problems. So that I can help define possible solutions. The solution could be new technology, a new process, new data reporting, organizational structure, etc.” While most of us know that there is a LOT more to it than this, that’s a decent elevator pitch to those who truly have a minimal-to-no understanding of the function.

Why is there so much confusion about BA’s? Let’s take a closer look:

Can you have the BA title but do something else?

Yes, you can. While there are market standards, companies are free to title jobs in any way that fits their organization. At times, these titles may not match with the wider job market. Because of this, there are situations where people do get the title of Business Analyst but aren’t performing the typical “business analysis” activities. This can create a lot of confusion and headache at time of job searching for both candidate and employer.

Can you perform BA duties and not have the BA title?

Also, yes. In many cases, people are performing Business Analysis activities while having other job titles – and some have no idea that what they’re doing is considered business analysis. For example:

  • Have you ever investigated potential tools to use for a project or need?
  • Have you ever helped your team/a team define problems they have with a current process?
  • Have you yourself identified problems with a current process and defined a new one that would address issues/gaps?
  • Have you help identify individuals that may be impacted by an upcoming change?
  • Have you helped to facilitate a brainstorming session?
  • Have you done a current-to-future state analysis?
  • Have you made a process flow to articulate how something is done?

Guess what…each of these are business analysis activities. And frankly speaking, most of us in a professional setting has performed these activities before. And in most cases, regularly!

So even if you don’t have a title of Business Analyst, you probably still have the experience!

Circling back to the original question: Role or Capability?

The answer is both – it can be a role and a capability.

While I believe having the business analysis capability is far more critical than a title, sometimes if feels good to be able to call yourself a business analyst as well.

Set your project up for success and make sure you have someone performing business analysis activities (even if you must call them something different)!