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.
--- Paul Hanson <PHanson -at- Quintrex -dot- com> wrote:
> If you were involved in establishing standards for either a re-write of
> an existing system or the development of an entirely new system for a
> Windows OS, this email is for you. How long did it take your team
> (assuming that these standards were created with a cross-section of
> programmers and end-user advocates (QA, TW) to come to agreement with
> the following?
[SNIP]
> No pre-meeting info was provided. We were to bring examples, as
> explained in this text from the 'invite' email: "In addition to your
> ideas, would the following individuals please bring copies of the
> specified information to the meeting."
>
> A group of 6 (me, GUI/400 developer, 1 QA, and three programmers [from
> three different products that have different standards [VB, Centura, and
> RPG) got through one through three. The meeting was termed
> 'unproductive' by one of the programmers. He thinks that spending 1.5
> hours on three items is 'too slow' and that there must be a faster way
> to develop standards.
>
> Any hints?
> Paul
Even though I have not worked on developing "an entirely new system for a
Windows OS" I think I can offer some perspective as I have worked in--and
currently am working in--an environment where such project planning is a new
idea. That's what your email brought to my mind, that you are in an
organization that hasn't done a lot of planning before development before.
Especially in an organization that doesn't have a history of planning
(architecture development, requirements, standards, and design BEFORE coding
begins), you have to be patient at the beginning. It did not help--and you
should avoid if possible--having these meetings with "no pre-meeting
information" being provided. It slows things down an awful lot if people first
have to receive the list of items to be discussed and established. Then people
have to read it all on the fly and determine what is important to them. Let
folks have a chance to prepare for such meetings, and the meetings themselves
will seem more productive.
Second, when establishing standards and guidelines, particularly for the first
time, expect the initial meetings to go slow. If you really expect people to
follow the standards and guidelines established in such a meeting, you need to
let a consensus develop. Otherwise, you will find the standards ignored as the
project develops, and everyone will look back on the beginning of the process
as a waste of time...and they'll be right.
Third, griping is not unusual. Someone will always complain that too much time
is "wasted" in doing the preparation before the "work" starts. The best thing
you can do is persevere. Proper upfront planning--which is too often seen as a
luxury on projects--actually will save time later on. It is easier to keep a
project on track if you have your standards in place before you start. The few
who don't see that now can come around if they begin to see the benefits as the
whole effort unfolds. (And when I say be patient, I'm saying don't expect to
get everything your way all at once. It has taken me over two years at my
current situation to begin to achieve the kinds of results needed here, but
they are coming now, and I feel very glad that I did keep my cool and my
perspective.)
