Hatfield’s Project Management Maturity Model, Part II

 

I Wonder Where Ruth Is

In furthering my particular PM3, the casual reader may have noticed something peculiar about my approach: I’m ruthless when it comes to abandoning tradition when it comes to refining the model. In last week’s blog I made the case for jettisoning risk management, human resources, procurement, communications, and quality from consideration in my model (except for specific circumstances), leaving only scope, cost, and schedule from the original PMBOK Guide’s® table of contents. It just so happens that these three management areas, taken together, are commonly known as the “triple constraint,” the basis for all other project management information systems.

Maybe She’s Out Trying To Find Answers

I’ve often stated in this blog that the 80^th percentile best managers who have access to only 20% of the information they need to obviate a given answer will be consistently out-performed by the 20^th percentile worst managers who consume 80% of the information so needed. So, when discussing structures or models that represent how organizations or project teams move from poor to superior performance, my particular application of the Pareto Principle becomes relevant. Management information rarely comes easy (or cheap), particularly since it must satisfy three requirements:

• It must be accurate,
• It must be timely, and, most of all,
• It must be relevant…

…which pretty much leaves off those areas of PM “expertise” that I’ve abandoned as part of my project management maturity model. The number of “stakeholders” engaged is irrelevant. For the project manager, the total compensation package for employees is irrelevant (a huge deal for asset managers, sure; but, for the success of a given project, not so much). The entries in a typical risk register are both irrelevant and inaccurate. The information streams created and maintained, then, for the production of these kind of datum are a waste of time, energy, and expertise.

Conversely, the precise nature of the scope being pursued, and the cost and schedule performance of the project team cannot be undervalued. These items are hugely relevant, and the task before the project teams’ analysts is to deliver this information in an accurate, timely manner.

And Yet, Ruth Is A Person

As tempting as allowing the Hatfield Project Management Maturity Model to rest on the comparative epistemological value of management information systems may be, the simple fact remains that project teams are made up of people, informed and otherwise. It’s a fact that some people on the project team will be more motivated than others, and, in sufficiently large teams, it’s a near-certainty that at least one member of the team will be working against the overarching goals of the project, particularly if it means their own personal advancement or advantage. Even the seminal work in capability maturity models, the CMM© from Carnegie Melon University’s Software Engineering Institute, was based on the observed behaviors of the subject project teams. For the SEI Level 1, the members of the team were not cooperating. For SEI Level 2, they were cooperating, at a basic level. At SEI Level 3, team cooperation was no longer based on a few individuals influencing them to do so, and so on. My take is that things like universally-used forms or the documents associated with their common training are artifacts of this cooperation rather than causes or drivers.

So, if project team-wide cooperation is the name of the game, how is that attained, or expedited? Game theory can provide some insights here, which will be covered in Part III.

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.