Last reviewed: 10 October 2026. Product details reflect this review date. Availability and behavior can vary by account, role and release.
Editorial ink illustration: A project evidence box contains a drawing, a sample and supporting records.
A consultant records twelve hours against discovery. The project manager sees the time and asks whether discovery is complete. The hours answer how much effort was recorded. They do not, by themselves, establish that the agreed discovery output is finished or that the customer accepted it.
NetSuite Project Management connects tasks, resources, schedules, and time-related progress. These connections are useful when the team understands what each measure represents. A plan describes intended work. Time entries record effort. Task progress reflects the configured calculation and state. Acceptance depends on the agreed evidence for the deliverable.
This lesson uses a fictional thirty-hour project to connect those views. It also explains why task dates can move and why a recently changed project can temporarily display older data while recalculation is still running.
The basic Projects feature and Project Management have different capabilities. Do not assume an account that stores project information has every task-planning, resource, cost, and budgeting function available.
Before following a training exercise, have the account owner confirm the enabled project features and the user’s permissions. Resource Allocations and Job Costing and Project Budgeting have their own availability and setup requirements. Where Resource Allocations is used, resource allocation is part of the prerequisites for assigning resources to tasks.
Keep the exercise within the features actually available. Missing labor-cost information, for example, may require review of feature availability, resource setup, and labor rates. It should not immediately be treated as a failed time entry.
The user also needs the appropriate employee access and role. The employee-record and user-access lesson explains why a person’s business record and their ability to perform a task are separate setup decisions.
Begin with what the task is intended to produce. “Discovery” is a convenient name, but the team needs to know what counts as finished. It could mean an agreed requirements summary, a reviewed process map, or another specific output defined in the project agreement.
Then decide who owns the task and what work is needed. Use a task hierarchy where it helps separate phases and work activities, while avoiding unnecessary layers that make time recording confusing.
An estimate should describe the effort expected for the stated scope. If the scope is vague, the hours will be difficult to interpret later. A task that quietly absorbs extra meetings and rework can appear inefficient when the real problem is an unclear boundary.
Keep acceptance evidence in the organization’s agreed process. This article does not assume a universal built-in acceptance field or workflow. The important point is that the project manager can identify the output, reviewer, and evidence independently of the time total.
Imagine a fictional project with two work tasks:
The total planned effort is thirty hours. A consultant records twelve hours against discovery. At the review meeting, the requirements summary still has two unresolved questions that the customer needs to answer.
The recorded twelve hours are meaningful. They show effort captured against discovery, subject to the time records and applicable approval process. Dividing twelve by the original thirty-hour plan gives 40 percent of that original planned effort. That arithmetic is not a claim that NetSuite’s project progress field must show 40 percent or that the customer has accepted 40 percent of the project.
The manager should examine the actual task progress measure, the estimate of remaining work, and the unresolved output. Discovery may need more effort than expected, or it may be waiting on a decision with little additional internal work. Those situations call for different actions.
Changing the task to complete merely because the original hours have been used would hide the open requirement. Equally, ignoring the recorded effort because the deliverable is unfinished would conceal the cost and capacity already consumed.
NetSuite Project Management calculates time-related project information, including actual and remaining work. A displayed progress measure should be interpreted according to its specific definition and the account’s configuration.
Ask which time records contribute, what approval state is relevant, and how remaining work is maintained. Do not assume that an entered, submitted, approved, billable, and billed hour are interchangeable states. Verify the actual process used by the organization.
A useful review asks three questions together: what effort has been recorded, what work remains, and what output is ready for review? If the answers disagree, preserve the distinction. It may reveal a missing time entry, an outdated estimate, or work that is technically complete but awaiting acceptance.
For management reporting, label the measure clearly. A dashboard called “Project progress” should explain whether it represents time, task state, milestones, or another defined measure. The KPI lesson provides a practical way to make that definition visible.
Task dates depend on more than the effort estimate. NetSuite’s project scheduling considers task constraints, work calendars, resource availability, and predecessor relationships. A change in one part of that model can alter the resulting schedule.
In the fictional project, suppose configuration depends on discovery through the approved predecessor relationship. If discovery moves, configuration may also move. The manager should inspect the relationship and scheduling context before manually forcing the dates back.
Hours and elapsed days are different units. As simple capacity arithmetic, twelve hours of work could occupy two days at six available hours per day or four days at three hours per day. That example illustrates why capacity matters; it is not a prediction of the scheduling engine’s exact result for an account.
Check working days, resource commitments, and task constraints when a finish date seems unexpected. Also distinguish the person assigned to perform work from the evidence required to start it. A resource may be available while the agreed predecessor output remains unresolved.
Project plan recalculation can run asynchronously when the relevant preference is enabled. While it is running, recently viewed project data can be out of date. Once recalculation finishes, reopening the project shows the updated plan.
If a time or task change appears not to have affected the project, inspect the available project recalculation information. Check whether recalculation is pending or in progress and whether a failure has been reported. Record the time of the change and the time of your observation.
Avoid repeatedly changing estimates or resubmitting time simply to make the display move. That can introduce a second problem while the original calculation is still being processed. First establish whether the update is waiting, failed, or complete.
If recalculation has finished and the mismatch remains, investigate the source records and the measure’s definition. If the problem concerns repeated delays, use a reproducible example. The NetSuite performance investigation workflow explains how to collect useful observations without guessing the cause.
Project billing depends on the configured billing model and associated transactions. Time-and-materials work, fixed-bid arrangements, and milestone-based billing can use different rules. A time entry alone cannot tell you that a customer has been invoiced or that revenue has been recognized.
For the fictional discovery task, review the agreed commercial treatment before concluding that twelve recorded hours create a billable amount. The manager may need finance to confirm the relevant billing evidence and accounting treatment.
Similarly, a completed milestone in a project plan needs to be understood alongside the actual billing configuration and contractual process. Do not substitute a schedule label for the evidence required by the billing owner.
The sales-order lesson explains how a commitment, fulfillment evidence, and billing evidence remain connected but distinct. The same discipline makes project reviews clearer.
If a consultant cannot enter time, check authorized access, project-resource setup, assignment, and any time-entry restrictions. If dates changed unexpectedly, inspect the calendar, constraint, resource capacity, and predecessor relationship. If progress seems stale, examine recalculation before changing the underlying plan.
If cost information is absent or unexpected, confirm the relevant features and labor-rate setup with the owner. If time appears under the wrong task, trace the actual entry and use the approved correction process. Do not compensate with an unrelated estimate change.
The roles and permissions review guide helps with access-related obstacles. A good support request identifies the project, task, resource, active role, relevant time entry, expected result, and observed result without exposing unnecessary employee information.
For each important task, confirm the output, responsible resource, planned effort, recorded time, and remaining work. Check applicable time approval, the progress measure’s meaning, and recalculation status. Then identify any acceptance or billing question that needs a separate decision.
In the fictional example, the useful outcome is specific: the discovery effort is recorded, two questions remain, a customer-side reviewer owns the answers, and the manager must assess the effect on configuration. That is more actionable than calling the project “40 percent done.”
CuriousRubik’s NetSuite optimization services can help teams align project reviews with their actual handoffs. A good project record lets people see the effort and the unfinished work clearly enough to decide what should happen next.