DCPM: Use of Concurrent Scenario Approach (CSA)

by PH Lohnes, PMP

One of the ideas that has finally begun to gain ground on the fringes of the project management discipline is the failure of the phased approach to solve project issues in producing “fit-for-use” deliverables. The phased approach is such an ingrained part of project management bodies of knowledge that when I speak of this to project managers they look at me like I have two heads!

What I mean by the phased approach is that one collection of similar activities are completed and then a review or gateway is reached, permission is given to proceed, and then the next phase is commenced. Now most think of this as waterfall and not applicable to the new Agile-form of software development, but I need to bust your bubble in that Agile type project development formats are simply very small waterfall cycles. Instead of taking 6-18 months as in most waterfall approaches, Agile breaks the cycles into smaller 2, 4, or 8 week cycles called sprints. However, each Sprint goes through the same “phases” from requirements, design, development, and testing prior to sprint delivery to the customer. The sprints are simply shorter, covering less work effort before delivering smaller units of work effort.

I know that this may be seen as abhorrent to many in the Agile community, but it’s the truth and needs to be understood since the same problems of using the phased approach yield similar issues in both the traditional waterfall methodologies as well as the Agile methodologies. The main difference is the amount time between the cycles and the production size of deliverables to the customer.

So what is the CSA? In the phased approach, a single solution is selected upon which the project then moves forward into design, development, and delivery of this chosen solution. This seems such a wonderful idea that it is almost heresy to even speak about its shortcomings in open forums; however, the definition of a project itself shows that single solution approaches (or pre-fix solutions as they are chosen before project planning) are futile in many cases.

A project has the following characteristics:

  • A definite timeframe for its completion,
  • Confined by primary constraints (scope, time, cost, quality, and risks), and
  • Production of unique, “fit-for-use” deliverables.

This definition is a more specific than most bodies of knowledge currently in use; however, it covers all the true and mature aspects of projects as they are implemented today. The characteristic that is left out from most lists today is the second one of being confined by the primary constraints. The PM discipline now realizes that all projects are bounded by these constraints, and the balancing of these constraints is an important function of all project managers (See the concept of Deliverables-Center Project Management).

By exhibiting these characteristics, projects can be differentiated from operations which exhibit an on-going nature that produce common, and well-understood products or services. An example would be the production of a specific truck model from the Ford assembly plant in Dearborn, MI. Operations and projects are the two major activities that businesses engage in to accomplish their mission or vision profiles.

This seems a long route to address the CSA concept for projects; however, think about what a phased approach to project planning and execution means? Think about the last project you worked on and how the project had to define, cost, schedule, and execute a single solution approach. If you submitted a project business case that provided for a “trial and error” or multiple-scenario approach in order to decide on a development approach, you would have been ridiculed or even laughed at (I know from personal experience) for not coming up a defined solution that matches the requirements of the project’s business case. Is not this the reason for having business analysts on the project? Is this not the reason for all the requirements definition and mapping?

NO! Please explain to me how a set of activities that is to produce a unique set of deliverables would categorically know at the beginning of the project how to solve the production of these unique deliverables? One of the reasons for such dismal project success rates, in my opinion, is that project managers are required to submit a single, phased-approach to the solution of a project that has never been accomplished before this one. Being forced to settle on a pre-selected solution drives the project down a road that may, and usually does not given the current project failure rate, not produce the desired results.

Why cannot the project management discipline accept that a project needs to have the flexibility to investigate with actual resources, budget, and schedule the possible alternatives to the production of “fit-for-use” deliverables? The most often given answer is: COST!! However, please consider the cost of almost 2/3 of all projects that fail to meet their deliverables on either a budget or schedule basis. Would it not make sense to spend a few resources on finding the more appropriate solution as to one that we can only guess may be the right solution?

I caution you to use these ideas carefully. If you do not believe me, try suggesting this approach to the selection of a project solution at your next project kick off meeting and see how quiet and cold the room becomes at even the mention of this approach?

Placing Experience Where It Matters!

< This is a personal blog – not indicating the corporate views of MCLMG, LLC >

Project/Program Portfolio Management (PPPM)
By PH Lohnes, PMP

Placing Experience Where it Matters!

After listing the perspective characteristics of the PPPM levels in a previous post, one more discussion is needed to lay the foundation for understanding how all three layers work in harmony to produce an increasing rate of project successes. The idea is going to be difficult for many in the PPPM discipline to accept since it is contra-indicated according to current practices — even to the point of impacting fees and compensation.

In a nutshell, erroneously, most organizations have placed the most experienced project managers in the same hierarchical structure that indicates a direct reporting or management role of lower levels. This means that program managers are superior to project managers, and portfolio managers are superior to program managers as an org chart would indicate. This is counter productive in so many ways.

Now before you begin screaming and throwing your nerf (yes, I said nerf — google it!) units at the screen, understand the current problem with project management — IT IS NOT WORKING! Referring back to a pervious post on “What’s Wrong?” we made a case for lack of project success rates correlated to the number of certified project managers now in the discipline. This is one of the main reasons for that lack of success — yes, its the fact that most organizations deplete their executional project managers by making them program and portfolio managers!

There, it is said and it is out there! Deal with it, and once you have slowed your heart rate, think about the one thing you are not able to teach from a book, a course, or seminar?


You can teach someone how to plan, write a plan, document a plan, develop a schedule, update a schedule, identify risks, write risk mitigation strategies, document staffing plans, write a communications plan, and many other project management necessities. What is not taught, can’t be taught except through the school of time in the course of experience (re-read this last phrase if the alliteration is unclear) is:


This is a skill that can only be learned through long hours of actually practicing the craft of project management. Thus, bluntly and forcefully stated, most organizations promote themselves out of increasing project success by implementing the age old practice of “pushing experience up the ladder.”

Think about it. Organizations put their most junior (by this I mean inexperienced) project management personnel at the execution level, promoting their more senior and experienced project managers into program managers so they can increase their compensation. Unfortunately, the law of unintended consequences reduces the expected benefits. Therefore let this post end with:

No one should be more highly prized, compensated, retained, or supported than an experienced EXECUTIONAL project manager.

More mindset ideas in my next post.

Processes, Processes Everywhere…

< This is a personal blog – not indicating the corporate views of MCLMG, LLC >

Project/Program Portfolio Management (PPPM)
By PH Lohnes, PMP

Processes, Processes Everywhere, but not a Drop of Success Anywhere!”

While this may seem somewhat extreme, my two year research project has shown me that at all the organizations without exception, the demand for more processes was the rallying cry to remedy the project/program portfolio problems they were experiencing. In meeting after meeting, I heard that the problem is we need to define our processes, we need to hire a consultant to define the right processes, we need… You get the idea.

I can tell you that the reason for failure of project and programs in today’s PM environment is NOT the lack of processes. Even the PMI’s own body of knowledge has over 42 processes; the APM’s body of knowledge has defined its cache of techniques/processes; the IPMA has 46 competencies/processes, etc. On top of that, almost every consultant has their take on the kind of processes needed to shepherd a project to successful completion. So with all these processes, why is the rate of project success still around the 38-50% level depending on which study you read?

The problem thus cannot be the lack of processes – it is the simple lack of understanding about the correct perspectives that project, program, and portfolio managers should have in an organization. While this may seem rather dismissive to the complexity of the project management discipline, let me ask you one question:

As you know more and more about a discipline, does it become more complex or simpler?
The obvious answer is simpler!

Ask any subject matter expert (SME). They will most likely tell you that their discipline is very complex to the untrained, the uninitiated, or the neophyte. However, ask them if they find their discipline easy to understand, and they will, with a large smile, tell you that, “Yes, it is simple to me know that I understand it completely.” Another case in point – I watched my late father perform over 50 surgeries as a thoracic surgeon with each one a resounding success. The point that stuck me was the ease with which he yielded the instruments, excised the malignant tissue, and closed the wound. All without the merest hint of difficulty or hesitation. He had performed over 500 of such operations, and to him, the process was simplistic.

My point, it is the experience or skills with which the process is executed that is the paramount issue. So ask yourself: Does my organization put the most senior or junior personnel at the project management level? I maintain that in most organizations if not all, put the experience at the point of the hierarchy where it makes the least impact while depriving the project management level of the experience and skills needed for proper execution and discipline.

In closing, consider this concept: you can teach people how to strategize, plan, and manage, but learning how to execute is a skill only derived from the hours of hands-on experience served up in the crucible of time on the job as a project manager. In short, organizations should worry less about the kinds of processes they have, and more about the right experience and skills at the right levels.

Execution of the plan is the reason most project are not more successful. Does anyone write a plan focused on failure? Does anyone teach how to write failing project plans? Anyone can write a plan, only experienced project managers can implement it on-time and on-budget.

Processes? No, rather experience is the ticket. I will be covering this topic in more detail next week when I make my suggestions on how properly to staff your project/program/portfolio structure. Most organizations do not even consider achieving the best use of their experienced project managers, as I will show in a subsequent post.

Tomorrow we will post what the correct perspective focus each level of the PPPM structure should have in order to increase the success rates of project activities.

DCPM Blog Introduction

Welcome to the MCLMG, LLC’s blog on leading edge discussions and methodologies for the Project Management discipline.We at MCLMG have developed an innovative, and practical new concept of project management based on the simplest of concepts that the most important goal or objective that any project, program or portfolio must have is the production of “fit-for-use” deliverables. The PM discipline has gotten away from this concept, in our opinion, being more interested in credentials, processes, procedures, and “bodies of knowledge.”

We at MCLMG with a combined project management experience cache of over 60 years in just the senior management team have assisted our clients and customers in returning to the basics of project management by cutting through the almost liturgical confusion that several of the project management knowledge warehouses have attempted to propagate and/or demand as required for “proper project management” operations. Through actual implementation and results, MCLMG has provided a simpler, but more effective environment for achieving higher project completion success rates while staying within the budget, schedule, scope and quality constraints of modern project implementations.

Join us each day for poignant tips, techniques, and discussions on how your organization can improve their project management success rates while simplifying the processes and activities that have come to plague most project teams in today’s ever increasingly complex arena of project management.

To start your mindset re-programming, consider this: with an almost 20-fold increase in the number of certified project managers from about a decade past, it would appear to be intuitive that the project success rates would have increased in like manner. However, ask yourself: is this the case at your organization? MCLMG has found just the opposite which we have discovered is due primarily to the almost parallel increase in “project management body of knowledge” complexity. Complexity is the antithesis of success as the statement of Occam’s Razor has so succinctly stated:

“All things be equal, the simplest solution is usually the best.” (paraphrased)

 Join us in helping you and your organization recapture the project completion success rates that a simpler management solution can offer while reducing the stress and strain on your project teams and management resources.

Take care.