“Internet time” has made us all crazy. The idea that innovation and businesses move faster on the Internet is pervasive. It’s even the reason that Warren Buffet won’t invest in technology companies; at his last Berkshire Hathaway shareholder meeting, Buffet said, “We have no religious belief [to not] buy into technology companies — but we’ve never found one where we think we know what the business will look like in 10 years.”
Ten years? There are others out there who are unsure of what it will all mean in 10 months. With tech stocks up and down (and then up again), changing technology, and increasing competition, business are clamoring to get a new website or site redesign to market. But in the rush to market, the end results can be shoddy and can cause big problems down the road.
One element that is missing from this kind of rapid website development and deployment is documentation. After all, contractors don’t start renovating without a blueprint — why would you renovate your website without a real plan?
But planning takes time, which, ironically, is the main argument against it. As a website developer, I’ve dealt with clients designing new sites or updating their current sites who make statements like, “This is the Internet! If I don’t have this done by the end of October, I might not be in business! I don’t have time to write everything down.” And at this point, the person making the comments usually takes a big swig of black coffee and gets up to refill his oversized mug.
The net-time craze can be contagious. As a website developer, I have to admit there are times when I’ve taken a one-page description of the work to be done and handed it off to a project manager: “This needs to be done by October — give the client a call if you have any questions,” I would say.
The result: By September, it was my staff that was drinking black coffee out of oversized mugs and refilling every two hours. And my project manager had requested a new headset because he’d worn out his former headset in hours of phone calls to the client.
After long days and several rounds of revisions to design, programming and database files, we made it. But not without investing more time than we had estimated — and not without hitting a series of potholes along the road. And after we were finished, I would have to do a pep-talk after launch: “We should all be proud — we made it,” I would say. But to myself I was thinking, “Sure we made it, but at what cost?”
A High-Altitude Attitude
The best planning lays the goals out on the table for all to review and understand. Begin with what can be termed a “50,000-foot view” of the project. What services do you offer to patients? Who’s going to look at your site? What do you want them to do when they get to the site? Then you should condense your answers into a one-page description of the overall project. Let everyone in your practice, from doctors to the receptionist, provide input. Sound too simplistic? You’d be surprised how often people don’t agree on this high-altitude view. But if it gets on paper and is reviewed, everyone gets to speak their mind and everyone gets to buy in early on — not disagree later on.
The next step is to drop down to about 30,000 feet and summarize how the site is supposed to work for the different audiences you’re trying to reach. What’s the process of searching for health-care information, browsing, potentially purchasing products, etc.? Each sentence counts here, because the process dictates all the programming that goes into the site. Change the process, and the programmers you’re working with might end up spending additional hours, days and weeks to make the site work the way you want.
The contractor analogy fits well here: If the bathroom is getting renovated, the contractor needs to know where the whirlpool bath is going to go, right down to the inch. Moving that once it’s installed is almost impossible — or amazingly costly if possible at all. Regardless, you will have one cranky contractor on your hands.
Next comes the 20,000-foot view: Describe how the site works on the back-end, and how the site works with your practice. Who receives mail from your site’s e-mail forms? How many people get that e-mail so there’s no single point of failure if Margaret the office manager is out sick? Creative aspects of the site need to be discussed at this level so the designer putting together the graphics for the site has a framework for creating the look and feel of the site. This is where the plans are made to make the site engaging, fun to use and appealing. It’s not good enough to just give a designer the right adjectives — a designer needs to map out the “how,” sometimes with the help of developers, to accomplish these goals. These are important details that can’t be related in a single-page description of the site.
Now you should drop down to 5,000 feet to address the nuts and bolts of how the site looks to the user. This is not programming the interface, but rather using a diagramming program to create the look and feel of how the forms and search results look. These details need to be determined so programmers have a framework for building individual pages on the site.
The final view is a 100-foot one and is for developers only, but this view need to be available to all. It includes the technical details that make the whole site work: boring things like data schematics that include data relations and table content. It might include additional detail such as comments on code objects and how they work with the site. It identifies any third-party software that is used and how it works with the rest of the site.
This section is often overlooked, but is amazingly important in the long-term, because it’s the most complex and technical work. If it’s done correctly, any developer will be able to pick up the documents and get his head and hands inside the system in no time. On the other hand, if it’s not done or done poorly, be prepared for long debugging cycles as developers “learn on the fly” about what makes the system work — and that’s is no fun for anyone.
The Value of Documentation
With all this info on hand, you’re now ready to build. The goals and details are accounted for so developers can see the forest as well as the trees. The glorious launch day comes and goes, and three months later it’s time for the next revision — which is where the documentation shows its value.
What if the original developers are not available? What if you decide you want to take development in house? How does a new staff member get her arms around the site so she can maintain it and help it grow? This is where initial planning is invaluable.
After all, if your hot-shot programmer is moving on to different pastures in two weeks, is all the detailed knowledge of the project going to leave with him? Answer: Not if work is documented.
Planning and written documentation will make projects run smoothly, stay on schedule and on budget. It’s also an insurance policy against job-hoppers and wayward contractors. You’ll sleep better and your site will run better. This type of planning won’t stop the net craze completely, but then a complete stop might seriously jeopardize all the fun we’re having!
