Elijah Agile Delivery

Re-Baselining Delivery for an Urban Intelligent Traffic Control System

Executive Summary

This anonymized urban intelligent traffic control system project was a typical city-level digital transportation infrastructure project. It covered a command center, communication subsystem, traffic signal control, traffic video monitoring, traffic event monitoring and recording, road vehicle monitoring, traffic guidance, dedicated vehicle positioning, and traffic flow collection. The project included both central platform construction and a large number of field facilities deployed across intersections and corridors.

The delivery approach was built around long-cycle re-baselining, joint design review, phased implementation, and acceptance-driven planning. The original plan had to be recalibrated because technical standards had changed, some equipment had been replaced or discontinued, field conditions had evolved, and multi-system integration had become more complex. The project team converted that uncertainty into an implementable, acceptable, and extensible delivery plan. Design review materials, equipment statistics, commencement records, engineering notices, and issue-closure evidence supported final acceptance readiness.

Project Background

The project served the improvement of urban road traffic management capabilities. The owner and user organizations have been anonymized. It was not a single information system or a single field-device project. It was an integrated system covering central platforms, communication networks, field intersections, business applications, and acceptance documentation.

The project could be divided into two major parts: central facilities and field facilities. The central part included the command hall, central equipment room, servers, storage, switching equipment, large-screen display, platform software, and coordinated operations environment. The field part included traffic signal control, traffic video monitoring, traffic event monitoring and recording, road vehicle monitoring, traffic flow collection, and traffic guidance devices deployed at intersections and field sections.

The main subsystems included:

  • Command center supporting facilities.
  • Communication subsystem.
  • Front-end control subsystem.
  • Traffic traffic video monitoring subsystem.
  • Event monitoring and recording subsystem.
  • Field object monitoring and recording subsystem.
  • Information publishing subsystem.
  • Dedicated object positioning subsystem.
  • Flow collection subsystem.

The overall project manager had to manage contracts, technology, schedule, intersection implementation, equipment arrival, integration testing, documentation, and acceptance organization at the same time. The challenge was not whether one subsystem had been installed, but whether all subsystems could form a complete loop for information collection, transmission, analysis, control, and display in real traffic management scenarios.

Main Challenges

1. Long Construction Cycle Required Technical Re-Baselining

The project went through a long period from early procurement and contract activation to substantive implementation. During this period, electronic devices, image capture, storage, GIS platforms, communication architecture, and industry standards changed significantly. Some originally planned equipment was discontinued or upgraded, and some design concepts no longer fully matched updated operational requirements.

If the early solution had been executed mechanically, the project could have faced two risks: equipment might be purchasable but technically outdated, or it might comply with the contract but fail to meet future use and expansion requirements. Therefore, the project had to use joint design and expert review to re-baseline the original solution.

2. Multiple Subsystems Had to Be Unified at the Center

The project was not simply about installing equipment at intersections. Signal control, traffic video monitoring, road vehicle monitoring, traffic event monitoring and recording, traffic guidance, traffic flow collection, and vehicle positioning all had to connect to the central platform through the communication network and form unified display, dispatch, and management capabilities in the command center.

This meant project management could not proceed only by equipment lists. It had to proceed by data links: whether field devices could collect data, whether the network could transmit it, whether the center could receive it, whether the platform could process it, whether the large screen and applications could display it, and whether business users could operate it.

3. Changing Field Conditions Affected Equipment and Civil Works

During implementation, some intersections were affected by road widening, municipal construction, and changing site conditions. Lane numbers, poles, foundations, conduits, and device layouts all required adjustment. Records showed that some locations could reuse existing conduits and poles, while others required new construction or modification.

If these changes were not managed in a unified ledger, equipment lists, drawings, field implementation, and acceptance scope could easily diverge. The project had to treat each intersection as a small delivery unit and confirm equipment, foundations, cabling, power supply, communication, and platform access point by point.

4. Upgrade From Standard Definition to High Definition Required Link and Storage Redesign

One important technical adjustment was the upgrade from a standard-definition solution to high-definition capture and display. Event evidence capture, speed detection, road vehicle monitoring, and traffic video monitoring all involved front-end device upgrades. Display equipment and storage architecture also had to be adjusted accordingly.

High-definition upgrading was not just camera replacement. It affected bandwidth, storage, decoding, display, platform processing, and later maintenance. If only front-end devices were replaced without redesigning transmission and storage links, the system could suffer from network congestion, storage pressure, or poor display quality.

5. Broad Acceptance Scope Required Testing and Documentation in Parallel

Acceptance test materials show that the project combined centralized meetings with on-site inspection to evaluate the overall system operation and equipment installation. The team sampled field devices, central equipment, video images, captured event images, vehicle positioning, operations flow detection, and platform functions.

This means acceptance was not merely a check of whether devices had been installed. It had to verify whether the system worked, whether data reached the center, whether the platform displayed it, and whether business functions were effective. Engineering documentation, concealed work records, equipment statistics, and test reports also had to be collected in parallel.

Management Approach: Four Reconfigurations for a Long-Cycle Project

The core experience of this project can be summarized as four reconfigurations: solution reconfiguration, scope reconfiguration, schedule reconfiguration, and acceptance reconfiguration.

1. Solution Reconfiguration: Use Joint Design Instead of Mechanical Execution

Through joint design, expert review, and multi-party coordination, the project adjusted technical solutions in the original contract and supplementary agreements. Under overall price control, the project recalibrated discontinued equipment, high-definition upgrades, GIS platform selection, communication architecture, supporting civil works, and selected subsystems.

This approach mattered because it did not simply reject the original contract or allow unlimited scope expansion. It created an executable balance among contract constraints, technical reality, and business goals.

2. Scope Reconfiguration: Control Change Through Equivalent Substitution and Functional Improvement

Records show that discontinued equipment was replaced, and event capture, speed detection, road vehicle monitoring, traffic video monitoring, storage, and display systems were upgraded. At the same time, some less applicable or less business-relevant items were cancelled or adjusted.

From a project management perspective, this was not a simple addition or deletion. It was scope reconfiguration: limited investment was shifted from lower-value or unsuitable parts to areas better aligned with current standards and operational needs. A new execution list became the basis for implementation, acceptance, and payment.

3. Schedule Reconfiguration: Organize Milestones by Key Intersections and Platform Demonstration

In addition to overall completion targets, schedule management used key intersections, key subsystems, and central platform demonstration as stage goals. Some meetings required selected intersections to be completed first and their road conditions and subsystem operation to be displayed on the platform.

This approach decomposed a large city-level system into stage results that could be demonstrated, tested, and accepted. Closing a first batch of intersections end to end before scaling to more points made it easier to find issues and stabilize delivery.

4. Acceptance Reconfiguration: Move From Document Acceptance to Functional Sampling and Scenario Verification

Acceptance combined central-side inspection with field sampling. At the center, the team checked servers, platforms, large-screen display, and business functions. In the field, the team sampled front-end equipment installation and checked video images, captured images, vehicle positioning, operations flow detection, and platform functions.

This shifted the project outcome from installed equipment to usable functions. For a city-level intelligent operations system, the true acceptance criterion is not device quantity. It is whether the system can stably collect, transmit, process, display, and support operational decisions.

Issue Closure Examples

1. Nonconforming Roadside Manhole Covers

During early construction, some manhole and handhole covers installed for cable routing and road excavation did not meet quality requirements. The project team coordinated discussion, inspection, testing, and rectification, driving replacement of nonconforming covers with qualified ones.

This issue may appear to be a civil-work detail, but it directly affects long-term operation and road safety. Field works for an urban operations system must withstand long-term exposure, vehicle passage, rainwater, and maintenance operations, so management cannot focus only on electronic devices.

2. Equipment and Platform Adjustment Caused by Technical Standard Changes

Because of the long project cycle, some equipment was discontinued and some technical routes no longer fit updated industry standards or business needs. Through multi-party coordination, the project upgraded relevant equipment, adjusted storage and communication architecture, and adopted platform technology better suited for future interconnection.

The key point was not change itself. The key was that each change had a basis, boundary, substitution logic, and acceptance criterion. This helped avoid the common long-cycle project problem of uncontrolled scope expansion combined with outdated technology.

Project Results

The project ultimately produced a relatively complete set of construction and management outcomes:

  • Construction scope: command center, communication, traffic signal control, traffic video monitoring, traffic event monitoring and recording, road road vehicle monitoring, traffic guidance, dedicated vehicle positioning, and traffic flow collection subsystems were completed.
  • Investment control: the project had a large contract scale, and technical adjustment and scope reconfiguration were completed under overall investment constraints.
  • Process documentation: more than 10 coordination minutes, over 60 project progress records, a special equipment statistics report, commencement records, and multiple engineering notices were produced.
  • Testing and acceptance: field devices, central platform, video images, event images, vehicle positioning, operations flow detection, and software platform functions were sampled and verified.
  • Quality result: project documentation was complete and valid; after testing and trial operation, the system met contractual and relevant technical requirements and was ready for routine operation.
  • Delivery result: the project was completed in the a later delivery stage and was ready for formal acceptance.

Reusable Lessons

1. Long-Cycle Information Projects Must Be Re-Baselined Regularly

A solution that was advanced at contract signing may become outdated several years later. Project managers need technical review and solution re-baselining before key implementation stages to realign contract goals, technical reality, and business needs.

2. City-Level Systems Should Be Managed by End-to-End Links

Field devices, communication networks, central platforms, display systems, and business applications must form a complete loop. Managing only equipment installation quantity cannot guarantee system usability. The full data link from collection to display must be managed.

3. Change Control Should Focus on Equivalence, Necessity, and Acceptability

Technical adjustment is not inherently risky. The key is to explain the necessity, substitution relationship, investment impact, and acceptance basis for each adjustment. This prevents change from becoming uncontrolled scope growth and prevents old solutions from causing repeated investment.

4. Field Devices Should Be Delivered by Site Unit

Urban road sites are distributed and highly variable. Treating each intersection or road section as a delivery unit, and confirming foundation, pole, cable, power, communication, device, platform access, and test results point by point, is more reliable than counting devices by category.

5. Acceptance Should Cover Function, Performance, Documentation, and Maintainability

Acceptance of an intelligent operations system cannot stop at whether devices power on. It must include image quality, recognition effectiveness, platform display, data transmission, fault detection, documentation completeness, and maintainability. The earlier the acceptance framework is established, the more stable the final delivery will be.

Conclusion

This anonymized urban intelligent traffic control system project is useful because it shows how a long-cycle infrastructure project can be brought back under control after technology, equipment, and field conditions have changed.

Facing changing technical standards, equipment upgrades, evolving intersection conditions, and multi-system integration pressure, the project manager used joint design review, scope reconfiguration, stage goals, quality sampling, and acceptance back-planning to turn distributed equipment work into an integrated system supporting urban traffic management. The central lesson is that complex information infrastructure projects cannot always execute an old plan unchanged. Effective project management keeps goals, technology, and delivery paths aligned within contract constraints, so the project remains controllable, acceptable, and sustainable as conditions change.