Part 3 published here November 2014.

 

Musings Index
PART 1 | PART2 | PART 3

Implementing a Standard Project Management Methodology: Part 3
Thoughts on an Interesting Discussion

Last month I described my reactions to some of Larry's original observations by listing some further observations. Here are Larry's views on them.

"Max:

Certainly, you may use my comments on your web site if you wish.

Your message covers a lot of territory, and your comments apply to many of our LinkedIn discussions. Here are some responses to your "things we can learn:"

  1. I certainly agree with your general definition of a "project." I understand that many people, including PMs, seem to confuse or conflate the product of the project and the project itself. I don't understand why this is; I'm not sure I agree that it is a labeling problem. For me, there is a simple but profound distinction between the two, and I have no trouble keeping those two things separate.
     
  2. I don't view a "process" as the same thing as a "project." I tend to think of a process as a series of steps/phases/gates/etc. that something goes through as time passes. I think of a project as that thing that travels through the process on its way to completion. At any given point in time, the project will be at some point in the process, sort of like being at some point in the road during a trip from, say, San Diego to Boston to use a crude analogy.
     
  3. When does a project start? This is a really tough question to answer with some kind of confidence. It is really easy to confuse the beginning of the execution part of a project with the beginning of the project. From a practical standpoint, I view the beginning of a project as the beginning of the Initiation phase (i.e. when a request for a new project is completed and approved).

    This is before a Business Case is begun and before a Project Charter is begun. I understand fully that many will disagree with this, and I have no problem with that. Also, I understand that my view is as much dictated by a project portfolio management mindset as a typical PM mindset. If there is a contract involved, I think of the processes of building and agreeing upon a contract as a separate project from the project described in the contract.
     
  4. I certainly agree with your statement that "project portfolio management, and not project management, makes the best case for standardizing project management methodologies across several projects…". In an environment where there is only one current project (never saw such an environment myself), the standardization of the processes involved is not a big issue (as long as the chosen approach and processes comply with good PM practices). Some PMs may be used to this environment; I certainly am not. Your statement, "Such standards of unification, as you suggest, can be customized to suit the culture of the organization without compromising the project manager's need for flexibility in managing the particular technology" is certainly true. I do not understand why so many PMs don't seem to understand this.
     
  5. Regarding PPM, I have the opinion that most PMs have little or no experience in using PPM tools and/or techniques. (By the way, I believe that the same thing is even more true for organizational change management.) In my case, the experience of implementing a PPM system for an organization changed and expanded my perspective on how projects should be done by an organization.
     
  6. Reading your comment, I am not certain what you mean by "managing the technology of the product." One of my beliefs is that PMs do not manage the product of a project; rather, they manage the project itself (more specifically the work involved in completing the project). We are not Product Managers; that is a separate endeavor. From comments posted in our discussion, I get the idea that many PMs would disagree with this, or would not even understand my point. In another discussion, "How often do you use the WBS?" I see many comments from PMs who seemingly cannot distinguish between a Product Breakdown Structure and a Work Breakdown Structure. Many seem to think one can manage a project by just following the structure of the product.

So, there are some of my thoughts. I would appreciate seeing what you think of them.

Best regards,
Larry"

In his item #6, Larry certainly makes a very good point.

PART 2  PART 2
 

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page