The goal of gathering requirements for ServiceNow project, or any other software development project, is to review:
- What is done as of now, also known as “the as is”,
- The vision of where the system needs to be, also referred to as “the to be”.
The requirements constitute the area in between these 2, and specifies existing issues and/or areas for improvement. In the case of new projects and innovations, “the as is” will be a blank canvas.
The system should support people, processes and the very business. And your requirements should reflect these. Examples in the IT, can be Incident or Request Fulfillment; in HR, we can look to new hires, leaves etc.
How to define ServiceNow project requirements
1 of the issues is that requirements can sometimes be elusive. A stakeholder may want something, but isn’t able to define what it actually is or how it looks like. To succeed in their definition:
- Expressions must be clear, eliminating ambiguity,
- Statements must be precise, not too general,
- Project vision must be common for all stakeholders.
That’s the foundation.
What do good requirements look like
- Precise – not open to interpretation,
- Complete – all the connected information is present. Answers to the questions ‘what next’ or ‘what if’ are vital to understand the full scope,
- Atomic – aim for 1 actor, 1 task, 1 time per a requirement. The indicators that a particular requirement might require a split into next one(s) are 2 words “and” and “or”. It’s not always the case, but it’s always worth some investigation,
- Traceable – each requirement has its author and justification why it’s needed.
Requirement collection process
An analyst can use various techniques and approaches to collect requirements:
- 1 to 1 interviews,
- Workshops,
- Observation,
- Prototyping,
- Questionnaires.
Once the stakeholders have provided their input, it requires analysis and further validation to confirm it’s fully understood. At each stage, full understanding is the key to a successful project delivery. So ask questions until there is no doubt. These steps will help refine the deliverables for the project.
Why gather requirements
The collection of requirements is a cost, yet only provisionally. This cost allows you to optimize budget in the later stages of the ServiceNow project, turning into a saving tool. The analysis at the start of the project is most often less expensive than the replacement or repair of the issues arising if you don’t gather requirements beforehand.
Businesses often rush through this process. They don’t perceive it as a value added and almost never want to invest time and resources in the process before defining scope and setting up budget. The order should be different, starting from gathering requirements that allow to effectively manage both scope and budgets.
ServiceNow project retrospective
The aspects being subject to retrospective assessment of a ServiceNow (or any other) project are:
- The success / failure to deliver benefits and its triggers,
- How the system meet / didn’t meet the real business need,
- The number of bugs to fix.
The requirements collection and definition process should be built into the project delivery plan. Plan for it carefully to make the most of this provisional cost and to turn it into a project gain. It’s as important stage for the delivery as the setup of budget, timeline and resources.
If you need any assistance in your ServiceNow project delivery, don’t hesitate.
