TDWI | Training & Research | Business Intelligence, Analytics, Big Data, Data Warehousing

Avoid the Premature Release of Data Warehouse Software

Although we may be subject to intense pressure to meet implementation targets, we should make every effort to avoid treating our user community as beta testers or supplying users with inaccurate program prompts or user documentation.

• By Mike Schiff
• February 15, 2017

Most (if not all of us) have, at one time or another, used software with so many problems that we questioned how the app ever got released. We wondered if the developers were using us as beta, or even worse, alpha testers. As IT practitioners, we need to avoid placing our user communities in this same situation.

The botched 2013 rollout of the Healthcare.gov website for the Affordable Care Act (aka Obamacare), with its capacity and integration issues, is perhaps the example that most Americans remember. It is, unfortunately, not an isolated phenomenon.

Software users can cite unexpected problems with operating system updates, productivity tools, smartphones, smart televisions, and applications ranging from tax preparation software to computer games. Most organizations will pretest new software or major updates before placing vendor-supplied systems into production to avoid (or at least become aware of) potential problems.

Reasons for Incomplete Software Release

There are several reasons why premature versions of software might be released. These include the vendor's desire to beat a competitor to market, to catch up with a competitor that has already released an improved version of its product, or to meet contractual obligations and avoid late delivery penalties. It may also occur when it is necessary to fix a major problem associated with a prior release.

However, another reason that applications are released prematurely (and I have observed this more times than I care to remember) is simply to further a manager's career and/or allow a manager to earn a bonus for meeting a target delivery date. Many of us can relate to this and cite stories about colleagues (or perhaps even ourselves) who have been pressured by bosses who strongly advised them to "release the software by this date, no matter what; we can always issue a patch to fix any problems later."

One of the worst examples I observed was the forced release of a clearly preproduction version of software for the company's own internal use. An IT-illiterate manager threatened to fire the development manager if he did not sign off on the release. The manager received his year-end bonus, which was highly dependent on an on-time release, and left the company for a new job less than one month later.

He left behind a system with enough problems that it was ultimately scrapped. It could not be fixed by the development team as they were so disillusioned that most of them, including the development manager who became the scapegoat for the failed implementation, had voluntarily left the company for new jobs.

Avoid Release Problems with Communication and Collaboration

Assuming it would not place our employment at risk (and perhaps we should actively seek other employment if it would), we need to proactively take steps to avoid the premature release of our software efforts. At the very least we need to make our managers aware of any concerns we have prior to live implementations and propose alternative solutions. This can range from postponing implementation to moving some functionality or requested data sources to a future release.

Successful data warehouses result from close collaboration among user representatives and IT developers and analysts. User representatives should always be aware of our progress and any associated issues and perhaps be active participants in our beta tests that by definition involve actual real-world users. I also recommend that we beta test new versions of any vendor-supplied BI tools prior to their general release to our user communities.

Make Sure to Test Documentation

Many of us have experienced situations where the program prompts or user documentation were incorrect (e.g., a prompt reads, "enter dates in MMDDYY format," but the program rejects dates unless slashes are included). This may not be caught in an alpha test because the testers are familiar with the system and sometimes gloss over any prompts and documentation. Consequently, the beta test should also test any program prompts, embedded instructions, and written documentation.

This is especially true with new releases of programs where even though the functionality may be fine, some of the documentation and prompts may not have been updated from the prior release. Yes, we all know that a system isn't complete if it hasn't been accurately documented; however, we also know that in a crunch, incomplete documentation may not be a showstopper.

Keep Your Users' Confidence

If informed in advance, most of our users understand that not all implementation goals are always met, but they will be less forgiving if they are surprised by erroneous results or analyses that can result in incorrect business decisions as well as a loss of confidence in the data warehouse and its development team.

Once lost, this confidence is hard to restore, especially if the user community realizes that improperly tested software was prematurely released for general use without any warning about known problems and issues. Furthermore, as users can be easily frustrated by incorrect program prompts and erroneous documentation, we need to ensure that they are tested and validated prior to general release.