WebRef Update: Featured Article: Software Developers Have Something To Teach You | 2

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):

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! =)

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?

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?

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)?

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:

Clearly define the problems. Develop a complete definition of
what problems you face without trying to come up with a solution.

Gather information that will help you solve those problems.
This includes site builders, product managers, log files and their
analysis, etc.

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.