Overview
Poor requirements gathering is the silent killer of IAM projects. Clients often express requirements as solutions ("We need a SailPoint group") rather than business needs ("We need to ensure only certified accountants can approve wire transfers"). The consultant's job is to peel back the onion, translating vague desires into precise, technical logic that can be coded. This requires a shift from "Order Taker" to "Investigator." You must ask "Why?" five times, challenge assumptions, and document the logic of access, not just the list of current permissions.
Methodology & Frameworks
User Stories & Acceptance Criteria
Move away from 500-page "System Requirements Documents" (SRDs) towards agile user stories.
- Format: "As a [Role], I want to [Action], so that [Benefit]."
- Example: "As a Hiring Manager, I want my new hires to have email access on Day 1, so they can be productive immediately."
- Acceptance Criteria: "Account created in AD, mailbox provisioned in Exchange, credentials sent to manager via SMS 24h prior to start date."
The "Current State" vs. "Future State" Gap
Always map both.
- Current State: How do they do it now? (e.g., "Bob emails Alice, Alice scripts it"). Do not automate the mess.
- Future State: How should it work? (e.g., "HR triggers event, IAM system automates it").
- Gap Analysis: What data/process is missing to get from A to B? (e.g., "HR doesn't currently record 'Department' correctly").
RBAC / ABAC Workshops
Don't ask "What roles do you want?" Ask "What does a person in this job function do?"
- Group permissions by Job Function (Business Roles) and System Access (IT Roles).
- Use Excel or specialized role mining tools to visualize the data.
Key Decisions
| Decision | Options | Recommendation | Notes / Gotchas |
|---|---|---|---|
| Granularity of Requirements | High-level vs. Attribute-level | Attribute-level for automation. | "All employees" is useless. You need "All active employees with EmployeeType='Regular' and Country='US'". |
| Source of Truth | HR, AD, CSVs? | HR System (HCM). | If HR data is bad, fixing it is a requirement, not an optional scope item. |
| Scope of "Day 1" | All apps vs. Birthright only | Birthright Only (Email, Portal, Slack). | Don't try to automate niche apps in Phase 1. Focus on the 80% that everyone gets. |
| Handling Exceptions | Build logic vs. Manual Request | Manual Request for edge cases. | attempting to automate 100% of exceptions leads to "Spaghetti Logic" that is unmaintainable. |
Implementation Approach
Phase 1: Context & Discovery
Activity: Review existing documentation (if any). Interview the "Old Guard" admins who know where the bodies are buried. Output: Context Diagram, list of in-scope systems.
Phase 2: Workshops
Activity: Run functional workshops.
- Joiner/Mover/Leaver (JML): Walk through the lifecycle. "What happens when someone goes on leave?"
- Access Request: "Who approves this?" "Is there a backup approver?"
- Attestation: "How often do you review this? Who actually looks at it?" Output: Process flow diagrams (Visio/Lucidchart).
Phase 3: Data Analysis
Activity: Request data dumps from HR and Target Systems. Correlate them. Output: Data Dictionary and Data Quality Report. (See topic: Data Quality Analysis).
Phase 4: Sign-off
Activity: Play back the requirements to the stakeholders. "This is what I heard you say. Is this correct?" Output: Signed Requirements Traceability Matrix (RTM).
Deliverables
- Business Requirements Document (BRD): High-level "what".
- Functional Specification Document (FSD): Detailed "how" (logic, attributes, mappings).
- Use Case Catalog: List of specific scenarios (e.g., "Rehire within 30 days," "Contractor conversion").
- Process Flows: JML diagrams (Swimlanes are best).
Risks & Failure Modes
| Risk | Likelihood | Impact | Early Signals | Mitigation |
|---|---|---|---|---|
| The "Assumed Process" | High | High | Stakeholders describe the official policy, not what actually happens. | Ask for a live demo: "Show me how you did the last one." Comparison often reveals the truth. |
| Vague Definitions | High | Med | Terms like "Manager" or "Owner" are undefined. | Create a Glossary. define "Manager" technically (e.g., "User in the 'manager' attribute field in AD"). |
| Missing Negative Requirements | Med | High | Forgetting to define what shouldn't happen (e.g., "Terminated users shouldn't retain access"). | Explicitly ask about negative scenarios and "sad paths." |
| Scope Creep via Requirements | High | Med | "Oh, while you're at it, can you fix our payroll calculation?" | Strict adherence to the Project Charter. "That is a great idea for Phase 2." |
KPIs / Outcomes
- Requirement Clarity: % of requirements with defined acceptance criteria.
- Traceability: 100% of configured policies map back to a documented business requirement.
- Sign-off Speed: Time taken to get BRD/FSD approved.
- Change Orders: Low number of CRs during build phase due to missed requirements.
Consultant's Notebook (Soft Skills)
The "Five Whys" Technique
Client: "We need an approval workflow for the 'All Staff' email group." Consultant: "Why?" Client: "So people don't spam everyone." Consultant: "Why do they have access to send to it in the first place?" Client: "Everyone is in the group." Consultant: "Why don't we just restrict send permissions to HR and Execs, and remove the approval workflow entirely?" Client: "Oh. We can do that?" (Result: Zero development work, better outcome).
Silence is Golden
After asking a hard question ("Who owns this messy data?"), shut up. Wait. Let the silence become uncomfortable. The person who breaks the silence usually owns the problem or knows the answer.
"Walk a Mile"
Don't just talk to managers. Sit with a Helpdesk agent for an hour. Watch them provision a user. You will learn more in that hour than in a week of workshops.