Preface

I believe this book to be like no other on the subject of feasibility studies. First, there is scant literature on the subject of project feasibility and even fewer writings on the concept of “points of vulnerability” (POVs). Yet, if I take a second to think about it, points of vulnerability permeate the evolution of mankind and of nature at large. Nature should have equipped man with a third eye, not on the forehead, but on the back of the skull—perhaps Caesar, given his dramatic death, would have been grateful for having been born with such an asset, although it is not clear whether Cleopatra would have found it attractive or not! A third eye would ensure that a man could see who is stalking him or at least guess who is closing in on him, perhaps with threatening behavior (e.g., Brutus). Or else, nature would have equipped man with a rabbit’s eyes or the owl’s capacity to make an exorcist-like twist with his head so that he could see all around and not be exposed to surprise attacks. Regardless of the prowess that man would be capable of, there would still be points of vulnerability: man would not run fast enough from danger (e.g., predators) or else he would not tolerate sunlight. Whatever form man would adopt, he would have points of vulnerability. This makes for predator–prey dynamics: predators (dominants), just like chess players bet on their opponent’s vulnerabilities and force these vulnerabilities to emerge. POVs are costly: in chess, when taken advantage of by the opponent, they lead to defeat.

Put in the context of U.S. politics, recall what Colin Powell said: “(…) we will try to take advantage of whatever weaknesses exist there and play to our strengths and not act against their strengths.”³ Put in project management terminology, there are strengths (forces, which guarantee dominance) and weaknesses (which can be allayed by way of contingency planning) in any project, and a fair amount of risks that are not too distant. We can view POVs as performance gaps: they are costly, use time, and monopolize team members when they should be concentrating on their normal tasks, including ensuring quality outputs. A recent report found that 74% of the 1662 executives surveyed considered that success was achieved in a transformation initiative when both strengths and performance gaps had been assessed.⁴ Certainly, identifying POVs implies some expenditures; but the costs of conforming to the highest standards (e.g., observations, studies, surveys, and training) must be weighed against the costs of nonconforming (dead inventories, lost opportunities, rework, scrap, warranty surcharge, to cite only those). Managing POVs means improved productivity, no less.

I will talk a lot in this book about Dominant and Contingency strategies. In short, a Dominant strategy (DS) is one that allows a project manager to complete all mandatory sets of tasks, to drive the organization to the level that has been predetermined, and to deliver the final product within the specific constraints of time, costs, and quality.⁵ An example of an attempt to reach a Dominant strategy drawn from U.S. politics is the tug of war between the president, Congress, the Supreme Court, and the House of Representatives.

A Contingency strategy (CS) is one whereby the project leader is getting prepared to face risks and vulnerabilities in the worst of scenarios. PMBOK 5 (p. 119) refers to “preventive actions (as) an intentional activity that ensures the future performance of the project work is aligned with the project management plan (…).” A Short strategy develops when the manager is caught by surprise and loses control; he feels that he is out-smarted by uncontrollable human behaviors or naturally occurring events. Short strategies have a good side; failing everything else (Dominant or Contingency strategies), at least the manager can fall back on them to cope with unusual, threatening events. In cost analyses related to project management, a Dominant position is equivalent to a normal cost structure, a Contingency position corresponds to Contingency reserves, and a Short strategy to management reserves.

You may also think of this as a football game. The Dominant strategy is composed of all the meticulously planned and executed step-by-step approaches toward the goal: scoring deep into the opponent’s part of the field. The Contingency strategy is put in place when the quarterback is under pressure to throw the football; failing that, he may actually get hurt by a hard hit from the rushing adversarial team and lose ground. The Short strategy is resorted to when the opponent has managed to catch your football and starts running, from your perspective, like a chicken (or a game perhaps) with its head cut off deep into your zone. Obviously, you’d rather have the chicken (or the game) on your plate than in your game! Throughout the game, team spirit is of the essence.

Dominant and Contingency strategies are what the project leaders are after, as they must assess, audit, and forecast numerous activities and tasks in order to bring a project to satisfactory completion.⁶

The literature on project management likes to delve into concepts such as mature organization and agile management. While it is fine to be agile (especially in the IT industry), to take only this example, from a POV angle, it is much more efficient to be robust. Being robust means being able to deal with points of vulnerability, whether this entails being agile at times or else standing firm in front of adversity.

A project leader I interviewed has explained vulnerability, as follows:

When my father started this company at the age of 50, he faced quite a high level of risk, which we now call the “1-1-1.” He had one client, a single product (algae) and only one market. He soon realized he had to diversify in order to mitigate the risks (and vulnerabilities) and in order to be less dependent. The fact that our initial product was a commodity made the small company vulnerable: it was subject to market forces, which decided on the price of the algae. We developed value-added products which entitled us to justify our prices, thus reducing our internal vulnerability.⁷

As the reader can judge, I have strong opinions about project management, and I’ll endeavor to prove them in this book with numerous research results and analyses. The reader may find that I challenge some of the preset ideas or myths—such as project managers being free of biases, or the economy at large being an open system—but I’ll try to provide support for my points of view.⁸

Secondly, while most books on projects, and project feasibility in particular, address the aspects of finance, technology (engineering), marketing, or human resource management, the present book adopts a very wide view of projects. I dig into modeling, mathematics, human behavioral sciences, neuropsychology, and many other fields. I see projects as multifaceted objects that must necessarily be examined with intense and diversified scrutiny. Thus, I will refer extensively to research of my own, including in neuropsychology, to substantiate some of my arguments.⁹

How the human brain functions has been just as important to understand as is the means by which human behavior forms or how a bridge linking two cities is built. I acknowledge that human behavior is at the heart of projects, and that it is a fine-tuned mechanic that can be examined with some kind of an engineering approach. It is very simple: a tiger that is hungry will hunt and kill; it is programmed to act this way. A newborn baby naturally looks for his/her mother’s milk. There are a large number of behaviors that can be predicted or at least partly anticipated because they obey a certain mechanical scheme, which is anchored in the brain (e.g., in the hypothalamus). Hence, from my perspective, preparing a project feasibility study includes understanding how teams work from a human perspective (not merely from a human resource management perspective), how decisions are made with inherent biases that can at times compromise a project, and how plans and processes are conceived in order to build, say, a brand new commercial center.

Feasibility studies are not new: in the late 1950s, Khrouchtchev’s son, Sergei, asked his chief commander in East Germany to do a feasibility study regarding the closing of the frontier between East and West Germany (the German wall was eventually put up on August 13, 1962, and lasted 40 years). Everybody knows about the consequences on people’s lives and international politics following the erection of the wall.

I invoke the fact that organizations nowadays are no longer open systems; rather, they are closed dynamic systems.¹⁰ First, they must protect their intellectual property¹¹; secondly, the world has now completed a full loop during which all geographical areas have been explored and are open for business—what happens in one country affects what happens in many more¹²; finally, the Internet has made the world instantly reachable, so that each market player can retaliate against the other in a matter of seconds,¹³ one way or the other, for example, by running a denigrating viral video. We will see how this concept influences the way managers do their jobs; in short, companies are no longer walking in an open field, they are belted by regulations, markets, and capacities. They are in the midst of a bounded project’s reality, better yet, of bounded projects’ realities. Nowadays, all business is a series of projects. Thus, this book extends beyond the scope of projects and may provide, I would hope, some useful tips on daily operations that can be regarded as a continuum of projects. In fact, the last case in Chapter 7—“BB’s highs and lows” —should convince the reader that the knowledge transferred in this book can be readily used to analyze business operations and projects after they have been completed. I do not pretend, however, to act as management guru; my sole objective in this regard is to provide advice that may or may not be deemed useful, hopefully without sounding pretentious.

To assist me in my various demonstrations, I resort to a fair number of real-case scenarios (some of which have been slightly modified to conceal the identity of the market players when this was demanded of me),¹⁴ both within the various chapters that this book contains and in the “case studies” at the end of each chapter.

Overall, humans have vulnerabilities inasmuch as machines and equipment have limits; both can fail, break, or not deliver as expected. As mentioned, I am fortunate enough to have had the chance to study a slew of groups participating in different projects during the last seven years, and to have been able to distribute questionnaires and conduct interviews that have allowed me to make general statements, and to develop a working model accordingly. Analyzing my database, I have been able to pinpoint some behavioral components that I believe are intrinsic to projects, and through interviews with project managers I have been able to substantiate my findings qualitatively. Statistics in project management are, indeed, a tool that can be used, including with respect to planning, estimating, and monitoring deviations.¹⁵

This book talks about important psychological phenomena, and especially about behaviors that steer projects in one way or another. The project is assumed to be well planned and to proceed smoothly toward success. However, some team members experience a certain level of apprehension; they may display, for example, some level of fear that the project will not be brought to term, think that their manager is not out there for their best interests, or hold the belief that some of their colleagues play obnoxious games behind their backs. For a project to be a change process, management has to prevent team members’ resistance; to put it differently, members must comply with the schedule of activities and calendar of tasks, do all that they can to limit the costs and losses, and adhere to the preset norms of quality. These managers juggle between external risks and internal vulnerabilities and try to maximize the utility of their actions and decisions. In particular, they must keep the project under control, which means that they have to have the proper management skills, especially in consideration of potential or real difficulties with some employees, who resist or perform poorly, voluntarily or not.

The work culture is based on trust. Team members also want to be treated fairly. When there is trust and a sense of fairness, there is no reason not to cooperate, and this in turn encourages commitment. A team spirit is formed; everyone assumes his/her role and respects the plan, much like members of a football team. As the project evolves, management and team members get more and more satisfied with their progress; yet, they must remain vigilant at all times to avoid slip-ups. Overall, team members must learn to work with each other and find a point of equilibrium where everyone can perform to the level that is expected of them. At times, however, overly ambitious and optimistic individuals get in the way, or else panic kicks in and a negative mood prevails because the project looks less and less likely to see the light of day. Occasionally, a manager or a team member even becomes hostile. Some team members seem to drag their feet, others find any possible excuse not to do their job. Does it sound familiar? Sure it does, we have all lived through this; chances are that we experience this every week during work, be it project driven or not.¹⁶

The last argument about the virtues of the present book is that it provides what I believe to be a unique view of project feasibility while attempting to contrast the viewpoints of various experts and sources of reference. In fact, my references delve into three languages in which I publish and teach: English, French, and Spanish.¹⁷ I believe that this widens the analytical perspective for the readers’ benefit. I resorted to a research method called “data percolation” by which information is retrieved from five independent sources: expert opinions, literature, simulation, qualitative, and quantitative studies. I feel that this approach brings in a rich and pragmatic view of the subject. Everyone has seen one of those classic movies in which a car moves forward while its wheels move backward due to a stroboscopic effect. We do not want to be tricked by the effects of the reality of projects. When it comes down to feasibility analysis, it is not the best-fitted project that matters, but the one with the best grip on its points of vulnerability.

Many projects fail for having been erroneously evaluated, if it were only based on misjudging team members and project managers interpersonal competencies. The Project Management Body of Knowledge¹⁸ (PMBOK), which is a standard book in the field of project management, does not deal in depth with the sometimes dreadful dynamics that bind stakeholders together. Field and academic experts point to the fact that divergent interests on the part of stakeholders are a major risk (for external stakeholders) and vulnerability (for internal stakeholders).¹⁹ Some authors have also noted that, too often, it is technical competence that prevails over the interpersonal kind.^20,21 Yet, vulnerabilities (created by humans), if mishandled, soon enough lead to crises (and potentially heavy losses), if not to chaos altogether. The goal of this book is to offer the reader—business owners, project managers, project promoters, and students at the master’s and doctoral levels—tools to identify POVs and ways to deal with them.

We cannot blame computers or machines for errors. We must instead turn to the human factor for the real answer. In the movie 2001 A Space Odyssey, the space shuttle computer makes an error that the crew notices; crew members decide to act on it with dire repercussions as the self-conscious computer realizes its useful life is about to end. That computer was programmed by humans. Humans make mistakes and shape POVs. This is true at large and truer in a context of time pressure and stress as is the case when having to complete a project on time.

The effort of capturing what can go wrong in any particular project is worthwhile, even though it can be painstakingly demanding (and may appear depressing … but it is actually fun!). Project management is big business. Global construction business alone has been valued at US$8.5 trillion as of 2015.²² Between 2012 and 2022, it is estimated that 78,200 new construction managers will be needed in the United States alone.²³ Still in 2015, U.S. residential and nonresidential construction will amount to a whopping US$612 billion. The value of U.S. residential projects grabs a portion of US$354 billion of that amount, growing steadily since the posttraumatic effects of the 2008 predatory mortgage crisis. Since 1947, the cumulative number of projects supported by the World Bank amounts to 12,372, which have been sprawled across over 173 countries.²⁴ In 2014, private investments in infrastructure projects totaled over US$50 billion worldwide. Montréal’s new Champlain Bridge is just one of several major infrastructure projects in the planning stages across Canada that could help boost the fortunes of the nation’s engineering and construction firms. In 2015, a consortium led by Canadian engineering giant SNC-Lavalin Group Inc. was awarded a contract worth approximately C$3 billion to build and manage this new bridge, a necessary piece of infrastructure that connects Montréal to its south shore and the roads accessing New York. Elsewhere in Canada, projects include the Eglinton Crosstown light rail transit in Toronto (approx. C$5 billion) and a hydroelectric generating station in British Columbia (approx. C$9 billion).

A project expert²⁵ whom I interviewed provided this example:

I recall this particular project whereby a new building was to be constructed across the street from an existing building, which had become too small to accommodate the ever growing staff. It was of prime importance to verify that the staff in either building could communicate efficiently between them as the core of the business was about IT services to the community.

Two of the four stories of the new building were to be rented, and two were to be occupied on September 1, 2009 by the staff. The plans were ready by August 30, 2008 and construction was to end by August 31, 2009. Moving from the old to the new building would have to be completed by September 30, 2009 in order to minimize the impact on the existing clientele.

Two project teams were formed. The first one looked after the physical layout of each office in the new building. It was headed by a 20-year project management veteran. The second team was responsible for the technological infrastructures.

By mid-August of 2009, 2 weeks prior to moving, everything looked in marching order when it was realized that, while all the equipment had just been installed and cabled inside the new building, there had not been a plan to connect the various pieces of IT equipment between the two buildings! This would affect the accounting department (and with it the pay to the employees) among other work teams. No one had noticed that there had not been a provision to dig the necessary channels underneath the building to install the IT cables. While there were still 2 weeks left prior to the project’s completion, correcting the situation would not be easy. Underground channels are subject to various laws and regulations set by governmental authorities, so that obtaining the necessary permits takes time; it also involves various outside suppliers on which the teams had no control, of course.

A short-term solution was adopted whereby a wireless system was installed. It is not until 2010 that the project was actually completed, with its proper IT cabling system finally in place. Said one engineer: “We dealt with this predicament temporarily, but still, how could well-trained experts manage to miss such an important element of the project, and for so long? This baffles me. The project surely was feasible; it wasn’t rocket science after all. Nevertheless, its design contained a big hole. Perhaps it wasn’t well defined in the first place.” So no project is perfect, I suppose.

There is money to be made … but there is money that may be lost, in Canada, in the United States, and anywhere else in the world. Assume conservatively that projects present a 50% chance of suffering from POVs and that each POV costs, say, 0.01% to the project. On a US$ 3 billion project, this represents what could be the salary of one middle- or top-level manager who would have been able to prevent these very POVs from sticking out like a sore thumb. I suppose that it is worth sifting through POVs before they become a problem, and I speculate that not 50% of projects but, in fact, 100% present POVs. I will discuss this further in the general introduction of this book.

In short, all of the aforementioned projects contain points of vulnerability. POVs are no mystery.²⁶ Despite the best efforts made at planning projects, soon enough, shortfalls appear (e.g., in administration, human resources, or technical procedures; in building team spirit; in the capacity for managers to influence and impose authority or credibility upon staff, clients, and the general public; in change procedures; in endeavors requiring coordination; in relationships between stakeholders; in getting support from parent organizations; and in progress/status reports), or else excesses develop (e.g., in bureaucracy, complexity, insecurity, and structuring).²⁷ Shortages and excesses plague projects as inputs are transformed into outputs, as management and team members (Forces of Production, FP)²⁸ work with Means of Production (MP) to produce results, that is, deliverables.

Despite the fact that everyone knows that a substantial portion of projects experience considerable difficulties and fall short on promises, it seems that the concept of project feasibility remains largely underdeveloped. Yet, feasibility studies serve a number of goals, including evaluating opportunities for employment creation, forecasting market trends and innovation, giving a new life to once obsolete resources, improving standards such as security standards, performing financial and economic assessments, supporting government strategic business or community development (including antirecession measures), upgrading infrastructures, and so forth.²⁹

POVs represent costs: they demand that meticulous planning be set in place and that monitoring be emphasized for the entire length of the project. When POVs develop and start affecting the project, they call for corrective actions. In the worst-case scenario, they negatively affect the calendar of activities, the costs, and/or the quality,³⁰ or a combination of these three core aspects of the project. Not taking into account POVs is tantamount to poor loss management. In fact, I propose that if PMBOK wanted to keep the current logic it uses for defining domains of knowledge, POVs should be added as one of them.

I do not pretend to compete with the PMBOK but merely wish to add to current knowledge. In fact, PMBOK 5 (p. 130) refers to such tools as Failure Mode and Effect Analysis (FMEA) and Fault Tree Analysis (FTA). However, I feel project feasibility analysts can be better equipped than they currently are. I do not contend either that what I present is the absolute truth—although it’d be great to hold such power!—or that I am inventing anything revolutionary. I humbly present some of my findings, hypotheses, and ideas and hope they can be useful.

My objective is somewhat demanding because I look at the dark side of things, with respect to Plans,³¹ Processes, People,³² and authority (Power). It’s like being a forensic expert for a “beast” that is human, machine, and process based all at once, and to constantly probe the bad side of things. Maybe, at times, it’s like playing detective Eliot Ness or the socio-psychiatrist Carl Jung. Fortunately, each project being unique, there is something new to discover around every corner.

I believe that developing tools and measurements that can enhance the evaluation of projects has its merits, and that this effort should include how humans interact strategically from conception to completion of a project.³³ Indeed, PMBOK³⁴ recognizes the importance of interpersonal competencies and offers a rough view on it.³⁵ As part of what it calls general knowledge in project management, it refers to interpersonal and managerial competencies, knowledge of the environment, norms, and rules.

In my opinion, a feasibility study must preclude the emergence of potential problems, refine its scope of analysis until all aspects of a project are deemed measurable, and help determine, in a credible way, whether a project should go ahead, be hunkered down, or else abandoned. In other words, the feasibility expert wants to identify ahead of time where the project might fail; that is, he/she wants to uncover its POVs, including those pertaining to team members and persons of authority (Power). A good feasibility study is also able to define a project succinctly; it uses proper modeling to unveil a project’s components and their interactions, and it establishes scales and measuring indices.

Because this book walks on a different path than most books on project management, it cannot be used to pass Project Management Institute (PMI) certification (e.g., Project Management Professional [PMP]). However, it is my hope that the knowledge I provide will be deemed, one day, an essential part of project management and perhaps of contemporary management.

I provide some cases that are based on real business events and companies. In some of them, I have modified names and locations to preserve confidentiality as requested by the companies and people I have met. I have included some elements from the PMBOK so that they can serve as exercises for the theory that is taught in this book. This includes the project charter, the domains of knowledge, and the groups of processes.

Finally, please note that I favor a nonacademic tone and the use of humor at times. I believe that a few words in jest as well as expressions such as “hungry tigers”, “lonely sheep”, the “I gotta go” people, and the “no” people, as well as “bad apples”, can serve as mnemonic devices for a subject that is, occasionally, a bit raw. In my opinion, active sentences and a writing style that offers a source of motivation to continue reading the book are important features of any text. So there you have it: a project is at times a bunch of hungry tigers and lonely sheep, including “maybe,” “no,” and “I gotta go,” people, and bad apples that must be managed to ensure success!