What do lawyers and programmers have in common?

Like Vicki Lawrence says, "Don't trust your soul to no backwoods, Southern lawyer" might also be good advice for managing programmers.  Knowing practice and procedure does not insure value or desireable results.  Attorneys achieve results either by convincing judges and juries of merit in their client's view of the facts or by burying the opposition with so many filings that require expensive responses they win through economics. 

Left to operate in isolation, programmers must guess about customers needs and objectives.  Modern compilers, programs that use data to create programs that manipulate data, etc.,  generate thousands (millions?) of lines of code at the click of a mouse.  A programmer can deliver voluminous, extraordinarily complex software that fails to satisfy the intent of the customer's investment or to provide significant returns.

Even worse, customers often do not know what they want until they see a result they do not want.  "Bring me another rock" becomes a typical response to a delivery.  Unlike a trial where findings and facts lead to conclusions, software projects typically finish either with mutual agreement between customers and developers or when all resources have been consumed.  Businesses, including law firms, sometimes suffer to the point of dissolution because of failures that might have been avoided through proper management of the investment process.

Ed Yourdan, www.yourdan.com, remarked recently that Wall Street executives continue to express concern about software investments heard two decades previous reflecting an inability to manage risks and achieve successful outcomes.  Even with the advent of practice models like CMMI, Prince2 and ITIL, organizations struggle to realize anticipated benefits from automation.

What's an Indie to do?  You know that your desktop computer could help you make better use of your time and handle tedious details efficiently if only it spoke your language.  Your options?  Hire an assistant to increase your available hours or hire a programmer to translate your needs into computereze. 

Communicating direction to an assistant requires that they understand your business.  Communicating direction to a programmer presents a different challenge.  A programmer must understand programming and your business.  You should not need to understand programming and a programmer should not expect it.  Personalities drawn to programming sometimes seem strange to non-programmers making business communications even more difficult.

If you are considering hiring a programmer, begin with a clear, concise list of objectives.  You should be able to use this list as a "yardstick" after completion of a programming project to measure its success.  Statements like "Reduce week end bookeeping by 30%" and "Report sales results within one day of invoice" form the basis for such objectives.  Completing this list of objectives might even help you become more efficient by identifying areas for improvement in current practices.

From this list of objectives, develop a statement of work that includes estimates of required investments and schedules for completion.  Follow progress through regular communications with your programmer and act immediately if significant departures from planned results occur.

Technology based development tends to experience a "flood gate" effect.  Once small steps have been taken, a wealth of possibilities becomes apparent.  Resist the urge to move too quickly.  Build your automation house a brick at a time.  Use benefits gained to support future investments.  Remember how you achieved early success and follow a winning path.