Beyond the Valley of the Launch

For years, I’ve been telling people that I know what works for web sites. But I have a confession: I don’t know because I’m not psychic. For most of us, our job is to decide what’s most likely going to work through research, updates, trial and error, and testing. And lather, rinse, repeat. And just as every individual is unique, so is every company. To paraphrase the theme song of “Diff’rent Strokes”, what might be right for you might not be right for some.

But I have learned what doesn’t work for sites. In the spirit of this post, I’m going to try to post these on a more regular basis. In my last post, I discussed the importance of updating old content, but I didn’t mention the process behind it.

First tip: When you launch a new website, application or feature, look beyond the launch. Like I’ve said before, a launch is like a birth. It is exciting, but it’s not the end. I’ve witnessed too many websites, microsites, blogs, and other ventures that simply died on the vine because the people behind it didn’t plan beyond the launch. They figured, “It’s done, so I’m done.” Or, they simply ran out of enthusiasm for the project and moved on.

I admit I’m guilty of this. I revamped this site last November with the intent of blogging regularly, showcasing my years of expertise and posting on LinkedIn and other social media. But I also knew that I had a day job and family responsibilities that are my priorities. That’s why I never blasted an announcement “Hey everyone! I’m starting a blog!” This is site is really just a fun hobby for me. I don’t have customers depending on my content here. But I’m going to try to be better.

The basis of this thinking, besides good old fashioned procrastination, is that the web is still a fairly new commercial medium when compared to print, which is about 600 years old, and broadcast, which is about 60-90 years old. Companies are still struggling with how to build and maintain their sites from a corporate standpoint.

What we’ve (hopefully) learned over the last 20 years is that web sites are not print pieces. Basic branding and messaging is carried over and they contain words and pictures. But that’s where the analogy ends. In my opinion, web sites should be created and maintained more along the lines of software. You have a team of people who manage, produce, code, design, write, test, and ultimately launch your site. And then you have subsequent upgrades and releases. But even that is not a perfect analogy because they are different media with different functions.

Even if companies look slightly beyond the launch, there are other mistakes they are making along these lines:

Relying on one person. In most companies, there’s that one person who has been with the company since God was a child. They are like Yoda. They are wise. They know all. In transposed sentences they speak. Or there is the enthusiastic go-getter who has their fingers in so many pies, that they just know how everything works and where the bodies are buried. They are like Red from “The Shawshank Redemption” – THEY are the person who knows how to get you things, despite what they org chart says.

While nobody says it in the planning or post-mortem meetings, it’s unspoken that this person will be responsible for your site if anything needs subsequent updates and they will fix problems should they arise, so you can move onto the Next Big Thing.

Not only is this unfair to that individual no matter how well you pay them, but it is a very dangerous practice. The person you are relying on is human. He or she will get sick. They will go on vacation. They might even die, or to be less morbid, they might win the lottery and tell you to suck their fat one.

Or less dramatically, they might just quit for another job. Even if they give a few week’s notice, it’s the rare individual who really gives a rat’s patoot at this point to painstakingly train the remaining staff. And even if they do, chances are there’s something they are forgetting. You’ll remember what it was about 10 minutes after he/she leaves the building.

It is a good practice to cross-train personnel in different areas on a regular basis. You might even look at switching responsibilities on a regular basis to keep them on their toes and from getting bored and stale in their skill sets. This way, in the event someone is unable to fulfill their responsibilities, someone else can jump in without missing a beat. It works for Miss America, it will work for your web team.

Relying on an outside agency. I have nothing against agencies. They are wonderful, cost-effective resources when you don’t have the experience or bandwidth in house. And they help you add a needed objective perspective when you get too close to your product or project.

However, they are not committed to your company the way that on-staff personnel are. Once they are done and paid, they will most likely move onto other clients. And like individuals, agencies also come and go. Sometimes they just up and fold due to economics. Sometimes, they decide that they need to drop you as a client. If you are fortunate, they will give you ample warning to find an alternate agency. But more often, you will just pick up the phone one day and find the number has been disconnected and their web site generates a 404.

If you work with an agency, add a clause in your contract about training on-staff personnel to maintain the site after the launch.  If you use an outside ISP, get all usernames and passwords to ftp and the control panel. And while you don’t want to publish this information for the world to see and hack your web site, give this to more than one person (see above note).

If it’s not feasible for the agency to train your staff because you don’t have the personnel, time or skill  set, agree to a regular maintenance plan. Ask all the questions you need to ask.

Whether you develop in house or outsource, don’t make the mistake of…

Not having documentation. Whether you work with individuals in your company or an outside agency, there should be some documentation about your content, structure, and processes in an obvious and easily-accessible area. This should not be some guarded pirate treasure that requires future teams to know the airspeed of an African swallow in order to access it (yeah, I know I mixed movie references). And keep it updated. The document shouldn’t list staff members who left the company years ago as contact references.

Next in the series: Don’t be a copycat and the screaming Me Mes!