TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
> I have often heard business management types complain that independent
> programmers fail to deliver the programming functionality they expected.
If you haven't already, I'd strongly suggest looking at the classic book
on problems of managing software projects, Fred Brooks "The Mythical
Man-Month".
> In a recent conversation with the comptroller of one company I suggested
> use of an independent business analyst, who was familiar with accounting
> principals as applied to that business
I assume you're talking about accounting software? If so, the above makes
perfect sense. However, if the software is to run the factory or the web
site, the above seems spectacularly dubious.
[snip]
> What points should be included in the agreement.
You have a bit of juggling to do, getting an adequate /functional/ spec
without treading on the designer and implementer's toes, specifying details
that should be left to them. This will need at least one full turn around
the circle where you draft a spec, both the client and the developer criticise
it, then you modify it. It may take several iterations.
Depending on the size and complexity of the project, it is possible the
first payment might be due when all players have signed off on the spec.
The developer may have done significant work by then.
You need to negotiate with developer and client a development methodolgy
everyone can live with. One major question is the extent to which you
will prototype things. For some projects, you do not write a detailed
spec in advance. Instead, you implement some form of prototype which
lets you test, get user feedback, and then specify the final version.
Or the next version; for some projects you need several cycles.
There's a whole spectrum of techniques here, from carving the spec in
stone before coding starts to not even trying to write a spec until you
have a prototype that does almost everything required, and many points
between.
> I have a meeting scheduled on this topic and would appreciate any
> feedback. Including any business problems that may arise, such as
> dealing with the sometimes unavoidable changes in specifications.
One question is who owns the resulting code.
In nearly all cases, the contract should specify that the client gets
full source code for everything developed, and a license that at least
allows them to maintain the code, including modifying it for changed
requirements. In some cases, the acceptance procedure should include
an audit of code quality by an independent expert to ensure that it is
cleanly written and maintainable.
I've seen a situation where a business depended on custom software for
which they had only partial source and restrictions on modifying that.
When they disagreed with the contractor over pricing and schedule for
modifications, it was definitely not pretty.
However, other aspects may be negotiable.
Does the contract allow the client to freely share the software with
business partners, branch offices, ..., or would any such sharing bring
the contractor additional revenue? If so, are the terms for that fixed
now or when the need to share comes up?
Can either the contractor or the client license the software, or parts
of it, to third parties? Or develop additional software based on this
work and sell that? If so, does the original partner in the development
share in the profits?
I've seen deals where the client got a much better price because the
software clearly had potential in other markets, and the deal let the
developer keep the rights and try to sell it in those markets.
For some software, the best approach may be to make it Open Source.
If others use it to any significant extent, you get free publicity,
free debugging and likely free enhancements.
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available 4/30/01 at http://www.devahelp.com or info -at- devahelp -dot- com
Sponsored by DigiPub Solutions Corp, producers of PDF 2001 Conference East,
June 4-6, Baltimore, MD. Now covering Acrobat 5. Early registration deadline
April 27. http://www.pdfconference.com.
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
