Building a custom application in ServiceNow is an exciting opportunity to solve real business problems that deliver quantifiable outcomes. However, an often overlooked yet proven fact is that the foundation you lay at the start will determine the overall success of your solution. Too often, teams rush into development without first defining high-level capabilities, the data and security, who will use the solution, and how the automation process(es) should flow. The result? Solutions that don’t solve the intended pain points, can’t be maintained or updated, or aren’t adopted by the users they were created for. Projects that run over budget, miss deadlines, and cost implementor teams thousands to millions of dollars in unplanned costs, spent to protect their brand and reputation.
In this article, I will explain why investing time upfront to create key requirement artifacts isn’t just a best practice but is essential for delivering intended value on time and within budget. I will also provide samples of these artifacts, along with the reasoning behind each, as well as tips and tricks to gather this information from stakeholders.
Here are the key artifacts:
- A project charter that describes, at a high level, the capabilities the solution needs to include, along with the business problems that warrant the need for the solution.
- A data dictionary that is a discrete list of all data inputs and outputs that need to be a part of the solution.
- User persona groups of who will use the system.
- Security rules for each persona for the solution data
- Swim-laned, high-level business process flow with solution and non-solution activities.
Over the past 13 years, implementing ServiceNow solutions in over 40 separate projects, I have found this approach to be tried and true. Pay a little up front (in time) and save yourself (and your client) extravagant amounts of money, time, avoidable risk, and frustration.
Still not convinced?
Research conducted by McKinsey and the University of Oxford on more than 5,400 IT projects found that large-scale IT projects—those with budgets over $15 million—run 45% over budget and 7% over time while delivering 56% less value than predicted (https://www.mckinsey.com/~/media/McKinsey/Business%20Functions/McKinsey%20Digital/Our%20Insights/Del...).
Even more concerning, research by Info-Tech Research Group revealed that 70% of digital transformation project failures are directly attributed to issues with requirements gathering (https://www.infotech.com/research/flawed-requirements-trigger-70-of-project-failures).
These are not isolated incidents—this is a systemic failure across the industry that costs organizations billions annually. The intelligence is clear: inadequate requirements gathering is the primary threat vector to project success, and the mission-critical countermeasure is investing time upfront to define the operational parameters before a single line of code is written.
Project Charter
A project charter is a formal document that authorizes the project and defines its high-level scope, objectives, and business justification. This artifact provides executive leadership with the critical intelligence needed to approve resource allocation and project initiation. According to industry standards, the charter should include the project purpose, business case, success criteria, key stakeholders, constraints, assumptions, and the project manager's authority (https://itpmschool.com/project-charter-example/).
The charter is essential because it establishes the mission parameters before development begins. It prevents scope creep by documenting what is in scope and—equally important—what is explicitly out of scope. For ServiceNow implementations, a charter might specify that the project will build a custom Personnel Security Request application to automate clearance workflows, reduce processing time by 40%, and integrate with existing Contract management tables, while excluding post-deployment training and legacy data migration. This clarity prevents mid-project disputes about deliverables.
To gather charter intelligence from stakeholders, conduct targeted interviews with the executive sponsor and business owners. Ask mission-critical questions: What business problem are we solving? What quantifiable outcome defines success? What budget and timeline constraints exist? What are the risks if we do nothing?
Use a structured template from sources like SDLCforms (http://sdlcforms.com/PopupForm-ProjectCharter.html) to ensure you capture all required elements. Schedule working sessions, come prepared with draft content based on preliminary discussions, and gain formal sign-off from the sponsor before proceeding to detailed requirements gathering.
Data Dictionary
The data dictionary is a comprehensive inventory of every data field required in your ServiceNow application. This artifact documents the table structure, field labels, field types (string, reference, choice, date/time), mandatory fields, choice values, reference tables, field validations, auto-population logic, and any dynamic UI behavior. It serves as the technical blueprint that developers will use to configure tables and fields in ServiceNow.
This artifact is critical for three reasons. First, it eliminates ambiguity—developers know exactly what to build. Second, it exposes data relationship dependencies early, preventing solution core structure rework (which can be very extensive) when teams discover mid-development that two features require conflicting data structures. Third, it enables accurate effort estimation; a data dictionary with 75 fields across 4 tables requires substantially different resources than one with 15 fields on a single table. Without this artifact, development teams make assumptions that lead to misaligned implementations and costly refactoring.
To extract data dictionary requirements from stakeholders, begin with the forms and documents users currently complete manually. Ask for reports that are currently used. Photograph or collect samples of existing paper forms, spreadsheets, reports, or legacy system screens. If a data import is in scope for your project, ask for the data up front. Add report and import data to the data dictionary.
Walk through each field with subject matter experts, asking: What information goes here? Is this field required or optional? What are the valid values? Does this field need to reference data from another table? Can this field be auto-populated? Use the template provided in this article's accompanying Excel file, which includes columns for all necessary field attributes. Conduct multiple focused sessions—one per major data table—rather than attempting to document everything in a single marathon meeting. This incremental approach maintains stakeholder engagement and allows time for validation between sessions.
User Personas
User personas define the distinct roles that will interact with your ServiceNow application, grouped by their job function and required access level. Each persona includes a name, description and business groups that will be assigned to that persona. For example, a "Request Admin" persona might include members of the Personnel Security Office who require full edit access throughout the workflow, while a "Contracting Officer Representative (COR)" persona includes contract managers who can only edit requests tied to contracts where they are designated as the COR.
This artifact prevents security gaps and access control failures. Without defined personas, development teams build applications with ad-hoc security rules that either grant excessive privileges (creating audit vulnerabilities) or restrict access too tightly (blocking legitimate users from performing their duties). Personas also improve communication—when discussing requirements, referring to "the FSO persona" immediately orients all stakeholders to which users and access levels are being discussed. Additionally, personas drive the security matrix and testing scenarios, ensuring that access controls are systematically validated before deployment.
Gathering persona intelligence requires identifying all the actors who will touch the application at any point in its lifecycle. Start by mapping the current business process and identifying every person who reviews, approves, edits, or views information. Interview representatives from each department involved in the process. Ask: What is your role in this process? What actions do you need to perform? What information must you view? Do you need read-only access or edit rights? Are there any conditional access requirements based on data values? Document each persona with its access requirements in the template provided. Validate the persona list with your executive sponsor and department heads to ensure no critical users are overlooked—a missing persona discovered during User Acceptance Testing triggers expensive emergency security configuration changes.
Security Matrix
The security matrix is a structured table that maps CRUD (Create, Read, Update, Delete) operations across all data tables to each user persona. This artifact shows precisely which personas can create records, which can read specific tables, which can modify data, and which can delete entries. For instance, the matrix might show that Platform Admins have full CRUD access to all tables, Request Admins can create and edit Request records but cannot delete them, CORs can only read Request records where they are the assigned COR, and FSOs have read-only access to all Contract data.
The security matrix is mission-critical for compliance, audit readiness, and operational security. It forces stakeholders to make explicit decisions about data access before development, preventing the "we'll figure out security later" approach that leads to either overprivileged users or broken workflows. The matrix also serves as living documentation for security audits, clearly demonstrating that access controls were designed with least-privilege principles. For development teams, it translates directly into ServiceNow Access Control List (ACL) configurations, eliminating guesswork and reducing post-deployment security patches.
To build an effective security matrix, start with your validated user personas and data dictionary. For each table in your data dictionary, systematically determine which personas require which operations. Conduct a working session with security officers, business owners, and compliance representatives—their combined expertise identifies both operational requirements and regulatory constraints. Ask targeted questions for each persona-table combination: Does this persona need to create these records? Should they see all records or only specific ones based on criteria? Can they modify existing records or only view them? What conditions would require delete access? Use the provided Excel template's Security Matrix tab, which lists security operations (Read, Write, Create, Delete) down the left and personas across the top. Flag any security requirements that depend on field values—these conditional rules require special ACL scripting in ServiceNow. Review the completed matrix with your Information Security team to validate that it meets organizational security policies before development begins.
Swim-Laned Business Process Flow
A swim-laned business process flow is a visual diagram that maps the end-to-end workflow across different actors, departments, or systems, with each "lane" representing a distinct participant (https://venngage.com/blog/swimlane-process-map/). For ServiceNow implementations, this diagram shows how requests move through stages, which personas perform actions at each step, where approvals occur, what triggers notifications, and how the application interacts with non-ServiceNow activities. For example, a Personnel Security Request workflow might show lanes for the Requester, COR, Security Office, Background Investigation vendor (external system), and FSO, with tasks flowing between lanes as the request progresses from submission through reciprocity check, fitness evaluation, adjudication, and completion.
This artifact delivers maximum value for identifying gaps, redundancies, and automation opportunities. It exposes bottlenecks where work stalls between handoffs, reveals duplicate approval steps that extend cycle time, and clarifies which activities belong in the ServiceNow application versus which remain external. The visual format enables non-technical stakeholders to validate the process flow, catching logic errors that would be expensive to fix post-development. For development teams, the swim-lane diagram drives workflow configuration, notification rules, and integration requirements (https://www.lucidchart.com/pages/tutorial/swimlane-diagram).
To build an accurate swim-lane diagram, start by documenting the current-state process with the people who execute it daily. Schedule a 90-minute workshop with representatives from each department involved. Use a whiteboard or digital collaboration tool, and walk through a real example from start to finish, asking: What happens first? Who does that? What happens next? What triggers the transition? What are the decision points? Capture every step—even manual ones like phone calls or email notifications—because these reveal where ServiceNow automation delivers value.
Use standard flowchart symbols: rectangles for tasks, diamonds for decision points, arrows for flow direction, and clearly labeled lanes for each actor (https://venngage.com/blog/swimlane-process-map/). Tools like Lucidchart, Microsoft Visio, or even PowerPoint support swim-lane creation. Once you document the current state, review it with stakeholders for accuracy, then create a future-state diagram showing the optimized workflow with ServiceNow automation. The gap between current and future state quantifies the project's value proposition—if automation reduces process steps from 47 to 12 and cuts cycle time from 90 days to 30, that becomes a compelling business case metric. Validate the future-state flow with all stakeholders before development to ensure the automated process meets operational requirements (https://www.atlassian.com/work-management/project-management/project-planning/swimlane-diagram).
In short, starting with well-defined artifacts isn’t just a checkbox—it’s your best defense against budget overruns, missed deadlines, and unhappy users. By investing in these steps up front, you set your ServiceNow project up for success and deliver real value to your organization.
Pay a little now (in time and effort), or pay A LOT later!
