The key problem for Virtual U was that schedule and organizational issues hampered its ability to finish strongly and on time. Schedule delays are impossible to blame on one factor, but overall the inexperience with the complexities associated with this type of project resulted in some organizational problems exacerbated by many of the specific factors. Those factors included:

Use of a development team that was stretched thin
Enlight was an extremely capable and experienced company, but as Virtual U dragged on, other projects within the company began to compete and take time away from Virtual U. Furthermore, developer turnover within Enlight at key points of the process damaged team continuity and delayed the project several months as new developers assigned to the project had to get up to speed with the existing code.

This is a problem many projects face because often, only a few programmers will work on a specific project so the loss of any member during development will inevitably cause delays. To combat this, it's important for the coding and development process to stay extremely organized which is a responsibility of all involved, not just the development team.

The model and simulation engine took too much precedence
The strongest facet of Virtual U is its underlying model. This model, however, took too much precedence in the project to the point where less than desirable game aspects for Virtual U were brought forth. Virtual U's scenarios were planned after simulations development had begun instead of earlier where simulation features could have been planned in advance to support the scenarios envisioned by the designers. Aside from specific scenario tasks, Virtual U only features one way to lose the game - bankruptcy. This severely reduces the challenges facing the user in the game, and thus reduces the overall playability.

There is no doubt that Virtual U is a game: it has challenges, the player controls the outcome, and it looks and feels like a standard computer game. However, the initial development planning missed the potential for VU to have a more coherent and complete game premise. Subsequently, with limited time and budget left when these issues were raised there was only so much game goals and play that could make it in the final stage of development. Much like the garbage in - garbage out metaphor, the more game in the plan at the beginning of the process, the more game out at the end.

The complexity of the software created obstacles to wider use
Not every game is easy to use. While the argument that a game interface and motif makes it more enjoyable and easier to use than an inherently statistical simulation or model, no interface can hide the underlying complexity of the subject matter unless the overall simulation is watered down. Water down a simulation too much and it's overall realism, purpose and/or educational value may be irreparably harmed.

While it's hard to categorize it as something completely wrong with the end result of version 1.0, Virtual U suffers from a complexity problem. In order to begin instigating more pronounced and interesting policy moves, it takes a user as much as three or four hours to properly acclimate themselves to the simulation. Even with all of its documentation the game is more suited for one that moves at a slow pace, and has a steep learning curve.

Much of VU's complexity may have to do with its concept and content rather than any outright failure of design. If anything, the design has taken a very complex subject and made it infinitely more accessible to its users. However, by categorizing VU's overall complexity as a failure the design and development team feels it can do much better. This includes improving feedback mechanisms for the player, improving the model itself, and improving documentation. Furthermore, the project has begun listing trainers among VU's more experienced user base to help those who need more personal one-on-one training with the product as well as providing paid one-on-one training by the project team itself.

Initial assumption of user mix for the product was not correct
VU's initial priority target users were presidents, provosts, and deans of United States-based universities. Unfortunately, this group is also among the busiest, so sales to and impact on this group has been lower than expected. Conversely exposure and impact on students, lower-level administrators, faculty, and department chairs has been higher than expected. To adjust for this, the project has focused its efforts on lower-level administrators in its direct mailings, as well as professors and students of education. To keep the goal of reaching out to presidents and other upper-level managers, the project has tried to arrange for demonstrations and interactive sessions at various presidential conferences, workshops, and retreats.

The lesson here is that many times models and simulations are built with the hope of educating and impacting very high-level targets. Unfortunately the combination of limited computer access, skills, and available time usually hinders the ability for personal one-on-one exposure to the software. Even the novelty and ease-of-use of a game might not be enough to overcome these obstacles. Instead, personalized demonstrations are best, especially at times that have already been set aside for exposure to new ideas such as conferences and workshops. In some cases, getting that first important exposure has resulted in personal orders for themselves and staff.

next >