Intranet Journal
The online resource for intranet professionals
Making a Home for Your Intranet: Part 3
Outsourcing Your Intranet - Page 2
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.What's the lesson here? Never trust a carpenter who won't use his own tools.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-engineering 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."