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 seems like it's predominantly a status meeting. What part of the
meeting is so critical that it cannot be replaced with a memo? I know that
we like face-to-face contact for feedback about progress and how to proceed,
but too many questions or contacts like this can make a project manager seem
to need a little hand-holding.
I think that project meetings are more effective when topics like status and
other progress are communicated in email and meetings are reserved for
addressing critical issues and for determining requirements and
specifications. Meetings should also be focused on a specific area of the
project, like current issues, rather than have multiple topics like issues
and specifications. This is important because I think it is easier to
attend a brief meeting that handles one important aspect of the project than
it is to attend a meeting that sounds like it will last three hours and
possibly involve something that doesn't concern me.
* If I was in this situation, then I would take a step back from wanting
direct contact with the stake-holders of the project, without a critical
reason.
* I would, as I tend to, email weekly status reports that are a less than
one-page summary of the past week's accomplishments and plans for the future
week. (I think this is a typical format.) I may support the report with
gantt chart if people like that, but they should already have access to the
project's chart.
* When I need to be clear about the project's direction, then I'll send a
brief description of the issue and my plan, as sort of a mini-proposal. I
would end my proposal with something like, "We can meet to discuss any
changes to this proposal, if necessary, otherwise, this is how the project
will proceed."
* If stakeholders want to change the proposal, then I would schedule a
meeting. In this case, the stakeholders will have buy-in to the meeting and
can have ownership in the meeting. They are more likely to attend meetings
that they own.
Lauren
> -----Original Message-----
> From: techwr-l-bounces+lt34=csus -dot- edu -at- lists -dot- techwr-l -dot- com
> [mailto:techwr-l-bounces+lt34=csus -dot- edu -at- lists -dot- techwr-l -dot- com] On
> Behalf Of Kevin McLauchlan
> Sent: Wednesday, August 01, 2007 11:16 AM
> To: TECHWR-L
> Subject: RE: How to...
>
>
> Hey again.
>
> I got a few suggestions, both off-list and on, but everyone
> seems to have
> missed that it was not me calling the meetings. It was a
> project manager,
> trying to keep everybody informed about the status and upcoming
> actions/requirements (from each department) for all the
> product release
> schedules she's overseeing - and also to get everybody's
> input regarding
> problems, schedule-changing resource or timing problems, etc.
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
