Eleven Change Requests and an Unsupported Scheduler Hook at Helio

Treat the categories differently because their risk profiles are different.

Standard configuration (40 hours). Approve and schedule immediately. It is supported, upgrade-safe, and cheap. No reason to create friction here; approving the easy items builds credibility for the harder conversations.

Workflow rules and custom fields (120 hours). Approve conditionally, subject to governance: naming standards, a documented owner, a limit on the number of rules per object, and a review before the configuration freeze. These are supported but accumulate technical debt and can hit platform limits. Require that each rule maps to a named requirement and has a test case.

Code-level changes (380 hours plus 240 hours per year). Split them. For changes that use documented extension points, approve with code review, a test harness, and a support plan. For the scheduling-engine hook, recommend rejection in its current form. Reasons: the vendor has declared it unsupported; a major release in nine months will likely break it during the retail-partner go-live stabilization period; the client has no developers with platform experience to maintain it; and the true five-year cost is roughly 380 hours plus about 1,200 hours of maintenance, against a contingency that is 60% consumed. A hook that breaks after go-live is worse than a weaker scheduling rule that survives.

Offer an alternative for the scheduling need: standard assignment rules plus a custom score field computed nightly for preferred customers, or a pre-computed ranking loaded into a supported field that the standard engine can consume. This delivers most of the business value without touching package internals.

Do not lead with "the vendor says no." Lead with the business outcome and the cost of the options.

Steps:

• Restate the requirement in business terms: preferred customers should get faster and more consistent technician assignment without sacrificing qualification or travel time. Confirm that this, not the specific algorithm, is the goal.
• Present three options with explicit costs and risks: (a) build the hook as requested, with 380 build hours, about 60 hours per quarter, high probability of breakage at the nine-month release, and no vendor support; (b) supported approximation using assignment rules and a pre-computed score, lower effort and upgrade-safe, with somewhat less precision; (c) defer until after the retail-partner go-live, then revisit with vendor roadmap input.
• Quantify the risk in the client's terms: what happens to 850 technicians and the retail partner if scheduling fails during the release window? Who fixes it at 2 a.m., given two developers who have never worked on the platform?
• Ask the vendor for written confirmation of the support position and any roadmap item for weighted scheduling. If the vendor offers a supported extension point, option (a) changes shape.
• If the director still chooses the hook, require a signed risk acceptance from the operations director and the IT owner, a funded support plan, a regression suite that runs before every release, and a documented fallback to standard assignment rules.

The relationship is preserved by showing that you can deliver the outcome, not by refusing the request. What you must not do is build an unsupportable customization quietly and leave the client to discover the maintenance cost after go-live.

Give them a one-page scoring framework applied at design review, with the solution architect facilitating and the business owner deciding.

Criteria:

1. Business value: what measurable outcome, and how often does it occur? A rule affecting 850 technicians daily outranks one affecting a monthly report.
2. Supportability: is it standard configuration, a documented extension point, or an internal hook? Internal hooks require explicit sign-off.
3. Upgrade risk: what is the vendor release cadence and what breaks? Nine-month major releases mean any hook has a known expiry date.
4. Total cost of ownership: build hours plus three years of maintenance plus expected rework after each release, not build hours alone.
5. Reversibility: can it be switched off or replaced without redesign? Prefer reversible designs.
6. Capability to sustain: does the client have named people who can maintain it, and are they trained before go-live?

Process rules: every change request gets a named business owner, a requirement ID, a test case, and a disposition recorded in a decision log. Changes above an agreed effort threshold go to a change board with the retail partner's delivery lead informed. Contingency is released only by the engagement partner, not by the delivery team under pressure. The client's two developers should be assigned to supported customizations first, with training completed before the configuration freeze, so sustainment is real rather than nominal. Revisit the framework at each design checkpoint and report the technical-debt total to the steering committee every two weeks.