PMI's research puts a number on this problem: nearly half, 47%, of unsuccessful projects fail to meet goals because of inaccurate requirements management. Errors caught early cost far less to fix than errors discovered after go-live, a pattern NASA's own engineering teams have documented for decades.
This post is a practical checklist. Six common mistakes, why they happen in identity governance and access management projects specifically, and exactly how to fix each one.
Key Takeaways
- Incomplete stakeholder input and vague documentation cause most requirements failures
- Interview-and-spreadsheet methods are slow, inconsistent, and hard to trace
- AI-guided questionnaires compress discovery timelines while improving accuracy
- Every requirement needs a verification method, an owner, and a measurable threshold
- Governance and compliance context must be built into discovery, not added later
Mistake #1: Failing to Identify All Stakeholders Early
Skip a stakeholder category during discovery, and that gap surfaces late, usually during UAT or worse, during an audit. For identity projects, teams routinely forget application owners, data owners, and auditors who define the governance context nobody else thinks to ask about.
PMI's research on this is blunt: one in three unsuccessful projects fail to meet goals because of poorly engaged executive sponsors. That figure is sponsor-specific, but the pattern holds across roles: projects stall when the right people never make it into the room.
Who Gets Missed Most Often
- Application owners — validate access levels and business justifications
- Data owners — review sensitive-data access and classification rules
- Managers — confirm access actually matches job function
- Compliance officers — check policy and segregation-of-duties requirements
- Security teams — review privileged or high-risk access
- Auditors — define what evidence a control needs to produce
The fix: map every internal, external, and "hidden" stakeholder before drafting a single requirement. That includes offshore delivery teams, risk officers, and certification reviewers who rarely get invited to kickoff calls.
Reusable, practitioner-built questionnaires make that mapping repeatable. Identity CoAnalyst's library covers 500+ questions across 11 identity domains, structured so stakeholder categories are hard to skip by accident.
Mistake #2: Relying on Unstructured Interviews and Spreadsheets
Ad hoc interviews feel efficient in the moment. Then someone tries to reconcile six different spreadsheets from six different interviewers, and inconsistencies pile up fast. The coordination burden alone is brutal. Scheduling stakeholder time on a traditional identity discovery project can eat 1-2 weeks before a single question gets answered, on top of a process that commonly runs 6-12 weeks overall. Inconsistent notes compound the damage. Institutional knowledge disappears the moment an interviewer leaves the project.
Why This Fails
- No standardized template means every interviewer captures different details
- Follow-up emails replace real-time clarification, slowing everything down
- Spreadsheet rows disconnect from the original stakeholder rationale
- Static forms force stakeholders through irrelevant questions Conversational AI platforms close this gap. Identity CoAnalyst replaces static interviews with guided, plain-language questionnaires stakeholders complete on their own schedule — no calendar coordination required. The AI explains why a question matters, skips irrelevant branches based on answers, and avoids forcing anyone through a 150-row spreadsheet of boilerplate fields. The checklist fix: standardize data capture with one consistent template or platform, so every interview produces comparable, traceable output instead of six incompatible documents.
Mistake #3: Writing Ambiguous or Unverifiable Requirements
"Access should be easy to manage" isn't a requirement. It's a wish. Different teams will interpret it differently, and that mismatch usually surfaces during integration testing, when it's expensive to fix.
NIST's own role-engineering research illustrates the scale of this problem: a large European bank with more than 50,000 employees discovered approximately 1,300 roles once they actually decomposed job functions into their component access needs. Vague role definitions at that scale don't just cause confusion; they cause audit findings.
What a Testable Requirement Looks Like
Every access requirement needs:
- A verification method: how is access provisioned, and how is success confirmed?
- A named owner: who approves the access, and who handles escalation?
- A measurable threshold: what specific condition makes this requirement true or false?
A testable rewrite of the wish above might read: "Finance-system access requests are approved by the cost-center owner within 24 hours and provisioned through the IGA workflow with a logged confirmation."
A requirement nobody can test is really just a preference.
Identity CoAnalyst's discovery process treats a requirement as incomplete until it has a documented provisioning method, an approval chain, and measurable acceptance criteria. If a stakeholder gives a vague answer, the AI probes with a follow-up rather than accepting it at face value.
Mistake #4: Skipping Documentation of Assumptions and Edge Cases
Unrecorded assumptions about scope, timing, or system behavior have a nasty habit of resurfacing months later as scope creep. Someone assumed contractors wouldn't need self-service password reset. Nobody wrote that down. Now it's week nine and the scope conversation is happening again.
The checklist fix: document every assumption and every out-of-scope decision right alongside your in-scope requirements. Don't let them live in someone's meeting notes or a forgotten email thread.
- Record what's explicitly excluded, not just what's included
- Note edge cases discussed but deferred, with the reason why
- Capture dependencies that could shift scope if they change
- Tie each assumption to the person who made it and when
Mistake #5: Neglecting Governance, Compliance, and Contextual Access Requirements
Regulated industries — healthcare, financial services, federal government — need more than functional access requests. They need segregation-of-duties rules, audit trail specifications, and governance context captured from day one.
HIPAA's Security Rule requires mechanisms that record and examine ePHI-system activity, and the FTC's Safeguards Rule calls for periodic review of access controls and monitoring for unauthorized activity. Treating these as afterthoughts guarantees rework once the audit team gets involved.
Those controls only hold up when discovery also records who can access what, under which conditions, and how that access is reviewed.
Domain-Specific Coverage Matters
| Regulated context | Discovery must capture |
|---|---|
| Healthcare (HIPAA) | Authorized ePHI access, activity logs, review cadence |
| Financial services | SoD, access review evidence, privileged-access controls |
| Federal government | Control mapping, event logging, evidence workflow |
The checklist fix: build compliance questions into discovery from the start, not after design begins.
- Ask for SoD rules, audit-trail needs, and access-review cadence in the first discovery pass
- Cover Access Certifications and PAM alongside core IAM/IGA scope
- Use a vendor-agnostic library so gaps show up before build—Identity CoAnalyst includes about 50 certification questions and 56 PAM questions on SoD policy and audit controls
Mistake #6: No Process for Tracking Changes or Sign-Off
Requirements without version control or formal approval create chaos the moment priorities shift. A sponsor signed off on an early draft, priorities changed, and now the analyst, architect, and delivery lead are working from three different versions of "the truth."
The checklist fix: maintain a single source of truth with timestamps, named approvals, and audit-ready documentation. Scattered documents and email chains aren't a substitute for a controlled record—and they fall apart the first time a sign-off is disputed.
- Track who answered each requirement, when they responded, and on what basis
- Require written justification when a stakeholder disagrees with a prior answer
- Preserve full conversation history for audit purposes
- Flag contradictions across stakeholders before finalizing anything
The Requirements Gathering Mistakes Checklist (Quick Reference)
Run through this before you call discovery "done":
- Have you mapped every stakeholder category, including hidden ones like offshore teams and auditors?
- Is your capture method standardized across every interviewer and session?
- Does every requirement have a verification method, an owner, and a measurable threshold?
- Are assumptions and out-of-scope items documented alongside requirements?
- Is compliance and governance context built into discovery, not added afterward?
- Is there a single source of truth with timestamps and traceable approvals?
Consulting firms and enterprises evaluating identity platforms do not have to work these boxes by hand across 8–16 weeks. AI-powered discovery tools can compress that timeline to under 10 days and produce audit-ready documentation from day one. At blended consultant rates that often exceed $175 an hour, that compression pays for itself quickly.
Frequently Asked Questions
What are the key steps in requirements gathering?
The core steps are stakeholder identification, elicitation, documentation, verification, validation, and formal sign-off. Skipping any one of these, especially validation against business objectives, tends to surface as rework later.
How do you perform requirements gathering?
Choose your elicitation technique (interviews, workshops, or guided questionnaires), document responses in a standardized format, then validate findings with stakeholders before finalizing anything. The technique matters less than the consistency of the process.
What are some examples of requirements gathering processes?
Traditional processes rely on scheduled interviews and workshops followed by manual spreadsheet consolidation. Modern approaches, particularly in specialized domains like identity management, use AI-guided conversational questionnaires that stakeholders complete asynchronously.
What is the most common mistake in requirements gathering?
Incomplete stakeholder involvement and ambiguous requirement language are the two most frequent root causes of downstream rework. Both are preventable with a structured, checklist-driven discovery process.
How can AI improve requirements gathering accuracy?
AI-guided questionnaires standardize input across stakeholders and translate plain business language into testable technical requirements. This reduces missed and contradictory requirements common in manual interview processes.
