Is Your NetSuite Project on Track? A 10-Question Self-Check

The project tracker says on schedule. The steering committee deck has the right number of green cells. Nobody in the last status meeting raised a hand.

None of that is the same claim as “this project is actually on track.” The gap between the two is usually invisible from inside a status meeting, because a status meeting is built to report against a plan. As one ERP consultancy puts it, status meetings are designed to track progress, structured around schedule adherence, budget burn and open risks.¹ The plan is exactly the thing that stops being the whole truth a few weeks after kickoff.

The early signs that something is off are quiet by nature. The same consultancy lists three: milestone “rebaselining” that reframes delay as scope clarification, user acceptance testing declared complete despite unresolved usability complaints, and finance raising concerns about reporting accuracy while IT reports progress.¹ None of those shows up as a red status on its own.

They show up as a pattern, if anyone is looking for the pattern instead of the individual data points. Another ERP program consultancy makes the same point: subtle signs emerge long before missed milestones, budget overruns or failed go-lives.²

If you run finance or operations on NetSuite, whether you are mid-implementation, six months past go-live or years into steady state, what follows is written for you: ten direct questions, the kind a health check would ask, that you can answer for your own NetSuite project right now, without waiting for a consultant to ask them for you.

01. Why “On Schedule” Isn’t the Same Claim as “On Track”

Every NetSuite implementation runs on a plan, and every plan was accurate on the day it was written. The problem isn’t that plans are wrong. A plan is a snapshot, and a NetSuite instance, along with the business running on it, keeps moving after the snapshot is taken. Scope gets refined.

People roll on and off the project. A decision made in a working session three weeks ago quietly changes what “done” means for a phase that was scoped before that decision existed.

None of that shows up on a Gantt chart, because a Gantt chart tracks tasks, not the gap between what a task was supposed to accomplish and what it now needs to accomplish. By the time that gap becomes a missed go-live, a budget line or a reopened phase, the project has usually been at risk for weeks, and everyone involved has been reporting it as on track in good faith, because the status report was never built to catch this kind of gap.

The ten questions below are built to catch it anyway. None of them asks whether your project is late. They ask whether the plan and the reality underneath it are still the same thing.

02. The 10-Question Self-Check

Answer each with a straight yes or no. Don’t round up. A “mostly” or “I’d have to check” counts as a no for scoring in the next section.

1. Do you know who owns each handoff between project phases, not who is accountable for the phase, but who is accountable for the handoff itself?

Almost every NetSuite project has clear phase owners: someone owns discovery, someone owns configuration, someone owns testing. Far fewer have anyone explicitly responsible for the moment one phase’s output becomes the next phase’s input. ERP writing calls the cost of that moment “dark time”: the stretch where a task is technically finished but the next step can’t move, because the context that made it finished didn’t travel with it.³

Panorama’s 2026 ERP Report, a survey of 170 organizations, found that ERP issues are most often related to unclear process ownership, poor user adoption and lack of strategic alignment around project goals.⁴ Our resource plan built around roles, hours and gates treats handoff ownership as a planning input from day one rather than a problem to solve if it comes up.

2. When was your current configuration last re-verified against what the business needs today, not just what it was built to do at kickoff?

Configuration gets tested against its original specification constantly. It gets re-tested against the business’s current needs far less often, and the two are different claims: “this was built correctly” and “this is still correct for what we’re doing now” can both be true on different days of the same project. A structured post-implementation review exists to ask the second question on a schedule, rather than waiting for a symptom to force it.

3. What share of your migrated records has actually been checked, not just confirmed as “loaded successfully”?

A load success rate can look nearly perfect and still conceal the records that matter most, because the defects that derail a go-live are rare by nature, and a clean sample says less about a rare defect than it feels like it does. A standard result in statistics, the rule of three, puts a number on it: if you check N randomly chosen records and none has the defect, the most you can say at 95 percent confidence is that the defect affects fewer than about 3 in N.⁵

To rule out a defect that hits 1 record in 10,000, you need roughly 30,000 clean records checked. A spot check of 300 leaves a defect rate of up to 1 in 100 unexcluded. Upstream, ERP Research calls dirty legacy data one of the quietest timeline killers and advises cleansing before configuration, so migration becomes a load exercise instead of a cleanup project.⁶

Our cutover plan built to validate, not just load walks through what checking the records you didn’t sample looks like.

4. Have you tested what happens when something goes wrong, or only confirmed that things work when they go right?

One ERP practitioner calls exception-scenario testing often the most neglected part of user acceptance testing, because most businesses test only the ideal situations. The scenarios it lists are partial deliveries, partial receipts, purchase and sales returns, rejected materials, currency fluctuations and price revisions.⁷ The same write-up treats role permissions and approval workflows as a UAT step of their own, which is worth checking against your plan, because access problems tend to surface after go-live, not before.

If your UAT plan was built from the processes everyone already knows, it was very likely built to skip the processes nobody thought to write a script for.

5. If your lead consultant left tomorrow, would your documentation still describe how the system actually works, or how it was supposed to work at kickoff?

One practitioner write-up describes the mechanism with an illustrative case: a consultant works through a fix on a call, types the resolution into a direct message to the project lead instead of a ticket, and rotates off. The decision never reaches a system of record and lives in a thread someone would have to scroll back through to find.⁸

Treating knowledge capture as a one-time sprint before someone’s departure, rather than something that happens continuously as a normal part of the work, is the pattern that lets this decay build up quietly.⁹

6. Could you and your implementation partner each write down, independently, what “done” means for the current phase, and would the two answers match?

A 2009 Project Management Institute conference paper on scope creep notes that when a team interprets the requirements and builds what it thinks is right, the chances of misinterpretation and expansion of scope are high.¹⁰ An ERP consultancy separates two things people lump together: scope creep, which it describes as new requirements added by the ERP vendor or consultant, and “scope seep,” where the client’s own project team voluntarily asks for features beyond the original scope.¹¹

Both start from the same root: nobody checked whether “done” meant the same thing to everyone holding the plan. Unresolved, this is one of the more common paths into a project reaching rescue stage months later.

7. If someone asked for the reasoning behind a decision made three months ago, could you find it, or would you have to remember who might remember?

One project-software vendor describes the usual picture: a choice is made in a steering committee, the rationale sits in someone’s notes, a constraint is discussed in Slack and a trade-off is recorded in an email thread. A useful record names the owner, the options considered and the expected effect on scope, schedule and cost.¹²

The same vendor’s other write-up puts the cost bluntly: agreements that stay trapped inside the platform where they happened are effectively lost to the rest of the project team.¹³

8. Is there manual work happening right now to compensate for something the system doesn’t do, and does anyone outside the person doing it know about it?

Manual work that fills a gap in a NetSuite implementation rarely shows up as a late task. It shows up as someone’s unscheduled time, absorbed quietly enough that the project still looks fine on paper. One analysis calls this the workaround problem: unlike a customization, which breaks at upgrade time and forces a decision, a workaround never breaks, because the person keeps absorbing the variance.¹⁴ We wrote up where this hides in a NetSuite project and why it keeps recurring even in well-run implementations.

9. If someone asked for an access and permissions audit of every integration connected to your NetSuite account today, could you produce one, and would you trust what it said?

This applies whether or not anything AI-driven is connected yet. Oracle’s guidance on its AI Connector Service is direct about the stakes: NetSuite never runs these tools under the Administrator role or any role with full permissions, tools run with the permissions of the user behind them, and Oracle recommends separate roles for different tools, with periodic reviews of who holds MCP permission.¹⁵

The same principle holds for any integration. Whatever is connected to a role inherits that role’s full permission scope, including whatever over-permissioning has quietly accumulated since before the integration existed.¹⁶ Our structured checklist for exactly this shows what a real answer looks like, and our NetSuite AI integrations service covers the governed-connection side.

10. Could someone new to this project understand why the system works the way it does, or does it only make sense to the one or two people who were there for every decision?

ERP implementations concentrate this problem, because engagements span multiple phases with rotating team members, each carrying context that never gets fully written down before they roll off. If the honest answer is “only Dave knows,” the project has a working system and an undocumented one running in parallel, and only one of them will still be there when Dave isn’t.

03. How to Score Yourself

Count your “no” answers, including any “mostly” or “I’d have to check.” Then read the total:

• Zero to two: your project is handling its seams about as well as any NetSuite implementation realistically does, so a periodic re-check is enough, not an intervention.
• Three to five: normal friction, concentrated enough that it’s worth deciding, on purpose, which of these to fix first instead of letting all five compete for attention at once.
• Six or more: this isn’t a prediction that your project will fail. It’s a signal that enough of the connective tissue between phases, people and decisions has gone unverified that nobody currently has a reliable picture of where things stand, which is a different and more urgent problem than being behind schedule.

04. What a Low Score Usually Means

A high “no” count isn’t a referendum on your team’s competence. The published numbers on how ERP projects go wrong are easy to over-read, so here is what one primary source actually says. Panorama’s 2026 ERP Report surveyed 170 organizations between January 2025 and January 2026. Its charts show:⁴

• Budget: 50.6% finished on budget and 19.4% under budget. 22.9% ran slightly over and 7.1% significantly over, 30.0% in total.
• Schedule: 58.8% finished on time and 18.8% early. 18.2% ran slightly late and 4.1% significantly late, 22.3% in total.

Among those over schedule, the most common reason was organizational issues, including governance, resistance to change and process redesign, which show up as delayed sign-offs and prolonged design workshops.⁴ That is the seam problem this self-check is built around, not a technology problem. The survey is self-reported and the respondents are self-selected, so treat it as a signal, not a benchmark.

Our own audit of where ERP failure figures come from goes further and finds that no reliable public source establishes a universal NetSuite-specific failure rate, because available figures mix ERP, software and general projects and use incompatible definitions. That is worth knowing before you repeat any of them in a steering committee meeting.

The honest takeaway isn’t that failure is inevitable. A low score means seams in your project currently lack an explicit owner or an honest check, which is common and fixable, and which this self-check was built to catch while it is still a “no” on a checklist instead of a missed go-live date.

05. Why This Happens Even on Well-Run Projects

Read back across the ten questions and a single pattern sits underneath all of them. Every one is work that exists in the space between two owners: between the team that sold the project and the team that builds it, between “the system was configured” and “the configuration still fits,” between a decision being made and a decision being findable later.

None of that work is explicitly anyone’s job on a project plan, because a plan is a list of phases, not a list of seams, and seams don’t look like work until something falls through one.

That is why the early signs are quiet.² A seam failing doesn’t trigger an alarm. It shows up later, reframed as a late milestone, a budget line or a controller quietly doing something by hand that was never supposed to be anyone’s permanent job. Nothing about this pattern marks a bad implementation. It’s close to the default outcome of any complex, multi-phase project unless someone decides, on purpose, to check the seams instead of just the phases.

One way to make the answer structural is to assign each seam to a named role, with a person accountable for the result. In our agentic NetSuite delivery:

• a requirements role captures what you asked for and ties it back to where you said it
• a design reviewer challenges every design before work starts
• a QA role tests every build against your requirements
• a training role writes the guides your team will use

It doesn’t make every seam disappear: migration validation and permission reviews still need an explicit owner on any team. What changes is the default, because ownership is assigned up front instead of discovered later.

06. What to Do With a Low Score, Depending on Where It’s Low

Read the pattern by group.

• A low score on questions 1, 2 and 6 (handoffs, configuration currency, definition of done) usually points at an ownership problem: something needs an explicitly named owner that currently has an implied one.
• A low score on questions 3 and 4 (migration and testing) usually points at a validation problem: the checks that exist are real, just scoped too narrowly to catch what matters.
• A low score on questions 5, 7 and 10 (documentation, decisions and institutional knowledge) points at a capture problem: the information exists somewhere, in someone’s head or a message thread, just not in a form the next person can find.
• Questions 8 and 9 sit slightly apart. Question 8 is a symptom that can show up from any of the other gaps, and question 9 is about whether your governance model would survive a genuine audit, which is worth answering on its own.

None of these categories requires an outside party to start fixing. A general best-practice guide, applied deliberately instead of skimmed, closes a real amount of the gap on its own. What it won’t necessarily give you is an honest read on how deep the gap runs, for reasons the next section gets into.

The same seams exist outside NetSuite: reports that wait on one person, policies nobody wrote down, knowledge locked in one senior head. Houseblend.ai, our separate site for AI adoption, covers that side, from assessment and policy to connecting AI to company systems and training the team, with a person signing off every output.

07. When an Outside Read Is Worth It

Self-diagnosis has a structural limit, and it isn’t about effort or honesty. Everyone close enough to a project to answer these ten questions accurately also has some stake in the answer. A project lead who scores their own handoffs is also the person whose handoffs are being scored. That isn’t a conflict of interest in the dishonest sense, just how proximity works, and it is why a second opinion tends to catch things a first one doesn’t: not because the first team was careless, but because nobody can fully audit a seam they’re standing inside of.

An outside read is a cross-check against your team’s own, not a replacement for it. Houseblend offers a free executive assessment of your NetSuite environment, covering strategy, performance, risk and cost. To be clear about what it is: it is our own assessment, run by Houseblend, not an independent audit. If you want a read from someone with no tie to your implementation partner, ask for one from a firm that isn’t bidding on the next phase.

If your score was low enough to sit with you after reading it, that is usually the signal worth acting on, more than the specific number.

08. FAQ

Is a low score always a sign of a failing project?

No. A low score means several seams in your project currently lack an explicit owner or an honest check, which is extremely common and not a special kind of failure. What matters is which questions scored low and whether anyone plans to do something about it.

What if my implementation partner disagrees with my score?

That disagreement is itself useful information. If you and your partner can’t agree on the answer to something like “do we know who owns this handoff,” that is a definition-of-done problem (question 6) showing up in real time.

Does this apply after go-live, or only during active implementation?

Both. Several of these questions (documentation currency, integration governance, institutional knowledge) matter more after go-live, once the team that built the system has moved on and the team running it day to day has to live with whatever didn’t get captured.

What’s the difference between this and a formal audit?

This self-check is designed to be answered honestly in ten minutes by someone close to the project. A formal review, such as the one in our post-implementation audit checklist, verifies the answers against the actual system and documentation instead of relying on anyone’s own read of their own project.

Talk to Houseblend

If your score came back at six or more, or three or more of the answers surprised you, that is usually the point where a second set of eyes pays for itself. Houseblend’s agentic NetSuite delivery puts a team of AI specialists and a senior consultant, accountable for the result, behind your NetSuite work: built and tested in your sandbox, with a person signing off before anything reaches production.

This article was researched and drafted with AI assistance and reviewed for accuracy before publication. It is not professional, legal, or financial advice.

Sources

1. Panorama Consulting Group, “What an ERP Health Check Actually Reveals” ↩ ↩
2. OP Consulting Group, “Early Warning Signs Your ERP Program Is Going Off Track” ↩ ↩
3. VersaCloud ERP, “What Really Breaks ERP Timelines: Handoffs, Rework, and Decision Gaps” ↩
4. Panorama Consulting Group, “The 2026 ERP Report” (survey of 170 organizations, January 2025 to January 2026) ↩ ↩ ↩
5. J. A. Hanley and A. Lippman-Hand, “If nothing goes wrong, is everything all right? Interpreting zero numerators”, JAMA 1983;249(13):1743-1745 ↩
6. ERP Research, “How Long Does ERP Implementation Take? Real Timelines by Vendor” ↩
7. ERPPILOT, “The Hidden Value of ERP User Acceptance Testing (UAT)” ↩
8. ScopeDocs, “Where Tribal Knowledge Lives Inside ERP and CRM Implementations” ↩
9. Argus AI Labs, “The Tribal Knowledge Problem: What Happens When Your Best People Walk Out the Door” ↩
10. Richard Larson and Elizabeth Larson, “Top Five Causes of Scope Creep”, PMI Global Congress North America, October 2009 ↩
11. The Answer Company, “Preventing Scope Creep & Scope Seep in ERP Implementation” ↩
12. Causr, “Why Every Major Project Needs a Decision Audit Trail” ↩
13. Causr, “Project Decision Tracking: How Project Delivery Teams Lose Decisions” ↩
14. Kognitos, “ERP Implementation: The Workaround Column Is Your Real Operating Model” ↩
15. Oracle, “Associated Risks, Controls, and Mitigation Strategies” (NetSuite AI Connector Service) ↩
16. Netwrix, “NetSuite AI Connector security risks and governance” ↩