In a recent article, we asked you to send us your most frustrating Web development experience. Those experiences chosen as most frustrating by our panel of judges received some free stuff from Builder.
More about our contest
Check out the original article, "Turn your most frustrating Web development experience into free software," to find out more about the contest rules. And read this article about our fifth place winner, Juan Romero.
Our fourth place winner, Scott Atherton, shares the trials and tribulations he faced developing an intranet site for an insurance company. His story is an example of what can happen when the expectations of management outstrip the practicalities that can actually be delivered by the development team. The importance of getting everyone involved in the project on the same page cannot be overemphasized. For sharing his frustrating experience with us, Scott received a Builder.com T-shirt. Here is his story
Scott Atherton's development challenge
My toughest Web project was setting up a reference and training material intranet site for a large insurance company.
I had been hired as a project manager for Web development, and was in the process of setting up an intranet. We had only one server and it was four years old. I was creating development requirements, working with the standards board on software and hardware requirements, and trying to build a competent staff. In other words, nothing really existed except the desire to have an intranet.
A vice president in the company had seen a presentation by a major e-commerce provider about how they used their intranet to provide training and information to their phone reps. We flew to their facility, met with their management team, and went through a two-hour presentation. There were lots of bells and whistles, and much of the content and training modules were being managed by an outside vendor. On the return trip, I was told to create a prototype of something like what we'd seen, customized to our needs, and I was given a six-week deadline.
I was assigned one business analyst to assist with gathering requirements and content. At this point I had one Web developer contractor and two untrained analysts who wanted to be Web developers (and who proved to be less than adequate).
The site involved delivery of frequent alerts and reference content updated daily and sometimes hourly, as well as content created and delivered to individuals and small groups. Training modules were also required with testing and grading capability. Minimal requirements were given, and immediate research ensued to figure out how to accomplish this seemingly impossible task.
Servers were scrounged from anywhere we could find them, and our network administrators became Web server administrators. Many interesting situations occurred as they struggled with IIS. Our Oracle database administrators were pressed into service to handle the individual recognition and content delivery. Both analysts proved to be less than competent, and were moved back to their original tasks. This left me and a new contractor to complete the prototype.
During this time, the vice president driving the project was transferred to a different position, and control of the project was moved down to a lower-level manager with little understanding of the scope of the project. We threw together a fairly static site, complete with content, administration tools, and two graded training modules. Only minor database connectivity was possible due to lack of personnel and time constraints. During the six weeks, ideas and concepts from the business side changed daily, and we struggled to keep up with the delivery schedule and scope creep.
All content had to be entered and updated manually. Extensive OCR use ensued to get some of the printed content into electronic format. No one seemed to be able to determine how the original documents were created or who created them. Most of the site's material was made up of static simulations of how the site would operate if connected to a working database.
On completion, the prototype site was unveiled to loud acclaim and ambitious projections of the money to be saved by eliminating paper and training manuals from the desk. This was followed immediately by the command to put the prototype site into production the following week. I progressed from explaining the meaning of the word "prototype," to demonstrating that the pages were not actually hooked to a database and the displayed results did not change no matter what search terms were used. Then a heated discussion began involving how I had wasted those six weeks creating a nonfunctioning Web site, and then I made a firm refusal on my part to allow the site to be used.
Fortunately, I received backing from my manager and the IT director. A production version was created over a period of four months and rolled out, with further enhancements scheduled over the next six months. One year later, the paper manuals still remain and are regularly updated, as well as the intranet site. Some murmuring is being heard about how expensive the site is, and if it was eliminated, how much money would be saved. Meanwhile, I am now working on another prototype intranet site.
What makes a prototype?
Obviously, Scott had to overcome some terminology barriers during the development process. Have you had to explain what "prototype" means during a project? Did you have the backing of your supervisor or IT director on that occasion? Can you top Scott's story? Share your experience with us in the article discussion below.
Mark W. Kaelin has been writing and editing stories about the IT industry, gadgets, finance, accounting, and tech-life for more than 25 years. Most recently, he has been a regular contributor to BreakingModern.com, aNewDomain.net, and TechRepublic.