Larry Moore: PMBOK Fine So Far as it Goes
When we evaluate and/or discuss the definitions of project success or failure, I believe that we must be careful to distinguish between the PROJECT itself and the PRODUCT of the Project. If a project is completed according to specifications, on time, and under budget, but the product produced or implemented is found to be inadequate to meet the organization's needs, will this project be considered successful by the organization as a whole?
Unfortunately, the management and executives of most organizations tend not to make a distinction between the project and the product (this is especially true for organizations that are not mature with respect to project management). So it is not unusual for a "successful" project to be labeled as "unsuccessful" if the end product turns out to be not as effective as anticipated for reasons beyond the scope of the project.
One of the ways to prevent this kind of situation is to place great emphasis on the Project Initiation phase of the project (with many, if not most projects, this is not done). If sufficient effort is put into assuring that the right PRODUCT is either chosen or defined, the chances of the project's being considered a success are greatly enhanced.
Actually, the original question was (and I quote) "How does this fit with or diverge from your view of project success from the project manager's perspective?" This question was in reference to Matthew's several quotes from the PMBoK. So, I take it that Matthew is interested in our personal opinions as to what constitutes project success. From my own perspective, I believe that the quotes from the PMBoK are fine as far as they go. However, I think there is something to be added to this regarding the actual success or failure of a project. I think that the qualities of the PRODUCT of the project must be included in the evaluation of the project.
It is entirely possible to complete a project according to all of the constraints (time, scope, budget, quality, etc.) and to have a project that might or should be deemed a failure. A Project Manager can manage a project very well and end up producing the wrong product for the organization. For example, in my world of IT projects, the organization might have already selected the product they want (or think they want) and then define the project as installing and setting up that product. Then, after the project is completed, they discover that they chose the wrong product in the first place.
In my view, that project is not successful. Such a project should have been expanded to include a thorough evaluation of alternative products prior to beginning the installation & implementation project. I am very interested to see if anyone shares this perspective.
I cannot agree with the suggestion that: "Whether or not project managers have input into the product choice is irrelevant." While it is unfortunately very common to have products chosen without any input from the project manager that will be tasked with the installation or implementation project, this is certainly not the way it should be.
I believe that the choice of a product to be implemented should be treated as a project in itself, (separate from the implementation project) and it should have an assigned project team and be directed by a PM. Doing so eliminates or minimizes many problems that commonly occur with implementation projects. Failure to do so just invites (and in many cases guarantees) that the implementation project will encounter many issues and/or problems and the implementation project will eventually be viewed to be unsuccessful because the organization's overall goals and objectives that generated the project have not been met.
In the case where the assigned PM actually knows at the beginning of the project that the wrong product has been chosen, what should that PM do about this? Does the PM have some responsibility to make others aware of this? Or, should the PM take the attitude that, if the organization ends up implementing the wrong product that this just isn't his/her problem because he/she was not involved in the product choice?
Although a Project Manager is usually not the final decision-maker regarding what constitutes the product of a project, in many cases the project manager is a critical part of that decision-making. In my world of IT projects, this is very common.
Let me give you an example from my own personal experience: Let's say that an organization needs to implement a new Human Resources and Payroll Management solution (perhaps because of business growth, modernization, cost containment, etc.). This organization is certainly not going to try to design, build and implement a new solution because there are numerous packaged solutions available at a much lower cost. All can provide all of the functionality needed, and they can be implemented much more quickly than with custom software development. For this environment, there are at least a dozen very viable solutions from many different software vendors. So, selecting the best solution to implement becomes a critical success factor.
While most of these solutions can provide approximately the same functions, features, and benefits, the costs of a full implementation can vary by extreme amounts. One solution can easily cost 3-4 times what another viable solution might cost (and these cost differences can easily amount to hundreds of thousands of dollars, or even more). Most of this variation in total costs is not in the licensing or purchase cost of the solution, but rather in the cost of the implementation project itself.
So, an evaluation and analysis process must be undertaken to decide on which product should be implemented. This is where a Project Manager really must be included as a participant in this process. Who else can determine the scope, timeframe, and costs of an implementation project better than a Project Manager? While this situation might not be common in many environments, it is almost a de facto standard in the IT environment. It is certainly not the case that all organizations do things this way for IT projects, but those who do have a much better chance of project success.
8. Larry Moore: Project Management Professional