And your next one probably will too.

I know. You're not in technology. You build things, or you are in a services industry.

Technology projects? Who cares about those?

You should, because technology doesn't exist for its own sake. Technology is a tool, and businesses of all sizes have to leverage technology to get work done that can't be done any other way.

It could be building a Web site. It could be wiring up a network in the office. It could be getting a new, custom-built order entry system.

Whatever the case may be, sooner or later, almost every business owner finds himself alone in a room with a technical resource.

And that is where the trouble starts. Most technology projects are doomed before they even start, and usually for the same reasons. Even if they succeed, the level of success is a lot lower, and a lot costlier, than it needed to be.

But how can business owners, most of whom are not technical, make things work a lot more smoothly with technicians?

Here are some simple steps that anyone employing a technical resource should keep in mind to avoid a failed project.

1. Know what you are trying to do.

A technician coming into a project is usually going to insist on a design document. Think of this as a road map for where the project is going to go. Since most businesses don't know how to prepare one of these, technicians or business analysts from a tech shop will often write the document, after consulting with the business, and present the document to the owner for approval.

Most owners either don't read it, don't understand it if they do, or just skim it. Few take the time to really get into the nuts and bolts of the plans.

That is, until later. In the technology industry, we refer to scope creep as the natural process by which end-users discover what they really want. It is also the process by which inexpensive, quick projects turn into budget-busting disasters as the real extent of the underlying needs becomes apparent.

Scope creep is expensive in both time and money. Many business owners sleep walk through a project up until the time the proto-type is delivered. At that point, they suddenly realize that the specifications they approved don't fit the bill, don't meet the real business objectives, and sometimes don't even make logical sense.

Of course, recriminations often fly, insults could be exchanged, and angry technicians storm off in a huff, sometimes never to be seen again.

The truth is, this is a self-inflicted wound. Know what you are trying to accomplish with your Website, with your new software program, with your new network, etc. I mean really know. Write it down. Read over it. Show it to your spouse. Get input.

Then, when your technicians provide documentation on what they plan to do, read that too. Carefully, and ask questions. Look at similar technology platforms, if possible, to get a feel for how they operate.

Trust me, a little extra time up front will really save both time and money later.

2. Read Up a Little on What You are Trying to Do.

No, you don't have to be a technician yourself. But, try as they might, technical resources can't purge tech-speak totally from their vocabularies. In technology, certain words and concepts are hard to translate precisely into everyday language.

Things will go much better for your Web project, for example, if you take the time to research some of the basic concepts of Web development. That doesn't mean you have to be able to build the site yourself. But it does mean (for example) that if your developer tells you the best way to upload files is via FTP you won't stare at him blankly.

It also means that when you speak to your technician about your wants and needs, that you will be able to do so with some precision. A few weeks ago, a customer told me on a conference call that a Web page was "broken."

Twenty minutes of interrogation later, I finally had arrived at what the problem was. Now, multiple that occurance by 10 and do it everyday. That is a typical project when the owner of the business has taken no effort to learn even the basic concepts underpinning the project.

It leads to misunderstandings. It leads to missed deadlines, and it leads to angry technicians having control over your source code.

That's bad. Do your homework up front. You'll learn a little, and save a lot.

3. Be Specific - Is it a Concept or a Design?

Technicians are usually very literal people. If you give them something that looks like a design document, they will frequently try to turn your design into reality.

Which is great, if it is a real design. The problem comes that business owners sometimes give technicians concept documents. The business owner isn't sure that this is the right approach. The document is a concept of where the owner wants to be, but he isn't sure how to get there.

A technician who doesn't know that, however, might just take this ball and run with it. The results, of course, are a disaster as a pretty solid concept gets morphed into a really badly designed end product.

If you're sure on what you want implemented, then make that clear. If you have a good concept but need consulting, then be sure that everyone on the project knows that. Don't let your concept be mistaken for a series of action items.

And don't be surprised to end up paying for consulting services, either. Implementing a finished design is one thing. Creating a design and then implementing is something entirely different.

4. Track Your Project

If at all possible, don't assign action items to your technical resource via email. Don't report bugs via email. Use project planning software, either your own or your technician's. That way you can look up what you have asked for or reported, and your technician has a concise list of action items to work through.

I remember on one project that the customer was sending me 10 to 15 emails a day with requests, comments, complaints, etc. Worse, the customer actually cc'd me on items tasked to other technical resources.

There was no way for me to keep up with what was mine, what was not, or even what in the world I was supposed to be doing. I needed a full-time staffer just to read the email and convert the contents to action items.

There are a ton of software options for project management, many of them open source. A good one is used on Orthodoxbiz called Project Fork, which requires the Joomla framework. However, there are plenty of stand-alone applications as well. Pick one, install it where you can reach it (or use it in a hosted fashion), and use it.

Conclusion

You don't have to fail in a technical project. The list above isn't exhaustive by any stretch, but if you take the advice it will certainly get you moving in the right direction towards success!