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.
>This is written in reply to:
>
>******************
>We need to wake up to the fact that in modern product development,
>design changes occur
>almost up to the day of release, and that this is not a fault in the
>development process but a necessary part of business life for any
>company
>that wants to maintain a competitive edge.
>******************
>Sorry, I'm not buying this. ...
>
>Most of the time, however, making revisions until the last second prior
>to release is a symptom of inadequate up-front analysis,
>poorly-developed specs, bad project planning, improperly organized
>testing, and overall shoddy project management. Unfortunately, these
>are very common in software development; so common that they are
>sometimes passed off on the unwary as "modern development methods."
Well, people not buying things is very much the point here. We live in a
world in which the market window of opportunity for a product is shrinking
and shrinking. This is true of virtually every type of product, but probably
most acute for companies in the Internet marketplace where your window of
opportunity to sell a product may be only a few months -- or less.
To compete in a market like this we need to change how we do design and
development -- and project management. Of course projects should be well
managed in all the aspects you list, but increasingly we are going to have
to replace serial processes with parallel ones, and adapt out project
management practices and our design and development processes to deal with
that parallelism. It is not wrong to accept design changes almost to the
point of delivery. It may be necessary to maximize your product's window of
opportunity. You can't rule it out as bad analysis, bad design, or bad
project management. Instead you have to rethink analysis, design, and
project management to accommodate it.
From a purely documentation based perspective, it doesn't really matter if
late changes from development are the result of a well managed dynamic
development process that adapts well to changing market conditions or merely
a chaotic and poorly managed one that can't get its act together. Either
way, late changes are a fact of our business lives, and instead of
complaining about them, or waiting vainly for development to change its
ways, we should take responsibility for the fact that we have to accommodate
such changes and choose our tools and design our processes accordingly.
It can be done. The content management system that my group uses allows us
to accept design changes from development as little as one day before
internal release, without loss of quality. If you think that's impressive,
consider the achievement of the newspaper industry. They have a product with
a market window of, at best, 24 hours, and they successfully create a new
product every 24 hours to maintain their market position. If journalists can
do it, why can't technical communicators?
---
Mark Baker
Manager, Corporate Communications
OmniMark Technologies Corporation
1400 Blair Place
Gloucester, Ontario
Canada, K1J 9B8
Phone: 613-745-4242
Fax: 613-745-5560
Email mbaker -at- omnimark -dot- com
Web: http://www.omnimark.com
