Buying Web Services: The Survival Guide to Outsourcing
Chapter 13: The Web Roundtable
June 5, 1998, New York City
The goal of the Web Roundtable
is to provide a forum to discuss practical, nuts and bolts business policies
and practices taking place in the Web development community today.
The Roundtable was initially
launched to offer some of the authors in this book the chance to comment
on subjects that were outside the scope of the specific chapter that they
wrote for this book. We also had as a goal the notion that we could get
more than one opinion on some of the topics covered in this book, an important
consideration given that anyone who has ever built a Web site knows there
are dozens of ways to accomplish the same goal. We also wanted to see
what type of spontaneous ideas about our industry would evolve from a
more in-depth group discussion. While the panel for the Web Roundtable,
for the most part, consisted of the authors in this book, we did add two
individuals to the discussion for the purpose of attempting to get at
as diverse a range of opinions as possible.
The Web Roundtable presented
here is part of an ongoing series of discussions that, in the future,
will include such topics as the role of traditional advertising agencies
in the Web development process, budgeting and billing Web services, developing
sound legal contracts, and more. Transcripts from future discussions will
be made available either in print or on the Web. For more information,
send an email to: JP
Frenza.
Moderator: JP Frenza, author,
Buying Web Services: The Survival
Guide to Outsourcing
Jerry Spiegel, attorney and author
of Chapter 6: Covering Your Legal Bases
Dev Mukherjee, author of Chapter 11: Going Forward: Next Generation Sites
Julia Rubinic, author of Chapter 8: When Things Go Wrong
Vlad Edelman, Senior Producer of New Media at CBS
Chris Bryant, author of Chapter 5: Infrastructure and Site Hosting
Lara Stein, President of IXL New York
Peter Seidler, author of Chapter 4: Understanding Design
For more information on the chapter's
referenced above, see the Table
of Contents.
This book is about the process of outsourcing Web development services--from
developing a concept, understanding design and crafting a legal contract
to project management and technology assessment. I'd like to go around
the table and ask each of you to take five minutes and outline your top
three keys that every client should pay attention to when outsourcing
their site--things they should look out for, issues they should look to
their Web developer to address, and so forth.
I'd like to address what I see as some of the issues that clients are likely
to fail at when it comes to the Web development process. I think the first
and most important failure that a client can make is to fail to set clear
business objectives for their Web site. I think the second potential failure
concerns the failure to do the appropriate planning in terms of the strategy
for the site and how that strategy takes into account the issues of creative,
business and technology development. Finally, and I am starting to see this
one become more and more prevalent as of late, is the failure to recognize
that once your Web site is complete it is not actually done. What I mean
by that is the fact that a Web site doesn't end when a contract with a Web
developer ends--and the costs don't end when you perceive that you are done
with your Web developer. In fact, they've just begun. Failure to address
the ongoing nature of Web sites, whether it is from the perspective of content
or budget and cost, is becoming increasingly acute.
Chris has a list remarkably similar to mine. I would say the first biggest
failure that I see happening with regard to how clients are going about
outsourcing their sites is the absence of some kind of an Internet strategy
which cuts across all of the divisions of the company. Second, I would say
the failure to develop the idea of a "scope document," which is critical.
The client should expect to work with the developer to produce a scope document
that details every aspect of the project and the plan for the implementation
of the project. If those things are not created at the outset, there are
likely to be problems during implementation. Finally, I would add this idea
that the Web site itself, or let's say any digital change that is happening
to the company, is something that is going to keep going and that it is
not a one-time process. Transformation is ongoing and that fact needs to
be recognized.
I should note for the record that many Web shops use the term "scoping,"
which refers to the process of working with a client to define the exact
nature of a Web site, or the final Web site's definition in the form of
a document that can be shared with both the client and the developer.
I would say the first problem is not setting a long-term vision for a project.
I think that many companies going into this medium right now are looking
at it from a very short-term perspective. It is almost like they have a
knee jerk reaction to the Web. They are looking around and they are seeing
everybody getting into it, and they know they need to be there, but they
are not taking the time out to look at their business and get a good understanding
of where the whole industry is going and how to leverage it.
Do you have any thoughts on how many years a company should include in its
plan?
I think three to four years, which is really making them look into a crystal
ball but at least they are blue skying. They can always step back from there.
I also believe that documentation and creating a very specific scoping document
is key because it definitely does set expectations on both the client and
the developer side. Finally, an important part from the client's perspective
is really looking at what the project is and where the balance between technology
and creativity lies and using that balance to determine the type of partner
they need based on that. I say that because I think that from a marketing
standpoint a lot of entertainment clients, for example, are targeting a
very different set of people and having a developer that can create and
develop the right sensibility and the right technology is very important.
I'm going to split my thoughts a little bit between clients and developers.
I think that on the client side one of the biggest problems is unrealistic
expectations. You have to come into this process with basically what you
want to accomplish, what you are willing to spend on it, and be completely
open to discussion as to how much it is going to cost. That, in my mind,
is the biggest problem on the client side. The second is not really thinking
far enough ahead. Too many clients come in thinking of Web sites in the
short term, or technology solutions in general, that are in the short term.
Too many developers let clients get away with that. They are not telling
the client that they are thinking in the short term and that a certain solution
is only going to work for three months and that they will be back asking
for another contract. I think the client would be better served if the developer
said "this is extremely short term, we recommend a better long-term solution."
On the developer side, I just want to add that I think the biggest problem
is the overstated ability to deliver and poor project management. I think
the key on the developer side has to be an unbelievable ability to manage
the project. Remember, as a client, I am farming something out for the specific
reason that I don't want to have to manage it.
I think that managing expectations with respect to both the time element
of a project as well as the budget aspect of the project are important.
Also, I think that clients need to know that this process is not easy and
they should be open and willing to hear about a project's potential limitations
and really make an effort to understand what they might be. Speaking entirely
from the client's point of view, I would say that, in a way, during the
pitch, I would rather hear about potential limitations up front rather than
"sure we can do that." And I would advise clients to probably pick their
developer, whoever it may be, based on the realities that they are telling
me that I have to understand as well as on timeline and on price issues.
Second, I think it is also important for clients to educate themselves about
the process of Web development and gain an in-depth understanding of their
project and the ramifications of decisions that they might make along the
way. As a developer we know that we are an industry where a lot of people
do not completely understand the technology. We have an obligation to not
only tell our clients about the key things that they have to approve, but
also we have to go a step further. We have to be willing to tell that "this
is an important issue, this is what we are doing, this is what we are going
to do next, and more importantly, this is what happens if you change your
mind." I think it is the client's responsibility that if they are missing
that information, if it is not conveyed or they don't completely understand
it, to really truly seek it out and try to understand what the ramifications
of every decision are for the project as a whole. Finally, and I write about
this in my chapter, is the issue of treating the developer as a partner.
It doesn't necessarily mean micro managing them but if the company decides
upon a branding initiative, then the people who are building your Web site
are just as important to that initiative as any group internally in the
company. Clients need to be sure to view their developer as a partner and
to convey important information to them. In some sense, Web developers are
as involved in the company's initiative at a lot of levels as their ad agency,
maybe more so.
I think every client should set very specific business objectives, but not
just a general objective, I think it should be quantifiable. Maybe not a
complete return on investment, for example, "I am going to spend a million
dollars, here's how I am going to make a million dollars back." Something
more realistic--"I expect to get 5,000 leads, or 200 new partners, or 50
new sales" from my site. You may end up changing those goals, but at every
step of the project you should, at the very least, have objectives and have
them perfectly communicated within your organization and to your developer
partner. Second, I think there should be very clear ownership within the
client. Step one should be to pick the smartest, most Internet savvy person
you can within your organization and say "you are it and if this Web site
fails you are fired." I say this because it is too easy to get distracted,
it is too easy to have fragmentation within your organization and have five
or six months go by with no results. Unless you annoit someone to do the
job, the project is going to fail. As a continuation of that thought, if
I was starting our Web development all over again I would, day one, appoint
an interactive architect to manage the structure of the project. Whether
that was someone I hired in my own company, or someone that I essentially
pinched, borrowed, or rented from my developer doesn't matter. The point
is there should be someone who is paid to be separate from the development
activity and would serve as the architect of the project. Third, I would
from the beginning, set technology standards for the project. Because this
industry is moving so quickly, I would try as be as open as possible right
now so that I don't lock myself into a non-open standard--whether it is
an IBM product, and I hope it is, or a Microsoft product, it doesn't matter.
Openness is important in an industry where flexibility is key and we don't
know where we are going to end up. We and our partners, and even some of
our competitors, have taken Web sites or other applications, where there
are say a hundred, fifty, or twenty-five NT servers, and migrated them back
to mainframe solutions. This is necessary because what happens is that some
small part of the organization starts this Web thing and then all of the
sudden the business says "hey, we are really dependent on this Web thing,"
and then they have to apply the same standards that they apply to the rest
of their core systems. The thing has to work, there should be data integrity,
and there should be security.
Just yesterday, I heard something that I hear not too infrequently which
is that people don't really like lawyers. I don't understand why [laughter].
But seriously, the nature of this industry is such that whether you realize
it or not, you have placed in the hands of lawyers more power than they
have ever had before in the history of man. This is true because every asset
that is created today on the Web is a virtual one and it exists only by
virtue of intellectual property law. The idea that some people used to have
about the Web being this great anarchy with no law is the most absurd concept
because the Web really exists only because intellectual property laws exist.
Otherwise it would be pure chaos. So I think it is important that clients
find a lawyer that they are comfortable working with, someone that they
can pick-up the phone, or send an email, and get a useful and intelligent
response to their questions. So, I guess my first point is: find a lawyer.
You really cannot exist or function in this business without one. Number
two, make sure that your lawyer understands what is going on in the industry
and also understands the dynamics of the relationship, the dynamics of the
medium, and also the dynamics of how business models are changing as a result
of the digital revolution. This is important because a client wants to get
a certain job done in the middle of all of this change and uncertainty so
they need someone who understands the rule of law, but also the needs of
business. It is important to get the job done, but you want to also make
sure that you are protected. I think the third thing is that at some point
everyone needs an understanding as to what intellectual property is at some
fundamental level. It is an essential aspect of business and life going
into the 21st century. I think that bringing this education to youngsters
would go along way toward training the workforce for the next generation
in these fundamentals. At the very least, clients should be familiar with
these concepts because they are the business tools they will need to use.
If I could jump in--I agree. As information workers, all we have is not
our manufacturing skills, but virtual knowledge. The other thing that I
would mention is that anyone getting on to the Web should consult a lawyer
on the issue of privacy. There are a lot of people who are going to get
sued in this medium because they don't have adequate privacy protection
policies in place.
Absolutely! But there are lots of issues that remain to be resolved. Back
in 1990, I think it was, the Cubby case was decided (Cubby vs. Compuserve),
which is the first real online libel decision. No one paid any attention
to it, but it was the only piece of law that existed until 1994. The only
piece of law that addressed any of the issues we are discussing here. The
explosion of law, and I use that term very broadly, is astonishing and that
is going to continue and we are all going to have to learn to live with
that and run our businesses within that context.
The Process of Web Development
I would like to shift the discussion to the issue of process, because this
book is really about educating businesses about the process of building
a Web site. I'd like us to focus our discussion on what we perceive as the
most important processes involved in Web development. For example, is the
design process the most important? Technology on the back end? Site infrastructure?
I think that clearly one of the most important processes that a client needs
to concern itself with is the whole issue of developing and defining a company's
business objective in this medium. What is the return on investment (ROI)?
I recently read an interesting report from Gartner which indicated that
by the end of this year, most of the so-called experimental Web projects,
and by that I mean the ones that up until now have really fueled the industry,
for example, those projects where no one is worried about the business objective
or the ROI, will come to term. People will be asking "what is happening
here? What are we going to get out of this?" We are now at the point where
a number of companies are going to have to really start answering the question
of "okay, we've spent $5 million on our interactive strategy, what are we
really getting in return?" You are also starting to see a number of companies
taking a long hard look at their competition and asking what are they doing,
what is their big play, and what does that mean for their business.
This is interesting to me because I have been on both sides of the fence
here--as a buyer at Microsoft and now as a developer at IXL. I think the
biggest challenge in an outsourcing relationship is the process of setting
clear expectations for both the client and the developer. On the developer
side, it is very important to listen to the client and to, more importantly,
listen to what the client says its expectations are and clearly define those
expectations in a manner in which both sides are comfortable. In this business
it is very easy to get "creep" in a project--that is the scope of the project
continues to grow. The more documented you can be up front and the more
specific you can be up front--whether that is a comprehensive scoping document
or not--you have a better chance of making sure that important expectations
have been met. On the flip side, clients have to make every effort to be
as clear as they possibly can and it is often very difficult because so
many of the larger Web projects are governed by committees so you have a
lot of different voices that must be taken into account. What we have found
at IXL is that a successful project has to have a one to one, point to point
of contact and responsibility for both the client and the developer is probably
the best way to ensure objectives are met.
I totally agree with that. At RGA Interactive we are always demanding a
single point of contact and that single point of contact should be responsible
for incorporating and managing all of the input from everybody on their
team. You can't try to satisfy every one on the client's team individually.
I have to agree that the process of setting expectations Lara talks about
is really important. I'd like to add that in a lot of the cases it is the
fault of the buyer in shifting the objectives of the project. For example,
the client walks into a conference room and says "we want this and that"
and two weeks later what the client wants is completely different. But I
would like to add that the biggest problem that I have encountered is managing
expectations on the developer's side. Developers who don't know what they
can deliver is in my mind the biggest problem. You have a great deal of
cases where there are developers who promise they can meet expectations
when in reality, they can't deliver.
I find that interesting given that one of the reasons you are outsourcing
is to take advantage of some previous experience that the developer is supposed
to bring to the project.
The process of setting expectations is really about the process of developing
a relationship. When you think of the entire team being made up of the client
and the supplier, then we need to understand how these different thinking
styles work together to create something new. There needs to be an understanding
on both sides.
I think that part of the reason you see this roll-up strategy going on in
the industry is because of this issue of expectation. Clients come to a
relationship with a certain set of expectations and they want to partner
with a developer that has the specific skill set they want to meet their
goals and objectives. We are living in a world where there are so many types
of technologies that for one small shop to be able to be an expert in all
of those different areas is very, very difficult. Larger Web developers
have the ability, for example, that if we don't have a specific skill set
in New York in a certain AT&T solution, our office in Atlanta may.
Our experience has been that those client expectations are best met by documentation.
The most important thing that we, or any developer, can do is to create
documentation to set expectations up front and make sure that expectations
are clearly addressed in writing. For example, when we work with a client
we give them a project scope document that clearly defines roles and responsibilities
on each side. You also get a number of other documents straight down to
a functional specification that clearly indicates "this is the definition
of the project." With that definition comes a clear delineation of the expectations.
Right from the beginning the precedent is clearly set that if requirements,
and hence expectations change from what we have agree upon, then there will
be additional costs and that may affect other aspects of the project as
well. But it is all in writing and it is all clear to the client. I would
encourage every client to get that sort of documentation from their developer.
I think there is one other additional issue which needs to be addressed
which is also similar to what we are calling "the expectation consideration."
Many times when you contract with a developer or supplier to do a job you
get a scope of costs set over a fixed period of time. For instance, you
have a relationship with a client and the client says we are going to work
with you over the period of a year and it is going to cost X amount. The
thing that a lot of clients don't realize is that once that period ends
the costs associated with that product do not. In fact, they may increase.
We try to approach our clients from a longer-term perspective. A lot of
times when you are trying to make the sell it is not the most advantageous
thing to say "by the way, over three years the site is really going to cost
you $5 million as opposed to $3 million." That is another aspect of setting
expectations that is equally important. Clients would do well to look long
and hard at the cost expectation up front as well.
I think that another difficult challenge that clients face in regard to
outsourcing their Web site has to do with the simple process of finding
a Web developer. There are places in New York City and San Francisco where
you can throw a rock down the street and there will be a good chance that
you will hit a Web developer. The real trick is finding the right Web developer.
What advice would this group offer to companies looking to find the best
outsourcing partner?
I think clients need to recognize that it is a balancing act between creativity
and technology that they should be looking for. Often shops--whether they
are small, medium or large--specialize in very different kinds of services.
I was talking with one of our clients the other day and they had a definite
interest in working with a cutting edge shop. But at the same time, they
need somebody at the end of the day that is going to be able to do legacy
integration and various other skill sets they require for their business.
So I think that for the client it is a constant dichotomyÐdo I go with a
cool, hip shop, or do I go with something that is a bit more staid but stable?
I would say that as a client, I would want to know that the developer I
am working with has processes in place and they have been delivering solutions
over a long period of time. A demonstrated ability to make on time deliverables
are probably the most important thing to consider when picking a developer.
It is a tough issue and one that as a buyer of Web services I address with
my colleagues at CBS on a frequent basis. What we have found is that a lot
of developers will come in and tell you how great the design is going to
be and how phenomenal the technology is going to be but those are issues
that are less important for our goals than one would think. We really need
a developer to come in and say "What do you want to say?" so that we can
work with them effectively to figure out the best way to say it. It is like
the great IBM commercials where the two people are sitting in front of the
computer talking about how they can make their logo spin, catch on fire,
and attract people's attention. Then they stop when they can't answer the
simple question of how they can sell stuff on their Web site.
Well, thanks for the great plug [laughter]. I do think the client is responsible
for misdirecting the nature of the search. If the client is unfamiliar with
the real value of the Web as a medium, they are the ones that encourage
developers in the wrong direction when they are impressed not by solutions
but by those spinning logos. If you are an auto dealer, you really want
to work with your Web developer and focus the discussion on how you can
use the Web to structure and extend your business. The discussion should
not be about the technology. It should be about who you are and where you
are going.
But I do think expertise should be an important question that clients should
ask. For example, at IXL we focus on a couple of verticles where we go very
deep--we have two companies that just focus on the travel market. When we
go into meeting with travel clients and we've already worked with lots of
hotel chains and lots of airlines we know their business intimately to a
degree that is a huge advantage for our clients. Understanding a clients
business as best you can and going in with an intelligent pitch that really
tells your client how to use the Web as a marketing tool is essential. That
is what clients should be looking for.
Should a client be looking for a developer with an expertise in their specific
industry?
Well, as developers we are expected to know such a broad scope of businesses
and it is not like you are in the advertising business where you might only
be responsible for the development and projection of something like brand.
Often times, you are digging very deep into the core of a company. You might
be involved in their IT strategies, their infrastructure, their sales, marketing,
etc. You are really fundamentally changing how that business is going to
operate into the future. In order to do that in an intelligent way you have
go to know that their business as well as they know their business to create
the vision they need for the next century.
It depends on how involved you are. Sometimes you work with the ad agencies
for the client directly and they handle the branding, the creative platforms
and all of that documentation is given to us to implement. Sometimes we
do take a step back and include an account rep who understands their industry.
It depends at what level you are when creating the strategy.
I am not sure that it is necessary for the developer to have the experience
with the same type of client, but I do think it is important to find out
whether or not the developer has the team with the capacity to develop the
knowledge necessary to do the work in order to understand the businessÉ"
there are people on this team who have the knowledge necessary to do the
work in order to understand the business.
I think every client needs to be told that they are going to have to invest
an awful lot to help the developer understand a lot more about your business
than just what industry you are in. In fact, it appears the Web is so much
the integration point across so many aspects of a business. Your Web developer
or Web partner is going to end up knowing more about your total business
than your ad agency or any other partner that you might have.
You also look for specifically, not people who have experience in your industry
as much as people who are known to have done certain things well. For example,
who does the best database.
At the end of the day, you want your site to be able to function. You want
to make sure that it is an easy site to use and that people can navigate
through it and there isn't a big wait. If it is a database driven site,
a huge part of that is database integration and at IXL that is one area
where we also have a huge amount of specialties. But at the same time, I
think that, for especially an entertainment client, having a great front
end that extends their brand is also a crucial part. So a client must really
weigh the technology versus the creative and making sure that you are picking
a partner that can deliver both--or you can go to two different companies--one
for functionality and integration, and the other one for design.
This is one of the ways in which the world is changing because of the convergence
of media and transaction. Historically, when you look at the advertising
industry, there developed over time relationships between certain agencies
and certain clients, some of which were incredibly successful and went on
for 20, 30, 40, fifty years, and some of them are still going on today.
There are fewer today than there were ten years ago for various reasons,
but I think that what is going on with interactive media raises that to
a whole new level. It really is a question of bringing your media partner--the
Web company--in more than just as a media partner. You are really asking
them to be part of your business strategy. This means, I think, that just
as I have to understand what business my client is in so that I can be a
good lawyer, developers will have to really learn and understand their clients
business. I think this is necessary because they have to make decisions,
offer up recommendations and give advice on which really affects the nature
of the client's business.
I think that what is happening right now is a function of the youth of the
Web industry and its relative newness. People right now are differentiating
by skill sets whereas in the future there is going to be a vertical segmentation
of companies by type of industry. Technology integration is simply going
to be a minimum level of entry.
IXL right now is focusing on five verticles and we have a breadth of products--everything
from laptop presentations to database integration. I've also spent the last
few months that I have been on board layering and putting into place some
world class designers so we have that aspect as well and we also have rather
extensive client services. So, at the end of the day, we can go to a client
and say, "we know your business extremely well and you can come to us regardless
of what your digital needs are."
I don't think it is going to be possible for a company to do that successfully.
At the risk of making a prediction, I think you will see in the next two
to three years separate companies. There will be those who are interactive
architects and those companies who specialize in understanding the business
transformation side of it who will act as integrators to the services that
Web developers provide today. The reason I say that is that it is clearly
too big a stretch for one company to do all of that well.
Well, we don't look at ourselves as a Web developer, we look at ourselves
as a technology company and we layer the other services on top of the core
strategy of what we do.
But it is like saying to Ogilvy & Mather, or any other ad agency, "I want
you to be responsible for business transformation as well as brand stewardship."
The people are just too different. It won't work.
I understand your point, but IXL's culture did not grow out of a design
agency.
True, but still you can't have your design folks and your technology folks
and these business transformation experts under the same management. The
businesses are too different.
Dev, I think what you are touching on is this idea which is floating around
in our industry regarding who specifically owns the client relationship.
Is it the consultant? Is it the ad agency? Is it the developer? On top of
that, there is an emerging kind of company that will be the integrator,
while at the same time, there will continue to be these very focused database
shops, design shops, and the emerging information architect company as an
additional layer.
Peter, that is very interesting thought. And, in some companies, those information
architects will also work for the same company. By that I mean they will
work in a different group at the client's company. It is a very difficult
thing to pull off under one roof. As we say in the pure consulting area
all of those businesses that try to have that and accounting ,or have that
and something else have ended up fragmenting, splitting, or just fading
away.
I think that is very insightful. As our companies try to transform to the
next level I think that is something we are all struggling with--how do
you become an integrator and a developer under the same roof? Their motives
should be very different. And the question is how do you maintain that autonomy
under the same umbrella? I don't know that I agree with you completely that
it can't be done, I think there are some ways but it definitely needs to
be looked at as two separate businesses.
I agree and I think that it is because, in a way, we are really talking
about two separate functions. One is the business strategy side and the
other is the implementation side. On the implementation side, my opinion
is that you can't separate technology and design.
This all might be true, but I don't think the industry is ready for that
until clients become more savvy with how to manage all of these different
aspects if they are going to go to different companies. One thing that I
find very interesting about working at RGA is that we have a great studio
side that does special effects, broadcasting and commercials--they are pretty
well known. Their big joke is that they have clients, unlike the interactive
side, that have been doing this for years and there are processes in place.
So on their side of the business, to go to different shops for different
things is very simple because they have been doing it for years. And then
they look us and we are just trying to teach a client what a Web site means
in some cases and there are no processes in place--there aren't even conventions
developed yet. So you have to get to the point where there is an understanding.
Skills on the client side are tantamount to the skills in organizing where
we would like the industry to be.
That's interesting. So the evolution on the client side is to know enough
so that they can hire directly or enough that they can successfully hire
a consultant.
After they have picked the right developer does a client need to know what
they want to do on the Web? I've heard some developers express the idea
that it is preferable if a client has a pretty good handle on what they
want to accomplish before they start working with their developer.
I disagree with the idea that a client has to come to you with knowledge
of either the Web or what they want to do there. I think that is part of
the challenge. It's not that we encourage it because it is more of a challenge,
but when you can think of structuring the business relationship with a client
so that you can encourage them to be a part of the creative process, you
will ultimately have a better product.
Conceptually it is a good idea to educate the client about what they want,
but that is part of the problem of how bad contracts get structured. For
example, I have seen a several situations where a client comes in and doesn't
have a confident idea as to what they want to do on the Web. Typically,
they wind up with an agreement that had to be continually adjusted almost
every week and they wound up six months behind on their project.
I think the scoping idea--which I've recommended to many clients on both
sides--is a helpful contractual technique. It enables the client to take
the necessary time to develop the concept for what it is that they want
to do on the Web and at the same time it protects the developer by setting
the terms of the relationship and defining exactly what the project will
be. In that scenario you really have two phases of the project with the
first phase being essentially the creation of a contract for the scoping
document and the second phase being the actual development of the site.
I agree. From our experience, the Web development industry is moving in
that direction--where you have the development of the concept of what needs
to be done as a separate process from the actual implementation of the work.
In other words, in terms of scoping out the project in the form of a document,
it is not simply a one way conversation--it is part of an ongoing dialog
between the client and the developer.
But I think the separation of the scoping from the project is more possible
in some industries than in others. For example, in advertising, I think
if you walk in the door and say "you are going to pay me to scope out your
project" it is not going to work. There you generally tend to bid on jobs.
That's the same with the entertainment industry. Unfortunately, developers
are out there doing a lot of work before you get any kind of a contract.
But if I am one of your clients and I say "you need to come in and pitch
me five ideas of what you can do to help me'" the developer might come in
and say "well here are some promotional things that you might do," and so
on. So you have a few key ideas to start the process and that then leads
into a proposal.
Yes, but certain businesses are more open to that idea than not. I think
for the financial institutions consulting is normal for them. That they
would need to spend millions of dollars on consulting is something that
they are used to doing. So if a developer were to come in and say "we need
$30,000 or $50,000 to develop a scoping document," it isn't such a big stretch.
I think the point is that there is a time in which the Web site actually
begins to be built and a lot of time before that, before the client brings
a developer into the process. We all know that there is this tremendous
amount of planning that goes into the Web development process whether the
client does it themselves, or whether they hire someone to do it with them.
I would just make the case to all clients that it should be done.
The problem is whether you are talking about designing the site from the
ground up, or whether you are talking about outsourcing bits and pieces.
We worked with, for example, Razorfish, on the enormous re-design of our
site. That was a very long contract and there was a very intensive scoping
period before that. We brought them in early enough so that they had an
idea about what we wanted. Unfortunately, a client can't always do that.
Sometimes you are constrained by deadlines, by how fast you have to get
the site up, and who you have to answer to in your company. I've had to
actually outsource to two or three developers different pieces of one site
and that is where you enter into a mess. Developer A has an idea as to what
the site should be and that is different from what developer B might believe
the site should be and you wind up with a patchwork site that looks a little
odd and doesn't function well.
Along the same lines, Vlad, these sites are no longer discreet units. It
used to be that we would do the Elecktra site and it would be a self-contained
autonomous thing that would be on the Web. But now it actually is linked
to and involved in all of these different business units and it is an ongoing
consumable thing that needs to be addressed.
My only point was that the planning has to be done and I would recommend
all clients take the time to do it. I prefer to do it with my client than
have them do it by themselves and that is not strictly because of the idea
that planning is part of the revenue generating process. We don't build
Web sites for our clients as much as we focus on becoming their partner--it
is the only way that you can solidify a business objective. The best way
to do that is to come in at an early stage with enough time to have it benefit
the client.
It is also a little frustrating when you come into a project and you get
an RFP and you understand what the client's goals are, but with your knowledge
of the industry or the medium you would like to recommend something that
might be much better but because it is completely different you can't.
I think we all agree that you have to do the planning. You have a better
chance of success if you do the planning with the vendor that you want to
do the project with. But that brings us to the issue of the financial relationship--is
this a retainer based relationship where I am going to contract with you
for the next two years to continue to build my site, or is this a straight
work for hire, one off job?
Dev raises an important point here. We all agree planning is good but how
is the relationship between a client and a developer structured during that
process financially? It seems like there is no standard method for determining
that aspect of the relationship.
Several years ago we always worked on fixed fee projects and now we have
transitioned to only working on the basis of time and materials. Generally
that involves estimating projects, but it is time and materials which sets
up the possibility of having an ongoing relationship which will last as
long as it is still positive and productive partnership.
For the first year, your relationship with any developer has to be on a
time and materials basis. I say that because probably, if you are being
honest, you are going to fire them. The chance that you stay with the first
developer that you select is pretty slight. But once you get a good relationship
working and that partnership established a retainer makes sense for both
sides. So my position is do not start out with a retainer initially but
have the relationship grow into that.
For us, we are not in a constant relationship with the developer. There
are different partnerships that we have with various companies that are
helping us manage various pieces of our technology. We work with Oracle,
Razorfish, a whole different group of people who come and go. It is not
necessary to have a developer, at least for us, under contract. We sort
of farm it out when we need it.
Going forward, I think the way to have successful projects is to establish
longer term relationships with a developer I can speak for the development
side when I say it is much more difficult to come in on a one off basis
on a project and hit everything right off. The client has a history and
as a developer coming in you get an RFP or a description and you go in and
do the best that you possibly can for what you think the client wants but
you don't have the background on what drove those requirements. So you get
half way through the project and the client has a committee that has to
make decisions and you have to make decisions on the fly and frankly, in
our industry, as in all industries, sometimes you make good decisions and
sometimes you make bad decisions. So I think that at least we are seeing
it in our business with our clients that it makes more sense that we get
not necessarily a retainer, but some kind of flexible contract over a period
time where there is some kind of float. For example, it could be between
this number and that number and it is time and materials between that.
I think that might be fine, but I do think we are being unrealistic. I think
that one of the biggest problems that we face in the financial relationship
is that a lot of companies get into trouble on the money side, for example,
because they have completely unrealistic expectations. They are not realistic
as to what it is going to take to design something or to integrate something
so they start to parcel it out bit by bit paying as they go along. They
are unlikely to opt for a retainer-based relationship. Then you get into
trouble because a lot of developers, especially smaller developers, will
come in and pitch completely unrealistic prices and that is a huge problem
because you start having expectations and those expectations are not because
it is physically impossible to meet them under any circumstance.
There is an interesting thing that is starting to happen in our industry
with this consolidation that is taking place. With the current wave of "roll-ups"
that are happening, there is this tremendous land grab going on. It is important
for these companies that need to hit 50, 60 million in revenues because
they have investor expectations to grab as much revenue as they can. One
of the things that we are seeing is that suddenly these companies that have
been historically the high bidders are coming into projects tremendously
low. I think it is something that is a trend that we are likely to see going
forward.
For the record, Chris is referring to the strategy of some of the larger
Web developers to purchase smaller companies that might have a specific
expertise or be located in an area where the large Web shop perceives that
they will need to be able to offer client services.
I don't think that
is entirely it, Chris. It is also that clients are becoming more savvy.
They know what their projects should cost and what is realistic. If we
go in and we low-ball it, they get it. Also from the entertainment standpoint,
a lot of times going into a project within these corporations there is
a resistance to spend too much money in the space. Instead of looking
at the long-term vision of "where and where should I be five years from
now?" Web work is far more piecemeal.
But that is quickly changing. Within a very short period of time, say 6
months, all of your major clients are going to have a VP of Interactive
Marketing, or VP of Interactive Services. If I think back a year ago, if
I tried to find my peer in one of our clients it was pretty difficult. We
are quickly coming to the point where I think shareholders will revolt in
a couple years time if companies don't declare what their interactive strategy
is going to be. It is that important.
I think you are right. IBM is doing a great job of that--and I am not saying
that just because I am working on a project for IBM! [laughter]. IBM is
doing what I don't see a lot of other companies doing--they are taking their
interactive side seriously enough to incorporate them in all aspects of
the company right down to the branding messages that get moved around throughout
the company. It is one of the things that I can't change as a developer.
But I would love to advise a client to change the support structure for
the Internet at any company because often times they are segmented away
in a small office and they are not incorporated as much into the company
as a whole. Whereas you may have coordination with print and TV, you don't
see that when it comes to the Web on the Web sites.
I think you make a good point. One of things I would like, part of the pitch
I would like from a Web developer, would be to say "here's the organization
you should have on your side." Before we start this process, or maybe part
of the consulting engagement, is to look at my organization and determine
who should be the lead interactive person and where you should put interactive
people in your structure--sales, marketing, management and so on. I think
that would be a very powerful model for ensuring success.
Let's talk about the legal issues that every client, and their developer,
should address. It is, after all, becoming far more important, is it not?
What aspects should clients consider when it comes to legal issues of Web
site development?
Having a clear written legal document that sets forth the requirements of
a project is crucial to starting a relationship with a Web developer. Those
things are always a function of a particular situation and I've never seen
the same exact situation twice. Each one is slightly different and what
I advise my clients is that you want to do business so you have to be accommodating
and that's where you have to be creative. My job is to help the client be
creative in solutions to satisfy what the client wants as far as structuring
an arrangement, how the contract relationship is going to work, at what
point parties can opt out, make changes, and so forth. I'd like to hit a
slightly different point and throw this out to the table for discussion
because I've been involved in what we traditionally call new media for fourteen
to fifteen years. In the old days, my clients tended to be what everyone
else would perceive as crackpots. You had to be a crackpot to be in this
business back in 1985. One of the things I remember most vividly from those
days was being told that copyright is dead. I remember everyone feeling--now
it is a good laugh but back then it wasn't such a crazy thought--you had
this gigantic copying machine that would exist and it seemed pretty obvious
that you couldn't control copying of intellectual property and therefore
copyright couldn't exist. And, of course, what we've learned over the last
several years is that more people are aware of these issues today than ever
before. If anything, copyright is more critical to our lives and critically
here to the success of business because indeed what we see going on right
now, and what will go on for the foreseeable future, is the creation of
more intellectual property assets ever before in our history. I think that
the businesses that will be successful--the survivors--will be the ones
who understand what intellectual property is and how best to exploit it,
to identify those things that are significant and make sure that they are
protected for their use so that they can generate revenue from them. I rarely
talk to people who have any sense of that issue. But when you talk to people
on the application side about technology they have plenty to talk about.
I think the law and the issues of copyright--and all intellectual propert--is
as equally as important.
I agree. As a client this is where you need a lot of input from your develope--and
developers need to be able to provide this service to their clients. Whether
its finding intellectual capital in your organization that can be used on
the Web, right on down to advice in managing privacy, for example, where
there are a number of issues that someone building a large Web site might
not have any idea about. It is the developers that are the thought leaders
that can advise their clients on what to do and what traps to avoid.
I agree and those issues, of course, change depending upon who the clients
really are. For example, we are doing a big Web site for kids and there
are a lot of issues in the television and the entertainment world that are
pretty traditional limitations put in on that space. At this point, in the
Web space, there are less specific limitations and you create your own limitations
based on not wanting to potentially get into areas where you think there
is a vulnerability whether it is perceived or real.
That leads to a phenomenon that you see happening every day. You have a
convention in traditional media that is not taking into account the possibility
of what can happen in new media. So new media ends up as a driving force
which causes a rethinking of the convention in traditional media to the
point in which traditional media is no longer bound by its former restrictions.
As a client at an entertainment company, I have to agree wholeheartedly.
For us these issues are some of the biggest stumbling blocks to creating
a successful Web site. I work specifically on special projects, which is
Web sites specific to a particular show on the network, such as David Letterman,
and for us, these legal issues are perhaps the most significant aspect of
our development process.
Fortunately, there are a lot of institutions that are becoming more open
with their content. In the past they may have been very closed, guarded,
and secretive about it and generally suspicious of the whole Internet. Now,
while they might still be protective of their content and rightfully so,
they are much more open and there is the potential that you can work with
them.
Still a huge part of my day-to-day operations center around the management
of content issues. If I had to make an estimate, I would guess that thirty
percent of my time is taken up by trying to figure out where my content
came from and where it can be used. And that is something that should be
pointed out to clients that are building Web sites. They need to be careful
about their developer making assumptions about what can be used on a Web
site especially given that they might not be expert enough to make such
claims. For example, with media companies, content can only be used on one
specific context. We might get the rights to use one Bettman photo archive
only on a page that we create in conjunction with Time magazine and only
on the third page for only one month.
It is important, no question, for but us as a developer a lot of what we
are creating is the tools for business to change the way that they do business.
These are very literally the businesses themselves that we are creating
so we have to come up with innovative ways to actually transform or convert
existing traditional business practices into a digital environment. For
instance, for Schwab where we are building their trading environment, it
is actually coming up with ways to structure that information and making
determinations about whether or not to buy or build software, not so much
content acquisition. On the flip side, Razorfish has a very narrow client
focus--financial institutions, media and entertainment, cultural institutions,
and technology companies--and we are not developing sites where the site
itself is not the business. For a lot of the media companies the kind of
content that's being produced is the business. Razorfish Studios, which
is a separate company, is in fact working from the point of view that the
idea comes first and how it's actually delivered is second. Whether it is
a book, music, or a Web site, what is more important is the end view of
getting the message across.
Outside of the media and entertainment industries, however, content is not
an issue in the same way. We actually license content for some of our clients
to enhance the offering available on their Web site. So in that sense we
are having to face those issues up front. We are approaching the hurdles
to begin with. We are not putting up a large amount of content on our site
and sorting out the details later. The details for us, and I assume for
most corporate sites, come up front so it is handled differently.
I think that when it comes to what we call the entertainment vertical, a
lot of the sites are an extension of the existing puppy, that is they are
more of a marketing driven site. With the financial institutions you are
often building tools for them or things that require a certain amount of
functionality. On both sides of it what we are looking at a lot at IXL and
the company that IXL originally grew out of in New York City was a company
that specializes in self-generated content. They had what amounted to the
largest sports game on the Web called Small World Sports, which is a site
all about dynamic content--database driven content. So I think that in order
to cut costs, avoid potential legal issues, and make it beneficial for entertainment
companies to be able to put content up on the Web, you have to find efficient
ways of developing original content. Content that is not too expensive and
cost prohibitive because at the end of the day we still don't have a mass
media platform. You can't justify spending the kind of money you could on
television, for example.
The situation has changed a lot also from five years ago in the sense that
companies that we work with are getting electronic rights up front and that
is a big difference from where we were. Five years ago it was a big challenge
and we had to cut content because a company didn't have the research staff
to do the kind of research or renegotiate and even track people down in
the first place. Now what you see is the rights are already taken care of
and addressed up front. So, overall, rights are not the big issues they
once were.
I think a big part of the problem is this continuing concern about protecting
those assets and the sense that once something is digitized and made available
to people over the Web it has a life of its own, which indeed it does at
some level. It is unquestionable in my mind that it is something that needs
to be carefully addressed. I also firmly believe that no one has come up
with a solution that will work in the future for all media--text, pictures,
video, sound.
I think that if I were advising someone who is building a big Web site that
they do actually try to get as much of their own content--and they can license
content as well--because it is so very useful to users who visit their site.
To take the example of an insurance company, the site that has the requisite
product information and rates as well as how to choose an insurance policy
and some of the other things that people might really want to know, is definitely
useful. We all have to be sensitive to the intellectual property rights
of our own content as well as the content that we license. But the reason
that we are having this conversation is that it is useful to our audience
and that cannot get lost amid the discussion of legal issues. Content might
present legal challenges but we can't not have it.
I agree. I am a lawyer and I deal with these concepts daily--they are my
tools. But I also understand that business people don't function like I
do and they have other needs. The legal requisites, as important as they
are, have to be placed in perspective to the overall situation and what
the client is actually trying to accomplish. One of the things that I try
to do is to help the client think through a sense of perspective when we
have to deal with issues. So, for example, if there is a particular problem,
say they want to use a piece of material and there is a problem, I think
the most important thing that I can do is identify what the problem is and
look for a potential solution. What I would say to the client as good business
advice is "you are not in the interactive business and you are not in the
computer business, do you think you can assess content and build a great
Web site yourself?" The answer is that if you do, you are out of your mind.
You need expert help and you don't even know where to go for that. What
you really need to do is go out, talk to people, research and educate yourself.
And then try to find a company that shares your values and what you are
trying to accomplish. Hire them and make them part of your team. You can't
let the legal issues stand in the way of growing your business.
I would like to add one last note on the legal discussion. Today, Web developers
are building more than Web sites--they are building business solutions.
For example, we just built an extranet for American Express. The big concern
for us is where does liability begin and end. For example, suppose there
is some kind of security infiltration of a system or some kind of damage
to a client because of something that a developer did or failed to do. That
is a really huge issue that is not adequately being addressed. As we move
into these larger, more far reaching projects, that is where the greatest
risk is.
Sounds like a great topic to start off our next roundtable.
|
|
ISBN 0-471-31289-4
400 pages
October, 1998
Wiley
Computer Publishing
Timely. Practical. Reliable.
|
