Vince McGevna[6] Extends the Organizational Picture
In product development, where I have the bulk of my experience, there are project managers, product managers, and program managers. The project managers are responsible for the individual projects — e.g. the delivery of the animals to the island.[7] Success of that project is measured by on-time delivery of all of the animals. The program manager is responsible for the bigger picture, which might include the animal delivery, the creation of an appropriate habitat and other projects to set up the needed infrastructure. The product manager is responsible for success in the marketplace. Each is aware of the needs and responsibilities of the others and they work together to assure overall success.
As a project manager, my projects have run the gamut of working very closely with the end customers/users to having little or nothing to do with them. It all depended on the products and the organizational structure. However, my work was always done at the end of the project and that was what I was evaluated against. Of course, I might then manage another project to enhance what I just delivered, but this was all laid out in the product roadmap. However, if the end product of a project is of poor quality, the project manager might get involved with the customer problems to straighten them out.
@Larry: You do bring up an interesting issue. My experience in product development is that too many outside of project management have preconceived notions that are wrong. Unfortunately, it is extremely difficult to get them to understand or admit that they are wrong. It's akin to believing the earth is the center of the universe in the middle ages!
For example, organizations could collect a gold mine of data to improve estimating and prediction, but for various reasons they don't think it is that valuable:
- In one organization I collected estimates and actuals from other PMs and showed that if we could just categorize projects as small, medium or large, this could significantly improve our estimates. It was rejected on the grounds that we were on the "bleeding edge" of technology and every project was unique.
- In another organization I looked at time records to estimate the ratio of QA engineers to developers, something we needed for early estimating. This was ignored.
- And I've showed, using actual data, that when about 25% done with a project we could give a reasonable prediction of the end date. Again I was shot down on the basis that the projects were unique and the causes for the slips were also unique to each project and hence unpredictable.
6. Vince McGevna: Project/Program Manager; Author: Schedule Centered Planning: An Incremental Approach for Plan Driven Projects
7. See David Willcox's project analogy described in Part 2.
|
Larry Moore
