Laiserin's Lemma ™ —Process Knowledge

The first thing that comes to many people’s minds when considering process modeling for the AEC, FM, plant and infrastructure industries is the catch-all term "project management" or PM. PM is a well understood discipline that cuts across all project-centric business (aerospace, automotive, software development and so on—not just projects for the built environment). However, the "PM" category applied to software products and services covers an extremely diverse collection of tools operating at widely varying levels of sophistication across vastly different scales and scopes.

Thus, applying the label "PM Software" equally to a document-sharing website, an administrivia checklist program and a sophisticated, enterprise-wide business process modeling application is confusing at best and misleading at worst. Such uncritical stuffing of anything project-related into the oversized "PM Software" pigeonhole does a disservice to developers/vendors and customers/users alike. Instead, I’d like to propose applying a new classification scheme to software that models one or more aspects of project-related processes.

My proposed framework charts the breadth (or scope) of the processes to be modeled and managed (along the horizontal axis) against the corresponding depth (or type) of knowledge required (along the vertical axis). Conversely, one could say that the ability to deal with higher levels (or greater depth) of knowledge enables the capacity to model and manage broader processes. It may seem obvious that a process based on managing documents at the level of transactional knowledge differs fundamentally from a process for managing multi-project portfolios according to knowledge of business process rules. However, positioning both such tools (and many others) within a unified process/knowledge "space" yields a number of useful insights into the past, present and future of process models for project-centric businesses.