Menu

Beyond Features: Defining Requirements

What features do you need in your new ICIMS ATS?

It seems like a straightforward question, but it’s actually the wrong place to start. In my years of guiding HR teams through implementations, I’ve learned that successful projects begin not with feature lists, but with human-centered outcomes.

According to research by Aptitude Research Partners (2022)*, 55% of organizations report that their ATS implementation failed to meet expectations due to misalignment between purchased features and actual workflow needs. Why? Because they focus on software features rather than solving real human problems.

The Requirements Paradox

Last year, I worked with a healthcare system implementing a new ICIMS ATS. Their initial requirements document was 15 pages long: an exhaustive list of features and technical specifications. Yet something was missing.

When I asked their recruiters about their biggest pain points, they described spending hours manually tracking candidates through their complex credentialing process. This critical workflow wasn’t even mentioned in the requirements document.

This disconnect happens constantly. The people creating requirements documents are often not the same people doing the daily work of recruitment.

The Mythology of Features

Features have become the currency of software selection, but they’re a deeply flawed metric. A feature checklist tells you almost nothing about how a system will perform in your environment or whether it will solve your specific challenges.

I’ve seen organizations choose systems based on impressive feature demos, only to discover those features were:

The result is shelf-ware: expensive functionality that sits unused while teams revert to manual workarounds.

The Outcome-Driven Alternative

Instead of starting with a feature wish list, successful implementations begin with clear outcome statements:

These outcome statements focus on what success looks like rather than how to achieve it. They become the North Star for your implementation, guiding decisions about configuration, integration, and customization.

The Job-To-Be-Done Framework

One powerful approach to requirements gathering is the “Jobs-To-Be-Done” framework. Instead of listing features, identify the jobs your ICIMS ATS needs to perform:

For candidates:

For recruiters:

For hiring managers:

This approach focuses on user needs rather than system capabilities, leading to implementations that actually work for the people using them.

The Voice of Your Users

Requirements that reflect real user needs come from, surprise, actually talking to users. Yet many organizations skip this step, assuming executives and HR leadership already know what’s needed.

Effective requirements gathering includes:

One technique I’ve found particularly effective is the “Day in the Life” exercise. We ask recruiters and hiring managers to document everything they do in a typical day, noting each system interaction, manual process, and communication touchpoint. These journals reveal patterns and priorities that might never emerge in a conference room discussion.

The 80/20 Rule: Your Implementation Lifesaver

One of the most valuable frameworks I share with clients is the 80/20 rule for implementation. Don’t let perfect be the enemy of good. Focus first on the 20% of functionality that will solve 80% of your needs.

I often tell clients: “We can build anything, but we can’t build everything at once.” Phased implementations with clear priorities consistently outperform attempts to solve every edge case in the first release.

This approach requires disciplined prioritization. We use a simple framework:

Forcing requirements into these categories leads to healthy debates about what truly matters and creates a roadmap that extends beyond your initial implementation.

The Compliance Dimension

For many organizations, particularly those in regulated industries, compliance requirements form a non-negotiable foundation for their ICIMS configuration.

Yet compliance needs are often stated in vague terms like “must be compliant with EEOC regulations” rather than translated into specific system requirements.

Effective compliance requirements should specify:

This translation from regulatory language to system requirements requires collaboration between HR, legal, and your implementation team. Don’t assume vendors automatically understand your specific compliance needs.

The Integration Imperative

Your ICIMS ATS doesn’t exist in isolation. It needs to communicate with other systems in your HR and business ecosystem. Integration requirements deserve special attention during the requirements phase.

For each potential integration, document:

Many organizations underestimate the complexity of integrations. A simple statement like “must integrate with our HRIS” masks dozens of decisions and potential complications.

Future-Proofing Your Requirements

Your organization isn’t static, and neither are your recruitment needs. Requirements should consider not just current needs but likely future scenarios:

Building flexibility into your initial configuration can prevent painful rework later.

Preparing for Requirements Success

Before your first implementation meeting:

Remember, the goal isn’t to create the longest possible list of requirements. It’s to identify what truly matters for your organization’s recruitment success and to communicate those priorities clearly to your implementation team.

In my next article, I’ll address one of the most underestimated aspects of implementation: data preparation and the critical decisions you need to make about your candidate information. I’ll explain why data migration is about more than just technical transfer and how to make strategic decisions that set your new system up for success.

What’s been your experience with requirements gathering? Have you found yourself implementing features that ultimately weren’t used? Have you discovered critical needs only after go-live? I’d love to hear your stories in the comments.

* Aptitude Research Partners. (2022). Applicant Tracking System Implementation Success Factors.