Clear, concrete goals should drive any decision made about the project.  If a requirement or idea comes up that doesn't meet any of these goals, that idea or requirement should be discarded.

FOCUS - On Goals

By D. Keith Robinson

Why FOCUS on goals?

Any successful project, be it Web based or otherwise begins and ends with clear goals.  Funny enough, goals aren't often brought up when talking about Web projects, at least not in any practical manner.  This is unfortunate, and most likely the cause of many Web site failures.  I could point out quite a few cases where this is true, and I imagine if you've been around the Web at all you could find some yourself.  Instead, however, I'd like to concentrate on the solution rather than the problem.

Much of this is going to sound like common sense, and to be honest, that is what it is.  What I want to do is talk about the kinds of goals that need to be defined to make a Web project successful, as there are some peculiarities to Web design and development that might not appear in other sorts of projects.

Three Kinds of Goals

A successful Web project is made up of various goals, each falling into one of three rather broad categories.  Those categories are Business Goals, User Goals and Organizational Goals.  One might argue the semantics of those categories (another common cause for failure on Web projects) but we're going to stick with those labels.  Feel free to call them something else if that makes more sense to you, the labels aren't all that important.

What is important is that to truly succeed on the Web each of these goal categories needs to be addressed in some fashion.  Depending on your project you may spend more time on a particular goal, and that is fine, but don't leave on of these categories untouched.  In most cases these will rank in levels of importance, but a Web project that addresses all three will be better in the end.

Business Goals

Usually these are the most important goals for your Web project, without Business Goals there would be no project at all.  They define the reasons behind doing the project at all.  Most times they will parallel the goals of the business or organization in some way.  If you were looking to sell your product on the Web for instance, a good business goal would be: To sell $10,000 of product through our Web site in the next year.  These goals don't have to relate to the bottom line, but they should be the foundation of your Web project.

Business goals should be fairly easy to gather, but that is not always the case.  In many organizations it may be hard to get all the stakeholders in the same room, let alone on the same page.  Often times different factions working on the project may have conflicting goals, this is fairly common and may take considerable effort to work out.  These goals have to be nailed down before a project can move forward.  If this isn't done the project most likely will fail on some level.

User Goals

Here is where you address the needs of the people who will be using your Web site.  They can be the hardest to nail down and get a grip on, but they are vitally important to the success of a Web project.  If people don't use your site, what was the point?

Gathering user goals can be tricky, but if possible as much effort as needed should be spent to learn what those goals are and address them properly.  The key here is to let the users themselves dictate their goals, not dictate the goals to them.  Some ways to gather these goals are as follows:

While it is true that to gather and address these goals properly, it would be best to have someone working on the project who understands and advocates for users, it is not true that this needs to be a lengthy or costly process.  In general some work done here is better than none.

Organizational Goals

It might be easy to confuse these with business goals, and in some cases they will bleed over, but for the most part they are something totally different.  Falling under Organizational Goals are things like maintenance, communication, personal goals and the like.

The CEO of a company, as an extreme example, might want the Web site to reflect his personality and love of the color blue.  It's a stretch, but trust me, not that much of one.  This goal can't really be considered a Business Goal, but if the CEO needs to sign off on the Web site, this is a goal that needs to be accounted for.

Mostly these goals involve development, maintenance and planning for future growth.  A good Web site needs to be able to expand and anticipate the needs of the organization down the road.  There are many sites out there that at one point or another satisfied the needs of a company but got stale or unmentionable over time.

The Triangle

Now that you have a better understanding of these goals, try to think of them as the foundation of a triangle.  To have a triangle it must have three sides.  A one- or two- sided triangle is a pretty sorry site.  It's ok in most cases if one side of this triangle is stronger that the others.  For example, there might not be a lot of time or money for the project, so User Goals might be something that is addressed in a less than ideal manner.  It's important to note that regardless of the circumstances, all of these types of goals can be, and should be, addressed.

FOCUS on Goals

Gathering these goals and communicating them to everyone involved with the project is the first and most important step.  Along the way these goals should be checked on, not only to weigh the progress toward achieving them, but to assess whether or not they've shifted or need to be revisited.  Keeping them in mind throughout the life of the project will help assure success.

When design and development decisions are made, these decisions need to be held up and determined if they meet any of the goals.  There will be instances when goals need to be weighed against each other, and stakeholders may need to make decisions based on which goal is deemed more important.  Goals can be very helpful in this, giving the team concrete rules to design against.

Clear, concrete goals should drive any decision made about the project.  If a requirement or idea comes up that doesn't meet any of these goals, that idea or requirement should be discarded.  Avoid changing the goals if at all possible.

Upon completion the goals of the project should be looked at in detail and before the project goes live it should be determined if all goals were met.  If there are goals that haven't been met, these can be addressed on an ongoing basis, but if possible all goals should be taken care of before the project launches.

Resources

Comment on this article over at Asterisk*

Send feedback about this article.


Warning: main(/home/sites/site221/web/refer/refer.php) [function.main]: failed to open stream: No such file or directory in /home/.idol/dkr/7nights.com/dkrprod/focus_goals.php on line 124

Warning: main(/home/sites/site221/web/refer/refer.php) [function.main]: failed to open stream: No such file or directory in /home/.idol/dkr/7nights.com/dkrprod/focus_goals.php on line 124

Warning: main() [function.include]: Failed opening '/home/sites/site221/web/refer/refer.php' for inclusion (include_path='.:/usr/local/lib/php') in /home/.idol/dkr/7nights.com/dkrprod/focus_goals.php on line 124