Project Context and Management Positioning
This project belonged to the 2016 annual information-systems delivery cycle. It was a second-phase upgrade of an existing public service collaboration platform. The objective was not to build a standalone system, but to extend an existing platform with self-service information reporting, mobile management, and multi-channel assistance capabilities while preserving existing accounts, permissions, workflows, interfaces, and data-exchange arrangements.
I managed it as a platform upgrade and capability-extension project rather than a normal software build. The real management work was to define the upgrade boundary, validate multi-role requirements, control cross-boundary data exchange, connect a short development cycle with trial operation and third-party testing, and build an acceptance evidence package covering requirements, design, testing, training, user feedback, and handover materials.
Project Type
This was a single project, not a programme or a portfolio. However, it had the complexity of a typical upgrade project: the existing platform had to remain stable; new public-facing and mobile-facing functions had to be added; internal users still needed review, handling, query, statistics, and feedback workflows; and the delivery also involved secure access, data exchange, and independent testing.
This classification shaped the management approach. I managed the project through scope control, requirement-chain validation, interface governance, quality verification, and acceptance evidence. Success was not defined as delivering three visible modules; it was defined as whether those modules could operate as a complete service chain within the existing platform.
Delivery Conditions and Objectives
The project was an upgrade to an already running public service platform that supported online queries, service handling, consultation, and information publishing. The second phase added structured self-reporting by external participants, a mobile terminal for internal handling staff, and multi-channel assistance through web, mobile, SMS-style notification, and messaging channels. In public wording, the architecture can be described as external intake, controlled exchange, internal processing, and external feedback.
The functional objectives were grouped into four areas. First, external participants could submit structured information through PC, mobile app, and messaging-style channels, with back-office review, query, and statistics. Second, mobile users could query information, receive notifications, handle transferred items, use auxiliary office functions, and collect field information where needed. Third, the assistance channel allowed users to submit non-emergency service requests and query handling results. Fourth, external intake data and internal handling results had to move through a controlled exchange mechanism rather than bypassing security boundaries.
The requirements also contained performance, security, and maintainability targets. The materials referred to high daily traffic expectations, concurrent access, response-time targets, system stability, identity authentication, permission control, logs, backup and recovery, interface security, and controlled boundary exchange. For management purposes, these were acceptance requirements, not technical side notes.
Management Objectives and Framework
I divided the management objectives into four layers. The upgrade boundary identified what would remain unchanged, what would be newly delivered, and which interfaces had to connect old and new capabilities. The requirement chain mapped external submission, back-office review, internal handling, mobile processing, result feedback, and statistical reporting. The delivery rhythm connected requirements survey, architecture design, detailed design, coding, self-check, trial operation, third-party testing, and acceptance. The evidence layer ensured that each stage had documents, records, and conclusions.
The control framework was boundary, chain, rhythm, and evidence. Boundary controlled scope. Chain controlled role-to-role and network-zone continuity. Rhythm controlled the compressed schedule. Evidence made the final acceptance conclusion traceable.
Key Management Focus
The first focus was preventing uncontrolled scope expansion. The self-reporting module involved multiple reporting scenarios, data entry, review, query, statistics, submission, and backup. The mobile terminal involved authentication, permissions, notification, transfer, auxiliary tools, and field collection. The assistance module involved several access channels. Without a firm phase-two boundary, each channel could have generated additional workflow expectations.
The second focus was compatibility with the existing platform. The upgrade could not break existing users, organizations, permissions, databases, interfaces, or operational workflows. The public-facing intake process had to connect with internal handling, and internal results had to return to the external query side. A visible front-end feature would not be enough if the end-to-end service chain failed.
The third focus was balancing security and usability. The materials referred to hardware-key-style authentication, permission settings, controlled data exchange, logging, and operational alerts. These controls needed to be designed into the system early, but they also had to remain workable for field and back-office users.
The fourth focus was the compressed delivery sequence. Weekly records show requirement work and planning in mid-October, design review in the following week, start approval and coding in late October, trial operation around early November, and then third-party testing and acceptance preparation. That schedule left little room for late documentation or late test planning.
Key Challenges and Responses
The first challenge was the overlap of multiple access points, roles, and workflows. External participants, mobile users, back-office reviewers, management users, and technical operators all had different expectations. I managed requirements as role chains instead of as a screen list: who submits, who reviews, who handles, who replies, who reports, and who maintains the service.
The second challenge was controlled cross-boundary data exchange. The project had to support external intake, internal processing, and external result display without allowing public access channels to bypass the internal security environment. I required design documents to explain the data-exchange method, interface boundary, permission control, and exception-handling logic. Acceptance could not rely only on front-end demonstrations.
The third challenge was the short path from development to trial operation and third-party testing. Independent testing could only start after the system was ready, and its timing was not fully under project-team control. I therefore treated requirements confirmation, design review, self-check, trial-operation application, test preparation, training, and acceptance documents as a connected sequence rather than as separate end-stage tasks.
The fourth challenge was a real network issue during trial operation. It was not ignored as a minor incident. The impact was clarified, the contractor restored the service, and the later running status was observed and recorded. For a platform upgrade, trial operation is where compatibility and stability are validated under real conditions.
Schedule Management
Schedule management used weekly checkpoints. The first stage confirmed contract scope, overall planning, and requirements. The second stage covered system architecture, database table design, application logic, interface design, coding standards, detailed design, and UI design. The third stage moved through start approval and coding. The fourth stage entered trial operation. After that, the project summarized trial-operation results, contacted the testing organization, waited for test results, and prepared acceptance materials.
The scheduling challenge was the density of post-development activities: trial operation, user training, third-party testing, acceptance documents, user feedback, and final acceptance had to follow one another quickly. Weekly reports and special supervision reports fixed each milestone into the record, including plan review, start review, implementation completion, trial-operation reporting, training, feedback, and acceptance.
Quality Control
Quality control started with requirement and design consistency. The requirement analysis, outline design, detailed design, technical plan, schedule, and quality plan had to match the actual business process. In an upgrade project, a design mismatch can be more damaging than a coding defect because it can leave the service chain incomplete after launch.
Implementation quality was controlled through coding completion, self-check, trial operation, and third-party testing. After coding and self-check, the system entered trial operation. The supervision team monitored system status and issues. After third-party testing produced a qualified result, the project moved into acceptance preparation. The acceptance plan considered usability, stability, maintainability, flexibility, operability, security, documents, code discipline, and comments rather than only functional demonstration.
Training was part of quality control. Training covered self-reporting, the internal handling side, the mobile terminal, and multi-channel assistance. User feedback later emphasized continuing operations support and cooperation on future functional optimization, which indicates that the project required a post-handover maintenance discipline as well as initial delivery.
Risk and Change Control
The main risks were requirement misunderstanding, old-new platform incompatibility, unstable cross-boundary exchange, third-party testing schedule uncertainty, trial-operation incidents, delayed documentation, and insufficient post-handover support. Because the project cycle was short, risk control had to be embedded into each stage rather than postponed to final correction.
Requirement risk was controlled through role-chain mapping. Interface risk was controlled through technical design and trial operation. Schedule risk was controlled through weekly and special reports. Testing risk was reduced by preparing test and acceptance materials early. Operations risk was addressed through user feedback and handover documentation. The materials do not show a major scope change, but they do show a real trial-operation incident and post-handover optimization expectations, which makes the case more credible than a perfectly smooth delivery story.
Stakeholder and Interface Governance
The project involved the user organization, contractor, supervision team, and third-party testing organization. Early communication focused on requirements and design confirmation. Mid-stage coordination focused on coding progress and trial-operation status. Late-stage coordination focused on testing results, training, user feedback, and acceptance documents. My management emphasis was to convert discussions into confirmed documents, stage reports, and acceptance evidence.
Interface governance covered four areas: external access channels and platform business services, externally collected data and controlled exchange, internal processing and business databases, and mobile terminals with back-office permissions and notifications. The public version does not expose actual system names, addresses, topology, or interface details, but these interfaces were central to the management problem.
Acceptance Evidence and Handover
The acceptance evidence included requirement analysis, outline design, detailed design, technical design, schedule, quality plan, development summary, acceptance plan, trial-operation records, training materials, user feedback, third-party testing, handover list, and final acceptance report. The final acceptance conclusion stated that the contracted scope had been completed, the acceptance documents were complete, and the project met quality requirements.
I treated acceptance as three judgments. First, functional scope: whether self-reporting, mobile management, and multi-channel assistance were delivered. Second, operational status: whether trial operation was acceptable, the network incident had been resolved, and third-party testing was qualified. Third, maintainability evidence: whether user manuals, system administration materials, database documents, data dictionary, operation documents, training records, and handover lists were available.
The source materials also include supplementary acceptance items covering an online payment module and an internet SMS-interface adjustment. In this public case, I treat them as follow-up capability supplements. They show that the platform continued to be refined after the main delivery, and that additional capabilities also needed contract, test, documentation, and acceptance closure.
Project Result and Lessons Learned
The project completed the second-phase upgrade of an existing public service collaboration platform. It delivered self-service reporting, mobile management, and multi-channel assistance capabilities, and completed training, trial operation, third-party testing, user feedback, and acceptance. A network issue during trial operation was resolved, the test result was qualified, and the acceptance evidence package was complete. The key lesson is that an upgrade project should not be managed as a set of new screens. The real risks are unclear boundary, broken service chain, uncontrolled interface, shallow trial operation, and weak evidence. Effective management connects requirements, design, development, trial operation, testing, training, feedback, and acceptance into one closure path.