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:

• Too complex for their team to use effectively
• Built with assumptions that didn’t match their workflow
• Unable to handle their specific volume or configuration needs
• Technically present but practically unusable

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:

• “We need to reduce time-to-offer for our technical roles from 45 days to 30 days.”
• “Our hiring managers need mobile access to candidate information between meetings.”
• “We must ensure a consistent evaluation process across all our global locations.”
• “Candidates need more transparency about where they stand in our process.”

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:

• Help me understand if this role is right for me
• Make it easy to showcase my relevant experience
• Keep me informed about my status
• Respect my time throughout the process

For recruiters:

• Help me focus on the most promising candidates
• Reduce administrative burden so I can build relationships
• Provide insights that improve my sourcing strategy
• Make it easy to communicate with hiring teams

For hiring managers:

• Give me visibility into the candidate pipeline
• Make it simple to provide timely feedback
• Help me compare candidates consistently
• Streamline scheduling and coordination

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:

• Contextual Interviews: Watching recruiters and hiring managers work in their natural environment
• Focus Groups: Bringing together users with similar roles to discuss challenges and needs
• Journey Mapping: Collaboratively mapping the ideal candidate and recruiter experience
• Prototype Testing: Creating simple mockups to validate concepts before configuration
• Prioritization Exercises: Having users rank requirements by impact and frequency

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:

• Must-Have: Without this, the system cannot go live
• High-Value: This will significantly improve performance or experience
• Nice-to-Have: This would be beneficial but isn’t critical for launch
• Future Phase: This is important but can be implemented later

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:

• Exactly what data must be collected and when
• How long different types of data need to be retained
• Who should have access to sensitive information
• What reporting will be needed for audits and verification
• How the system will prevent or flag potential compliance issues

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:

• What data needs to flow between systems and in which direction
• How frequently data needs to be synchronized
• Which system is the “source of truth” for different data elements
• What happens when data conflicts arise
• Who will be responsible for monitoring integration health

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:

• How might your hiring volume change in the next 2–3 years?
• Are you planning to expand into new geographies or business lines?
• Will you need to support additional languages or compliance regimes?
• How might your employer brand and candidate experience evolve?
• What emerging recruitment technologies might you want to incorporate?

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

Preparing for Requirements Success

Before your first implementation meeting:

• Create a prioritized list that distinguishes between must-have and nice-to-have functionality
• Document specific compliance requirements for your industry
• Consult with your legal team to ensure your new process will meet regulatory standards
• Consider future needs and scalability
• Gather input from a representative sample of actual system users
• Translate feature requests into outcome statements that describe the problem to be solved
• Identify which requirements represent significant changes from current processes
• Document your integration ecosystem and data flow requirements

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.