MW: 2. If this is course material (as set out), what would be the benefit of someone taking the course in terms of his or her opportunity for employment?
MS: This remains a good question most organizations prefer that their analysts produce conforming analytics, not necessarily the truth. However, there appears to be a growing trend on the point of integrity. It's interesting that the OECD is pushing Integrity internationally and companies are being "ensnared in its grip." Companies such as KPMG represent themselves as a voice of objective analytics and yet they get caught as well from time to time. It raises the question on what basis are you asserting your analysis is sufficient, objective and balanced?
Organizations that purport to promote integrity in analytics could turn to this as a certification program to indicate their support for integrity.
I should also add, with the advancement of the Internet, information sources are much more open less peer reviewed material and more "hear say". Thus a reference on sound analytics vs. what I refer to as "sociolytics" becomes more important for those wishing to separate fact from fiction. In fact, there is a cottage industry out there on truth subversion by "trolls" on the Internet. The public has less and less opportunity to judge for themselves.
The "greenFields model" or whatever variant the community accepts in future enables a common analytic perspective on the truth where diversity of view can be seen in the a priori assumptions and not in the interpretation per se.
The WIN-PM piece is a case in point. WIN-PM and the DBM "plug into" Program 2, module 4. The greenFields model thus provides a larger continuum as the basis for testing assertions such as those in the PMBoK.
I have noticed that as I lectured on the DBM over the years, audience discussions expanded quickly into matters of law, engineering, philosophy, and psychology ... and yet there is a common analytic underpinning to all the disciplines (i.e. analytic correctness does not change between Project Management, Law, etc. etc.). I can teach the DBM to law students, and I can teach law to project management students.
MW: 3. I notice that the several pages of Terminology listings appear three times. I haven't checked to see if they are identical, but if they are, why are they repeated? Why not put them in an Appendix?
MS: The greenFields model (think "PMBoK" for Analytics) is a three program series. This would be like three PMBoK's one focused on the individual, one on the professional in the corporate environment and one on Society in general.
Each program is stand-alone and could be offered separately. Hence the Terminology is gathered for each program and the terminology indicated within is unique to each program.
MW: 4. And in any case, what is the benefit of such a list of terms without their corresponding definitions?
MS: This is a good point the definitions need to be entered. This is simply due to limited time on my part.
The intent is to broaden the team and somehow allow contribution of others without introducing chaos. Not sure, quite frankly how to achieve this yet, but I'm sure the folks at PMI went through the same challenge. With that, the greenFields model is perhaps more of a discussion piece toward the prospect it suggests, a starting point.
On the subject of the Book WIN-PM:
MW: 1. This is also very nicely assembled and presented and, of course, full of valuable reference material. When did you finish it?
MS: A few weeks ago
MW: Have you published it as a book in some form? Or perhaps as an academic paper?
MS: I put it on-line for download. I would have liked to publish or present it as an academic paper however again it comes down to time constraints. I was hoping not to delay issue.
MW: 2. If not, would you be interested in putting it as a series of Guest articles on my web site (Similar to the DBM)? You have about 20,000 words so that might be about 5 months of 4000 words each. Let me know what you think.
MS: Yes this would be good.
Separating project management from technology management
MW: 3. I like to take every opportunity to ride my latest hobbyhorse about the PMBOK and those who (try to) follow it slavishly. The original issue of the PMBOK back in the '80s was a statement of the extent of the project management domain (excluding all those overlaps with the various disciplines of general management, such as people management, and so on.) To repeat, it was intended to be a statement of fact put out for discussion and improvement.
However, with the advent of the popularity of systems thinking, a great effort was put into trying to make it such, which resulted in the publication of a "Guide to". This in turn was adopted generally as a methodology, because that is what it looks like, notwithstanding clear statements to the contrary in every subsequent update. At the same time, there have been two serious flaws in these publications, aside from the confusion over the project management processes: The first is:
(a) Insufficient attention to the "Project Life Span" control design that should be specifically designed for every project and which, in fact, drives and orchestrates the rest of the whole project process. And
(b) A failure to recognize that it is the technology of the project (and not any preconceived idea of a "project life cycle") that determines the major sequence of control points in the design of the "Project Life Span" control sequence.
If only people would recognize and understand the distinction between project management and technology management, and hence separate the two, many of the seeming conflicts both in theory and in practice would disappear.
MS: I perhaps need to better understand this point. I certainly agree with your "hobbyhorse" in principle and have for a few decades had the same opinion.
If one could separate technology management and project management and enable parallel perspectives that don't conflict, I think this would be good.
The DBM makes the point that it is not the technology per se but the complexity (uncertainty) inherent in the technology and the larger plan that must be considered.