What increases the cost of systems projects most is not the basic price, but the customization clause. What raises the customization clause is not the complexity of the requirements but their poor classification: requests that can be achieved with a standard setup are valued as paid development, because no one asked the right question at the right time.
Categorizing each requirement before pricing saves your facility an entire item in many cases, and protects you from another surprise: customization that builds outside the product framework and becomes a burden with each update.
The short answer is cost
Customization Three items with completely different costs. Setting Use flexibility built into the system — defining your services, roles, templates, forms, and approval paths — and is implemented within the implementation and not priced separately. Development The construction of something that does not exist, and is estimated as an independent clause. Integration Is connected to an external system, and has its own classification and rating.
The good news for buyers: what customers most think of as customization falls into the first category. So ask for each requirement to be rated in writing before you accept any estimate — details the difference in Customization page.
Items included in the estimate
First: Classify the requirement
Show each request three questions: Can it be achieved by changing a setting in the system? Does it need a screen or business logic that doesn’t exist? Does it require exchanging data with another system? The answer determines the type, and the type determines the cost.
Second: Depth of request
Within the development class, requests vary greatly. A report with a specific column order is simpler than a business rule that does not resemble system logic, and an additional field in a template is simpler than a multi-level approval path. Ask for an estimate for each individual order, not a lump sum amount for your “allocation.”
Third: Impact of updates
This item is always overlooked and appears after a year. Ask: Is this customization built into the product and its tools, following a natural update cycle? Or outside it, so it needs to be reviewed with every major release? Who bears the effort of this review – you or the provider? Ask that the answer be written in the presentation.
Fourth: Testing and acceptance
Every customization requires a written acceptance criterion: when it is considered complete and who on your team approves it. Customization Clause Without Standard Acceptance Recipe Ready for Disagreement Upon Delivery.
Fifth: Its impact on the table
Customization costs not only money but time. Request a statement of the impact of each item on the project phases: Should the launch be delayed or implemented in a second phase? In many cases it is better and cheaper to postpone it after operation.
How do suppliers’ offers compare?
Send your list of requirements as is to each provider, and ask that each item be categorized into: setup, costed development, integration, or proposed standard replacement. Then compare ratings, not numbers.
And pay attention to an important sign: a provider that categorizes all your requests as paid development either has little flexibility in its system, or bases its price on customization. A provider who suggests standard alternatives for some of your orders — even if it reduces the value of his offer — is often more trustworthy.
What do you require clarification before contracting?
- A written classification of each requirement: preparation, cost development, integration, or proposed alternative.
- Acceptance criterion for each development item: when it is considered completed and who approves it.
- The impact of each customization on the project schedule and delivery phase.
- How each customization is handled in updates, and who bears the effort of reviewing.
- Is customization within the scope of standard post-delivery support or is it a special arrangement?
- Ownership and rights to use what is developed specifically for your facility.
Do not accept an open item titled “Allocation as needed” for an estimated amount. Either specific items with their descriptions and costs, or postpone customization until after launch when your actual need becomes clear.
The next step is to define your range
Write your requirements in problem form, not solution form. “We need the admin to know that this status has exceeded its authentication timeout” opens up cheaper alternatives than “We need a button here.” For each requirement, state: the current procedure, problem, users, exceptions, and expected output.
Then send it in for review before pricing. You’ll often find that most of it is achieved with the standard setting, and the rest is less than you expected. See System Features First, some of what you think of as customization already exists.
Request a quote for your organization
Submit your specific requirements, and we return to you a written breakdown of each item — what is achieved with the setup, what needs to be developed at cost and time, and what we suggest a simpler alternative for before you pay for it.