The Project Manager's Environment
A LinkedIn Discussion circa December 2013Around November/December of 2013 an intensive discussion took place amongst several contributors on the subject of a Project Manager's working environment. The observations of one participant, Larry Moore, caught my attention in particular. So, towards the end, I asked Larry this question: "Larry — What do you think you have you learned from this interesting discussion?"
I thought that Larry's response was worth capturing. So here it is, over five years later! Note that in his response, Larry mentions that he comes from the Information/Technology sector. Larry Moore replied: "Max: Thanks for asking. I think I have learned quite a bit about the overall knowledge and understanding levels of many well qualified PMs (and others not so well qualified). For example: There is a great tendency of many PMs to focus almost entirely on the details of managing an individual project rather than expanding this focus to include how their project fits into the portfolio of current projects and how these projects fit into the goals, objectives, strategies of the organization. My reasons for utilizing a custom-built, standardized methodology for all projects in a given organization have as much to do with the whole portfolio of projects as they do with each individual project. I believe that the methodology used must be fitted to the organization and the way it conducts its business. The processes built into one organization's methodology certainly might not fit another organization. It seems that many of the discussion participants have a great deal of difficulty understanding this; many of them seem to think that this is a "one size fits all" philosophy when it really is not. Such a methodology can be designed to allow quite a bit of flexibility in the way individual projects are planned and conducted.
I think it is difficult to adequately explain why using standardized processes and project artifacts during the initiation and planning part of a project is so important. I probably haven't done a good job of this. I have learned that people generally do a better job and are more productive if they know what to anticipate and what will be expected of them. Implementing a well-governed set of processes so people can anticipate what they will need to do and/or provide helps greatly with this. My PM environments have primarily been in situations where there are literally dozens of needed projects competing for resources, budgets, and time. In this environment, priorities and productivity are critical. Standardized processes help to save time and improve productivity. Methodologies can be designed and implemented that will significantly shortcut the time required to produce the project artifacts needed and get approvals needed to proceed with project efforts. Such a methodology can also force quick responses from project sponsors and other executives when those responses are needed. (In my experience, the issue of getting quick responses from executives has proven to be a real problem). From this discussion, I have gotten the feeling that a lot of PMs just don't like any kind of regulated methodology. They seem to prefer having a free reign in how they approach each project and how they choose to manage their projects. Having been an IT tech person, I understand this attitude, but I don't endorse it. I apologize if I am being too 'wordy' in my response. I hope this gives you at least some answers to your question."
Now, in 2019, I am wondering to what extent Larry Moore's views may have changed since 2013. So I asked Larry that question as part of my regular practice of seeking the author's approval before publishing. Here is part of what Larry had to say. "I want you to know that I am pleased and honored that you think enough of my comments to save them and to consider publishing them. I have reread those comments, and I don't think I would change any of them today. Except perhaps to add some clarification that in these comments, I was NOT really discussing a methodology for product development, software or otherwise. I should add that in my four decades of involvement in IT projects, the large majority of those projects have NOT involved any actual design and development of new software. My comments are about the whole environment of managing the entire project. So, this would allow for plenty of room for different approaches or methods of product development, such as "waterfall," "Agile," iterative, incremental, scrum, or others. Where new software development is required, I would want the development approach to be determined by the characteristics of each individual project and the particular environment surrounding that project. That is, instead of implementing some dictated approach for all software development. I have retired, so I do not have, or work for, any company. My interest in project management certainly continues (and I am still learning much about how to effectively do project management in today's world). One of my main motivations for participating in LinkedIn discussion groups is the hope that I can pass along some real-world knowledge and perspective to other participants who will find them useful. Thanks again for the interest you have shown for my comments and opinions. Larry"
Well said. 
| 
