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.
The model you are looking at is often called matrix management. It allows
for functional management of staff (typical hierarchical management for
hiring, firing, reviews, promotion, etc.) and for project management of
projects across functional groups.
We do this at our company and have done it for some time. However, PM's are
expensive resources. What we do is use PM's for small cross-functional
projects with problematic clients and for all large projects. The
cross-functionality is really the issue.
The upside is that PM's shouldn't necessarily favor any one group in the
team: eng, QA, docs, IT, etc. They also focus the client's communication
and manage expectations as well as focus the team's attention away from the
client. Being lead of an area in a project is not dependent on being a
manager; just being trusted as a lead. All good things.
The downside is that PM's often do favor one group which can be disastrous
if there is not upper management oversight of these issues. Another issue
to watch for is that on highly technical projects, clients may want to talk
directly with technical leads and leave out the PM. This can cause amazing
issues in delivery expectations. Finally, everyone has at least two bosses.
Sometimes you can even be the project boss of your functional boss. Some
employees don't get it and some managers don't get it.
To make this work, you have to really work at it and have functional
management support. As part of our internal orientation, we present the
matrix management model and walk through all the questions that inevitably
come up.
Most of this is pretty standard stuff in the PM world, but if you haven't
worked this way, it seems strange.
We actually use about four PM models for our various projects. They are all
communication/functionality variations: strong control of client
communication, distributed control of client communication, single
functionality projects, and cross functionality projects. At one point, we
had 16 projects going and only 7 PMs. Consequently, we can never completely
rely on PMs for every project. But we need everyone to understand why we
use PMs and why we don't.
I actually gave a presentation on this last week for a local grad school
class in a tech docs masters program. There was significant interest and
wide range of experience in very different PM models.
BTW: Technical Writers often make great PMs if they can get over the turf
issues that they have struggled with over their careers. Communication is
one of the biggest issues. Technological understanding is another.
Understanding Business models and the industry expectations is another. ...
BTW again: All this gets even stranger when you start including Program
Managers and Product Managers. But that is another tale...
Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l
Doc-To-Help 2005 now has RoboHelp Converter and HTML Source: Author
content and configure Help in MS Word or any HTML editor. No
proprietary editor! *August release. http://www.componentone.com/TECHWRL/DocToHelp2005
---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-
