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?

Leave a Reply