The Outsiders

Looking to outsource e-commerce development? These 10 pointers can save you a lot of grief the outsiders

By Scott Dunn

I recently met a colleague of one of my co-workers and our discussion soon turned to the progress of his company's pending Web site launch. He told a story that I've heard numerous times: His company had decided to use a third-party integrator to develop its e-commerce application, and now, months later, the project was well past its original deadline, and the application wouldn't be functional for another six months.

As is often the case, this consulting company isn't some disreputable software shop. Rather, it's a well-known, publicly traded software company.

Because of the pressing market need for companies to have a Web presence, the short time frame of Internet delivery schedules, and the lack of workers skilled in these nascent development languages and tools, many companies turn to Internet consulting firms for e-commerce development. As a result, even with their recent setbacks, these firms - with Viant, Razorfish, RareMedium, and Scient among the leaders - have reached hundreds of millions of dollars in combined revenue.

The decision that outsourcing is the best solution for your e-business needs is the first of many. You can generally group these decisions into two categories that reflect the divergent paths of in-house assimilation of source code vs. vendor ownership and maintenance: project management associated with e-commerce application development and post-launch site management.

Whether you're considering outsourcing only the initial version of your application or beginning an ongoing client-partner relationship, several issues - 10 of them, to be precise - warrant your special attention.

Who You Get

First, you need to get a complete view of the vendor. Evaluate its past as well as its present: its previous projects, current projects, and workers. Although the vendor's "resume" is important, its work schedule and number of available developers are important considerations as well.

When reviewing the vendor's previous work, you should not only review the URLs on its resume but also get several details. For example, make sure to interview the vendor's previous customers. Find out what aspects of e-commerce development the vendor, and the specific branch office in question, were supervising: page design, order processing, news feeds, business components, graphics, animation, FTP or XML utilities, or creation of all business objects. Furthermore, does the vendor have experience in your specific industry? Does it have a development life cycle process in place?

Investigate the firm's developer resources. How many of its programmers have certifications for the products used to build the system? Will these certified programmers be working on your project? Also confirm whether the vendor, for any part of your project, will use subcontractors. Using subcontractors can add a number of potential complexities: turnover of important contributors, lack of personal ownership, ambiguity of responsibility, and quality of work.

At the start of the project, make sure that the vendor understands and buys into the goals of the project. How many other projects is the vendor working on? Are its developers shared among projects? The more you can find out about these other projects, the better you'll be able to tell how your project ranks in importance, and correspondingly, the quality of the developers who will work on it. If the vendor's current volume of work is not at full capacity, your project is more likely to get top priority as well as the best programmers available.

It may make business sense to turn the contract into a long-term partnership. An equity stake or profit sharing may be a good motivator for quality work. As a contingency plan, however, be sure to have second and third choices in mind. If initial deliverables from the vendor look shoddy, you'll be able to contact a backup vendor rather quickly, and the project timeline won't bend too much.

Malleable Web Pages

If you outsource the site's design, consider using a Web design shop for site and page layout rather than a graphic artist or print shop. This point may seem obvious, but consider the potential confusion: A print shop, which might be doing brochures and trade show banners for your marketing department, can submit beautiful images of mocked-up Web pages. But only a Web designer would know which modifications or options are more difficult than others; the print shop may not have a clear understanding of the complexity and browser compatibility issues relative to change proposals. When you multiply these changes and variances with the total number of pages involved, they can become a huge impediment to the efficient communication required among designers, management, and programmers.

What You Get

Have all end-user requirements, down to the click, explicitly defined by unified modeling language (UML) use cases. UML is the lingua franca of application modeling, and it should ease and clarify the definition of business requirements. Ask to see an example of its product requirements documentation from a previous engagement. Set an agreement and pricing for "cafeteria-style" functionality. Down the road, if your fiercest competitor gets its site up before you do, you may want to quickly pare down your delivery and get it out the door fast. Make sure the vendor will allow changes to the requirements (more on that later).

Who will own the code? Would it be an issue for the vendor to resell your custom application to someone else? Will any shrink-wrapped software be used for the application? Are these licensing costs already factored into the project cost? You'll need answers to these questions.

When You Get It

Ask for iterative live deliveries. Consider whether customers would rather see a working site model than wait around for a site with more functionality.

The first approach has several benefits, including giving your company earlier public visibility and an opportunity to measure initial customer response. Furthermore, as different departments become e-business enabled, you can flesh out and finalize the business rules and process for this new "family member." This approach avoids development delays while business units determine how to interface with e-business processes. Delivering a simple e-commerce model also offers more flexibility in shaping the final application, because the preferences of potential customers will probably strongly influence the final outcome.

In the initial agreement with the vendor, be sure to lay out the payment penalties for missed deadlines. If the vendor has a defect tracking system in place, there will be less confusion and wasted communication associated with identifying, qualifying, and eliminating bugs.

Getting Ready for It

At the beginning of the project, start working on your marketing plan, and, if you will be selling goods, your fulfillment process. Far too often the business is not ready when the site is - especially if the company is young or a dot-com. I've been in situations where the marketing department begins testing the site several weeks after the site has been completely built and debugged. With an end-user review this late, it is only natural to expect that gathering and summarizing user feedback will add many weeks to the new "final" version.

Take into account that even after you review this summary with management, suggest changes, and get them approved, it could still take months for programmers to incorporate these changes, only for marketing to review them again. Consequently, avoid changing a completed product by initiating parallel efforts with end-user tests as development teams work on the last annoying bugs.

As for business processes, many people think that fulfillment is a rather simple thing to establish. These may be the same people tied up at launch time with partner agreements and business rules for the business-to-business (B2B) exchange of fulfillment information. Rather, they need to understand that departments will be in new waters as they modify or create business processes that use Internet technology. For example, a B2B exchange (say, exchanging order or pricing information via XML) would probably be new to all parties involved. Thus, they would all confront multiple new challenges in solidifying business and technology rules.

Asking for Directions

Certain aspects of application development, especially involving new technology such as e-commerce, require design, application, and code documentation. Documentation confirms that there is a plan and helps the developers on the customer side install, run, and modify the system.

Design documentation also serves as a map to show you where the vendor is taking you and how. I cannot overemphasize the importance of documentation: Request technical design and architecture documents before construction begins. If the vendor cannot do so by an indicated date time, take that missed deadline as a warning. If the vendor can't meet deadlines, even in trying to win you over and gain your business, trouble looms ahead. (I have yet to see where failed project deadlines, deliverables, and cost overruns were not precipitated by initial delays and difficulties.) If you do get these early warning signs, switch vendors quickly and don't look back.

Documenting standards, the code itself, and installation procedures will help ensure product quality and timely delivery. Ask the vendor for a copy of its internal coding standards documentation. You'll need it later to make sure that all program code is written in accordance with established standards. If the vendor doesn't have coding standards documentation, you can often obtain it from the company providing the software used to build the application.

Be sure to request that the vendor provides technical as well as installation documentation. Technical documentation should exist in inline and external versions. A simple method of ensuring that your minimum requirements are met is to set a quantitative threshold, such as "At least 5 percent of code must be comments of some form," or "External documentation should be one page for every 2,500 lines of code." Ask to see samples of application and installation documentation from previous jobs. And don't underestimate the need for a thorough and lucid installation document. The days are long, literally and emotionally, when your company has the goods and, with management watching, can't get them installed and running.

Hired Guns

If you do not have experienced, high-level technical staff to review the vendor's design documentation and ensure architectural integrity, hire a consultant with experience in at least several e-commerce implementations. This person may act in several roles and her short- term involvement will probably have a lasting impact.

Consultants may act as the project's technical architect or lead. If so, they should verify that technical requirements are met, and the system will meet the business need. Consultants should be comfortable with conflict and have sharp attention to detail, as they'll be "toeing the line" with the vendor. If you do assign this responsibility, provide as much authority as you can and back it up with published documentation. If you don't let consultants make bold lines in the sand, then you're taking a step toward unilateral disarmament. Conversely, if you don't officially and consistently validate the consultant's stance, then you lose standing and leverage with your vendor.

You should also assign an internal technical employee to shadow much of the consultant's time for the purpose of transferring knowledge and information. This information will be critical after the consultant's job is complete.

Shaping What You Get

If the plan is to have the Web site delivered as a complete package, you should at the very least review the pages and functionality as they mature. You can do so either by visiting the vendor and reviewing its work in-progress, or by having the vendor deliver the software incrementally. Try to do so as early in the project as possible, and with increasing regularity from that point on. You can time and plan these reviews so that they align with milestones on the project plan.

Microsoft Project can be saved in HTML format, so there's no reason that an Internet consulting company can't provide updated project plans over the Web.

Have the vendor agree in writing to the frequency of updates to the project plan. This preventative measure alone will greatly help both parties do their part in keeping a healthy project pace.

Taking the Baton

The first task in transferring ownership of, and assuming responsibility for, the code is to make sure it meets all agreed upon standards. Acceptance should already be defined in a mutually signed document. This document should dictate severity levels, bug definitions, and timeframes for issue resolution. Make sure a user-acceptance team and processes are in place to verify expected functionality and log and handle bugs immediately after the site is delivered. The existence of requirements documentation will facilitate this validation.

Care and Feeding

Do you plan on owning and maintaining the site after delivery? If so, consider several future needs. First, be sure you have completed step two, which covers the agreement issue of who owns the source code. On the issue of staffing, any code maintenance or enhancements will require support from a Web development team.

Developers for certain languages and platforms can be difficult to find, as well as more expensive. If any shrink-wrapped software (an Oracle database, for example) is part of the application, you may need to hire workers just to install, configure, and administer it. Check candidate availability in your area as soon as the decision has been made as to what technology will be used to build the site.

Hire early. Any new hires can immediately begin reviewing the incremental deliveries for quality and preparing to take over the code after final delivery. Also, depending on the share of responsibility for hosting the site, you may need an IS engineering team to run the application, as well as make bandwidth decisions and support site users.

Always Prepared

Your project is important. Projects are difficult, and not having the work done under your own roof potentially opens the door to more difficulties. But third-party solutions can also have fairy-tale endings. The key is in identifying potential issues, obtaining written agreements from the vendor on these issues, and through this, staying in control of the outcome.

Scott Dunn (sdunn@onebox.com) started out in IT loading data reels. He has worked the last several years for consulting companies doing client/server and e-commerce development.