When I began my career at IBM I chose to work in a group called Quality Assurance. This area went through a completely different management chain than the product development organizations it served. It was not QA – testing – as we know it today. It was responsible for being totally informed on the activities of product development and groups such as publication writers (“Information Development”), service (“Field Engineering”), and IT. With all this information for quality assurance analyst provided assessments at two points in the product development life cycle, at announcement and again at shipment (also called “General Availability”or GA).
Prying the information from uncooperative development managers and staff was the norm.
A technique that proved to be effective in allowing quality assurance to do its job more effectively was to have some skin in the game. Some tasks that were not critical path but required could be taken on by quality assurance personnel. So as not to be taken advantage of, when a deficiency was identified that development could not address, and there was expertise in the QA group, then the offer could be made to be of assistance – if you will, to be more on the same team. The good QA analyst multitasked and with more details about the activities of development a more accurate and less opinionated assessment could be made.
I see this approach as a viable for the project manager. Here’s why. The project manager that is capable of some of the work in the project plan might well do some of them. It’s hands-on, a way to get at the details, allows for a project manager to maintain or grow other skills, a way for the project manager to be accepted more by the project team (especially if they are new and gaining credibility). Certainly there is a lot to weigh out before going along this path. Perhaps the project is very large and the project manager doesn’t have enough time as is. Perhaps a Project manager has no applicable expertise in areas needed to accomplish project tasks.