RE: persuading (was Release notes: term for bugs)

["Jonathan West" <jwest -at- mvps -dot- org>]

Hi Sean
>
> Johnathan West Wrote:
> Technical writers IMO have a valid input in terms of persuading their
> companies of the need to write design specs, and being in a position to
> help with getting the information written down clearly and unambiguously.
>
> ----------------
> I agree. And they also have a place for writing procedures and
> processes that the company goes through to get its work done.
>
> But _how_ do you make those persuasive points. The needs of a
> small company (under....maybe 15 people)are far different from
> the needs of a larger company (say around 50 or so employees),
> which are different from a company of 200 people, and so on.

That is the hard part. From what I have seen, persuading a team to change
behaviour has it goes through the first size barrier is the hardest, because
they don't have any experience of the need to change as size increases.
Basically, it usually takes at least one "death march" (and usually more
than one) before they realise that things aren't going right.

The key is getting the team leaders to buy in to the idea that something
needs to be done. If they accept it, they have the power to impose it on
everyone else.

How to persuade the team leader? That's tough, and depends on the individual
character. Here are some ideas that might help.

- Specific examples of design inconsistencies in the latest development
cycle, and a guesstimate at what it cost in time.

- Your own credibility - can you give examples where you have seen this
before in other companies?

- Does he want to be a hero, and get the next product out of the door
quicker? You can help him do that.

- Whatever you do, avoid any suggestion that the leader was incompetent in
letting things get so bad. It is a common problem, and every company goes
through these growing pains. Its normal to have a death march or two, the
key thing is to learn from it.

> Obviously, the more people you get working towards the same goal,
> the more you need guidelines of varying detail that everyone buys
> into and follows to reach that goal. That's how you avoid goof
> ups like multiple people working on the same task, or conflicting
> GUIs. But how do you convince the people who were used to just
> yacking in the hallway about a new idea that their ideas should
> be presented in a meeting, and documented before implementation
> begins? I guess I'm thinking of my own experience, where we tried
> to convince those in charge a change was needed, but they
> rejected it out of scepticism and a little paranoia........

Well, one other tack that you can try is saying something like "While *your*
ideas are usually solid, we can't say the same about Joe, Fred and Mike. If
we are going to get them to code to a standard, we need to make sure they
know what the standard is!"

However, sometimes nothing you can say is good enough. Where I'm working
now, I can see at least two large projects where the politics is such that
nothing I can say would persuade them to streamline, even though one is in
the middle of a death march with no end in sight. I'm steering well clear.

Regards
Jonathan West


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  Your monthly sponsorship message here reaches more than
  5000 technical writers, providing 2,500,000+ monthly impressions.
  Contact Eric (ejray -at- raycomm -dot- com) for details and availability.

Check out RoboDemo for tutorials! It makes creating full-motion software
demonstrations and other onscreen support materials easy and intuitive.
Need RoboHelp? Save $100 on RoboHelp Office in May with our mail-in rebate.
Go to http://www.ehelp.com/techwr-l
---
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.