State of the Art of Project Management — Underlying Theory is Obsolete

8 Responses to “State of the Art of Project Management — Underlying Theory is Obsolete”

1. David Schmaltz Says:
   January 28th, 2004 at 7:41 am

   Hal:

   Thanks for your comments! I read the piece you referred to on the 25th, and commented briefly then. I agree that his description is just a description, and a description of a sorry state, indeed.

   I have long argued that the chief difficulty on projects is incoherence, stemming from our poor skills for coping with the inherent unmanagability of our efforts. It’s not that we are inept managers, but that we attempt to manage efforts that are fundamentally unmanagable. The following paper, though poorly written, frames the difficulty pretty well.

   http://www.univie.ac.at/constructivism/papers/glanville/glanville97-unmanageable.pdf

   Glanville concludes that we have three options when we encounter unmanagability. 1- We can reduce complexity by limiting the system somehow- this describes much of the state of the present art, 2- reorganize, though this reduces possibility or 3- alter our attitude towards unmanagability. The third alternative is by far the most mature approach, and hints at what the art might become.

   He suggests conversation and responsibility as elements of approaches that cope well with unmanagability. From within the predict and track frame, notice how many suggest even more of the same as the solution to the problem. david

2. Markus Koerner Says:
   January 28th, 2004 at 9:08 am

   Hal,

   same substance, different tone: the use of tools and methodology is already so advanced that further improvements are only possible if we seriously deal with the ’soft factors’. These, however, generally escape conventional methodology.

   I think this should be much more agreeable. From there, two options:

   a) Recenter our approach to be less addicted to methodologies and tools. Work as human beings, communicate authentically (step one: listen), develop verve and shared vision.

   b) Still try to further develop methodologies to better grasp soft issues. The emphasis given to the structuring of team meatings and to hands-on collaboration in SCRUM or Last Planner hints in this direction. This can also be scaled up, e.g. stakeholder analysis for IT projects.

   I think these two approaches complement each other.

   Markus

3. Glen B Alleman Says:
   January 28th, 2004 at 2:11 pm

   Hal,

   Thanks for starting the discussion of Archibald’s paper. A couple of your comments didn’t work for me:

   (3) Use the strategy of the project, portfolio, of business to define the measurements, not from a list of measurements others have made. This way there is a strategic reason for the measure. Consider the measurements as data for testing the hypothesis of the strategy, not just data gathering.

   (9) Manage the portfolio as youwould a project. Use financial measures for the portfolio’s hypothesis - is this portfolio of projects earning its keep?

   (12) Leadership is exhibited by those performing the role of a leader, regardless of title.

4. Paulo Napolitano Says:
   January 28th, 2004 at 4:38 pm

   Planning, measurements, control procedures are essential. We cannot manage projects without them. Projects are processes, and a process is the bringing about, the causing, and the production, of a terminal condition, state or object, its product.
   The product is a part of the process, and therefore the process isn’t complete until that product is produced.
   Process isn’t a sequence of events which stand in certain causal relations to one another. It is their standing in these relations to one another, one or two more events producing or bringing about another. The causal relation is as much a part of a process, as much a part of we are talking about when we talk about a process, as is the marital relation in marriage.
   “A marriage is more a complex entity than a pair of people who stand to each other in the marital relation. It is their standing to each other in this relation, their being married”.
   So control systems, procedures, planning are connected and related to each other in this process and they have a meaning that emerges from each situation or event in the course of the project.
   To each situation or event we have a specific meaning that emerges. If we are not able to identify this meaning, these tools, procedures and so are useless. More the meaning changes from time to time as we are going toward the end of the process even if the same situation happens again.
   We put our efforts in developing new tools, software, but we forgot to put our efforts to make the team achieve the ability to capture this meaning making all the tools useful.
   Projects change as they go toward the production of this product and so the meaning that emerges to each new situation and if the project team is not able to sense the new situation they misrepresenting it. In other words they are intentionality saying that something means “P” when ‘P” is not the case and more they a behaving according to their misrepresentation and we face a breakdown or failure.
   We need to put our efforts to make the team have the ability to sense based on the reports the situation and it is more than simple reading. It is to capture the essence, the meaning without misrepresentation sensing what is expressed, measurable and at the same time what is unexpressed the invisible links that permeates all the process connecting all the events to each other and to the process that are under my point of view be called communication. This communication comes from language that emerges from our behavior as a result of our cognition ability to represent or misrepresent the situation or process that we are living.
   So communication permeates all the events that are related to a process. I am not saying language because communication is the result of a language with a shared meaning. We can talk without communicate, but we cannot communicate without make people or the team understand what we are talking.
   The challenge today is to find people that have a strong capacity in sense, that have a ba

5. Mike Cooper Says:
   January 28th, 2004 at 5:01 pm

   Paulo,

   The way I interpret your post is that the fundamentals of planning, measuring and control systems are important, but are in effect useless if the purpose of the project is not constantly monitored, and are useless if the changes that often occur on projects are not taken into consideration.

   Things don’t always go the way we planned, but that’s part of being a good project manager - understanding what’s going on and making the constant minor adjustments (and sometimes major adjustments) that are necessary to ensure the project achieves its objectives. In other words, planning is not a one time activity, it’s ongoing. Project managers who develop a good plan, but then fail to maintain it, and not managing the project. They are probably also not leading it.

   Mike

6. Hal Says:
   January 29th, 2004 at 1:01 am

   Thanks everyone for your comments today. I’ve just dragged myself out of bed. I’m on my way back. I’ll respond tomorrow.

7. Gary Kuhn Says:
   January 29th, 2004 at 4:00 pm

   A true Home Run Hal! I only hope I can have the successes that Mr. Chastain must surely have achieved. As has been mentioned before in the Lean Conferences, projects are chaotic and that’s where the energy lies. So, as you noted Hal, measurements can not be achieved because of the chaos. However, I must say we should at a minimum determine the metrics that the Customer wants to see so at least until he becomes as wise as you, we have to provide those measurements.

8. michael mckee Says:
   January 31st, 2004 at 1:34 am

   Most of the comments I’ve seen concerning Project Management appear to come from folks who are themselves managers of one type or another. My belief is, and has always been, that one cannot successfully manage what they do not implicitly understand. Not that a non-technical person can’t attempt to do their very best at Project Management, but they will invariably become babysitters on any given project - forever at the mercy of developers, analysts and test personnel. It is important to understand that the information required of these technical folks as input into a Project Plan is only as useful as the person who interprets that information.

   My belief is that only someone who has themselves been a developer, design engineer or architect can understand the intricacies of any given IT project. I’m not trying to be an elitist here, but what I would like to point out is that unless the Project Manager can understand the mind-numbing details of each phase of an IT project (something which only comes with many years of being “in the trenches” themselves) they will not have the background nor the ability to ask the proper questions with respect to the timelines and tasks involved. Not only this, but they would not likely have the ability to detect when some seemingly insignificant issue is likely to become a serious impediment to the success of the project as a whole.

   Unfortunately, few highly technical people choose the path of Project Management as it is not only a thankless task, but offers little in the way of either a rewarding career or a pathway toward upper management. Having said this, however, I myself have made this transition from programmer, design engineer and architect to project and program manager with a great deal of success. This, only because I do not blindly accept the information I am provided by the personnel associated with any given IT project. I continually challenge not only the information as a whole, but also the person providing that information. Because of this I am known as a major butt-head and by other various names, none of which would be appropriate for this venue. I guess what I’m getting at is that unless the Project Manager can understand the intricate details involved in an IT project, and can furthermore ask the appropriate questions of the personnel involved and can demand justification for the information provided, they will be unlikely to have the ability to drive a project to its successful completion.

   There is much more I’d like to say on this topic, but need to get back to work here.

   Best regards,
   Michael McKee

Comment On This