Hatfield’s Project Management Maturity Model, Part III

 

Does It Work?

In discussing the development of management maturity models, I would like to steer the conversation towards how such things should be approached in the first place. As I discussed in Part I of this series, the traditional, academic approach to this sort of research is to launch a project, collect members who see themselves as subject matter experts, get them to agree to the least objectionable set of premises possible, assemble those premises into a document, have the document peer-reviewed, and then (finally) a new theory is introduced and advanced. But does that approach really work?

Meanwhile, Back In The Real World…

I think that two of the most significant advances in project management in the last half-century came from the 1989 book Managing the Software Process by Watts Humphrey[i], and the 1982 book In Search of Excellence, by Tom Peters and Robert Waterman. While their conclusions are now pretty standard fare in business schools across the country, what I think is remarkable about these two books is the way their authors conducted their research. They did not follow the traditional model, nor its close cousin of developing a hypothesis, and seeking data that would support their conclusions. Instead, they (and their researchers) went out among functioning organizations that were succeeding, and noted what they all had in common. After a sufficiently broad data gathering effort, they focused in on which shared characteristics of the winners were relevant, and drew their conclusions from this data set. Note how different this approach is to the typical one – Humphrey, Peters and Waterman sought out what worked, and used their advanced grasp of causality to capture the source; conversely, the traditional approach is to collect ideas, and then get a sufficient number of so-called experts to agree to base their assertions on the collection.

A Return To The Unreal World

Managing the Software Process would lead to the now-famous Capability Maturity Model, developed by Carnegie Melon University’s Software Engineering Institute (SEI), which I believe is a valid model. However, in 2002 a “successor” to the original CMM was released, the “Capability Maturity Model Integration,” or CMMI®. This effort was to “improve the usability of maturity models by integrating many different models into one framework.”[ii] Naturally, the authors appear to have returned to the traditional approach, which rendered, in my opinion, the CMMI® inferior as a management science theory to its predecessor, the original CMM. It’s actually kind of ironic, the whole effort to integrate many different models into one framework, seeing as how virtually all of those many different models were very similar to (if not out-and-out derivative of) the SEI version in the first place.

And Now, For the Actual HCMM!

Actually, ladies and gentlemen, it doesn’t exist. Having one overarching structure that lends insight into how to influence a limitless number of project teams to perform better is pretty much beyond me. In many circumstances I like the original SEI CMM, but even it has its limitations, some of them quite stark. I believe that, if I were to be put in charge of developing a capability maturity model (by a paying customer), I would begin with these steps:

• Narrow the scope. Software project teams will use a very different PM tool set than construction, and aerospace projects would hardly be recognizable to PMs from the pharmaceutical industry.
• Remove any and all self-identified experts from the team, and retain only bright, well-educated researchers.
• Once we know the specific industry, find out as much about their projects, both successful and un, as possible from available records, particularly performance and change control information.
• Categorize the projects’ outcome as “Exceeds,” “Meets,” or “Fails to Meet” original project parameters.
• Only after these steps are complete would I attempt to interview members of the projects’ teams, the lower in rank the better. Major questions:
  • What went right?
  • Why did that succeed?
  • What went wrong?
  • Why did it go wrong?

Then I would interview the projects’ principals and consultants (if any), to see what the official story was, and contrast that with what the rank-and-file had to say.

From this data set I would begin to identify common factors among the winners and losers, and propose a structure to be published and peer-reviewed.

Did I mention the avoidance of any self-identified experts?

Lagniappe

My third book was released last week, and is available here. It’s entitle The Unavoidable Hierarchy, Who’s Who In Your Organization And Why, and it’s about how people tend to form and move up and down within social structures, including those in the corporate world. If you are a manager in charge of a team, it might be worth a look.

[i] Capability Maturity Model. (2016, September 19). In Wikipedia, The Free Encyclopedia. Retrieved 19:28, September 24, 2016, from https://en.wikipedia.org/w/index.php?title=Capability_Maturity_Model&oldid=740240845

[ii] Capability Maturity Model Integration. (2016, August 22). In Wikipedia, The Free Encyclopedia. Retrieved 20:02, September 24, 2016, from https://en.wikipedia.org/w/index.php?title=Capability_Maturity_Model_Integration&oldid=735671761