Transform a Prototype Into Final Product

Reading: Transform a prototype into final product

Transform a prototype into final product

Inside this reading:

Revisions

Planned change

Unforseen change and contingency clauses

Mastering

Delivery and installation

Delivering on CD and DVD

Packaging

Support materials

Handover—training

Final sign-off

Final agreements

Summary

Revisions

Planned change

There is little point having tests or trials, if the development team, being overly-optimistic about getting everything right the first time, has no budget or time to make necessary production and programming revisions. Enough time and funds must be allowed for this.

Revisions requested by test users may prove to be major. Such revisions are not only costly—but at the end of what may have been an exhausting project, can be deflating.

Unforseen change and contingency clauses

It can be particularly difficult in a very long project if industry, technical or production quality standards have evolved or been upgraded, requiring you to create new content. Such things can happen, for instance, in companies that are sold to larger companies or merged. Broader corporate decisions can create big hurdles for completing projects on time. Note that it is wise to insert clauses in projected timetables that unforseen changes outside the control of the developer (such as industrial relations disputes, company restructures and staff rotations) may delay the final delivery date.

Managing such situations requires skill and the developer’s role here is to maintain team motivation and explain to all stakeholders the processes that need to be followed that will resolve the problems and/or complete the product.

Mastering

Mastering is when an image is made of the final product to replicate or distribute it. This is only done after all testing and revision. If the master is made to distribute a CD or DVD, it might be done internally or by an outside printing service, depending on the nature and size of the project and on any skills and equipment in-house.

If the master is to be copied from the development web environment to a production web environment, it’s a much simpler process.

The following things should occur when preparing digital materials for the creation of the master file.

The complete program, including any digital support materials (‘read-me’ files) and any fonts or system extensions to be bundled must be copied to a development hard disk
Final tests completed to ensure the program will run and display correctly should be collected together on the same volume.
Files should be re-checked to ensure there are no flaws (viruses or corruptions).
A destination site of adequate capacity to contain the final disk image should be prepared. The destination site might be on an external hard drive, or more often simply a CD or DVD.
Finally, the program with all its files should be copied to the destination site.

Usually, one or more test disks produced by the printing service are returned for approval before replication of the full production run. These disks are thoroughly checked by the user group before final approval.

Delivery and installation

Where in the past most final versions were delivered to users on auto-run CDs, now most packages are designed for company intranets or the web, with a hybrid CD or DVD backups.

Whatever the delivery site, the developer needs to ensure the process is a simple one, especially if thousands of CDs or DVDs are going to print to be mailed out to users.

Using installer programs is useful, or even for remote users, utilising compressed self extracting exe programs to place the files in specific directories for users. These tools regularly help with delivery to users located in distant locations.

In addition, supporting documentation and install instructions have to be clear, simple and virtually foolproof. The team doesn’t want to go to all the effort of building a fantastic multimedia tool, only to have it sitting in a CD rack where a user finds it too hard to install.

Delivering on CD and DVD

There are many standards with CD and DVD that may affect successful delivery.

CD technology

Here are some of the issues relating to CD delivery:

1CDs can be burnt or copied from a glass master (this fact influences cost in small print runs of under 1000)

2CDs come in CD-R and CD-RW (CD-R is excellent for multimedia distribution as it is cheap, reliable and most users have a CD player).

Standards include:

Red book (audio CDs)
White book (video CDs)
Yellow book (normal CD-ROM)

Green book (CD-I Interactivity)
Orange book (magneto-optical).

It’s important to recognise here that thorough beta testing must include installing and running the ‘end product’ on a large sample of proposed end user machines. (This also becomes more vital if any of the users have very old, low speeds such as a x4 CD player) as sometimes newer mediums do not recognise older ones.

You can learn more about these issues from the following websites.

Packaging

If the product is going to be sold, marketed to other areas, or if you just want to impress your end users, then packaging is important because such things as CD or DVD covers or printed jackets make for a vital first impression and give a sense of professional finish to the product.

Generally, this task is quite affordable, but the rule to keep in mind is that the more colours you use and the more artistic it is—the more it costs!

Graphic artists usually design in tools like Photoshop and supply final artwork to the printer. Most printers advise what format they want the files delivered in and they again do a mock up to gain approval from the client and developer before it goes to print.

The art should reflect the subject of the product and will often include a corporate logo to promote the management team’s efforts. Remember to include printed instructions or notes on an insert sleeve or back cover to assist the users.

The printing companies also have machinery that assembles the CD packets, labels them and shrink-wraps them. Most developers argue that printers do this job for less than half of the price and in a quarter of the time that the development team could do it. So generally this is a useful task to outsource!

In conclusion, for the time and effort spent on developing the product, professional packaging is a small-cost but high-impact marketing strategy.

Support materials

When the final product is complete, developing support materials needs special consideration and attention. The documentation is important in creating a professional feeling about the media product.

Support materials might include digital ‘Read me’ files, ‘help’ documentation, printed technical, training or user materials, user-licence agreements and copyright notices.

Often, the design of these materials is left as one of the last things to do, with the result that user documentation is sub-standard and does not do the job for which it is intended. In projects running behind schedule, software trails often taking place before support materials are produced. While to some this may be unsatisfactory and could compromise the reliability of trials, others feel that it is not wise to invest too much time on user manuals until the final product is 100% complete.

When developing the user manuals, remember that staff change in organisations and it is possible that someone new will have to pick up the manual and ‘run with it’. One tip is to utilise screen dumps, graphic displays and diagrams as much as possible to ensure the instructions are as simple as possible.

Also if at all possible, place the user manuals on an intranet or on the web. This makes it much easier to maintain version control.

Handover—training

Training staff on using and supporting the system is another ‘finishing off’ tasks that is often completed poorly.

As a developer, you want the system to work for the client and the business. No one wants the system to be functioning 100% until the day the development team packs up and leaves.

The best strategy is to submit a request for a local ‘champion’ to take over the administration of the future system. This person would need to be appointed in the early stages of prototyping. They need to be ‘onboard’ during development so to understand the system, be trained how to repair or rebuild the back end and to administer the system.

Depending on the licensing and support agreement, this person or persons would need to have comprehensive skills in a variety of areas of multimedia. The usual tasks are:

Completing updates (editing text, graphics, audio, etc)
Adding users to the system (if on the web)
Monitoring security
Producing more CDs or DVDs
Fixing bugs
Maintaining version control
Marketing
Providing user support
Assisting with training and presentations.

One mistake that developers make in this area is in miscalculating the time it takes to train someone to this level. Depending on the size of the project, experience suggests it could be months, whereas most project plans allocate a few days. Again, think holistically about the project.

Final sign-off

Final sign off is an important task that must be done with great thoroughness and vision. Sign-off acknowledges that the development stage is complete and that the final product can be released.

It cannot be emphasised strongly enough that before the concluding document is signed, the scope of the project is fully documented and explained. This is a major problem for multimedia developers as if this document is vague in any way, then it is hard to prove with any clarity whether the job is finished or not.

To protect the developer the detail in the document content must be very specific. If the detail is specific, then the jargon is often technical. And if the document is full of jargon, the client will not understand what they are signing.

Contracts, legal conditions, support documents and technical specifications in the computing world are presently a minefield. Unfortunately, as a developer you have to document what you think is appropriate for the environment you are in. It is suggested however that you strive to protect yourself and your development team from continually being asked to repair the product, when in fact the ‘repairs’ are more than likely amendments or errors that internal staff have made to the system.

It is imperative that this concept is grasped when preparing the sign-off documents.

Final agreements

Written agreements, or contracts, between client and developer are important in making clear the obligations of each party. The written agreement should limit the consequences of settling any disagreement at a later stage. This could affect the project in terms of time lost, cost and loss of goodwill.

If the client is accepting a new multimedia product, then the written agreement should deal with:

what the client will supply in terms of future assets, resources and support
the final product structure and specifications
the ownership of the product
what rights the developer has (such as source code, copyright, etc)
future contract rates
future maintenance and support
licence details for existing software
duration of licences
whether the software is restricted to a particular place or equipment.

Again, the documentation may seem excessive, but in the long term it protects both parties.

Summary

Often projects are rushed to meet deadlines, but remember the delivery of a quality product is always the end goal, so avoid shortcuts in the final stages.

The tasks of revising, organising delivery methods, packaging and obtaining final signoff, are all essential to building a professional multimedia product. At no stage can a step be missed—all the work done and effort spent so far depends on a professional conclusion to the process.

1752_reading.doc