Four Dogmas of Empirical 3PM

February 23, 2012 | Author: PM Hut | Filed under: Project Management Musings

Four Dogmas of Empirical 3PM
By Terry Rankin

Caution: this article is long and will be difficult for some to grasp, but worth the effort. Also, apologies to philosopher W.V.O. Quine; the article incidentally corresponds to his “Two Dogmas of Empiricism” in some specific phrasing and general conceptual reference, e.g., as in the title of the article itself.

To begin, the limit of the scope of this analysis must be explicit: the paradigm in question is not the analytic (or a priori theoretical, ideological, and methodological) collections of concepts, principles, practices, methods, and models found in Project Management Institute’s (PMI) Project Management Body of Knowledge (PMBOK), Software Engineering Institute’s (SEI) Capability Maturity Model Integration (CMMI) Project Management Process Areas, International Standards Organization’s (ISO) Standards or Guidance for Project Management (ISO 10006:2003, ISO 9004:2009, and forthcoming, ISO/DIS 21500), Six Sigma Certification, Agile/Scrum, or other approaches having comparably sound and well-grounded foundations in the theory and practice of project, portfolio, and program management (‘3PM’). Indeed, even a partial or moderate implementation of these approaches cited would displace the fallacious paradigm exposed here.

The scope of this analysis focuses upon the empirical (a articleeriori, in situ) world of ‘3PM in the field’, in situ, i.e., as it is practically conceived, understood, and applied in the (more or less) real world of corporate business and operations, in any industry (finance, banking, healthcare, manufacturing, logistics, etc.) and in every sector (for-profit, private, public, etc.). Despite the success of PMI, SEI, and others in recently establishing, supporting, and promoting project management as a genuine profession and its conceptual methodological paradigms, what actually takes place in the daily grind of empirical 3PM, in the operational trenches and the corporate hallways and board rooms, usually reflects a very different – and very effectively disguised – 3PM paradigm that is fallacious to the core.

Despite steady and somewhat aggressive growth in the profession of project management during the past quarter century, the dominant 3PM paradigm undermining the greater success of PM pros and the outcomes of their projects continues to rest upon at least three fundamental fallacies. Two of these root causes of 3PM failure are basic category mistakes and the third is an absurd reduction (reductio ad absurdum) derived from the first two.

Semiotically, a category mistake is a logical (essentially semantic) fallacy wherein the thing a sign stands for is wrongly classified (i.e., miscategorized) as belonging to one class, set, or group of things when that thing actually is a member of another category associated with different signs. Applying the ‘fish’ categorical sign to cetaceans (e.g., whales, dolphins, porpoises, and manatees), for instance, would be a biological category mistake. It is an improper use of the sign and a wrong classification of the things for which that sign stands.

Similarly, despite often being correct in terms of purely syntactic derivability (i.e., based on signs and relations between them apart from any of the properties and relations of the things for which those signs stand), a reductio fallacy may appear valid but remain nonetheless unsound. Example: based on classical rules of formal logic, “if today is not Wednesday, then JFK and Elvis are still alive and well in geosynchronous earth orbit aboard a top secret space station” is a valid inference every day of any week except Wednesday. But surely the absurdity of this inference is evident regardless of the calendar. [Note: this example illustrates one or more of the paradoxes of material conditionality.]

In the following discussion of the core fallacies in the prevailing empirical 3PM paradigm today, two category mistakes and one reductio will be identified. Several additional secondary but nonetheless genuine fallacies will also be shown to sustain and perpetuate this flawed 3PM paradigm through disguise, misdirection, and manipulation.

The 3 Core Fallacies of Empirical 3PM

Note: the “Skeptics Guide to the Universe” provides a nice summary of informal fallacies, of which category mistake, reductio ad absurdum, and other secondary fallacies cited here are just a few.

Category Mistake #1: Project=Task Conflation (CM#1)

This fallacy is committed by equating a project with a task list. This occurs when corporate vision, strategy, direction, and operational (static or dynamic) inertia pre-determine one, more, or all of the following without benefit of a rationally sound 3PM model and without involving a bona fide 3PM professional in the process (note – this list is incomplete but sufficient to illustrate the point):

project resources (stakeholders, team members, funding, equipment, facilities, etc.)
project relevance (goals and objectives, business scope, requirements and deliverables, etc.)
project framework (approach, method, success criteria, cost benefit, etc.)
project timeline (start, finish or duration, milestones, deadlines, etc.)
project viability (risk-benefit, -likelihood and -impact assessment, contingency planning, etc.)
project impact (outcome value, benefit or contribution, operational and cultural effect, etc.)

The fundamental 3PM paradigm category mistake leading to these blunders is a naive presumption that a project consists of nothing but a list of work tasks and activities. The seniority of the leader and the tendency to commit this fallacy appear to be directly proportional – the more senior the leader, the greater the likelihood they commit this fallacy. Thus top executives are usually more likely to presume that all strategic elements and aspects of every project are perquisites of leadership. It is their role and responsibility, therefore, to define all of the key elements of every project and program in the entire portfolio. Once these strategic resources, constraints, objectives, deliverables, etc., are determined by leadership prerogative, they become fixed parameters and expectations the ‘project team’ they’ve identified must transform into a work breakdown structure (WBS) to carry out; i.e., a list of fully specified work tasks and activities.

The reductio aspect of CM#1 is the leadership’s tendency to ignore the ‘fully specified’ qualifier and make the naive – and grossly mistaken – assumption that having defined the essential parameters and expectations of the ‘project’, the ‘tactical details’ of defining and completing all the tasks and activities for the project to succeed is beneath them … work to be delegated to and managed by the project team and their supervisors. Leadership has done all the hard and strategic work of defining the project, they assume, so all that remains is for the project team to complete the workaday tasks and activities to execute their leaders’ ‘project plan’.

Of course what leadership has provided is far short of being an actual project plan (since it doesn’t contain the WBS), and what the ‘project team’ must do is much more than define the WBS. Once a project team in this situation begins to work on a fully specified WBS within the constraints given by leadership, an enormous gap inevitably appears between their tactical reality and the leadership’s strategic vision. An enormous amount of data and information emerges concerning WBS (task and activity) contingency, dependency, risk, cost, priority, scope, duration, and all the other concerns in the list above. Thus begin the costly and intense recurring multilevel rounds of thrust-and-parry negotiations between leadership and the project team – with managers and supervisors in the middle – struggling to close that gap. The outcome is usually a (more or less complete) de- and reconstruction of the project that may or may not have a better chance to succeed. The one certainty is that relations between leadership, management, and workers will have been severely strained, time and money will have been wasted, and project morale will be neutral at best.

Had CM#1 (and its implicit reductio and other fallacies) been averted and replaced by a sound 3PM model and involvement of a qualified 3PM expert from the initial inception of the project, this entire fiasco would have been avoided and the project would have started not only the right foot, but with an actual and complete project plan on much more highly probable course for success.

The CM#1 blunder completely obfuscates the true nature of projects. Properly understood, a project is an organic, dynamic whole far exceeding and transcending the sum of its task- and activity-parts throughout its existence, in all of its stages, phases, cycles, and directions. It is no more reducible to a punch list of work tasks or activities than a living human being is reducible to a shopping cart of chemical elements, compounds, and batteries. Indeed, start a project under the burden of CM#1 and most likely outcome will be a project cadaver. As a lethal category mistake, CM#1 is every PM’s nightmare – from which we only rarely awaken in the empirical 3PM world.

Category Mistake #2: Business >Technology Conflation (CM#2)

Unlike CM#1, CM#2 doesn’t directly identify (“=”) one category with another. CM#2, by contrast, just makes a false assumption about the applicability (“>”) of knowledge, expertise, and experience in one category (business) with knowledge, expertise, and experience in another (technology). The same false assumption is often at work in CM#1, insofar as business leaders tend to freely take it as axiomatic that their business leadership knowledge, expertise, and experience directly apply to the discipline and profession of 3PM. This problem is exacerbated when the same leader(s) also embrace the false 3PM paradigm of CM#1. Two false assumptions conjoined at the core of 3PM (vs. just 1) doesn’t double the likelihood of 3PM failure – the increase is exponential, perhaps by an order of magnitude. CM#2 is the false assumption that business knowledge, expertise, and experience applies with the same integrity and force in the field of information technology (IT).

Most information technology (IT) professionals accept their role as specialized experts in one or more areas of IT skill and expertise – networking, telecommunications, database, applications, or others among a rapidly growing number of IT-specific domains. They would reject any suggestion or idea that they could presume to professionally function and perform well in areas of business expertise (finance, marketing, manufacturing, investment, real estate, logistics, etc.). It would make no more sense than asking or expecting a plumber to perform brain surgery, a rodeo bull rider to conduct accounting audits, or an NFL quarterback to plead a legal case before a federal judge.

Among a growing majority of corporate leaders and executives, however, a viral delusion seems to have infected and disabled their common sense: an alarming number of business leaders – in the fields of marketing and finance especially – see no fallacy and show no hesitation in making crucial decisions directly or indirectly affecting the entire enterprise, regarding IT products, vendors, staffing, infrastructure, design, architecture, operations and ultimately every aspect of IT in their companies. It is still quite common, for instance, to find top IT leaders reporting to their CFO or COO – even in multibillion dollar enterprises where the use and leveraging of IT resources is mission-critical, from the broadest business vision and strategy to the detailed tactical operations and daily activities. The situation only worsens in small and midsize businesses.

While leaders and executives deluded by CM#2 may hasten to admit they lack the ‘technical know-how’ to actually build and operate IT systems and applications infrastructure on a daily basis, they are nonetheless confident in their abilities to decisively determine what the core nature and basic framework and product components of that infrastructure should be. Once again, the leadership is susceptible to the delusion that their authority and roles per se extend to determination and control of IT infrastructure, just as in CM#1 the leaders are susceptible to the delusion that their authority and role extend to 3PM control and determination.

Like CM#1, CM#2 is also a self-inflicted category mistake that is a simple case of mistaking one’s own identity, i.e., of thinking one is someone other than who they actually are. Vanity and hubris are often the root causes of both delusions. The effect of the CM#2 miscategorization is to conflate business leadership skills, expertise, and experience, on one hand, and technology leadership skills, expertise, and experience, on the other. Unlike CM#1, however, in which no distinction or difference (that makes a difference) remains between the concepts and signs ‘project’ and ‘task’, in this case (CM#2), the conflation is only, as it were, ‘one-way’: while business leaders lacking genuine skill, experience, and expertise to qualify as IT experts nevertheless (delusionally) see no problem at all in assuming the role of and functioning as IT professionals, the converse does not hold – the very idea of an IT professional assuming the role of and functioning as a top executive or senior business leader in finance, marketing, operations, logistics, or other (non-IT) business domains would be rejected out of hand as laughably absurd.

Several additional secondary fallacies may also be at work to exacerbate CM#2 or CM#1:

argument from authority, i.e., concluding that business leadership entails and bestows IT leadership simply because of the leader’s authority (despite any lack of IT qualification, skill, competence, expertise, etc.);
argument from ignorance (ad ignorantiam), i.e., concluding that business leadership entails and bestows IT leadership despite more or less complete ignorance of the essential values, principles, concepts, methods, best practices, scientific foundations, etc., of the IT field per se;
attacking the person (ad hominem), i.e., concluding that business leadership entails and bestows IT leadership based on a condescending and belittling view and assessment of IT leadership and/or technological or technical roles (and/or individuals filling those roles); and,
straw man, i.e., concluding that business leadership entails and bestows IT leadership on the basis of a false or flawed understanding of IT per se and/or IT leadership (e.g., “I read a great article in SKY Magazine on my flight back from Palm Springs that said cloud collaboration was the way to go in the future of computing … why didn’t you tell me about this and how quickly can you convert our total IT operation?”)

The PM’s nightmare thus becomes a living horror story. Obviously having any combination of CM#1, CM#2, and the secondary fallacies cited above affecting PM and/or IT in any business enterprise is worse than a slippery slope (another type of fallacy). In that situation the slope plummets over a cliff and the only remaining hope rests in hang gliders or parachutes (which would require exactly the 3PM risk management expertise cast out via CM#1, CM#2, and the secondary fallacies as cited).

Reductio ad Absurdum #1: Project Manager Role Reduction (RA#1)

The 3rd fatal primary fallacy dogmatically corrupting empirical 3PM in situ is a reduction to absurdity.

The primary (CM#1,CM#2) and secondary (as cited above) fallacies, whether affirmed in whole or in part, lead to the absurd conclusion that project management is task management (and vice versa) and project managers are task managers (and vice versa). This in turn leads to the equally absurd conclusion that any member of any good team of workers can successfully perform the PM role on any project, since the work of project (=task) management is best done by someone who’s already on the team – and it’s not really a fulltime role anyway, so they can keep doing their regular job and complete many of those tasks themselves as a working member of that team.

One of several hidden premises that facilitate this fallacious inference is usually some version of, ‘common sense is all that’s needed to be a good task (=project) manager, and every competent worker has at least that much common sense or they’d be fired.’ This premise is of course based on yet another fallacy of circular reasoning since, among other things, it begs the vital question of the extent – if any – to which the management of one’s own tasks is essentially the same as the management of others’ tasks.

CM#1 also results upon its own reduction to absurdity by conflating ‘project(s)’ to ‘task(s)’. Within the perspective of that conflation it is all too easy for an essential characteristic of projects to fall through the cracks (part of the ‘baby’ that’s ‘thrown out with the bath water’) as the conflation occurs: namely, that while it is true that projects do indeed consist (but only partially) of work tasks and activities, those tasks and activities are rarely if ever one in kind. With rare exception, every project’s work breakdown structure (WBS) consists of many tasks spanning multiple types of skill, expertise, experience, and responsibility. This reduction to the absurdity of ignoring those differences, buried within the conflation of CM#1, greatly increases the likelihood that the RA#1 fallacy will be embraced as sound reasoning, and once again exponentially increases the likelihood and impact of project failure with it is incorporated into the fallacious 3PM paradigm.

Reductio ad Absurdum #2: IT Professional Role Reduction (RA#2) should be apparent without elaboration beyond pointing out that it corresponds to CM#2 in precisely the same way that RA#1 corresponds to CM#1 – i.e., the effect CM#2 is to reduce the role of IT professionals (especially in supervisory, management, and mid- or senior-level leadership positions) mere workaday technical task and activity management. Elaboration of other details and implications of RA#2 is an exercise left to the reader.

Conclusion

Once embraced as professional, business, corporate paradigms, CM#1, CM#2, RA#1, and/or RA#2 fallacies quickly become dogma – they are not open to question or challenge, and jobs and careers are at stake for any who may dare. Gartner’s ongoing statistical findings, root-cause analyses, and interpretive explanations regarding project failure rates in most business domains and sectors are a strong indicator of just how widespread and dogmatic these fallacies have become. (Search the phrase “Gartner project failure rate’” for an informative results list.)

Attempts to identify, uproot, and abandon the stranglehold these fallacies have on enterprise 3PM confront an incredible array of obstacles – largely cultural and political – and they incur enormous expense and cost in human, capital, material, market, and other assets and resources. Success in change management of corporate paradigm shift away from these fallacies and their impacts and effects upon corporate identity, culture, and politics is about as likely as successful 3PM results in a company deluded by the CM#1, CM#2, RA#1, RA#2, and/or secondary fallacies themselves.

As dogma, the fallacies explained here are so deeply semiotically encoded into the neural systems and corporate matrices of their victim-proponents that scant hope remains of easily or comfortably disabusing them of their individual or corporate delusions. Among the victim-proponents, whether acknowledged or not, The Peter Principle is in full bloom and pervasive effect. Barring traumatic deconstruction deconstruction and reconstruction of their business identities, leading others blindly down the path to project failure (especially in IT) will persist as a permanent career disposition.

One would be wise to carefully reflect and consider – with as much determination and objectivity as can be summoned – the extent to which oneself is infected with the fallacies exposed here and their delusional effects. The next step is to scrutinize and analyze one’s business or workplace – with equal determination and objectivity, to ascertain the presence (or not) of the fallacious dogmas in every leader, manager, supervisor, colleague, department, and team, to determine the enterprise’s individual and collective states in the same regard. The final step, especially if one share’s one’s findings, is likely to be a career-changing decision – voluntary or not.

Terry Rankin is a (mostly) sapient being and career technologist (by practical default) who befriends few, offends many, and alienates most, it seems, due to chronic impatience and acute intolerance in coping with the crawling grind and inevitable exsanguination of most human interrelation – who loves you nonetheless despite those contrary behaviors and misanthropic sins. His blog is often abstruse and deliberately esoteric (some may too hastily think elitist), but nonetheless universal in scope and vibrant when grasped (or so the blogger likes to think), as all worthwhile philosophical metalogue will be.

Share this article:

This entry was posted on Thursday, February 23rd, 2012 and is filed under Project Management Musings. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Management by Heroics

Project Planning for Project Sponsors: Why You Need To Be Involved

Lost in Projects - Integrated Project Management

10 Warning Signs that Your SharePoint Implementation May Be Heading for Difficulty

Smaller is Better and More Effective

Finding the Roots of Organizational Incompetence

Project Management Office Basics: Six Secrets For Efficient Shared Services

Project Management Foundations - What Makes Projects Fun?

How to Make a SWOT Analysis

Brutal ICT Development Project Classification

Four Dogmas of Empirical 3PM

The 3 Core Fallacies of Empirical 3PM

Conclusion

feel free to leave a comment