Author's Response
As is our custom, we submitted a draft of our review for the author's consideration to ensure that we had not made any errors of fact. James Brown responded with enthusiasm to a number of issues adding further insights to this important and evolving topic.
The sea shell analogy
In response to our sea shell analogy, James suggested a very different interpretation, thus:
"I would be in the group of others with regard to the Sea Shell adaptation as being representative of Program Management. The shell is more comprehensive if it is alive. Obviously the creature alive inside the shell represents the operations that must go on as all the projects proceed to improve those operations or spawn new operations. For example, I have a cruise line client that must implement a set of new projects up to including IT systems for new ships and modification of existing systems while operationally maintaining the existing systems. Ditto for my hospital client that may be rolling out a new robotic pharmacy dispenser and other projects while they are operationally operating the existing IT systems.
The Space Shuttle Program has always had a program manager during development and operations. This is also similar to other large military and commercial programs where there is a program manager during development and a program manager once the system goes operational to manage the operations and the projects that improve the delivered system. The system is alive! Obviously as indicated you can have program managers without operational responsibility. The number of program managers with operational responsibility may be less only because they are usually higher in the organizational structure than those without operational responsibility."
Author's view of program management
Earlier, we suggested that James' view of program management "is a far cry from the PMI-accepted view of program management". James responded:
"I do not disagree with the far cry statement above. The PMI accepted view is valid but just a piece of a complex puzzle when put in context with the real world. If it were as easy as implementing a standard or a methodology wouldn't all of our problems be solved? I really emphasize salesmanship and relationship building because so many discount its importance. They tend to think that everything should be done with a methodology, logic and/or a governance model of some sort and tend to forget they are in a human system. People and organizations are far from logical.
The dirty little secret in the project management community is the number of PMO's that have failed or been rendered powerless by their leadership. A lot of this is because of the inability to sell the leadership and the organization on what needs to get done. BTW you can have successful program and project management without a PMO. A PMO is just one way it can be done. As mentioned I believe in process … but just the right amount of process based on the organizational need. There is more than one right way to do program and project management.
I hear so much whining by project managers that my leadership doesn't understand this or my leadership doesn't understand that and frankly it is not the leadership's problem it is their problem. They have not "sold' the leadership on the correct course of action. Being right is not enough. These selling skills, knowledge of human behavior skills are necessary at the project level and even more important at the program level. To be effective you have to know what makes people change their mind - you have to know what creates buy in and commitment from the organization and must be proficient at using this knowledge in the context of your real world environment."
Meaning of "Chaos"
We stated that "Chaos" is defined as "State of extreme confusion and disorder" - and then asked: "Are there really that many companies that are that bad?" To this, James observed:
"My experience based on observation and class participant comments is yes - there are many"
And promptly added evidence that, for obvious reasons, we are not at liberty to divulge!
Role of Program Manager
We suggested that "In practice, the problem is that the position may or may not be called "Program Manager" and may or may not have a proactive mandate." This prompted James to say:
"I believe you can be in a program management position whether your organization chooses to call it that or not. Even if they call it that you may not have a mandate. It is up to you, title or not, mandate or not, to lead, prod, cajole and yes 'sell' the organization down the path of effective program management."
Program Manager's work overload
We expressed considerable concern over the work load with this observation: "Given a number of projects in the program, the number of identified stakeholders and suggested frequency, this sounds like a full-time job in itself!" To this, James makes the following recommendation:
"Literally, yes, this can be perceived as and could be a full time job. But my assumption which I did not communicate well and will correctly clarify next time is that judgment must be applied here. Most program managers have project managers and stakeholders they have worked with awhile and have established relationships with and these do not need to be checked as frequently.
Also, calling these stakeholders does not imply a long conversation. In fact a lot of times you will not even speak to them but leaving a voice message expressing your interest and concern. This is powerful and they do not have to call you back. Some projects are more important than others and some programs are more important than others. There is opportunity for prioritization. For large programs you can call a specified number at random a day.
I am strong on this because a lot of leaders become very out of touch or are perceived as out of touch because they do not make these types of calls. These calls start the process for painless resolution of problems before they arise."
|
Conclusion