Tell me a story, Requirements gathering Part 2

[britta]

In part one, I talked a lot about the soft skills and processes you need to be successful with requirements gathering and some of the common pitfalls. In this installment, I'm going to outline the hands-on tactics for getting requirements together.

The first thing any organization ought to do after they sign a contract with ServiceNow (or better, yet as soon as they know they are changing platforms) is to gather whatever written documentation that they currently have on the processes they are migrating and integrations that support them. If the current process is not documented, that needs to be done immediately, and as I noted in the part one, even if you are changing the process, you must first understand present state. 

Because right after having a kickoff, your implementation partner will be planning to have business process workshops with the team.  As I mentioned in part one, it is important to have the right people in the room for these discussions and to make sure their roles are clearly defined.  Without clear authority of who owns what, you will be endlessly spinning your wheels trying to define requirements.

During the process workshops, you will need to review current state, and document future state.  This is where a debate usually erupts with one side saying, "Let's just review what is out of the box and fill in the gaps", and the other side saying the design should be created agnostic of the platform.  What I recommend is an informational demo of whatever products you are implementing, BEFORE you start the current state review, so folks can see the platform.  Many people are visual learners and need this context.  However, it must not devolve into solutioning the outcome.  This will derail the workshop because then discussions will start on what would need a customization, we don't do it that way, etc...  And you will never get through the process review. 

Once you have confirmed and documented current state, you can start writing requirements.  This is another area where teams often go awry because someone wants to know if the platform can do that, or another person will insist the requirements need to be put in order of how they will be developed.  While both are legitimate concerns, those conversations happen later when your requirements are completed, and the developers will be able to determine how to order the requirements and what is possible. (I mean, anything is possible in ServiceNow, but that doesn't mean you should do it!)

How does one write requirements is yet another area where there is often dissent.  We recommend using an agile approach and writing stories that can be organized into sprints.  Some will want to include the technical details in the story, but that is for the developers to decide and document later.  Until all requirements are collected, it does not make sense to document how to do development because there WILL be changes along the way.  And if you get into solutioning every story as you go, requirements gathering will go long past its allotted time.

The most important thing to document is: "As this persona, I need to perform this action to get this outcome/benefit."  By stating the outcome or benefit, it allows you to prioritize the work, AND potentially to remove stories because you realize the requirement really doesn't have any value.

What requires a story?  I think back to taking my first computer science class where the professor asked us to write down how to make a peanut butter and jelly sandwich.  Many people started with spreading peanut butter on the bread.  But, where is the peanut butter? In the kitchen.  What cabinet?  and so on.  When writing stories, you must assume the developer is like a computer who would need to know every single step.  Assumptions lead to gaps in code.

You also need to not make sure you aren't making assumptions when writing the acceptance criteria for your testers.  This is an area where I've seen many a customer who wants to skip or do it later or not take seriously.   However, skipping minor details in UAT can lead to defects that go into production.  And no one wants to be the next CrowdStrike. 

In addition, you will need to document other things such as: assignment rules, roles, groups.  Then determine your golden source/s for user data, departments, locations, and how that data will be integrated into ServiceNow and how will it be kept up to date.  A thorough review of your data is recommended because most organizations need to do some level of data cleansing prior to setting up the platform foundations.  If that is the case, get on that immediately, if not sooner; otherwise, data could significantly delay your timeline later.  In my experience, it is always better to recognize any risks or delays at the start your project rather than hope they go away.  If the risk doesn't materialize, awesome.  If it does, then everyone was prepared, and you are not caught without a contingency plan. 

For templates to assist with data and requirements gathering see these articles on the community: 

Requirements Gathering Guide (ITSM)

Project Readiness Checklist

As always, please comment with your experiences, ideas, etc...!