The Three Primary Approaches

NetSuite implementations typically follow one of three methodologies, each with distinct advantages depending on organizational culture, project complexity, and risk tolerance.

Waterfall Approach

The traditional waterfall methodology moves through sequential phases: Discovery → Design → Build → Test → Deploy. Each phase completes before the next begins, with formal sign-offs at each gate.

When to Use Waterfall

• Regulatory requirements demand comprehensive documentation and audit trails
• Fixed budgets require predictable costs and timelines
• Stable requirements that are unlikely to change significantly
• Large organizations with formal change management processes
• Complex integrations with external systems that require coordinated releases

Waterfall Risks

• Requirements gathered months before go-live may no longer reflect business needs
• Users don't see the system until late in the project, leading to surprise issues
• Changes late in the project are expensive and disruptive
• Long timelines can result in stakeholder fatigue and turnover

Agile Approach

Agile implementations work in short sprints (typically 2-4 weeks), delivering working functionality incrementally. Users see and test the system continuously, providing feedback that shapes subsequent sprints.

When to Use Agile

• Evolving requirements in fast-changing business environments
• Engaged stakeholders who can commit time for regular feedback
• Technical teams comfortable with iterative development
• Startups and growth companies that prioritize speed to value

Agile Risks

• Scope can expand without discipline ("just one more sprint")
• Requires significant stakeholder time commitment
• Documentation may suffer if not explicitly prioritized
• Budget unpredictability if sprints keep adding

Hybrid Approach (Recommended)

Most successful NetSuite implementations use a hybrid approach: start with waterfall-style discovery and design, then apply agile principles during build and testing.

flowchart LR
    subgraph STRUCTURED["STRUCTURED PHASES"]
        D["Discovery"]
        DE["Design"]
    end

    subgraph AGILE["AGILE PHASES"]
        B["Build
Sprints"]
        T["Test
Iterative"]
    end

    subgraph CONTROLLED["CONTROLLED PHASE"]
        DP["Deploy"]
    end

    D --> DE --> B --> T --> DP

    style STRUCTURED fill:#dbeafe,stroke:#3b82f6,color:#1a1d23
    style AGILE fill:#dcfce7,stroke:#22c55e,color:#1a1d23
    style CONTROLLED fill:#fef3c7,stroke:#f59e0b,color:#1a1d23
    style D fill:#bfdbfe,stroke:#3b82f6,color:#1a1d23
    style DE fill:#bfdbfe,stroke:#3b82f6,color:#1a1d23
    style B fill:#bbf7d0,stroke:#22c55e,color:#1a1d23
    style T fill:#bbf7d0,stroke:#22c55e,color:#1a1d23
    style DP fill:#fde68a,stroke:#f59e0b,color:#1a1d23
                

This approach provides:

• Upfront clarity on scope, budget, and timeline from structured discovery
• Flexibility during build to adapt as users see the system
• Controlled deployment with formal cutover and go-live procedures

Project Governance

Regardless of methodology, establish governance structures before the project begins.

Essential Governance Elements

• Steering Committee: Executive sponsors who make strategic decisions and resolve escalations. Meet monthly or at phase gates.
• Project Team: Day-to-day decision makers including project manager, functional leads, and technical leads. Meet weekly.
• Change Control Board: Evaluates and approves scope changes. Can be the steering committee for smaller projects.
• Communication Plan: Who receives what information, how often, through which channels.

Timeline Expectations

Set realistic expectations based on organization size and complexity.

Stakeholder Categories

Every implementation involves multiple stakeholder groups with different needs, concerns, and levels of influence.

The Stakeholder Matrix

Map stakeholders by their level of influence and interest to determine engagement strategy.

Identifying the Project Champion

The most critical stakeholder is often not the most senior. The Project Champion is the internal advocate who will drive adoption from within.

Ideal Champion Characteristics

• Respected by peers — people listen when they speak
• Understands the business — deep knowledge of how things actually work (not just how they should work)
• Embraces change — sees the new system as an opportunity, not a threat
• Has time — can dedicate 50-100% of their capacity to the project
• Communicates well — can translate between technical and business language

Handling Resistance

Resistance is natural. Understanding its sources helps address it constructively.

Common Sources of Resistance

• Fear of job loss: "If the system automates my work, what will I do?"
  Address by: Emphasizing that automation handles grunt work, freeing them for higher-value activities.
• Loss of expertise: "I spent 10 years mastering this system. Now I'm a beginner again."
  Address by: Positioning them as the expert who helps design the new process.
• Bad past experiences: "We tried this three years ago and it was a disaster."
  Address by: Acknowledging the past, explaining what's different this time.
• Lack of involvement: "Nobody asked me what I need."
  Address by: Including them in requirements gathering and validation.
• Workload concerns: "I don't have time for this on top of my regular job."
  Address by: Getting executive support for backfilling or reducing other responsibilities.

Building the Project Team

The core project team should include representatives from each functional area affected by the implementation.

The Requirements Hierarchy

Not all requirements are equal. Use the MoSCoW framework to prioritize:

Interview Techniques

Structured interviews with stakeholders are the foundation of requirements gathering. Prepare thoroughly and listen more than you talk.

Before the Interview

• Review any existing documentation (process maps, procedures, org charts)
• Understand the person's role and what they're likely to care about
• Prepare open-ended questions that invite explanation, not yes/no answers
• Schedule 60-90 minutes; shorter sessions often just scratch the surface

Effective Questions

• "Walk me through a typical day." — Reveals actual workflows and pain points
• "What's the hardest part of your job?" — Surfaces frustrations and opportunities
• "Show me how you do that." — Observation reveals more than description
• "What happens when [X] goes wrong?" — Uncovers exception handling
• "If you could change one thing, what would it be?" — Reveals priorities
• "What would make this system successful for you?" — Defines success criteria

During the Interview

• Take detailed notes or record (with permission)
• Ask "why" to understand underlying needs, not just stated wants
• Probe on exceptions: "What percentage of time does the standard process apply?"
• Ask for examples of documents, reports, and artifacts
• Note emotional reactions—frustration or enthusiasm signals importance

Documentation Standards

Requirements must be documented in a way that's clear, testable, and traceable throughout the project.

Requirement Attributes

Each requirement should include:

• ID: Unique identifier for traceability (e.g., REQ-FIN-001)
• Category: Functional area (Finance, Sales, Inventory, etc.)
• Description: Clear statement of what's needed
• Priority: MoSCoW classification
• Source: Who requested this and why
• Acceptance Criteria: How will we know it's done?
• Dependencies: Other requirements or configurations this depends on

Writing Testable Requirements

Good requirements can be tested. Compare:

• Poor: "The system should be fast."
• Better: "Order entry screens should load in under 3 seconds."
• Poor: "Users need good reporting."
• Better: "Users can generate an aged receivables report by customer with drill-down to invoices."

Common Requirements by Area

Use these as prompts during discovery to ensure comprehensive coverage.

Financial Requirements

• Chart of accounts structure and mapping from legacy
• Multi-currency requirements and exchange rate sources
• Intercompany transactions and elimination entries
• Revenue recognition rules (ASC 606 compliance)
• Financial reporting requirements and close procedures
• Audit trail and compliance requirements
• Tax calculation and reporting requirements
• Bank reconciliation and payment processing

Operational Requirements

• Order-to-cash workflow and approval requirements
• Fulfillment processes (pick, pack, ship)
• Returns and credit memo handling
• Procure-to-pay workflow and three-way matching
• Inventory management (locations, bins, lot/serial)
• Pricing rules and promotions
• Customer credit management

Technical Requirements

• Integration requirements (what systems, what data, what frequency)
• Data migration scope and historical data retention
• User access and security requirements
• Performance requirements (transaction volume, concurrent users)
• Disaster recovery and backup requirements
• Customization requirements (scripts, workflows, SuiteApps)

Requirements Validation

Never assume requirements are complete after initial gathering. Validate through multiple rounds.

Validation Techniques

• Walkthrough Sessions: Present documented requirements back to stakeholders for confirmation
• Process Simulations: Walk through scenarios in the current system to verify understanding
• Cross-Functional Reviews: Have different departments review each other's requirements for conflicts
• Gap Review: Compare requirements to NetSuite's native capabilities

Current State vs. Future State

Document both where you are and where you're going.

Current State ("As-Is")

Document how processes work today, including:

• Actual steps performed (not documented procedures, but reality)
• Systems and tools used at each step
• Handoffs between people or departments
• Decision points and branching logic
• Pain points and bottlenecks
• Exceptions and workarounds
• Approximate time for each step

Future State ("To-Be")

Define how processes will work in NetSuite:

• Streamlined steps that eliminate redundancy
• NetSuite transactions and records used
• Automation opportunities (workflows, scripts)
• New approval and control points
• Integration touchpoints
• Metrics and visibility improvements

Core Business Processes

Every organization has these fundamental process flows. Map each one relevant to your implementation.

Order-to-Cash (OTC)

flowchart LR
    L["Lead/
Opportunity"] --> Q["Quote/
Estimate"]
    Q --> SO["Sales
Order"]
    SO --> F["Fulfillment"]
    F --> I["Invoice"]
    I --> P["Payment"]

    style L fill:#dbeafe,stroke:#3b82f6,color:#1a1d23
    style Q fill:#e0e7ff,stroke:#6366f1,color:#1a1d23
    style SO fill:#fef3c7,stroke:#f59e0b,color:#1a1d23
    style F fill:#ffedd5,stroke:#f97316,color:#1a1d23
    style I fill:#dcfce7,stroke:#22c55e,color:#1a1d23
    style P fill:#bbf7d0,stroke:#16a34a,color:#1a1d23
                

Key questions: How do orders enter the system? What approvals are required? How is inventory allocated? When do you invoice—at shipment or on a schedule?

Procure-to-Pay (PTP)

flowchart LR
    R["Requisition"] --> PO["Purchase
Order"]
    PO --> RC["Receipt"]
    RC --> VB["Vendor
Bill"]
    VB --> PM["Payment"]

    style R fill:#dbeafe,stroke:#3b82f6,color:#1a1d23
    style PO fill:#fef3c7,stroke:#f59e0b,color:#1a1d23
    style RC fill:#dcfce7,stroke:#22c55e,color:#1a1d23
    style VB fill:#fce7f3,stroke:#ec4899,color:#1a1d23
    style PM fill:#f3e8ff,stroke:#a855f7,color:#1a1d23
                

Key questions: Who can create POs? What approval limits exist? Do you do three-way matching? How do you handle partial receipts?

Record-to-Report (RTR)

flowchart LR
    TE["Transaction
Entry"] --> GL["GL
Posting"]
    GL --> RC["Reconciliation"]
    RC --> AD["Adjustments"]
    AD --> CL["Close"]
    CL --> RP["Reporting"]

    style TE fill:#dbeafe,stroke:#3b82f6,color:#1a1d23
    style GL fill:#e0e7ff,stroke:#6366f1,color:#1a1d23
    style RC fill:#fef3c7,stroke:#f59e0b,color:#1a1d23
    style AD fill:#ffedd5,stroke:#f97316,color:#1a1d23
    style CL fill:#fecaca,stroke:#ef4444,color:#1a1d23
    style RP fill:#dcfce7,stroke:#22c55e,color:#1a1d23
                

Key questions: What's your close timeline? What reconciliations are required? Who can post journal entries? What reports go to executives?

Process Documentation Formats

Choose the format that best fits your organization's culture and complexity.

Swim Lane Diagrams

Show process steps organized by who performs them. Excellent for:

• Visualizing handoffs between departments
• Identifying bottlenecks at transition points
• Clarifying role responsibilities

Flowcharts

Traditional process flow with decision diamonds. Good for:

• Complex branching logic
• Exception handling paths
• Technical documentation

Narrative Procedures

Step-by-step written instructions. Best for:

• Training materials
• Standard operating procedures
• Audit documentation

Identifying Pain Points

During process mapping, actively look for opportunities to improve.

Common Pain Point Categories

• Manual Data Entry: Same information keyed into multiple systems
• Paper-Based Steps: Physical signatures, printed forms, manual filing
• Waiting/Delays: Approvals stuck in queues, batch processing delays
• Rework: Errors requiring correction downstream
• Workarounds: Spreadsheets outside the system, shadow processes
• Lack of Visibility: "I don't know the status of my order"
• Compliance Gaps: Controls that exist on paper but aren't enforced

For each pain point, document:

• What is the issue?
• How frequently does it occur?
• What is the impact (time, money, risk)?
• What causes it?
• How might NetSuite address it?

The Gap Resolution Hierarchy

When a requirement doesn't match native NetSuite functionality, you have options. Always start at the top and work down.

Conducting Gap Analysis

Work through each requirement systematically.

Step 1: Map Requirement to NetSuite Feature

For each requirement, identify which NetSuite feature or module addresses it. This requires solid NetSuite product knowledge.

Step 2: Assess Fit

Categorize the fit:

• Full Fit: NetSuite handles this exactly as required
• Partial Fit: NetSuite handles most of it; minor configuration or workaround needed
• Gap: NetSuite doesn't address this natively

Step 3: Define Resolution

For each gap, determine the resolution approach using the hierarchy above.

Step 4: Estimate Effort

For configuration and customization items, estimate the effort required.

Gap Analysis Template

Build vs. Buy Decision

When a gap requires significant functionality, evaluate whether to build a custom solution or purchase a SuiteApp.

Evaluating SuiteApps

• Built for NetSuite: Is it a native SuiteApp or a connector to external software?
• Vendor Track Record: How long have they been in the NetSuite ecosystem?
• Customer References: Can they provide references in your industry?
• Support Model: What's included? Response time SLAs?
• Upgrade Path: How do they handle NetSuite version upgrades?
• Total Cost: License fees, implementation, training, ongoing support

Select your industry below to see specific discovery considerations, key questions to ask, and common requirements patterns.