Hybrids, or Mutants?

 

In Stan Lee’s Marvel Comics universe, the X-Men are people who usually look like the rest of us (in Mystique’s case, literally), but are actually endowed with various superhuman abilities stemming from being born with a genetic mutation. There are mutants other than the X-Men, some of whom follow Magneto (who can manipulate metal without touching it) and represent the X-Men’s ideological adversaries, and some mutants who are un-aligned and just go about their lives.

And then there’s the rest of us, who have to endure seeing projects that took millions and millions of dollars and represent iconic aspects of American life – like the White House and the Golden Gate Bridge – ripped to pieces by the mutants who are trying to decide an argument  about an appropriate equilibrium point in human/mutated-human relations. Due to an entirely understandable reluctance to see iconic American structures ripped to pieces, considerable effort is expended in the X-Men universe to devise a method or machine that can reliably detect mutated humans, so that the mutants can be readily identified and dealt with, one way or the other.

Meanwhile, back here in the project management world, we see epistemologically similar conflicts, where certain long-held precepts about PM are challenged, or overthrown, by technical approaches that look like traditional PM, but have really been modified to fit specific types of project work. The modified versions appear to be in compliance with the PMBOK Guide®, but are actually different, and often times far more powerful – so powerful, in fact, that they threaten to shred some of the more traditional models. In our universe, there is also considerable effort dedicated to ascertaining which management approaches are consistent with basic PM precepts, and which represent something outside our codex, and need to be identified as such, les they infiltrate and blow us up (in the arena of competing management science hypotheses, of course) with their circumstance-specific greater power.

As it turns out, my second book, the one this blog is named after, happens to address this very issue, that of which easily-articulated tests could be employed to ascertain those management information systems that are effective, and for which purposes, and which, well, aren’t. The underlying theory behind this mutant-identifying machine (strikethrough) information stream validator is predicated on the idea that all project management information systems exist to answer at least one of the following questions:

1. Is the product or service being provided that which was originally agreed to for the price?
2. Once the project or activity is completed, is there an audit trail that allows a reconstruction of the decision-making process?
3. What is the cost and schedule performance of the work as it’s in-process?

Depending on which of these questions is important to the contractor or customer, the available PM techniques can be abandoned, or embraced.

Take #1, whether or not the product or service is what was negotiated for the price. The variations of this are those times where either (a) the product/service is sub-standard (quality management, scope definition), or (b) the contractor attempts to increase the price for the same amount of work (change control/configuration management). In those instances where there is little chance of the product/service being sub-standard or a price increase (e.g., contractual delivery of a commodity), then all that PM stuff about quality and scope can be abandoned safely.

Number two is obviated by the use of firm fixed price (FFP) contracts. Using these types of contracts means that there’s no valid use for all of the basis of estimate detail, variance analysis reports, change control justifications, and schedule analysis that are often demanded from projects by the customer(s). Which leaves us with…

Number three, the ability of PM techniques to report on cost and schedule performance as the project is on-going. In the cases of Scrum or Agile, the latitude to jettison the PM artifacts of the other two information demands allows a streamlining of the technical approach. Note that, in Scrum/Agile, one of the first things abandoned was the formal change control process, which existed in the first place to address issue #1 – something that has considerable more latitude in, say, software development projects than it would in the construction of an iconic bridge linking San Francisco to Marin County, or an executive mansion for the President of the United States.

Yes, in the mutant (strikethrough) hybrid world of PM, some icons can be (cinematically) blown to smithereens. Knowing the conditions that need to be in-place prior – that’s the superhuman power.