POC Beyond the Agreed Scope: Validate the Opportunity First, Then Let the Client Decide on Inclusion

When an opportunity outside the agreed scope appears during a project, POLISH first proposes it proactively, runs a small-scale validation, discusses it with the client through screens and results, and leaves the client to decide whether it enters the formal scope. This process runs in parallel with scope management. The output of the proposal stage consists of paths, screens and test results, and it does not replace the agreed specifications and design. Content is written into the plan only after the client decides to include it.

The practices below come from POLISH's work on the Ministry of Education project, including operation of the Outdoor Education Resource Platform and production of the 2026 Taiwan Outdoor Education Season.

What research says about trial builds, experiments and risk

Boehm, 1988 proposed the spiral model, which guides the software process through a risk-driven, step-by-step evolutionary approach. POLISH applies the same thinking to proposals outside the scope: find the most uncertain point and validate only that point.

Flyvbjerg and Budzier, 2011 open with the case of an apparel company. The company decided to migrate to a single system, was at one point unable to ship during the transition, and later recognized losses of more than one hundred million dollars. Switching a large system over in one step can have severe consequences, so before scaling up, POLISH looks at the results of a small-scale trial.

Drawing the user path and a sample screen before proposing

When route data from several units was being consolidated, POLISH stated that wireframes would be produced as an additional aid to coordination whenever documents alone could not make the matter clear to the units concerned. Route data involves multiple units, and screens make consensus easier to reach than text does.

The map experience is another example. POLISH proactively compiled a reference list of experience problems and possible solutions, and shared material on 3D maps with the designers to explore a better presentation beyond the established design.

One planned feature of the Outdoor Education Resource Platform was proposed outside the existing operation work. POLISH first drew out the user paths, with the experience paths for teachers and for the general public kept separate, and then posted a clickable sample screen and a mascot concept. The project team replied with related concept articles, usage information, a needs survey questionnaire and lesson plans and teaching materials, as research references for the design of the planned feature. Both sides therefore worked from the same planning input.

At this stage, ideas are first checked against concrete screens and paths, and the decision on inclusion in the formal scope follows. Once a screen exists, the project team can point directly at what needs to change, and the discussion starts from concrete content.

Testing at small scale and scaling up once feasibility is confirmed

After the project team opened ad management access for the fan page, POLISH ran an ad test first, and scheduled expanded placement to begin only once the test was confirmed successful.

After the test succeeded, POLISH assembled a proposal deck and an ad asset folder covering several video and image ads, and asked the project team to confirm the deck and the folder before seeking instruction from higher authority. As soon as confirmation is complete, the next round of placement is planned, with the target of finalizing it within that week and starting the count the following week.

Thomke and Manzi, 2014 point out in Harvard Business Review that the data on hand cannot predict how customers will react to an innovation, and that rigorous experiments are needed to learn whether a wholly new concept will succeed. An ad test belongs to this kind of experiment.

POLISH follows the same order for feature proposals: look at the results at a small scale first, then discuss expanding.

Self-designed rules and plans: documented first, then discussed

The recommendation ranking of the site list was designed by POLISH and explained publicly in the project's regular communication channel. The weighted score is built from three inputs plus a small amount of randomness: data completeness, accumulated view count, and how closely search terms match the analysis tags. The three inputs carry equal weight, and randomness accounts for only a small share.

A separate interleaving mechanism places lower-ranked sites into fixed positions in the front part of the list. The county and city entry images follow the same logic and use the cover image of the top-recommended site in that locality. The purpose is to give users more chances to discover new sites, along with a sense of surprise.

Once the rules are written down, every weight and every interleaving position can be checked, and any adjustment makes clear which item is being changed.

The use of illustration in the design stage was likewise a plan proposed by POLISH. POLISH looked at how heavily used large platforms avoid large-area illustration and adopted symbolic icon illustrations and illustrations that support communication instead. These are placed in headers, on both sides of the screen, and at category and item markers, and POLISH invited the designers to discuss together what should be drawn. This raises platform identity without taking space from the text content.

Letting the client decide on inclusion from screens and results

The project team asked POLISH for marketing recommendations on the "promotion approach" section of the draft annual plan. POLISH wrote the overall game mechanism discussed in the meeting into clauses. After a submission to the platform passes review, a phone-sized share image containing the user's own character is generated automatically. It can be shared to a personal social account with one tap, with an exclusive invitation link attached. When a friend registers and submits, the sharer earns points, and the points can be used for collecting characters, activity rankings, or eligibility for a prize draw. The design aims to encourage users to invite friends proactively, creating natural spread and long-term participation. The project team said it hoped the mechanism could be built. The clauses were taken into the plan and have been submitted to the supervising agency.

The prize mechanism for the points activity was drafted first by POLISH's project contact, in two lines: by ranking and by prize draw. An engineer confirmed feasibility and advised confirming the number of prizes. The project team then checked the prize allocation between the platform and the other activities and confirmed that the number of prizes was correct. Writing the rules first as implementable conditions serves to confirm that the prizes do not overlap with those of the other activities. For the accounting, abuse prevention and budget control of prize activities, see Accounting, Abuse Prevention and Budget Control on Prize Campaign Platforms.

Before a cross-unit consultation meeting, POLISH posted the annual key visual and a presentation preview in advance and exported some of the character cards. The project team took the visual and the cards to a discussion with experts at noon that same day. With a large number of characters, POLISH made each one as distinct as possible, hoping to create memorable points. The project team responded favorably to the visual and the cards and carried both into that day's discussion.

POLISH's project contact also initiated a discussion on expanding the functions for the site group in the teaching-material collection program. The project team's reply attached a cross-reference list of the sites of the 2026 Taiwan Outdoor Education Season and the sites already on the platform. When submissions are called for later, teachers can choose a site from the list to write a lesson plan.

After POLISH produced the quick-guide pack for the teaching-material collection, the project team confirmed it and compiled the points needing revision, together with contact information. After POLISH made the corrections, POLISH also proactively offered to produce a cover image for the project team's social media page, to stay up until the submission deadline. The project team said the quick-guide pack looked good, put the cover up that evening and published a post.

Many interactions on the platform fall outside what GA4 measures. POLISH added a "Traffic Analysis" tab to the admin console that supplements GA4 with detailed in-platform figures for activities, sites, routes and similar items, and the data can be exported. POLISH also updated the traffic summary sheet and told the project team that, combined with the existing GA4 data, it meets the reporting need. The project team replied that the data was clear and planned to include the top-ranked figures in the final report.

What these cases have in common is that POLISH prepared the screens, clauses or lists first, and the project team and the supervising agency judged whether to adopt the material.

The boundary between proposals and scope management

A proposal beyond the scope does not mean unlimited additions. Komal et al., 2020, published in IEEE Access, identified the factors of scope creep through a literature review and expert interviews, then applied a questionnaire and PLS-SEM analysis, and found that these factors are negatively correlated with the success of software projects. Uncontrolled scope harms project outcomes, so POLISH keeps scope management in place alongside its proposals.

POLISH handles proposals and the formal scope separately. The output of the proposal stage is screens, lists and test results, and each validation addresses a single question awaiting confirmation. Content is written into the plan or clauses, and enters the formal scope, only after the client decides to include it. When the client decides to hold off on inclusion, the agreed scope stays as it was.

For the cost after inclusion, How to Estimate the Cost of an AI Project covers the estimation approach when AI functions are involved. For how to assess a vendor's handling of additions and scope, see Evaluating a Software Vendor: A Scorecard and Pre-Contract Checklist.

Situations where validating first is a poor fit

In the following situations, validating first beyond the agreed scope is a poor fit:

• The method is already specified clause by clause in regulations or tender documents, leaving no room for adjustment.
• The launch date is near and acceptance of existing functions is still under way, so the time is reserved for formal delivery.
• The data or access needed for validation has not been obtained, so the validation results have no reference value.
• No one on the client side can review the screens and make a decision within the deadline.

In these situations, the formal scope is completed first, and the opportunity is raised in the next phase.

What to prepare before starting

Before validation, the client side prepares the following items so that validation can be completed in a short time:

• The question to be validated, stated in one sentence.
• The people who can review the screens and reply, and the response time.
• Research input already on hand, such as survey questionnaires, usage information, lesson plans and teaching materials.
• The access that validation needs, such as ad management access.
• Who decides on inclusion, and whether referral to higher authority is needed.

Such proposals mostly arise during engagements for long-term operation and platform development.

Once these points are ready, the next step is to contact POLISH, describing the opportunity to be validated and the project's current stage. POLISH first determines the scope of validation, then proposes an approach.