Project Context and Management Positioning
This project was a phase-three upgrade of an existing tourism operations and online ticketing platform within the 2016 annual information-systems cycle. It was not a greenfield system. The legacy platform had years of operational data, business habits, and on-site service workflows behind it. After an earlier platform release, the user organisation raised further needs around mobile collaboration, service-quality evaluation, ticketing refinement, self-service equipment, and operational support.
From my project-management perspective, the work could not be managed as software development only. It included three groups of software capabilities, on-site ticketing and printing devices, high-availability support, network-security maintenance, hidden interface work, internal and external network access, base-data preparation, card replacement for operating users, training, trial operation, and acceptance documentation. If any link failed, the back office might work while the self-service process failed, or the equipment might power on while the ticketing workflow remained incomplete.
I positioned the project as a legacy-platform upgrade combined with on-site service integration. The management focus was not the number of screens delivered. It was whether back-office management, mobile processing, online ticketing, on-site query and ticket pickup, ticket printing, service evaluation, and later extensibility could form one verifiable delivery chain.
Project Type
This was a business-platform upgrade project with on-site equipment integration and runtime-environment work. It was neither a simple equipment purchase nor a system built from scratch. It added capabilities on top of an existing operations platform, existing ticketing processes, and existing service locations.
The scope had three layers. The business-software layer included service-quality evaluation, mobile operations management, and dispatch-ticketing platform enhancement. The on-site service layer included self-service ticket pickup, information query, ticket printing, and handheld printing. The supporting-environment layer included server high availability, security-license renewal, internal and external network interaction, power redundancy, database services, and application runtime configuration.
The main challenge was multi-end consistency during a live operational upgrade. Management users, mobile users, public-service users, on-site equipment, and back-end data all had to remain aligned around orders, tickets, invoices, schedules, seats, prices, evaluations, and permissions. I therefore treated the project as a multi-end operations-platform upgrade whose core constraints were business continuity, data consistency, site usability, and acceptance evidence.
Operating Conditions and Delivery Objectives
The operating conditions were typical of a mature service platform. The old platform had been used for a long time, users had fixed operating habits, and the site involved frequent ticketing, ticket pickup, query, checking, and printing activities. At the same time, the project had to support mobile approval, service evaluation, online purchasing, and self-service ticket pickup. The records also mention network planning, UPS configuration, cloud or virtual-server setup, internal and external network security topology, equipment placement, and runtime-environment configuration.
The software objectives covered three capability groups. The first was service-quality evaluation, including visitor satisfaction, complaints and feedback, on-site inspection, covert inspection records, service-standard documents, and statistical analysis. The second was mobile operations management, including ticket sales, ticket checking, queries, authorisation, and operational message push. The third was ticketing and dispatch enhancement, including SMS-channel adjustment, ticket and invoice separation, different printing for group and individual tickets, preferential-price rules, online-product management, finance-related functions, and seat-zone based ticketing.
The hardware and support objectives included high-availability software, network-security-license maintenance, query touchscreens, self-service ticketing devices, thermal ticket printers, spare printing parts, portable desktop printers, and handheld mobile printing terminals. In the public version I generalise exact quantities and names, but retain the device categories because they shaped the integration risk.
The acceptance objective had four verifiable outcomes: the three software capability groups were usable, on-site equipment worked in the service workflow, the network and runtime environment supported launch, and testing, trial operation, training, preliminary acceptance, and handover evidence supported one another.
Management Objectives and Framework
I used a framework of three business chains, two support surfaces, and one evidence chain. The three business chains were service evaluation, mobile operation, and ticketing and dispatch. The two support surfaces were on-site equipment and runtime environment. The evidence chain covered design, equipment delivery, hidden-interface work, testing, trial operation, training, preliminary acceptance, and handover.
The service-evaluation chain checked whether entry points, complaints, inspection records, service documents, and statistics closed together. The mobile-operation chain checked whether ticketing, checking, query, authorisation, and push messages stayed consistent with the back office. The ticketing-dispatch chain checked whether tickets, invoices, seats, cabin or zone categories, preferential prices, online products, finance data, and printing output stayed aligned.
The on-site equipment surface checked whether users could actually pick up tickets, query information, print tickets, and use mobile printing devices. The runtime surface checked whether servers, database, application middleware, internal and external network interaction, security licensing, and power support were ready for launch. I did not manage these as isolated checklist items. I attached them to the business chains and verified them through delivery evidence.
The evidence chain was essential for closeout. The project produced design drawings, topology documents, equipment lists, installation and placement records, line drawings, procurement lists, equipment arrival inspection, power-on testing, hidden-work acceptance, weekly reports, test plans, function lists, test cases, test results, trial-operation records, training records, user feedback, preliminary acceptance reports, and handover materials.
Key Management Focus
The first focus was continuity in a legacy upgrade. The existing platform carried historical data, business rules, and user habits. New functions had to improve the platform without forcing the user organisation to abandon the operating logic overnight or creating a break between old data and new workflows.
The second focus was synchronised software and hardware delivery. The project included back-office and mobile software, query touchscreens, self-service pickup devices, thermal printing, and handheld mobile printing. Equipment delivery was only the first step. The real test was whether equipment joined the workflow, reached the right services through the network, printed or queried correctly, and could be maintained by on-site staff.
The third focus was runtime-environment transition. The trial-operation plan included base-data input, network planning, UPS configuration, cloud or virtual-server deployment, internal and external topology configuration, new equipment placement, and parallel operation of old and new platforms. The risk was not only code quality. It also sat in launch sequencing, site readiness, and business cutover windows.
The fourth focus was ticketing and financial consistency. Ticket and invoice separation, group and individual ticket printing, zone-based seat availability, preferential prices, refunds, and online products all touched service order, finance, and printed-output logic. Inconsistency in those areas would surface immediately at the site.
The fifth focus was documentation completeness. The project had software, equipment, hidden-work, testing, trial-operation, training, acceptance, and handover documents. I used the document checklist as a process-control tool, not just as a binder for final acceptance.
Key Challenges and Responses
The first challenge was controlling the boundary between the legacy platform and new demands. The user expected phase three to solve accumulated problems, but schedule and budget could not support an unlimited rebuild. I divided demands into required current-scope items, such as ticketing, printing, service evaluation, and mobile authorisation; experience improvements, such as query and page-flow refinements; and long-term items where an interface or later extension path would be enough.
The second challenge was the complexity of ticketing details. Zone-based ticketing, remaining-seat display, preferential prices, group and individual printing, ticket and invoice separation, invoice issuance, refund handling, and online-product management affected back-office rules, site operation, and finance. I required the team to verify functions through the chain of order, seat, ticket, invoice, price, printing, and refund rather than through menu availability alone.
The third challenge was integrating site devices and network conditions. Self-service pickup, query touchscreens, desktop and handheld printers all depended on power, network, interfaces, placement, and back-end services. Hidden-work records covered hardware interfaces, power, touchscreen exit control, server-facing external interfaces, and database-facing external interfaces. I linked equipment arrival, power-on testing, hidden-work acceptance, line and topology materials, and trial-operation records so that equipment would not pass procurement acceptance without entering the real service scenario.
The fourth challenge was avoiding a risky one-step cutover. The trial-operation plan sequenced full testing, base-data input, network and UPS adjustment, server and network topology setup, card replacement for operating users, equipment placement, parallel operation of old and new platforms, and gradual launch of the subsystems and self-service devices. I managed launch as staged readiness rather than a single switch.
The fifth challenge was closing real issues instead of hiding them. Weekly records showed issues such as inspection-form ordering, an unfinished offsetting function in a ticketing scenario, delays in mobile query and authorisation work, delayed integration testing, and incorrect ticket-surface information. Trial operation also recorded short interruptions and database-connection exceptions in specific components. I kept those as management inputs and tracked them through functional adjustment, performance tuning, user confirmation, test conclusions, and trial-operation indicators.
Schedule Management
The project started in the second half of 2016 and moved through environment setup, service-evaluation development, mobile development, ticketing-dispatch upgrade, performance tuning, integration testing, equipment arrival, hidden-work acceptance, trial operation, training, preliminary acceptance, and handover. It was not a single development stream. Three software streams and one equipment and environment stream moved in parallel.
I managed schedule at two levels. The first level tracked functional delivery: satisfaction survey, complaints and feedback, WeChat-based evaluation, mobile ticketing and checking, query, authorisation, SMS-channel change, ticket and invoice separation, zone-based ticketing, and finance-related functions. The second level tracked launch readiness: testing, base data, network and power, virtualised or cloud server environment, equipment placement, user-card replacement, and parallel operation of old and new platforms.
When delays appeared, I distinguished between date variance and critical-path impact. Some functions showed partial completion in weekly records, and integration testing was extended. I focused priority on items that affected mobile operation, ticketing and dispatch, on-site ticket pickup, printing, authorisation, and ticket-surface information. Those items had to close before realistic trial operation.
Near closeout, schedule control shifted from development completion to operational readiness: ready to launch, ready for trial operation, ready for training, ready for acceptance, and ready for handover. Completion reports, test reports, trial-operation records, training records, and preliminary acceptance reports were used together.
Quality Control
Quality control started with design and configuration baselines. The project had high-level design, detailed design, database documentation, data dictionary, system management manual, operation manual, configuration table, topology documents, placement drawings, and line drawings. These materials constrained software, equipment, and network implementation instead of leaving development to verbal requirements.
Testing followed unit, integration, and system levels. It covered module interfaces, local data structures, business paths, error handling, boundary conditions, user interface, performance, load, capacity, fault tolerance, security, configuration, and installation. Each of the three main software capability groups had test conclusions before the project moved to the next stage.
Functional quality was controlled through business chains. The service-evaluation chain validated scan-based evaluation, complaints, scoring statistics, inspections, and service-document maintenance. The mobile-operation chain validated ticketing, checking, query, authorisation, and push functions. The ticketing-dispatch chain validated zone-based seats, tickets and invoices, group and individual printing, preferential prices, refunds, and online products. The device chain validated pickup, query, printing, and mobile output.
Operational quality relied on trial-operation indicators. The trial operation monitored interruptions, interruption duration, CPU, memory, storage I/O, database connections, transaction locks, logs, tablespace conditions, and serious defects. Specific components recorded short interruptions or database-connection exceptions, but no important-level defects were recorded. That made trial operation a real observation period rather than a ceremonial launch.
Risk and Change Control
Scope risk came from the natural expansion of a phase-three upgrade. A legacy platform has many accumulated expectations. I used the function list, weekly reports, test cases, and acceptance list to hold the current phase boundary, while keeping later extension conditions for mobile, online services, and interface evolution.
Site risk came from equipment, network, and power readiness. The trial-operation plan included network planning, UPS configuration, virtual or cloud server setup, internal and external secure interaction, new equipment placement, and self-service network tuning. I therefore put those items into the trial-operation path instead of treating them as a one-time installation confirmation.
Cutover risk came from parallel operation, user-card replacement, and coordination with operating entities. The upgrade could not simply turn off the old system and turn on the new one. The team needed notices, card replacement, paper fallback preparation, operating records, and a period of dual-system operation before formal enablement.
For change control, the formal project documents indicated no formal engineering change. However, the process still contained business-detail adjustments and issue corrections. My position was clear: if contract scope did not change, it did not become a formal change; but user feedback, ticket-surface errors, functional delays, and trial-operation findings still had to be closed through quality and issue management.
Stakeholder and Interface Governance
The project involved the user organisation, on-site service personnel, contractor, supervision team, equipment suppliers and implementers, and operating entities affected by card replacement or online ticketing. The coordination challenge was not merely communication. It was making these roles act on the same launch sequence.
I built coordination around weekly reports, submissions, equipment inspections, hidden-work acceptance, test submissions, trial-operation submissions, training records, and preliminary acceptance submissions. Each document type represented a coordination moment: design confirmed scope, equipment inspection confirmed assets, hidden-work acceptance confirmed interfaces, trial operation confirmed launch status, training confirmed user takeover, and acceptance confirmed the delivery boundary.
Interface management was central. The system involved server external interfaces, database external interfaces, self-service hardware interfaces, touchscreen exit control, printer interfaces, mobile-to-back-office interfaces, and ticketing-to-finance data interfaces. I required key interface issues to be supported by documentation, tests, and trial-operation records rather than by informal technical assurance.
Training and user feedback were also part of governance. During training, users raised questions based on real operating experience, and those comments helped refine workflow and usability. For a phase-three upgrade, user feedback was not a distraction. It was a validation channel for whether the platform matched actual operations.
Acceptance Evidence and Handover
Acceptance was prepared continuously rather than only at the final meeting. The handover checklist covered initiation, procurement, contract, design, equipment, implementation, testing, trial operation, training, preliminary acceptance, and handover. Most items carried completion status, which helped me identify missing documents and cross-check whether documents matched the actual system state.
Equipment evidence included procurement lists, contract equipment lists, equipment arrival records, power-on test reports, serial numbers and certificates, random accessories, and hidden-work acceptance. Software evidence included requirements, high-level design, detailed design, database documentation, data dictionary, management manual, operation manual, configuration table, function list, test cases, test results, and test report. Operational evidence included trial-operation plan, trial-operation records, trial-operation report, training plan, training records, user feedback, preliminary acceptance report, software-media handover, and final document handover.
The preliminary acceptance result marked the three software platforms and system hardware as qualified. In the public version I remove the real names of the site and organisations, but keep the acceptance logic: software capability, site equipment, runtime support, trial operation, training, and handover evidence all had to reach acceptance condition together.
Project Result and Lessons Learned
The project completed the phase-three upgrade of a tourism operations and online ticketing platform. It delivered service evaluation, mobile operations, ticketing and dispatch, on-site query and pickup, ticket printing, high-availability support, and security-maintenance capabilities. Software functions passed testing, equipment passed arrival and power-on checks, hidden interfaces were accepted, trial operation and training records were produced, preliminary acceptance was qualified, and handover materials were assembled.
From a management perspective, the main result was not the number of new functions. The result was that legacy-platform upgrade, site equipment, network environment, ticketing rules, mobile collaboration, and user takeover were managed as one delivery chain. Staged testing, old-new parallel operation, card replacement, equipment launch, trial-operation metrics, and document checklists moved risk earlier than the formal acceptance point. The reusable lesson is that legacy platform upgrades must respect existing operations while still drawing a clear current-phase boundary. Online ticketing projects need back-office, mobile, on-site device, ticketing, invoice, and finance logic to be verified together. Equipment delivery is not enough unless the device enters the business workflow. Trial operation and training are management tools for finding process gaps, confirming user readiness, and supporting acceptance evidence.