Software Developers Have Something To Teach You

Analysis & Problem Presentation

Consultants have a hard job. They have to present their findings in writing for scrutiny. Sometimes translating your findings into a document is very challenging. Start by answering these questions (you may also need to expand your definitions or change the questions; this is only intended to be a baseline):

1. What is the site for?
   • Improving the company image.
   • Selling widgets (oooh, widgets!)
   • Providing services to customer X?
   • Building a resource aimed at being acquired or taking a company public?
   • A multimedia playground designed for shameless personal promotion. (Oh come on, you know who you are! =)
2. Why is it needed?
   • Do I actually need to build a new site or is this just another excuse to implement new technologies (well, maybe that's ok... if you have a good enough reason)?
   • Is there somebody out there who I can model myself on who is doing the same thing already?
   • What do my current users think? Why not ask them?
3. Do I have the skill I need to build it?
   • Do you need to hire more people?
   • Is someone else more qualified?
   • Should I outsource?
4. Who am I building it for?
   • Is it a site targeted at specific group of people?
   • Does the organization have a specialized focus on their Web site (like support)?
5. Why do I keep asking myself all of these freakin' questions?

That last one is not a joke. The answers you come up are like a roadmap for building your site. The more questions you ask, the more specific you can be in targeting your issues and your solutions down the road. With all of your notes and information in hand, now is the time to write a problem definition. This entails writing down the results of all of information gathering. Do not skip this step. You may have the information, but until you summarize it in writing, I guarantee you won't really know where it is you want to go.

Problem definitions are distilled versions of what you have found. They usually have a summary, a section where important problems are defined, and a conclusion. I call it the simple presentation format. Here is a sample:

This document summarizes the problems facing successful implementation of the Company X Web site.

* The support section currently refers customers to a Web site instead of providing more comprehensive solutions. Our customer feedback has indicated those customers are somewhat unhappy with this solution. * The Web site currently features the press releases more than five clicks from the home page. This may result in reduced coverage of press releases. * The company currently publishes its customer list to the Web site. This makes sensitive information available to competitors and should be removed.

A small redesign of the Web site, including redesigning the top- level navigation, removing customer information, and adding more content to the support area should result in significant savings for the company.

Now you're ready to begin figuring out the specifics of solving these problems. By stating explicitly the problems you are trying to solve you have already calculated your definition of success, which is key to knowing when your project is finished. Doing a complete job defining the problems will greatly reduce the amount of work you have to do after you get started.

Here is a summary:

1. Clearly define the problems. Develop a complete definition of what problems you face without trying to come up with a solution.
2. Gather information that will help you solve those problems. This includes site builders, product managers, log files and their analysis, etc.
3. Propose a Problems Presentation document for manager and peer review. Clearly define your definitions for success.

Remember, play for the team instead of the individual, stay calm in the face of politics, and feel free to refer back to your Problem Definitions document in the face of adversity.

Author Bio:

Jon Dillon is a 22 year-old author, designer and programmer living and working in San Francisco. He's been working on the Internet since he got out of college in early 1995. He's currently employed at MedicaLogic, making medical records available online. He can be reached through his Web site at http://jon.dillon.org, or email him jon@dillon.org.

Previous: Introduction and Problem Definition

This article originally appeared in the October 14, 1999 edition of the WebReference Update Newsletter.