Define Your Core Requirements and Define Them Early

By Adrienne Flatland, Managing Director, Tasman Global

By Adrienne Flatland, Managing Director, Tasman Global

Welcome to our first of a series of posts focusing on how to better handle the complexity of international implementations.  In this article, we look deeper at the first of those areas and how you can produce workflows and build that focuses on the core goals of your implementation.

Designing and driving an implementation towards success is always a challenge. International implementations are no exception.  However, we often see that methodologies and what constitutes success can differ dramatically between countries.  This makes defining the requirements, the expectations of the system, and the goals of the implementation much more critical.  Handling this process well can make your implementation straight-forward and a success.

Let us look at a few things you can do during the scope definition phase that will set you up for success.

Workflow Definition:

Today, your organization likely has workflows that your staff knows well and are comfortable following.  Often, there is temptation to simply replicate these workflows in your new system - resist the temptation to copy what’s been done before outright.

Take a moment to reflect and ask the following questions:

  • What is the desired outcome?

  • What are the necessary steps to achieve that outcome?

  • Are some steps redundant or unnecessary?

By establishing the core requirements of a workflow, you can design new workflows that are more efficient and manageable.

 

Information Documentation:

Core requirement documentation extends beyond workflows to individual pieces of information.   Often, there are multiple ways to handle pieces of information in the system. Some are very intensive for the user, but highly accurate.  Sometimes there is an option that is automated but may have limitations. Which will serve your users and patients better?

Some items to consider when determining why information needs to be available or how it should be stored:

  • What benefit are you trying to get from the system by including a particular piece of data in your processes?

  • What is the reporting need for this piece of data?

  • Who needs to be able to access this later?

  • Does a user need to document this information, or could the system calculate it for them?

  • Does this information need to be present for regulatory reasons?

  • If we decide to include this now, is it still going to be necessary in the future?

 

Engage End Users:

The project team often knows there are multiple ways to handle certain processes; however, it’s often hard for stakeholders to know what the project team could build.  Keep these individuals engaged in the conversation with the project team. Ensuring the users of the software are comfortable with redesigning what is required for them in the system is critical.  Making sure everyone feels comfortable concentrating on the core requirements will lead to a workflow that helps supplement the user’s documentation process, rather than one that requires more work.

Finally, make sure you start this process early.  The sooner you concentrate on the core requirements, the easier it will be in the future.  Start as soon as your team is certified. So much information is collected during the Discovery Phase and validated only a month or two later.  This validation ultimately is the template of the final product for go-live. Making sure you have all the information required, and only the information required, early can save you from having to re-do validation sessions and build. It will make the months of build and testing go much smoother, saving you time and money.

Need help clearly defining your scope?  Want to have experienced implementation advisors come alongside your teams to help them through this process?  We’re ready to help with skilled application managers who know what questions to ask and what common pitfalls to watch out for.  We’ll audit your scope decisions and workflows to make sure your scope is sufficiently defined up front, making you more likely to hit your build milestones and have satisfied end users.