The deployment of WiFi network billing systems is clearly scheduled in terms of the project's installation, configuration, configration, and up-link phases. But those who actually did the projects know that what was not written in the plan was the most delayed schedule. The supplier's engineers were here for two weeks, and it was not technical problems that got stuck, but a department failed to cooperate, a network had no access, and a interface system never gave an interface file. These hidden resistances do not appear in the creation report, but almost every project encountered during deployment, knowing much better than ad hoc responses.
Category I resistance: grey areas of cross-sectoral collaboration
The WiFi network billing system involves a number of departments, such as network centres, information centres, financial services, schoolworks, logistics. The most common cases are: network centres for network equipment and certification, treasury for billing strategies and fee matching, student account data in the school manual, and routing of accommodation areas in logistics. Each department feels that its own piece is no problem but that the connecting part is not. For example, after the change in the student account status, the CS has updated its system, but the WiFi network billing system is not synchronized, resulting in graduates remaining online from post-school accounts. The project must be initiated with a cross-section of data streams and operating processes, each interface point identifying the responsible person, without default"They know what to do."。
Category II Resistance: compatibility traps for older equipment
When WiFi network billing systems are deployed, multigenerational combinations of network equipment often occur in schools. The newly procured AP supports 802.1X and Portal certification, but the old switchboard may not support RADIFUS authentication or port isolation, and some areas are still using the old AC controller. The vendor uses all new equipment for PoC testing, everything's normal, but when it is officially deployed, the authentication process starts to pose strange problems.——Some end-uses can be certified but not connected to the Internet, some end-point intermittently fall off or some regional certification pages cannot be released. Checking such problems is extremely time-consuming because they are not in the system itself, but in terms of compatibility with bottom equipment. A full inventory of equipment must be performed before deployment, listing equipment that does not support key protocols, either upgrade them or make special treatment in a costing strategy.
Third type of resistance: inertia in user habits
WiFi network billing system is online, and user habits have to change. Even WiFi did not need authentication, now has a code for the account; there were no previous traffic restrictions, now there are set-up limits; and there are now overcharges. These changes are down for users, whose first response is complaining, regardless of how well the system works. If you don't communicate with them, the phone calls on the line will be blown up on the day. More problematic, some users try to bypass certification in any way.——Use another person’s account, modify the MAC address, and look for a system leak. These actions are pre-judged during deployment, and accompanying measures are prepared: user-directed documents, guest speech, and non-compliance strategy.
The underlying cause of the hidden resistance is that the project boundary is not clear.
The three types of resistance appear to be different.——The project boundary is not clear. The WiFi network billing system is created as a stand-alone project, with no connection to the software itself, regardless of its compatibility with the surrounding system, and irrespective of user custom change. The project boundary is clearly drawn, what is required for this project to be done, what other departments need to work with, and what risks are predefined, and deployment will take place without any disruptions.
The communication rhythm of the deployment phase is more important than the technology programme
There are a lot of WiFi network billing systems deployments, technology options are fine and finally stuck in communication. Some department doesn't know the system is going online, their own data are not ready; some docking system owner is on mission and no interface is confirmed; users have no idea about changing passwords and large access login failed on the same day.——Weekly cross-sectoral coordination meetings, synchronized deployments every day and user briefings two weeks before being online. Communication appears to be soft work, but in multisector, multisystemic projects it often decides more than technical programmes to succeed or fail.
The trial period is the best window to expose hidden resistance.
No matter how well prepared the pre-run is, WiFi will reveal unexpected problems when it gets online. The trial period is not an overflight but a window that really exposes hidden resistance. The test period is a quick feedback mechanism that allows users to report problems and enable transport to be quickly located and repaired.——Some are compatible with equipment, some are cross-cutting data streams, and some are user habits."System instability"That's it. This phase is done carefully and the accident rate will be reduced considerably after the official operation.