======Planning en ontwerp======
Bij de planning en initieel ontwerp van de algehele projectaanpak komt veel tegelijk om de hoek kijken. Technische communicatie behelst vaak meer dan een (set) handboek(en) welke ontwikkeld moet worden.

=====Andere partijen betrekken=====
De initiële ontwerpfase is hét moment om andere communicatiepartijen, zoals training en marketing, bij de ontwikkeling te betrekken en een gezamenlijk draaiboek op te stellen waarbij alle neuzen één kant op staan. Om dubbel werk en en interpretatieverschillen tussen diverse ontwikkelteams te voorkomen moeten alle hergebruikaspecten van communicatie in een hoofdstructuurontwerp terugkomen.

Het (initieel) ontwerp geldt als basis voor alle betrokken partijen en wordt mede ingevuld door de antwoorden op onderstaande vragen:
- Documentatie en trainingen worden voor gebruikers ontwikkeld. Voor welke gebruikers wordt er ontwikkeld? Vergeet hierbij niet de interne gebruikers. Naast (externe) klanten zijn de verkoop- marketing en engineeringsafdeling ook gebruikers; wat zijn hun behoeften?
- Welke media is/zijn gewenst voor gegevensontsluiting en welke content moet het bevatten? (denk bij media ook aan (E-)training). Bedenk hierbij dat niet elke vorm en content voor elk type gebruiker even handig is: een monteur met laptop is bijvoorbeeld meer gebaat met een gedetailleerde handleiding op CD dan met een paar kilo papier. Een verkoper die op pad moet zal daarentegen meer behoefte hebben aan een beknopte fysieke folder en een powerpointpresentatie.
- Veel professionele producten gaan gepaard met trainingen; bij softwareproducten wordt vaak een online help meegeleverd. Alle informatie uit deze technische communicatieproducten moet met elkaar in lijn zijn -dezelfde boodschap uitdragen. Als meerdere communicatieproducten gecreëerd moeten worden, zorg dan dat de ontwikkeling hiervan:
- vanuit één (unieke) bron wordt gecoördineerd. Denk aan informatie-overdrachtmeetings door specialisten of een R&D-hoofddocument. Zorg ervoor dat wijzigingen aan alle partijen tegelijk bekend worden gemaakt en verwerkt worden. Review elkaars producten. Risico hierbij is wel dat dit proces verwatert, teams uit elkaar vallen en er op den duur verschillen gaan ontstaan tussen bijvoorbeeld een pdf en online help.
- Een andere manier is het gebruik van [[SingleSourcing content re-use]] waarbij alle technische communicatieproducten uit één bron worden samengesteld. Hiervoor is vaak wel meer technische kennis en tooling nodig. Tevens dient de hoofdstructuur hierin te voorzien.

=====Terminologie en bewoording =====
Behalve een planning en een initieel ontwerp moeten ook afspraken worden gemaakt over te gebruiken terminologie en bewoording: hoe worden bepaalde onderdelen van het product genoemd? Houden alle afdelingen (service, R&D, enginering, verkoop) er dezelfde terminologie op na? Bij vertalingen (localization) moet tevoren ook duidelijk zijn welke termen wel moeten worden vertaald en welke niet. Zo zullen geregistreerde productnamen vaak niet in aanmerking komen voor vertaling. Zorg dus voor een handboek waarin de overeengekomen terminologie is vastgelegd, overleg regelmatig over nieuwe termen en communiceer dit in overleg met marketing naar alle betrokken afdelingen.
Zorg ook dat een redactionele fase wordt ingepland die teksten hierop screent.

=====Project documentatie =====
Juist omdat er zoveel partijen bij betrokken zijn is het aan te bevelen alle afspraken en visies op papier te zetten voordat iedereen zich terugtrekt om 'zijn' ding te doen. Daarbij moet gezegd dat eenmaal gemaakte project documentatie niet heilig is: inzichten en omstandigheden zullen vaak gaandeweg het proces wijzigen en dan is het zaak regelmatig te overleggen en de project documentatie hierop aan te passen.

Wel is het zo dat men er tussentijds van mag uitgaan dat alle partijen zich zullen conformeren aan de afspraken die in de op dat moment geldende versie van de project documentatie zijn gemaakt.
- Gebruik technieken als SCRUM of PRINCE II om regelmatig de geldigheid van de projectdocumentatie te verifiëren.
- gebruik een versiebeheersysteem om wijzigingen in de projectdocumentatie te monitoren en ervoor te zorgen dat iedereen met dezelfde versie werkt (distributie!).

Onderdelen van de project documentatie zijn:
- [[ProjectdocInfoplan het informatieplan]]
- [[ProjectdocProjectplan het projectplan]]
- [[ProjectdocPlanning de planning]]
- [[ProjectdocDocStructuur de document structuur]]
- [[ProjectdocTermsStyle de terminologie en schrijfstijl]]

----
Categorie: [[Projectaanpak]]