Making a Home for Your Intranet, Part 3

By Paul Chin

Originally published in Intranet Journal (12-Dec-2002)

back back to portfolio

Building your own house with a couple of buddies from the local softball team seemed like a good idea two months ago. Your shortstop has some basic carpentry knowledge, your catcher "has a guy" who can supply material at low cost, your leftfielder has more tools than a Home Hardware store, and you've always wished you were an architect—key word being "wished."

Now, with the foundation sinking into the soft soil beneath and the load-bearing walls unable to withstand the weight of a nest of pigeons that decided to make their home on the roof, you begin to realize that you're in way over your head.

In my last article, I presented five core questions that you need to ask yourself before committing to an in-house intranet. After exploring those questions, you should have a better idea as to whether you're ready, or able, to construct your own intranet with in-house resources. Building in-house is not for everyone. There's nothing wrong with admitting to the fact that you can't cut a straight line or use a power tool without having someone perched by the telephone with 911 at the ready. Every company has a different set of circumstances. If you find that, for whatever reason, building in-house is not a feasible solution, you may decide to outsource the project to those who build intranets for a living.

Here in Part 3, I'll be discussing some of the key issues you need to take into account during the selection process and, eventually, signing a service contract.

Let's quickly review the pros and cons of outsourcing:

Advantages of outsourcing

Disadvantages of outsourcing

As I mentioned in the very first part of this series, it requires a tremendous amount of effort to build a home from the ground up. You need architects to design the framework and infrastructure, carpenters to build what's been drawn on paper, interior decorators to design the look-and-feel, electricians and plumbers to make sure the lines and pipes go to all the right places and the alarm company to install security measures so that no one sneaks off with your priceless artwork.

Selecting the right people to do all of this doesn't mean flipping to a random section in the Yellow Pages and hoping for the best. Hoping for the best is what you do just before you roll the dice in Las Vegas. For an intranet, you need to do your homework.

The good news here is that any company with a TCP/IP-based network has already built a large portion of the house. This means network lines have been set up and security measures—firewall and proxy server(s), back-up and restore procedures, disaster recovery and data redundancy—have been established.

Before you go jumping at the first person knocking at your door, find out as much as you can about the people you're entrusting with your project. Here are five key points you need to consider before signing anything:

  1. Background, credibility, experience, and knowledge
  2. Talk to previous clients
  3. Are they willing to work on-site?
  4. Knowledge transfer and training
  5. Post-production support

Background, credibility, experience and knowledge

Obviously, if you were building a very elaborate home with a large skylight, marble columns flanking the entrance and a master bathroom with its own water filtration system, you would want to hire reputable and experienced contractors who have been around the block for some time. The last thing you want is to entrust a project of this magnitude to someone who calls himself an expert just because he finished watching a 10-hour This Old House marathon.

There are hundreds of intranet-specific consultants out there ranging from large IT firms to a single person working out of a home office. What's the one common link between all of these varied consultants? They all consider themselves experts. This, of course, is a subjective issue. One person's expert is another person's novice. It's much like the saying, "All poodles are dogs, but not all dogs are poodles."

Finding credible and experienced consultants is the most important step in outsourcing your intranet project; some have set up a solid foundation in the IT industry and others have built their reputation on word-of-mouth. You can do some initial research in IT trade magazines and on the Internet but don't allow yourself to be swayed by marketing. A shiny wrapper could simply be a mask for inadequate experience.

As you go along, make an informal list of potentials that meet your needs. Factor in any special circumstances that relate to your operation such as the need for one of the NATO Clearance Levels if you happen to operate under very strict security standards (but this is a much broader discussion for another time). You can then narrow the list down to three strong candidates and put them underneath the microscope, comparing things like client base, service offerings, price and experience.

Talk to previous clients

There's no better way to determine the quality of consultants' work than by reviewing what they have previously accomplished. By speaking with your potential consultants' past clients, you get an unbiased opinion of their services (unless, of course, they're receiving kickbacks for referring new clients, but let's not get overly cynical here).

Some of the questions you need to ask are:

Are they willing to work on-site?

Communication is the most crucial aspect of the client-consultant relationship. All too often time is wasted when mistakes occur as a result of one party assuming the other sees things in the same light. Reality dictates that, unless there's a clear communication of thoughts and ideas, this rarely works out to either party's favor.

The importance of this issue is even more apparent when the consultants work in a different location or time zone. Can you imagine what would happen if you needed clarification on something written in the project specifications and the turnaround time ended up being a full day? The project could come to a complete standstill while everyone sits around waiting for an e-mail or voice mail message to be answered.

Whenever possible, have your consultants work on-site. This way they are more accessible to answer questions or deal with problems. Remember, they want your business so they have to accommodate you, not the other way around.

Knowledge transfer and training

It's important that, after your intranet is put into a production environment, you know what to do with it. You need to know how to maintain and populate the site. Otherwise, it may seem as though you're dealing with some strange and foreign object, poking at it with a stick from a distance.

IT people have an ingrained habit of not always telling you everything you need to know. Call it absent-mindedness; call it self-preservation. IT professionals who are on the ball will be aware of what you'll need to know about the new system you've just adopted and will be open to your questions. Poor IT professionals, on the other hand, assume you already know everything they do.

The point here is to make sure that you get all the information you need from them and that they provide your internal intranet management team with adequate training on site maintenance and basic troubleshooting.

Post-production support

Don't pay the ferryman until you get to the other side.

Clients must have some assurance of reliability and support after the consultants have met all hard deliverables ("hard deliverable" being the completed Web site; "soft deliverables" being support and training). I've seen too many businesses fall prey to, what I call, the hit-and-run consultant. They come in, do a sufficient job, and take their money and run like they just broke out of jail.

It's important to include a certain amount of post-production support or follow-up in your service contract to avoid confusing "Why did they put that there?" moments that may not have been encountered during the quality assurance phase of the project.

Before signing the contract...

Aside from the five points I mentioned above, you need to be aware that a good consultant will ask you what you need rather than tell you what they think you should want. To illustrate this point, let me leave you with my favorite story about the importance of choosing the right consultant when you decide to outsource your project.

The following program is rated PG-13. It contains scenes of violence and course language. Viewer discretion is advised.

Long, long ago, in a corporation far, far away, a mandate was created to overhaul a company's intranet and Internet site. They decided, for whatever reason, to outsource the project to a design firm despite having more than enough available and experienced personnel in-house.

The internal IT department was not consulted or asked to be involved during any stage of the selection process. Like some secret buried deep within the Mayan ruins, it's unclear what criteria they based their decision on, but suffice it to say they thought they made a good choice and paid a hefty price tag for it.

The consultants worked from a remote location and held semi-regular meetings to follow-up on things. The day-to-day level of communication between client and consultant was adequate at best. After several months, and a few hiccups later, they delivered the end product: a brand new Web site.

The beauty of Web sites, of course, is that they're built and based on open standards. This consulting firm, however, delivered a site that was tightly integrated with their own homemade Web site management tool. They bragged that their in-house developers had spent years fine-tuning this tool and was supposed to be simple enough to use even for the non-techies. The intent was to allow their clients to manage the site by providing functionality to upload new information, edit exiting files and make site architecture changes all with the click of a mouse. Unfortunately, the site was locked into the site management software and it was maddening to try to do something outside of their environment.

The ineffectiveness of this tool came to light when it was unleashed within the internal site management team. Its functionality was completely counterintuitive to the way Web sites were supposed to be maintained. After days of frustrating, non-stop wrestling with the tool, several internal programmers got fed up with trying to figure out why it doesn't do things properly and reverse-engineered the software to get it to work.

A telephone call was then placed to the consultants who promised that these issues would be addressed in fabled "next versions."

"You guys have designed sites for other clients, right? How did you manage to get around these problems when you designed those other sites?" they asked the consultants sternly.

A slight pause on the other end of the phone raised tensions as they mulled this question over. When they finally chimed back in, they simply stated, "Oh you see, we don't use that tool when we design our sites."

What's the lesson here? Never trust a carpenter who won't use his own tools.

Copyright © 2002 Paul Chin. All rights reserved.
Reproduction of this article in whole or part in any form without prior written permission of Paul Chin is prohibited.