Vince McGevna: Project and Product
Management Not the Same
The PMBoK is about project management, not product management. So it stands to reason its definition of success would focus on the project. Projects produce many different products in many different areas for many different customers. It would not be feasible to tackle this in one body of knowledge.
My particular role in product success is largely determined by the organization I work for. On some projects I was tasked with developing a fully defined product to the best of my abilities. My ability to manage product success depended on my interaction with sales and marketing, something I did not always have control of. In others I have been a critical member of a core team where product and project are closely managed together. In the latter situation my ability to impact product success was much greater.
Similarly, how you define real project success is a function of the organization and the nature of the projects. Part of it has to do with how an organization is set up for success, as defined by PMI. Having managed many projects pushing the bleeding edge of a technology, it is extremely difficult to predict cost and schedule when key aspects of scope are only discovered long after the initial planning. However, organizations that engage in this type of work accept this as part of doing business. Going back to the original triple constraint cost, schedule and scope - these do not have the same priority, and the successful project manager understands which takes precedent and manages accordingly.
My experience in product development, scope is frequently most important and it is important to deliver a product that meets all functional and quality requirements. (I personally consider quality to be an integral part of scope.) On some projects there is a real drop dead date, and then it is my responsibility to deliver maximum value within the allotted time. Cost is primarily for resources, and is closely tied to schedule. Managing risk is also critical to success, but this is something I relate to cost schedule or scope to quantify.
@Larry: the role that the PM plays in the selection of projects depends on the organization and their business. In product development the decisions on what projects to do are made by marketing with heavy input from engineers and light input from PMs. In companies where I've worked, marketing is responsible for a roadmap where is the product line going in the next 5-10 years. Priorities are set based on the business case and resource requirements.
This roadmap generally goes through a scrubbing quarterly where near term projects will start getting strawman resource assignments to make sure they can be done. Again this is all done with input from marketing engineering and project management. As projects complete and resources free up new projects are started in accordance with the roadmap.
I've managed many of these projects and have observed many more and have not seen that this causes any problems in implementation. The carefully thought out and periodically updated roadmap means that projects are chosen to meet the organization's overall goals. Of course, some organizations do this better than others.
7. Vince McGevna, Project/Program Manager; Author: Schedule Centered Planning: An Incremental Approach for Plan Driven Projects