Unless you don’t watch any TV–or possibly live in a cave–then you know that in mid-February, traditional over-the-air television broadcasts will end and that consumers who rely on antennas to get their TV will need to buy either a new TV with a digital tuner, or a digital converter box.
To help with this change, the government took a small portion of the money it made from the spectrum auction and launched a coupon program to provide $40 to any citizen who needed to purchase a converter box (which tend to run from $50 to $60). Now, because of poor planning, some fraud and traditional government waste, the coupon program is running out of money, and many people who need converters won’t be able to get coupons before the analog signals go dark in February.
There are plenty of consumer angles to this story, but the part I find interesting is its lesson in poor planning, a lesson that can also be valuable to developers and IT managers.
The government clearly underestimated the number of people who would need or want these converters. It’s clear that government officials just looked at the number of people who don’t get cable or satellite, and set the program based on that number. Also, they clearly assumed that people would buy new TVs and didn’t anticipate the poor economy or the simple fact that many people are perfectly happy with older televisions.
But there are many reasons why these numbers were wrong. First, like me, many people may have satellite in one room but don’t find it worth the effort to run it to a bedroom TV that’s used less often. People have TVs in RVs and vacation homes that don’t get cable or satellite, and some people may just want to know that they have a backup in case their cable or satellite connection fails.
In short, this is an example of program officials who clearly didn’t understand the potential reach and use scenarios of the product they were offering. This situation isn’t unfamiliar in companies.
How many times have you seen an application designed for one specific department of a business end up being used by other employees? For example, a collaboration application built to help developers with project management is seen by salespeople, who ask if they can use it for risk management and their meetings. These situations happen all the time, and it can be hard to say no to departments that want to use an application if the application has the potential to improve productivity and save money.
This can also cause headaches if the original development and planning didn’t anticipate multiple units using the application. Maybe the security system isn’t set up to silo off different departments so they can’t view and access what other departments are working on. Maybe the application isn’t designed to scale to larger numbers of users. Of course, once other units start using the application, they will ask for features that weren’t anticipated in the original design.
So it’s a good idea during the original planning phase of any application to make sure other stakeholders at least have an idea of the program being built. The early information can be key to determining if an application will expand beyond its original intended user base. Having this information at the beginning of development also will go a long way toward reducing potential headaches down the road, making it easier to expand the application to new users.
Otherwise you might end up like the government’s digital TV program, with a lot of unhappy users and the potential for things to go dark. And in the case of business applications, the consequences would be worse than just losing your TV signal.