Implementing a Standard Project Management Methodology: Part 2
Thoughts on an Interesting Discussion
Last month Larry Moore gave me a good answer
to my original question as to what he thought he had learned from a discussion
on LinkedIn on the merits of establishing a "standard" or uniform PM methodology
for all projects in a portfolio of projects. My response to Larry was as follows.
"Thanks, Larry, that's a good answer! Can I quote you on my web site?
There are some other things I think we can learn. For example:
- We have a problem with the word "project". PMI defines this as the means by which a "product, service, or result" is achieved. (i.e. "A temporary endeavor".) In systems terms, it means a "process". Unfortunately the label is often loosely used to mean the product of the project. That's because we don't have labels to clearly distinguish between the two.
We have the same problem with the similarity between the names of the phases of a generic project and the names of the "five project management process groups". It would not be difficult to find alternative labels. Indeed, we could simply adopt labels from Henri Fayol's original management philosophy of Plan, Organize, Execute, Monitor, and Control.
- When does a project start? While not specifically addressed, different ideas are implied. For BAs it is the Business Case, for IT folks and others, including PMI, the conclusion or approval of a Project Charter. For engineering and construction types, it's the signing of a contract. (Until relatively recently, this has been the view of Dr. Harold Kerzner.) Understandably, this leads to different control requirements. Does that mean control in terms of the project life span (cycle)? Or in terms of the management of the technology?
- There is a problem with the definition of project management as understood by many respondents. PMI's definition of project management implies the management of a single project, even though PMI frequently uses the term to imply a basket of projects that is more properly referred to as a project portfolio. I think that's why, as you observed, many respondents "focus almost entirely on the details of managing an individual project". However, it is true that project portfolio management, and not project management, makes the best case for standardizing project management methodologies across several projects of whatever types and durations. Such standards of unification, as you suggest, can be customized to suite the culture of the organization without compromising the project manager's need for flexibility in managing the particular technology.
- Indeed, it is hardly recognized that project portfolio management is a different discipline from the management of a single project (project management). Not least by virtue of the different skills required (permanent people management, career opportunities , resource allocation and distribution, project filtering and balancing, and so on). That's more akin to traditional run-the-business (operations), as compared to change-the-business (projects).
- We are gradually seeing greater recognition that managing the "project" and managing the technology of the product are not the same thing and that these need different considerations or systems that nevertheless must be integrated. The former, project management, really requires a consistent and predetermined project life span (cycle?) design for purposes of control. However, the latter, the technology management, requires far more flexibility depending on the nature of the product's technology, its environment, urgency, politics, and so on.
What we don't have are suitable and well-established labels to describe each so that everyone has the same understanding. What that means in the discussions is that those who argue for more freedom and flexibility are probably thinking more in terms of managing the technology. Those looking for closer adherence to consistent standards have in mind the management of the strictly project aspects of scope, quality, time, cost risk and so on.
With these issues unresolved, it is no wonder that there are so many misunderstandings, differences of opinion and outright disagreements in these types of LinkedIn discussion threads.
What say you?
Of course Larry had even more thoughts on "things we can learn", but we'll leave his responses until next month's Musings.