Writing Client Goals into Acceptance: From Requirements to Outcome Indicators

POLISH treats a client's goals as its own. In the early stage of a collaboration, POLISH first draws out the problem the project is meant to solve, then breaks the goals into items that can be seen at acceptance. How the data for reports will be kept is decided before launch.

This article uses the Outdoor Education Resource Platform, built for a Ministry of Education project, as an example and follows how goals became acceptance items through design, development, launch, and the end of the campaign. For building and maintaining platforms and back offices of this kind, see long-term maintenance and platform development.

The problem the project is meant to solve is drawn out at the start of the collaboration

In an early meeting, the project team explained why the platform needs to find sites on a map: outdoor education site resources across Taiwan are scattered among different organizations, and the aim is to bring the resources together on one platform. The project team also wanted to run the questionnaire survey again. These two explanations tie the platform's core feature and its survey audience to the problem the project team wants to solve.

The project team needed to survey the target audience again on what it needs, and the engineering team listed questionnaire design as an item it could help with: a draft questionnaire for each audience type, with the wording drafted first in that session and the specific questions left for discussion the following week. In the collaboration feedback on the platform, Platform PO Lai describes careful discussion and analysis that brought the core problems into focus.

The literature also discusses how inadequate requirements affect software projects. Hofmann and Lehner, 2001 treat requirements engineering as a success factor in software projects, and the opening of the article argues that inadequate requirements are one of the largest causes of project failure.

Goals are broken into measurable items and matched to acceptance

Locke and Latham, 2002 summarize 35 years of goal-setting research. Specific and difficult goals consistently produce higher performance than a request to do one's best, and a specific goal leaves less ambiguity about what is to be achieved. People need feedback to know how far off a goal is, and a goal combined with feedback works better than a goal alone. The research subjects are mainly individuals and work teams. POLISH's practice is to write each goal so that its achievement can be judged, tie every goal to an item that can be seen at acceptance, and state where the data comes from.

Once a goal is written as one sentence, the next step is to break it into items that can be seen at acceptance: what to look at, where the data comes from, and how it is checked. The table below uses several goals of this platform to show how the four columns are filled in.

The "How acceptance checks it" column has to be fillable before the contract is signed. A way to check on the spot whether each deliverable passes is described in an evaluation checklist for software outsourcing vendors.

Acceptance tasks are written as scenarios

Core tasks for user testing are written as a scenario plus a flow. Feature names are left out. For example: find a site in a given city or county that matches a nature and ecology theme, and view its map location and transit route; after finding the site, obtain its contact details. The flow of a task can be adjusted to fit the actual mockups.

The reason is that testing has to verify whether the site information meets expectations and helps users make decisions. A scenario task can check whether users are able to carry on to the next step once the information is in hand. POLISH hands the finalized core tasks to the designer. Before the design phase ends, an acceptance presentation and then a user testing result report are delivered, so that the task results support finalizing the design.

External specifications are broken into checkable items

The legal basis for performance management, acceptance, and payment between an agency and a vendor is the Government Procurement Act: Chapter 4 governs performance management, and Chapter 5 governs acceptance and payment. How requirements documents and audit clauses are organized into deliverables is described in delivery and maintenance evidence for public-sector projects. What the platform has to meet comes from specifications supplied by the project team, such as the security specification and the accessibility testing requirements, and the engineering team then maps these to the implementation clause by clause.

The security specification has 6 items, covering account lockout, password rules, protection against automated login, the reset flow, and password storage. The engineering team mapped each item to an implementation location, marked it as owned by the front end, the back end, or both, and selected a ready-made solution for protection against automated login.

The accessibility testing requires every image on the site, including icons and logos, to have alternative text. The engineering team reminded everyone responsible for content that every image edited in the back office must have a description, and that the description must match the image; dynamic data is inventoried separately, item by item. The testing combines a software self-check with a manual review. The software self-check scans every URL that can be reached on the site, so alternative text has to cover the front end, the back office, and dynamic data.

The accessibility level is one of the supervising agency's acceptance requirements for the platform, and the website earned the accessibility mark at level AA.

How the figures for the report are kept is decided before launch

Figures to be cited in the final report cannot be looked up only when the report is due. For page views, downloads, and interactions inside the platform, it has to be confirmed before launch that each category is written to the records. Traffic that was never recorded cannot be recalculated afterward.

Before launch, engineers reviewed the coverage of the front-end page-view records category by category and added the findings to a checklist for tracking. The page-view records are the base data for reviewing traffic later.

File download counts need a separate design. The quality checklist listed one item, "the back office can display file download counts." After the engineering side and the front end confirmed the approach, the front end calls a recording interface each time someone downloads a file, and this allows the back office to show the download count of each file.

GA4 cannot capture detailed interactions inside the platform, such as events, sites, and routes. The engineering team therefore added a "Traffic Analysis" tab to the back office on its own initiative to supply these figures, with an export function, and updated the traffic summary sheet for the project team to use together with the existing GA4 data. The project team replied that the data was clear and planned to include it in the final report.

Comparison across years has to be handled in advance. Early after launch, the project team asked that the 2026 Taiwan Outdoor Education Season also have the same participant statistics page as the previous year, and that the previous year's data be kept for comparison. The engineering team replied that data would be provided as exportable tables during the campaign, with a final export when the campaign ends. How campaign data is organized and numbered before launch is described in data integration for cross-agency campaigns.

Ties can occur in the points ranking, and prize substitution needs an objective basis. After the project team raised the point, the engineering team added a column for the time of the last draw to the back-office export.

To write the final report, the project team asked the engineering team to prioritize the back-office export of reflections. Engineers first provided a table export that could be used right away, so the report had data to work with; images are hard to place in a table and were handled separately. Both sides adjust priorities directly as items are reported.

Matters the contract does not cover but that affect results

Beyond the acceptance items, some matters are not always written into a contract yet bear directly on the result the client wants. POLISH also adds these to the work items, raises each one when it is spotted and explains the reason, and leaves the decision to the project team.

For the sake of search exposure and consistent wording in later advertising, the engineering team proactively suggested unifying the campaign's public name under one main name that is easier to recognize. After discussion, both sides settled on showing two names together, and the project team decides the final wording. For the timing of the major public promotion, the engineering team suggested setting it after all rules are confirmed and the engineering-side adjustments are complete, releasing an animated video and an at-a-glance graphic guide at the same time, so that the promotional content matches the actual functions.

With three versions of a social media post on the table, the engineering team first explained the trade-offs: a version with more information may draw more clicks, while a concise version may communicate unclearly. The engineering team then proposed an approach of one main post plus content that is replaced each month, changing the shared topic month by month, so that the campaign has a new topic every month and the layout does not have to be redone each time.

Search and share previews are the main way the public finds the platform. During the launch period, POLISH treated the website's search exposure as its own goal, proactively checked the image and description in share previews, and generated a sitemap once the single domain was confirmed.

On the scope management side, Komal et al., 2020 identified the factors of scope creep through a literature review and expert interviews, then analyzed the factors with a questionnaire and PLS-SEM, and found that these factors are negatively correlated with software project success. When goals have already been broken into measurable items, a request raised midway can first be compared against the goals, and the project team then decides whether to include it.

After the campaign ends, the results feed into next year's planning

After the campaign ended, POLISH first gave the project team a brief analysis; the project team's internal discussion needed more detailed data, and POLISH then supplied it. After the discussion, the project team organized the feedback as a list and sent it back, covering mechanism adjustments, expanded cooperation and sites, and goal setting for the following year, and this became input for the following year's planning.

When this approach does not fit

• A one-time image page or campaign page with no follow-up report: with few items, a page list can cover acceptance, and breaking out outcome indicators takes more effort than the page itself.
• Acceptance sheets and items fully set by a higher-level agency: the focus is mapping clause by clause to the provisions, and outcome indicators can only supplement what is already specified.
• Specifications that do not allow collection of usage data: results have to come from questionnaires or manual reporting, and the recording and export methods in this article do not apply.
• Goals that change often in the middle of a project, with nobody able to decide priorities: the decision process comes first, then the breakdown into items.

What to prepare before starting

Four things should be ready before starting:

• The problem the client wants to solve, written in one or two sentences, without feature names.
• The external specifications and testing requirements that apply.
• The audience of the report, its timing, and the figures to be cited.
• The person who decides whether a change to the scope is included.

Once these are in hand, project goals and acceptance items can be discussed.