Why Public-Sector AV Projects Stall Before Installation Begins

The display and camera are approved. Then the network team asks for a security review. Facilities finds there is no backing in the wall. The clerk explains the recording must feed the public records archive. Communications needs broadcast graphics. Procurement says the new work cannot be added to the current purchase.

These issues all point to the same problem: weak project governance.

Public sector AV brings together buildings, networks, public service, accessibility, records, security, purchasing, and daily operations. The project should reflect that from the start.

Start with a service plan

Before design begins, write a short plan that defines the public or business service, locations, users, required outcomes, limits, funding source, target date, and project sponsor.

For a council chamber, those outcomes may include clear speech in the room, hybrid meetings, captions, voting or agenda system integration, recording, streaming, archived media, assistive listening, simple operator controls, and a documented backup plan.

State what is outside the project scope. Clear limits prevent confusion later.

Bring the right people together

Create a working group with people who can make decisions:

  • Program owner or executive sponsor
  • IT infrastructure and identity
  • Cybersecurity and privacy
  • Facilities, construction, electrical, and furniture
  • Clerk, records, or court administration
  • Communications, broadcast, or public information
  • Accessibility or ADA coordinator
  • Procurement, finance, and legal
  • AV operations, help desk, and end users
  • Integrator and design partners

Not everyone needs to attend every meeting. Each area should have one named reviewer, a deadline for decisions, and a clear path to resolve issues.

Build a responsibility matrix

Assign who is responsible, accountable, consulted, and informed for requirements, network approval, security, accessibility, construction, purchasing, user testing, training, records, support, and project closeout.

Virginia organizations can use the VITA policy library as a reference. Each organization should decide which policies apply and record those decisions. Do not expect the installer to make that call.

Use decision gates

Require approval before moving to the next stage.

Requirements gate

Approve user needs, accessibility, recording and streaming, security, backup plans, project scope, and success measures.

Design gate

Approve drawings, signal flow, network design, control behavior, room conditions, equipment, and project dependencies.

Procurement gate

Confirm purchasing authority, competition rules, contract scope, funding, evaluation criteria, approved substitutions, cybersecurity terms, documentation, warranties, and schedule. VIcom’s contract vehicles may help, but procurement staff should confirm they apply.

Site readiness gate

Confirm power, network, pathways, wall backing, furniture, lighting, acoustics, access, permits, hazardous material plans, and shutdown windows.

Acceptance gate

Test the full workflow, including accessibility, security, recording, remote participation, recovery, documentation, training, and support.

Define the connections between systems

Most project risk sits where systems meet. Document who owns each connection, including room control and lighting, microphones and streaming, agenda software and displays, recording and archives, captioning services and meeting platforms, room accounts and identity systems, and devices and monitoring tools.

For every connection, record the inputs, outputs, method, data involved, expected behavior if it fails, test owner, and vendor responsibility. If you write “by others,” name those people and include a delivery date.

Include operations in the project requirements

Require configuration files, administrator and user guides, asset lists, network requirements, software and license inventories, cleaning instructions, training, test plans, warranty details, support contacts, and end of life information.

Define support expectations and remote access rules. A reliable support plan matters just as much as the equipment.

Track changes

Late changes sometimes make sense. Record why the change is needed, its cost, schedule impact, security and accessibility impact, related design changes, and who approved it. Do not let field changes become permanent without documentation.

Keep a decision log. Staff and vendors change over time. A clear record explains why important choices were made.

Test with a real meeting

Run a full rehearsal with the chair, clerk, operator, presenter, public commenter, remote participant, captioning team, and support staff. Test common failures, including a bad microphone, a missing presenter, a lost network connection, a late document, and a recording failure.

Accept the system only after it completes the full workflow. Track every remaining issue, assign an owner, and retest when fixes are complete.

Review after launch

After deployment, review incidents, user feedback, accessibility requests, security notices, software updates, and long term maintenance. Keep the working group small, but keep ownership clear. Schedule regular recovery tests and a yearly service review.

VIcom helps public organizations plan projects, coordinate AV, UC, network, and building requirements, prepare systems before installation, deploy through approved purchasing methods, document acceptance, and support day to day operations. Good governance helps teams make key decisions early, when they cost the least to fix.

Use a simple governance dashboard

Track pending decisions, unresolved system connections, site readiness, purchasing milestones, project risks, approved changes, acceptance results, and the owner for each item. A project can look almost finished while key meeting functions still have not been tested.

Set a deadline for open decisions. If a network exception, accessibility need, archive connection, or furniture decision remains unresolved past that date, raise it with the project sponsor along with the cost and schedule impact. Do not treat silence as approval.

When the project ends, hold a lessons learned meeting before the team moves on. Record which requirements arrived late, which reviews caused rework, which tests found real problems, and what contract language should change next time.

That record becomes the starting point for the next project. Public organizations should build on what they learn instead of solving the same problems again for every council chamber, courtroom, training room, or emergency operations space.

Connect with VIcom by filling out the form below.