ITMPI FLAT 004
Main Menu
Home / Authors / Blogging Alliance / Red Queen Race: Why Fast Tracking a Project is Not in Your Control

Red Queen Race: Why Fast Tracking a Project is Not in Your Control

BloggingAllianceButton

“Well, in our country,” said Alice, still panting a little, “you’d generally get to somewhere else—if you run very fast for a long time, as we’ve been doing.”

“A slow sort of country!” said the Queen. “Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast, as that!”Through the Looking-Glass and What Alice Found There, Chapter 2, Lewis Carroll

There have been a number of high profile examples in the news over the last two years concerning project management. For example, the initial rollout of the Affordable Care Act marketplace web portal was one of these, and the causes for its faults are still being discussed. As I write this, an article in the New York Times indicates that the fast track efforts to create an Ebola vaccine are faltering.

In the world of the Red Queen, we must run very fast just to stay in the same place. The same can be said of project management. But what if we want to get someplace else—to “fast track” something? How much control do we actually have?

Critical and Project Assumptions

Many times when we read the headlines and reports critical of project achievement, the underlying assumption within the criticism is that we have a high level of confidence that we have the ability to control the variables and risk associated with the effort.

This is sometimes a result of improper analogies. Research and development are not the same as production. Opening up an additional assembly line will get more cars out the factory door. Opening up another lab may or may not result in expedited development.

But even acknowledging the difference between R&D and production, the criticism also presumes to accept the proposition that the assumptions used to frame the project’s goals were realistic. This is a fallacy.

According to a 2013 study by Arena, Blickstein, and others at RAND Corporation, it is these “framing assumptions” that are key in assessing realism over the project’s life. A later study by Arena and Mayer, also at RAND Corporation, built on this earlier paper by proposing a way of formulating framing assumptions in project management. When framing assumptions must be revised, it is an indication that the antecedent basis for undertaking the effort is at risk. At that point the effort essentially becomes a different project.

Project Resources and Risks

fantasycardsAmong the essential assumptions in undertaking any enterprise—but particularly as it relates to project management—is that there is a goal (or set of goals) and a plan. The effort is cohesive and identifiable. As with any system, we understand that one must contribute the raw materials and energy necessary to produce the technology, the entity, or the end item that is the purpose of the effort. In our world this consists of resources including people—with their concomitant expertise—money, facilities, access to tools and equipment, and the means to leverage the achievement of each necessary event in the development of the item toward the ultimate goal.

This last element, which can be measured by technical achievement but also consists of information and learning, is often ignored. It establishes our system as having closed-loop feedback systems that allow it to evolve within the environment in which it finds itself. Without measuring technical achievement, effectively sharing information, and learning, we may deliver a website that cannot handle the expected volume, a vaccine that is not applicable to the conditions under which the virus must be treated, or an airplane that cannot land on an aircraft carrier.

In the case of the Ebola vaccine, the framing assumption here is that we possess the means to “fast track” the development of the vaccine. The first order of business is to identify what exactly “fast track” means in terms of delivery. Does it mean by next year? Five years from now? As quickly as possible without a goal?

Let us assume that it is a goal that accelerates an established project plan. The project plan identifies a series of events that must occur through time in order to achieve the desired end goal of the project. The traditional approach is to throw additional resources at the effort. But this is not always the most effective route—and often results in a great deal of waste.

Depending on the risk in not achieving the end goal, the costs and waste associated with this approach may be viewed as inconsequential. We find this in historical examples where the threat that the effort was designed to address was an existential one. One obvious example here is the Manhattan Project during the Second World War, where it was determined that the consequence of allowing Nazi Germany to first achieve the capability of producing an atom bomb would be disastrous to civilization. But then, in such cases, such criticism is irrelevant to the framing assumption. Efforts directed toward project management and control in those cases are instituted to avoid fraud, waste, abuse, and to meet oversight responsibilities in resource expenditure.

But even in these special cases, where we are willing to accept a large measure of waste and alternatives that lead to dead ends, is the realization that any end item that requires specialized technical expertise will not always (and, in fact, very rarely) respond to brute force. In the case of Ebola, researchers must find a way for the virus to “cooperate.” The measures they take in doing this, whether consciously or unconsciously, with all of the variations in the pathways that may need to be explored, amounts to risk identification. The procedures and protocols in handling these results amount to risk handling, which may include risk mitigation or simply risk acceptance.

In the risk-based world we are always running to try to stay in the same place. For when we use the term “risk” in project management what we are really measuring is the entropy in the system. No system returns 100% effort from its inputs; there will always be loss.

We develop our plans to incorporate risk acknowledging this reality. Thus, our project plans—assuming our framing assumptions are correct—become a balance between managing risk and managing performance against the plan.

Information and Learning is the Key

storytimeWe must borrow from other systems in order to keep risk from manifesting in a way that it undermines the project framing assumptions and project resource constraints and consequently degrades the technical achievement resulting from the effort. To overcome the risk implicit, and therefore baked into the effort, either because of its nature or the entropy already experienced to date, we must find a multiplier so that we can “run twice as fast.”

I would posit that the only variables that have ever provided this kind of effect are information and learning borne of technical performance measurement. Only then can our time-phased plans, which must be tied to the achievement of work, accurately reflect and influence the chain of events (time) that must be achieved and leveraged to successfully conclude the effort.

 

For more brilliant insights, check out Nick’s blog: Life, Project Management, and Everything

About Nick Pisano

Nick Pisano has extensive experience in the software, project, business, and acquisition management fields, with over 30 years in both government and private industry. He is a retired “mustang” U.S. Navy Commander having served as a government contracting officer, contract negotiator, business manager, CIO, and program manager, aside from significant operational assignments aboard ship and overseas. He is internationally recognized as the developer and co-developer of several project management techniques and methodologies, including the integration of technical performance measurement and risk with earned value, and in the establishment of the concept of the integrated digital environment (IDE) to normalize proprietary data through the use of common data protocols. Since his Navy career, Pisano has held senior positions in various high tech project management companies. For the last several years, he has been President and CEO of SNA Software LLC, a project management software firm. Pisano holds a B.S. from the University of Maryland (Honors), an M.S. from Pepperdine University, an M.A. from the Combat Studies Institute of the Army Command and General Staff College (Honors), and is a graduate of the senior executive program of the Colgate-Darden School of Business of the University of Virginia. You can visit his blog, Life, Project Management, and Everything, by clicking the button below.

Check Also

7 Rules for Project Managers Devised from the Trenches

Being a project manager is not mindless busywork. In an article for Project Times, Davide …

Leave a Reply

Your email address will not be published. Required fields are marked *