Any system implementation is a large investment, no matter the size of the project. It is a financial investment, a time investment, and a people investment. But many companies come to the table not knowing exactly how they can do to be best prepared ahead a project kick-off.
As implementation consultants we work with businesses to ask questions to gather what the business needs to personalize the system, but much of the initial work can be prepared by business users. Before shopping for systems or beginning an implementation, user stories can be created as a sort of ‘wish list’ or placeholder for further and deeper dives into system configurations or customizations.
User stories capture the who, what, and why of a desired action in the system from a user’s perspective. This is the easiest thing a business can do to ensure that they have a successful implementation is to hyper focus on what each user needs to be able to do in the system. It captures how the user interacts with the system so they can execute the daily tasks to satisfy their job requirements.
User stories are placeholders in the Product Backlog that will help the implementation team cooperatively work with the business users to prioritize needs and wants so the value is being driven by business priority. Some user stories won’t be implemented in the system and will remain outside of the system, but its best to identify these so processes can be refined at go-live.
The benefits of user stories are numerous. User stories can:
- ensure that all system users’ interactions with the system are considered;
- make users feel heard;
- increase user adoption;
- simplify user acceptance testing;
- reduce system remediation;
- reduce failed implementations; and
- captures real world scenarios.
How To Write User Stories
User stories can take some time to get the hang of, but a little practice using some basic guidelines can help greatly.
Step 1: Identify the users of the system. These are called “personas” and refer to roles such as accounting assistant, sales user, credit specialist, etc.
Step 2: Identify the Who, What, and Why to start writing the user story
User Story Structure
| As a | WHO | |
| I want | WHAT | |
| So that | WHY |
Here are a few examples:
- As a sale user, I want to create a new Contact for an existing Account at any time to be synced nightly with the ERP system.
- As a service rep user, I want to search for active policies within the Agent’s book of business to answer policy holder questions over the phone.
- As an accounting user, I want to navigate to the accounting system from within the ERP system to save me time toggling between separate systems.
Creating user stories ahead of a system implementation is an effort that can save you a lot of time and money during any software implementation. Even if the use cases are not formal, it helps create a more detailed picture of what the business needs. This allows implementation consultants to convert business needs into quality design solutions. Yes, it takes some additional time upfront, but it will more than pay for itself on the backend through reduced errors, fewer edits, and faster solution results.
