7

Contractors and Clients

Websites can be developed in-house (internally), out-of-house (externally), or using both. With in-house development, a company designs and builds a website using primarily its internal staff. Out-of-house development is when a company goes outside and commissions another company to build its website, in a client–vendor relationship.

A fundamental factor in the management of a website development project is the business or employment relationship among the players. In the interest of tax collection, the Internal Revenue Service (IRS) has gone to great lengths to distinguish between an independent contractor and an employee. The distinction can be ambiguous in some situations, so the IRS has established a list of checkpoints that swing the balance one way or another. The guidelines specify that a contractor is responsible for the output and is not supervised or trained in how exactly to proceed toward that outcome. This is an illustration of how rules and customs governing interpersonal relations differ depending on whether the person is an outside contractor you’ve hired, a coworker from another department in your company, a direct report, or a peer. In short, an in-house project manager does not have the same control over a contractor that he or she is likely to have over an employee.

Most of the time, Web projects involve a mix of in-house personnel and contractors. Certainly large projects do. So many skills are involved in putting together the pieces (e.g., writing, programming, graphic design, and network administration) that a company usually goes outside for some services. Even though the corporate website now has an undeniable place in the communications and commercial mix, a company’s information technology or marketing departments are often too busy with other duties to build and maintain a site. Even many intranet sites running on large corporate networks are built and maintained by an outside developer.

Successful project management depends on communication. Your perception of a given project may vary greatly, depending on whether you are in the client company or the outside developer. Whether your position is as a project manager in a full-service Web development agency or an inside team leader who hires the outside firm, you have an interest in how the project is managed. If you’re the in-house team leader hiring an outside project manager, you will still manage facets of the project that only an in-house person can, such as executing the agreement, gathering content, and shepherding deliverables through the approval process.

Coordination is always an issue in project management, and it is likely to involve both contractors and employees. In this chapter, we look at how contractors and clients can align individual interests for the common goal of a successful website project. To search out this common ground, contractors and clients can benefit from understanding one another’s perceptions and motivations regarding the website project. This chapter explores both perspectives.

CONSIDERATIONS IN THE INSIDE-OUTSIDE MIX

The decision about whether to produce a project internally or externally is an important one that merits thorough consideration of many issues. A sound place to begin is with the three dimensions of project management—time, task, and resources. The project needs within the context of the organization’s overriding Web strategy should guide the decision.

A company getting ready to launch its first website will probably opt for a significant amount of assistance from an outside development firm. Once the site is up and running, maintenance duties can usually transfer to the client (often with the ongoing assistance of the original development firm). Internal personnel often maintain and develop intranet websites, which run on a company’s private network, but this function can also be outsourced. Most commonly, a hybrid approach is used, in which some aspects are handled by the client, some by the developer, and some cooperatively, as shown in Figure 7.1.

We’ll compare inside versus outside development in the following areas:

•	Expertise
•	Cost
•	Control
•	Teamwork
•	Time and scheduling
•	Investment and core functions

Table 7.1 provides a quick overview of the strengths and weaknesses of the two different approaches.

Figure 7.1 Internal/external/hybrid development tasks, a commonly used strategy.

Expertise

In-house development may not be an option. The first question the project manager must ask is: “Does the necessary expertise for meeting the project’s goals lie within the organization?” If the appropriate staff does not exist internally and a website is attempted anyway, the results can be disastrous.

If an organization lacks internal expertise but does have talented people who could potentially develop the necessary skills, should it use the project as an opportunity to do so? It is feasible for internal people to learn some tasks on the job, such as basic software testing or documenting design changes. Other tasks, such as Java programming or Web server maintenance, are not so easily learned in a short time. Nonetheless, a certain amount of in-house Web expertise is a real asset in today’s business environment. The work experience gained by participating in the development of a website, even an intranet site, is often applicable to other tasks within a company and could be of great use in the future. Again, the question of resource allocation arises. What aren’t the organization’s people doing during the time they’re developing the website? What skills are critical to the firm’s success? The glamour of website development may seduce staff away from more mundane, yet mission-critical, tasks.

Table 7.1 Internal versus external development—comparison of strengths and weaknesses. (Note: The project cost depends on many factors, including site design, technology, available resources, and accounting methods within a company.)

	Internal development	External development
Expertise		X
Cost (depends on project specs)	?	?
Control	X
Teamwork	X
Speed of development		X
Investment in future	X

When working with an experienced outside developer, the client company gets the benefit of that vendor’s experience and knowledge gained on other projects, potentially similar ones. The value of this experience is a prime motivation in using an outside developer and why it can be much less expensive in the long run to do so. If a project has a high risk factor and must be completed on time, the best bet is probably an external developer with a proven track record of producing such websites, rather than trying to do the work internally and learning along the way. An external developer is a specialist and can often do the work much faster and with fewer errors than in-house personnel. This efficiency greatly benefits the project and those associated with it. For example, if a company needs a database-driven website right away, but has never developed or managed a Web database, it’s a good idea to use an external website developer. Ideally, internal people will be involved as much as possible in the development process, so they’ll be prepared to take on a more active role in the future.

Cost

A common misconception is that developing a website internally is cheaper than going outside. Theoretically, a project requires the same resources whether it’s developed internally or externally. Therefore, given overhead and internal billing rates, costs should be comparable.

Arguably, with all else being equal, the development cost actually would be lower for in-house development because only “true” development costs would be charged, with presumably no profit margin added. Although the accounting practices of the company may require transfer payment between departments involved in development of the site, these costs would be lower than what an outside developer would charge.

Of course, all else is never equal. An organization’s overhead charges may, in fact, exceed what an efficient outside developer builds in as a profit margin. Inhouse skillsets may not match those available outside. Normal job responsibilities of staff may make them efficient with certain tasks of the website development project. For example, if a project requires data preparation using internal company source files, internal personnel will probably be faster and more experienced at working with the data than an external developer (who would be working with the data for the first time). Conversely, a key skill for the project, such as Java programming, may not be available internally.

Outside developers’ quotes that are not fixed bids should be closely managed. Enhancements or other changes can quickly escalate costs. Another issue is future updates. The most convenient way to produce an update is to go back to the original developer.

On the other hand, external developers can be much less expensive in some situations. Internal managers must consider the big picture. When time is crucial or when internal personnel do not have the skill or experience to do the job efficiently, external development may cost less. In addition, an internal project manager can often apply pressure on an external developer more effectively than on internal staff, especially when that staff is located in another manager’s department (such as the internal Information Technology department), which brings up the issue of control.

Control

Developing the website in-house lends the maximum control over how the project is executed. The development personnel are company employees and can be monitored closely, if necessary. The project manager has great flexibility in how resources are applied. In addition, if the development is done in-house, then presumably the maintenance can be done in-house as well. In a situation in which the Web project has great strategic importance and qualified technical personnel are on staff, in-house maintenance is the safest method. Also, if the team is composed of company employees, the project manager can better encourage and reward the commitment and loyalty of the development team. The issue of control, however, is not always cut and dry.

When working with an external developer, a company relinquishes some degree of control over the project. An external developer usually works off site and is therefore a more independent entity. In an external development arrangement, the resources are essentially guaranteed by the developer. When project milestones trigger payments, the developer is motivated to deliver, and the client has the leverage of withholding payment. Because many small developers run their businesses virtually from payment to payment, withholding a payment pending milestone approval usually provides sufficient motivation to meet the milestone dates and specifications (to the best of the developer’s abilities).

An internal project will also be more vulnerable to internal political maneuvering. When authority is unclear in an organization or when the project involves people from different departments, as is often the case with website development, in-house production does not lend the amount of control one might expect.

The project manager working with an in-house production staff needs to respect their time and other priorities. From the perspective of the in-house developers, internal clients can be the toughest customers. Project managers using in-house development sometimes feel free to make changes to the design at the last minute. They make demands of internal staff that they wouldn’t think of asking from a developer. Although internal development may give the project manager the control to do that, those actions still carry a cost in resource use and time.

Teamwork

If a company chooses to hire people for internal development of the website, a commitment has been made to keep them busy after the site is completed. Therefore, additional hiring for website development can only be undertaken in the larger context of organizational workflow. Even when using freelancers or hiring temporary employees on a project basis, a subconscious commitment to giving them work develops. Relationships naturally form when working closely with a person for a length of time and participating in the trials and tribulations of project development. Budgetary problems caused by excess staffing may ensue. Using an external developer helps avoid such situations.

A trend in corporations is to use cross-functional teams for special projects, like developing a website. A potential problem for the project manager, however, is that although development is in-house, individuals are “on loan” from other departments. Usually, these individuals retain at least some of their existing responsibilities in those departments while working on the project part time. For example, suppose a new section of the website needs to be developed to correspond to an upcoming tradeshow promotion, and the project manager intends to use existing company development resources. Perhaps the programmer is from the IT department and, although assigned to help on the project, may still retain some of his or her usual responsibilities. Work on the project may suffer, and development time can evaporate quickly in such a situation. To avoid problems with this situation, the project manager must seek clear guidelines from upper management on priorities and the level of commitment that can be expected from staff with multiple assignments.

No matter where in the company the internal development team comes from, they may be more difficult to motivate than an outside developer. They will get a paycheck anyway, regardless of when the product is finished. In this sense, project management is no different than any type of management position. When you manage a website project, you also manage people. Communication is one of your tools and one way you motivate, inside and outside the organization.

Virtually everyone wants to take satisfaction in a job well done, and this is especially true for those in the product development arena. By allowing internal staff to work on a website, managers give them the opportunity to take part in interesting work that can broaden their skills and to gain a sense of accomplishment when the project is completed. Not only does this situation benefit the individual, but it also benefits the company, by raising the interest level. This effect can be beneficial to morale, with a ripple effect even among those not participating directly in the project.

In-house website development is an opportunity to offer interesting work and shared glory to staff in various departments of the company. For example, internal art and design personnel may prepare graphics for the website. In doing so, they increase their visibility within the company, which in turn may help them justify increased staff and equipment to perform the work. Because websites may be perceived as hip, cool, or trendy, most staff will happily accept Web assignments. The shared experience can also increase the sense of teamwork among departments, which benefits the company as a whole and future projects of all types.

With reasonable foresight and political sensitivity, website projects can be developed internally with significant efficiency. Developing a website in-house can be a rewarding experience, both in terms of job satisfaction and career advancement. If you get the opportunity to develop a website in-house, make the most of it!

Time and Schedules

Internal company pressures may slow down the development process, relative to using an external developer, working outside the corporate environment. Even when fully staffed, a company must juggle many priorities. The website may be the ball that gets dropped. The choice between external and internal development often boils down to expediency.

Sometimes an external developer can offer the in-house manager a great deal of flexibility, letting a manager speed up and slow down the project at will (depending on contractual arrangements). If the work is being done on an hourly basis, the manager can request as much or as little work done as needed. An external developer can typically get projects started (and stopped, if necessary) faster and can often change directions faster during the project as well; however, in-house managers sometimes make the mistaken assumption that working with an outside company will somehow relieve them of all project management responsibilities. After all, isn’t that why the developer was hired? Outside developers can require just as much management supervision as internal staff, if not more, and the notion of a truly “turnkey” website developer is somewhat unrealistic. Usually, the many internal decisions, discussions, and judgment calls preclude giving an outside developer complete autonomy.

Investment and Core Functions

Matters of expediency tend to point toward outside website development. There is much less administrative work, in the form of reports, meetings, approvals, performance reviews, job descriptions to justify new staff, and so on. The main problem in developing a site internally occurs when it grows beyond the normal workflow capacity and staff responsibilities. New staff must be recruited, hired, and managed. Equipment, working space, software tools, and communications infrastructure (including Web and server access) must be arranged. These resource and logistical issues can consume a great deal of managerial, administrative, and technical support time that, while not directly related to running the project itself, drives up general operating expenses for the company and delays development progress.

The external developer can simply “do the work” and manage its own personnel. The equipment, communications, and staffing issues are generally the responsibility of the external developer; in-house managers do not have to arrange for rental computers or write up endless justifications and paperwork to purchase equipment. Instead, they can adopt the much more convenient role of consumer, purchasing development services as needed, rather than dealing with the time-consuming logistics and details required to directly manage a large (and perhaps temporary) staff.

In-house website development is full of hidden expenses. It is expensive in terms of indirect costs or opportunity costs that don’t find their way to the project development budget; however, an organization’s strategy may dictate that it is essential to grow an in-house capability for developing websites. An executive could argue that a marketing department that understands the company’s message and products should be able to create a website as well as it might implement a publicity campaign. From that perspective, the indirect costs of developing the website represent an investment in the company’s future.

One management philosophy is to crystallize the many activities of a company down to its core functions. Anything that is not a core function can be outsourced. Whatever is a core function should be performed or developed in-house.

The scope of the project is also an issue. How much does the executive want its marketing department to know? Should they be able to develop a database? Or is understanding message design and content enough?

TYPICAL PITFALLS

In order to establish and maintain a good working relationship between client companies and the external developer, it is helpful to know about some common sources of conflict.

Compatibility

One of the most common sources of problems between a client and developer is incompatibility. In these cases, the first mistake was agreeing to work together at all. A working relationship may be doomed from the start. Independent developers and outsourcing managers alike must learn to recognize trouble before they sign the agreement. The close working relationship necessary between the client and developer will flush out even the smallest incompatibilities before long. Incompatibility may be in the form of a developer’s lack of experience with developing a type of website or with using required tools. The client may have chosen the developer based solely on price or on marketing image. Here the importance for clear communication on requirements and needs of the website is evident.

Sometimes the problem is a simple clash of cultures. Every company has its own procedures, attitudes, and codes of behavior and dress, collectively referred to as the “corporate culture.” Small website developers also have their own culture. Differences may be so pronounced that they seriously impair the working relationship. Imagine the conservative banking institution that hires an offbeat Web developer partial to body piercing. This extreme example of drastically conflicting fashion may seem trivial; however, difference in styles, whether in dress or work habits, can easily overpower the basic communications about the project and lead to misunderstandings.

The clash does not have to be as monolithic as corporate cultures. Rapport among the key representatives of the client and developer teams is also important. Personality and chemistry is worth paying attention to during the selection process.

Desire for Control

Another common reason for client–developer problems is the desire of either party to exclusively control the project. If the client treats the developer as a true partner with valid ideas and valuable knowledge, the independent developer often puts forth effort beyond expectations. The developer who tries to control the project often causes more problems than are solved. The client is the customer and has every right to call some shots. Many so-called personality conflicts are actually battles over control of a project or an aspect of it. When both parties can focus on results, the value of respecting each other’s expertise will be clear.

Design Changes

Another potential trouble spot is when the client insists on making significant design changes throughout the development process, especially in the later stages. This is a major source of conflict because of both frequency and the severe problems it causes in development, often impairing the developer’s ability to finish the project on schedule.

Design changes can happen for many reasons: the client may be unable to envision the final website until it is up and running, at which time they may want to change the design; or the requirements themselves may change during the project because of competitive issues or new ideas. Whatever the reason, requesting significant design changes in the later stages of development can create a massive amount of additional work for the developer, along with the resulting schedule and workflow problems. A competent and realistic developer will request more time and money to implement such changes, and clients are rarely pleased when this happens.

Such an impasse is difficult to work through. The problem of ongoing design changes is best addressed through prevention. The workplan document developed in the analysis and planning stage is critical and should be the reference point for everyone involved. Project managers should continually coach the clients, whether internal or external, on the value of upfront planning. Companies may resist spending money for such creative development, especially when there are no tangible outcomes. The outside developer who creates a plan without client input or approval is asking for changes down the line. It’s also best to seek user input as early as possible in the process. When the client suggests a change down the line, you can gently remind them that the current version has been approved by users.

Relations between Contractor and Client

The importance of compatibility may be reminiscent of matchmakers and marriage. The developer–client relationship, like marriage, requires commitment, hard work, and dedication in order to survive the inevitable spats and conflicts. A long-term relationship can bring benefits to both parties that would be unachievable in working alone. If you look at the common pitfalls described previously, you can see that better communication could solve each one.

The first step to successful collaboration is to recognize and respect your different perspectives and motivations. In the most basic arrangement, where the developer is doing the project as a work-for-hire and is due fixed lump sum payments based on milestones, the objectives of client and vendor are fundamentally opposed. The client wants as much design flexibility, functionality, and quick development as possible. On the other hand, the developer wants to fix the design specifications “in concrete,” to avoid the data rework, revisions, “feature creep,” and technical problems that result in cost overruns. Documents like the workplan, proposals, and the agreement articulate a common ground between these conflicting motivations; however, no agreement can cover every possible situation, and those that attempt to do so often strain the relationship by spelling everything out. A sense of trust should underlie agreements that clearly define expectations, obligations, and respective roles in the project.

Some situations present even more hidden and conflicting agendas. Developers have been known to work on websites for unrealistically low fees (or for free) simply to “hook” a client. Such sites often have quality problems, because of the lack of resources invested, and may never get finished at all. On the other hand, client companies are sometimes guilty of “stringing along” small developers with promises of work to keep their options open and sometimes even to get de facto free consulting services from an eager independent developer. Both of these situations raise ethical questions. Open communication and integrity always produce the best results.

Dancing with Elephants

Although the Web development business is establishing quickly, and large, well-financed operations are emerging, the industry is still dominated by small, independent development shops. Project managers working in small website development companies should understand some important concepts involved in working with large corporate clients.

First, large companies can move very slowly. Usually, the larger the company, the slower it moves. In a small website development shop, the environment is completely different: decisions can often be made by one or two individuals and implemented almost immediately. By contrast, a large company may require several levels of approval, each of which is harder to obtain than the last. The chain of command, approvals, and buy-in decisions can be difficult to understand, even for those within the company, much less for a small, independent website developer who is waiting for a decision on a project. Your in-house contact may have little or no decision-making authority, or even input into the approval process.

Large companies often operate in the “hurry up and wait” mode. They may require a developer to perform a large amount of work in a hurry (such as to write a proposal by the end of the week), then wait an indeterminate length of time for a complicated approval process to grind to completion before receiving an answer. By the time the project is finally approved (assuming it does get approved), there may not be enough time left in the schedule to actually develop the website as described in the proposal. Often the best thing a small developer can do is be politely persistent, perhaps by checking in by telephone or e-mail once a week, while looking for other project opportunities in case the project under discussion does not materialize or is delayed.

Most important, when awaiting project approval, do not assume that large companies are rational, logical entities; they often are not. They sometimes pursue courses of action that appear to be (and actually may be) counterproductive and even self-destructive to their apparent business interests.

Decision Makers or Indecisive Companies

Project managers should identify the internal decision makers for their website project. The larger the company, the more likely the decision maker is not to be the developer’s primary contact. The internal manager and developer should discuss how decisions and approvals are executed inside the company. Not only do such communications avoid misunderstandings down the line, but they also help in project scheduling.

One of the most frustrating situations for the outside developer involves overly bureaucratic companies in which people cannot make even the smallest decision without endless meetings, committees, and layer upon layer of approvals. This means that few individuals are empowered to actually make real decisions, and the company must reach a consensus for any decision of significance, including the decision to actually sign a website development contract. If you start feeling that the decision-making process is taking much too long (and assuming there are no outstanding invoices), it may be time to look for other work opportunities while the client sorts things out internally. Check back by phone once every week or two to see how things are going. Patient persistence can be effective.

Here is an example of a compatibility issue. If you are a small developer who can work on only one project at a time, you may have to walk away from an opportunity to develop for the large bureaucratic company. The decision-making process may put you into unproductive downtime. Not all companies are overly bureaucratic, however. Don’t evaluate potential clients on size alone. Early negotiations provide a sample of what lies ahead. If you experience long delays in accepting your proposal, you can expect the same for approval of various project milestones unless something changes. If you’re concerned about future approvals, you should raise the issue with your contact person.

Long-Term Relationship

Once a website has been developed, the natural course of events is for the original developer to handle revisions of the site. The original developer already understands the development tools, data, and programming for the site and, therefore, is best able to efficiently make necessary changes. Although internal staff may handle modest content changes to the site, original developers tend to maintain websites into the future. Conflicts such as personality clashes, business concerns, and miscommunication can strain the relationship. This “uneasy marriage” creates a situation with significant potential for built-in conflict. Sometimes a client might feel they are in an inescapable relationship with a developer. Or a developer may feel underpaid or unappreciated for their creative efforts. If a mutually beneficial, “win-win” relationship is cultivated from the beginning, a project will have a much better chance of long-term success.

In an external development situation, the client often provides content and conceptual design input, with the vendor detailing the design and producing the site, including programming and hammering out technical issues. Various other aspects, such as data formatting, graphic artwork, and testing, may be performed internally or contracted out, as appropriate. This mixed approach is probably the healthiest method because it keeps vendors competitive, helps educate internal staff, and gives the company a wider choice of production alternatives. The larger the project, however, the more internal project management time is needed to coordinate the workflow and communication between internal and external personnel. Whether you are on the vendor or the client side, make sure the other party is creditworthy, and that the relationship can be managed toward mutual benefit.

SELECTION PROCESS

Carrying forward the marriage metaphor, it should be obvious by now that special care should be taken during the courting process to ensure that yours is truly a match made in heaven. A thorough discussion of vendor selection and negotiation is beyond the scope of this book; however, some basic points can keep vendors and developers out of a bad relationship.

The first step for the in-house manager seeking a developer is to call around and get recommendations. That’s not to say you should hire your buddy’s college-age son who’s “fantastic with this Web stuff.” Those days are long past, if they ever existed. Look for referrals of companies with experience in building the type of site you’re planning. They don’t necessarily need experience in the same industry. More important is the technology underlying the site. The nuances of various industries play out in the area of content, which generally comes from the client anyway. As an example, the sort of experience you might look for is development of an e-commerce site running on a UNIX server, with an Oracle database and Cold Fusion as the development tool.

Second, beware of exceedingly low cost estimates. Although developers who want your business will attempt to quote a competitive price, some unscrupulous developers have been known to quote extremely low prices simply to get the job, believing that once the website is sufficiently underway, they can ask for more money as it proceeds. This scenario does not lend itself to high-quality site development, nor does it encourage a good working relationship with that vendor in the long run.

One old method of selection when cost is truly the most important factor is to get three bids and pick the middle bid. The reasoning behind this approach is that the lowest bid is a lowball or low-quality bid, the highest is the one with the most built-in profit, and by default the middle bid is probably best. This arbitrary approach is little more than a human tendency to gravitate toward the middle. Though much better than automatically picking the lowest bid, its assumptions are probably false. With all the complexities and choices involved in website development, variations are just as likely to be caused by different approaches as by different profit margins. It’s not the same as installing a muffler.

A better tactic than simply comparing bids based on price is to request a detailed analysis of how the firm will accomplish the task in a prospective developer’s proposal, including tools, personnel, equipment, and testing. It may even be appropriate to pay the developer a small sum to help defray the costs of developing such a detailed proposal. Generally, the better and more well thought out the proposal, the higher the quality of the developer and the more seriously he or she will take the website project.

One real aspect to consider in choosing a developer is geographical location. Theoretically, an external developer may be located across the country, sometimes even in a foreign country, and still get the job done. In such a situation, however, it is difficult to hold face-to-face meetings, which are generally an important way to build and maintain rapport among team members. Distance can also become a significant inconvenience because of time zone changes. Given the large number of development houses located on the West Coast, this time zone change can make a big difference for companies located in Eastern states. The three-hour time difference shortens the available time for telephone conferences. Although this communication gap can be eased with e-mail and voice mail, it still does not replace the rapport gained in face-to-face meetings.

Once a manager has narrowed the field to a few developers he or she would be satisfied working with, it’s worth taking a closer look before making the commitment.

View Previous Work

The best way to assess the capabilities of a developer is to view samples of previous work. A reasonably well-qualified developer should have at least a few sample sites to show, ideally of the same type as yours. If the sample is for a different kind of website or isn’t of high quality, there is little need to continue the discussion. If the work looks good, try to find out what parts of the site (e.g., graphics, programming, page layout) this developer did, since most Web projects are a collaborative effort.

Contact References

Another way to check out the developer is to talk with previous clients. Any reputable developer will let you contact satisfied clients (unless a project was done under nondisclosure for some reason). If a developer has no satisfied clients as references, let that be a warning.

Visit the Company

There is no substitute for actually visiting the developer’s worksite. First impressions may not be 100 percent accurate, but they are often more correct than not. The layout of the offices, cleanliness of the environment, disposition of the employees, technical resources, decorative taste, and company rules and policies can all contribute to a more well-rounded impression of the developer.

Meet the Principals

One of the best ways to assess the quality and character of the development company is to meet the individual(s) who runs or owns the company. A company’s tone is set at the top, and meeting the people who run and own the company can provide an important insight into the company’s work mode and ethic. This is especially true with website developers because they tend to be smaller companies in which the owners run the company hands-on and are closely involved in the work. In fact, the company is often a direct reflection of the owner. If the owner seems to have a strong work ethic and is flexible, accommodating, and technically knowledgeable, this is a good sign. An owner who turns out to be an investor with more interest in fancy dining and expensive cars than in technology might not be viewed as favorably.

Size of Developer

The size of the independent website developer you choose should be appropriate to the size of the project. Generally, the larger the project, the larger the developer needed. The developer should be large enough to absorb fluctuations in the workload but not so large as to be too expensive or unresponsive to your needs. A single individual working as a freelance developer might be fine for a small project, such as a simple “home page” Web presence site. For a database-driven e-commerce site, however, a larger development house with other such projects and clients might be more suitable. Such a developer can absorb your workload fluctuations, and the other jobs provide the developer with a depth of experience that can also benefit your project; however, a developer who is too large for your project may not be as responsive as a smaller one. If a large developer falls behind schedule on someone else’s multimillion-dollar job, while yours is only a $15,000 Web presence site, the manager may be tempted to pull resources off your project to get the larger one back on track.

Make Valid Comparisons

When comparing developers and development proposals, try to make sure you compare them fairly and are not comparing “apples to oranges.” One developer’s $50,000 bid may be very different from another’s. One developer may be willing to build the site using the technology of your choice, or may include full browser version testing, graphic design, or even Web hosting in the bid, whereas another may not. These are real costs that can make a huge difference in the final project and maintenance expense.

Limit the Number of Vendors

If a project is being done out-of-house, work with the minimum number of external developers and vendors. When a lot of work is to be done externally, it is tempting to want to spread it around to several different developers. On the face of it this practice seems fair, and even a means of comparing the performance of different developers; however, each external developer requires a significant amount of internal project management time and coordination. As the number of vendors increases linearly, the effort to keep them all working together in sync increases exponentially. Conflicts inevitably arise among different external developers working on the same project: finger-pointing starts for missed deadlines, software defects, and the like; jealousy emerges over the amount of business being done with one or the other; fee comparisons are made; and issues of confidentiality exist among potential competitors. In addition, it takes time and effort to develop a good working relationship with a developer, to the point that the external firm understands your company (i.e., expectations, priorities, structure) and you understand theirs. It is often wise to focus more work on fewer developers than to give more developers smaller pieces.

BUDGETS AND BIDS

The In-House Development Budget

The motivation for in-house development is often a desire to save money. The false assumption is that the work can be done internally at a fraction of the cost. Often, a project bid received from an external developer is significantly higher than expected. At this point, individuals in the production department may start to imagine that they can do the work internally for the amount originally envisioned. Starting a large project based on this assumption can be a recipe for disaster. A better reaction to this scenario would be to reexamine the original estimate and interview the developer to better understand where the production costs lie. What often happens is that the purportedly high bid sways management to approve internal production for a project that is underbudgeted. Three months later, instead of going live, the site is still being tested and debugged with another three months estimated to completion, and management starts to realize its mistake. This situation benefits no one, least of all the production personnel who may have lobbied to do the work internally.

If you start a project without adequate resources being budgeted, it will require additional unbudgeted resources later. The project reels out of control, quickly escalating toward serious problems. Therefore, you should be especially careful that internal projects carry adequate budgets. Err on the side of overestimating for safety’s sake.

Realistic Expectations

Clients often underestimate the cost and effort of developing a website, sometimes drastically. Inexperienced clients naturally compare website development to more familiar media, like video and print, when in fact software development is the better analog. To further confuse matters, website development costs tend to vary wildly. Some companies are offering website deals as a come-on, angling for other businesses. Some college students will make a site for a pittance. The quality is often atrocious, but the low cost can set unrealistic expectations.

While sensitive to this tendency of clients to underestimate costs, developers must nonetheless be realistic regarding the true cost of development or risk working themselves out of business. Factors encouraging an unrealistic quote include:

•	sheer optimism
•	pressure by the client
•	minimizing the inherent unknowns in doing a software development project

In addition to the risk of losing money on a project, a low price can set an unfortunate precedent that could inhibit you from billing the client at more reasonable rates in the future.

Smart Proposals

The dialog around budget and bids can easily become a cat-and-mouse game, which is a disservice to both parties. It is perfectly reasonable for developers to ask clients what the budget for a project is. The client might fear that revealing the budget is no more than an invitation for the developer to use it all up in the bid. As discussed, it is not unlikely that the client will come in with gourmet tastes and a fast-food budget. Clear, open communications about the budget make for an early reality check on the project and ultimately foster proposals best suited to the client’s needs. Developers can help clients along by delineating various levels of solutions around specific components of the site. Then clients can see exactly what they’re getting for their money.

Clients may want to protect themselves by seeking a flat fee for development. A better arrangement for the developer is to quote by time and materials, with estimates for both, especially when working with a company for the first time. Website development is both a creative process and technical software development. The many unknowns around these processes make accurate time estimates difficult, and sometimes impossible. After quoting the project on a flat fee, the developer will have a difficult time coming out ahead when a client starts requesting design changes just before release. A client who has to pay incrementally for those changes becomes sensitized to the costs involved in changing the specifications. This awareness can be helpful in setting a precedent for future work, as long as the client doesn’t perceive that it is being “nickeled-and-dimed” for little things at the end of the project. No matter what the arrangement, it’s a good practice for contractors to always track their hours.

Ideally, even in a new relationship, clients will trust developers enough to work on a time and material basis. Both client and developer should want a quality project. The developer’s obligation is to keep the client informed of production costs along the way. Rather than automatically proceeding to work on every change request (knowing that the meter is ticking), the developer can discuss the cost ramification of new changes and explore alternatives, if appropriate.

Among the components of a proposal are the following:

•	executive summary
•	creative, strategic, and technical objectives
•	description of the project scope, including a rough sketch of the structure and navigation scheme of the site, scheduling in rough time frames around development stages and milestones
•	list and details of major features and functions
•	development tools and technical features of the site
•	summary of fees, services, and exclusions
•	payment terms
•	delineation of responsibilities
•	staffing and personnel assumptions
•	any assumptions made when preparing the proposal

The developer’s goal after submitting the proposal should be to obtain a face-toface meeting with the client company and make a presentation of the proposal.

AGREEMENTS

A written agreement defining the work to be performed and the amount and terms of compensation should govern the website development relationship. Where contractor and client are familiar with each other, doing business on a handshake may be convenient and appealing; however, the flexible and ever-changing nature of software development make undertaking any significant website project without a written agreement an extremely risky proposition. This written agreement might range from a simple, single-page letter of agreement to a full-blown software development contract. The specifics of the agreement depend on the situation and parties involved.

Without such an agreement, both parties put themselves at significant risk, proportional to the amount of time and effort that will be invested. A developer working without a contract is like a tightrope walker working without a net. When expected payments are delayed by bureaucratic tardiness or withheld on minor pretenses, the developer is left without legal recourse. A client who asks for work to be performed without a contract risks not only investing significant time and energy without a guarantee of product delivery but also litigation if disagreement arises.

For projects of smaller scope and shorter duration, usually done as a simple work-for-hire at an hourly rate, a basic letter of agreement often suffices. Such a letter generally includes a description of the work to be performed, intended delivery dates, hourly rate/compensation, and so on. This can even be a single-page document signed by both parties.

For larger jobs, a software development contract may be necessary, a subject that is too large to be treated fully in this chapter. Development contracts come in many different styles, but all attempt to detail the working relationship between the two parties. They describe which party is responsible for what elements of the development, including the following:

•	payments
•	deliverables with schedules
•	rights of ownership
•	warranties and indemnities
•	hosting arrangements
•	maintenance, support, and training issues
•	conditions of termination

Typically, tight schedules constrain website development, and the time spent negotiating the development agreement and obtaining approvals can eat up available time. The developer cannot afford to be put in the position of starting later but nevertheless being held to the same completion deadline. One way to address this situation while avoiding working without a contract is to start with a simple letter of agreement, which gives the go-ahead to start work, possibly defining certain steps in the analysis and planning stage. The letter of agreement is later superseded by the full development contract.

SCHEDULING AND DELIVERABLES

Contract Milestones

Many agreements are structured so that the developer is paid a predetermined sum by the client at specific milestones, such as delivery of the design specification, the Alpha version, the Beta version, and the final version. The contract defines deliverables with specific, objective criteria on how the milestone is determined to have been met. Nonetheless, as often as not, some disagreement about this occurs between the parties, such as whether a version submitted as Beta by the developer is accepted as Beta by the client.

Obviously, the definition of the deliverables is an important section of the contract. An unfortunate but unavoidable situation for the developer is that the client decides when the milestone has been reached. The unscrupulous client may manipulate the process and improve cashflow by delaying approvals. The developer’s best legal protection is the language of the contract. The truth is that the developer has no real recourse against slow payment because legal action itself is slow and therefore more appropriate in collecting when payment is refused. The client who makes a custom of such chicanery may have a hard time attracting quality developers to future projects.

Delays are not necessarily foul play, however. More often, they are simple realities of organizational life. Administrative mix-ups, lost invoices, and corporate policies regarding payment cycles all can contribute to late payment. For the small developer facing financial hardships, understandable excuses offer small comfort. The time to ask about the approval process, both in terms of milestones and invoice processing, is when you are creating the initial schedule.

Late Content

In many projects, the developer relies on content from the client to create the website. It’s not unusual for a client to push an aggressive schedule, then drop the ball from the onset by not delivering content. The delay can increase development costs and postpone milestone payments, through no fault of the developer.

The developer’s project manager needs to stay out in front of this process and either obtain the necessary materials in time from the client or make sure the client is well informed of the effects of delivering content late. Schedules should be conditional upon timely delivery of necessary content from the client. When problems arise, developers can sometimes help with simple matters, such as getting photos digitized or text input—with compensation, of course.

As a protection, some developers charge an overtime fee if the client’s late delivery of content forces extra or unusual hours. Not only does the developer benefit from this overtime rate, but its existence also sensitizes the client to deadlines.

PAYMENT

Clients should do their best to see that developers are paid on a timely basis. Developers, for their part, should understand that slow payment is an unfortunate fact of life and make their effort to plan for it.

For example, imagine that a developer is scheduled to deliver the Alpha version of the website on January 1, with a term of 30 days for the payment. The developer, assuming that the payment will take two weeks to process (which is how long it might take in a small company), expects and plans to receive payment in mid-January. In this case, though, the client takes one week to evaluate the Alpha version and determines that it does not qualify as Alpha. The developer takes two weeks to correct it, by which time it is the end of January. The milestone is approved a few days later, and the invoice is submitted for payment. It takes one week to amass the correct signatures, and the invoice finally arrives in the accounting department in mid-February. The accounting department holds the invoice for several weeks, according to an unwritten policy. The developer finally receives payment in mid-March, two months later than planned.

Small developers usually depend heavily on their individual clients. If a corporation withholds or delays payment, intentionally or inadvertently, it can have a serious and magnified effect on a small developer. This impact is sometimes difficult to appreciate by those within the corporate confines. A single delayed payment of sufficient size could cause a small developer problems with staff morale, credit, and making payroll. It may even result in the temporary or permanent layoff of staff. Short of such a dire outcome, slow payment at the least can brew resentments that are counterproductive to the project under development.

Unfortunately, ensuring that payments to a developer are made in a timely fashion may be a project all its own for the project manager in a large company. Many companies routinely hold invoices until the very last moment for payment, sometimes even longer, for good measure. Invoices can easily get lost on the desks of busy executives whose signatures are required for approval, or they can get lost in the accounting department while being processed for payment. Sometimes the approval process even gets changed while the invoice is in process, requiring it to start through the process anew. Meanwhile, the developer is anxiously awaiting payment and wondering whether to continue investing time and resources in the project. In-house managers and their counterparts in the development firm should both be motivated to work through this conundrum.

Discounts for Quick Payment

The converse of the standard penalty for late payment that is so often ignored, discounts for quick payment reward rather than punish. Offering a discount for quick payment may get the attention and motivation of a corporate accounting department. Many otherwise lethargic accounting departments jump through hoops to get the check out if the invoice shows a clear notice that the company is allowed, say, a 2% discount for payment within 10 days.

Early Invoicing (or the Old “Stash-the-Payment” Trick)

In the event that a more officially sanctioned method is not available, a corporate maneuver can minimize the payment delay problem. The project manager instructs the developer to submit the invoice for payment at the earliest appropriate date. The project manager then approves the invoice and submits it for approval and payment, regardless of whether the deliverable has actually been approved, with one qualification: the check is to be routed to the project manager rather than automatically mailed to the developer. Then the project manager can hold the check and send it out immediately upon approval of the milestone for payment. This allows plenty of time for the invoice to be processed, and it lets the project manager pay the developer immediately upon approval. When using this method, you should be discreet. Your accounting department probably does not approve of it. Likewise, a developer who knows the check has been cut already and is in your top desk drawer may perceive that payment is being deliberately withheld and may become insistent that payment be made immediately (regardless of whether the deliverable has been approved). Note that these sorts of actions could come back to bite you in a few different ways. Deceiving your in-house colleagues is a high price to pay for accelerating payment. A better way of addressing the problem may be to study the flow of invoices and approvals and seek out legitimate shortcuts to the process.

Talking Directly with Accounting

Finally, if all else fails, and the in-house manager laments that the invoice is “stuck in accounting,” the developer may want to talk directly with accounts payable. A polite, fact-finding conversation can sometimes reveal where the responsibility for late payment lies. The developer may learn useful information about internal corporate procedures. Trivial items, such as including your corporate identification number or social security number directly on the invoice, may make a significant difference. Before contacting the accounting department directly, developers should discuss this approach with the in-house contact and obtain consent. Otherwise, the developer risks alienating the client contact, if it is perceived that the developer is going around the contact, directly to the accounting department.

WIN-WIN

The focus of this chapter has been relations between client organizations and development firms. It is important to remember that the principles of project management apply in both settings. Business gurus have used the phrase “internal customers” to describe relations within an organization. If you are managing an in-house development project, you should treat colleagues commissioning the project like customers. If you are an internal team leader who is working with an outside development company, remember that you have not absolved yourself of project management responsibilities, but rather delegated the bulk of the details. Issues such as agreements, schedules, budgets, approvals, and payments still demand your time and attention.

Project managers in development firms often find themselves on both sides of the contractor–client relationship. Portions of the website development, such as graphic design or writing, may very well be farmed out to freelancers. The golden rule still applies. Treat the other party as you would like to be treated. For a win-win partnership, dedicate yourself to clear communication, respect your partners, and act with integrity.