Risk Mapping to Primary Constraints: Mapping the Project Schedule

Time:  Schedule

The primary constraint that overly occupies the attention of most project managers (even though it is not the most important) is the time constraint or vector as we call them at MCLMG. Project managers have become almost fixated on the “project schedule,” or “integrated master schedule,” to point that little else matters or is given resource priority. In reality, the schedule does not drive the project; it is the production of the demanded quality deliverables (“fit-for-use”) that should drive the project, the schedule is simply the artifact illustrating the project’s progress towards these objectives.

The needed parameters and achieved determinations are:

Parameters: non-risk adjusted schedule, risk register / issue log, lessons-learned, historical archives, organizational risk tolerance score

Determinations: a risk-adjusted schedule with REV-labeled tasks

At MCLMG, we teach and mentor our clients to only produce the schedule as the final step in the planning process, not the first or middle as is done on many commercial and governmental projects. The schedule fixation becomes the reason for many project’s “going off the rails,” needing remedial intervention to bring it back on track.

The risks or issues that impact our project’s schedule need to be identified in order to understand their severity and requirement for mitigation or response.  The risk register and issues log should identify the data parameters which assist in the mapping of the risks and issues to the schedule tasks that they could impact.

First, identifying if a risk or issue is internal or external to the project will allow the project manager and the team understand if this is a risk or issue can be managed within the confines of the project (internal), or if it lies outside the management boundaries of the project (external.) Additional parameters on the risk potential’s risk expected value (REV) on the other primary constraints (scope, cost, and quality) must also be identified and defined.

Once a risk or issue is identified as impacting time (schedule) the next step is to complete a “Schedule Impact Analysis.”  This analysis of the risk or issue and how it impacts the schedule will further help determine the steps to mitigate the risk or to respond to the issue.  Additional information gathered:

  • Trigger events and dates
  • Earliest and latest dates of impact
  • Impact to critical path tasks
  • Historical impact and lessons-learned data
  • Schedule impact deviations
  • Schedule impact probabilities

It is not enough to just track risks and issues on a risk register or issues log.  To proactively manage your risk and issues, additional measures and processes as delineated above are needed to ensure the equilibrium of the primary constraints is maintained. This equilibrium or balance is necessary to produce the project’s “fit-for-use” deliverables (the definition of fundamental project quality). is critical for today’s dynamic and visible projects.

Risk Mapping to Primary Constraints

Given the final acceptance of the project management community of the primary constraints model (scope, time, cost, quality, and risk) in place of the less applicable “iron triangle,” or “triple constraints” that was popular during the first two decades of the project management discipline, mapping of risks to the primary constraints becomes a necessary activity in order to improve risk mitigation and plan for more effective issue response directives.

The primary constraints model that we at MCLMG accept is illustrated in the following figure:
Primary Constraints

This figure shows that for all projects/program regardless of size or complexity, the need to ensure a balance between the primary constraints is necessary in order to produce the fundamental quality outcome of a project, i.e., the production of “fit-for-use” deliverables. At MCLMG, we call this Deliverable-Centered Project Management (DCPM).

While this concept may appear simplistic at first, we have discovered through the rescue and initiation of many projects for both the commercial and governmental sectors that many project teams including the project managers draw a blank when we ask them these seemingly straightforward questions:

“What are your project’s deliverables, and what determines their “fit-for-use?”

While for the project business sponsors the concept of what they expect or demand from the project for which they are funding can be an item of clarity, this clarity in many cases does not make the transition to the project team or its management resources. Business sponsors know intuitively what the project will need to produce and the quality of that production in order for them to accept the project as complete and successful – project managers in many cases are not so intuitively inclined.

Thus, the misalignment between the business sponsor’s expectations and the project manager’s focus is why there is the need to map risks to the primary constraints. When a project team maps their risk potentials (uncertain future events) along with their risk expected values (REV) to activities being planned, developed, and implemented, a better understanding of the future and its possible impacts on the project’s ability to produce “fit-for-use” deliverables suddenly becomes clearer. Project teams immediately focus their attention on those risks with the highest REV and the most severe possible correlation to the primary constraints as the paramount action of implementing proactive risk coverage to their projects. This mapping will assist in producing the additional risk register / issue log parameters necessary to support the association of risk potentials to the primary constraints.

The mapping of constraints to risk potentials immediately benefit the project by allowing the project resources to be applied with a better understanding of their efficacious and effective utilization on achieving the balance of the constraints needed to produce “fit-for-use” deliverables. This improved utilization supports the project’s goal of producing the demanded quality of deliverables within the budget and timeframes expectations of the business sponsors.

Over the next several blogs, we will discuss the mapping concepts between risks and the primary constraints (scope, time, cost, and quality). Please join us for this very important and needful discussion involving the risk environments confronting most if not all projects, programs, and portfolios.

The New RISK Standards for 21st Century Project Risk Practitioners

New Risk Standards for Project Risk Practitioners
Moving project risk standards, definitions, and concepts into the 21st Century

eBOOK

Project risk management has matured to a point where project risk standards and definitions need to be standardized so that project risk professionals can finally have a common platform about which to discuss and implement project risk concepts. As risk practitioners, the authors have found a myriad of differing risk definitions, and concepts of risk/issues. As project risk practitioners the authors have had to spend significant amounts of time in remediation of this quagmire of outdated beliefs. This eBook is the culmination of their efforts to finally give project risk environments the fundamentals from which discussions and research can take place without having to deal with different terminologies and varying project risk fundamentals.

This extensive eBOOK is offered to the project risk management arena as the beginning of a new era in the discussion and understanding of how project risks and issues are identified, assessed, and managed for the main purpose of improving the overall project success rate that should have accompanied the 10 fold increase in certified project management professionals over the past decade. Sadly, this increase has not been forthcoming, and the authors believe that one of the contributing factors is the continued infancy of project risk management standards.

This paper will offer three major updates and solidification to the current project risk management environment:

  1. Standard project risk terminology and definitions
  2. Logical and axiomatic definitions of project risk concepts
  3. Definitions of project risk goals and objectives

The eBOOK seeks to finally assist with the standardization of project risk terms and concepts so that when project risk methodologies are discussed and implemented, project risk professional will at have a bedrock of common terms and concepts from which to advance the burgeoning discipline of project risk management. An example of these common terms is the fact that many knowledgeable project risk practitioners continue to discuss and plan “risk response plans” when logically one cannot respond to a future event — which every risk potential is.

Another project risk management concept which continues to be based on outdated risk management practices is the concept that risks and issues are managed in the same environment using the same tools and techniques. This eBOOK shows how this concept alone is quite dangerous to improving project success ratios at most organizations.

The authors invite you read this eBOOK and think about the ideas and concepts presented, and as always, the authors welcome your comments and remarks about this very important advance in the standardization of project risk practices.

Take care,

Paul H. Lohnes & Cheryl A. Wilson
Alexandria, VA
July 25, 2012