In the eyes of the beholder

Abstract

This paper questions the fact that too many project managers argue that “projects deliver benefits” and seem to either not know or grasp the meaning of the basic definition of a project.

The paper gives an overview of the evolution of basic project and program definitions over the last 10 years, then moves on to the implications and meaning of recent project and program definitions. Furthermore, the paper assesses the economic concept of value in relationship to benefits over resources.

Lastly, project-level decision making is discussed within the general context of product, service, and result delivery. How does the project manager manage the project when the eventual benefits are not only beyond the scope of the project, but, may lie only in the “eyes of the beholder”?

Introduction

Although by definition a project is “a temporary endeavor undertaken to create a unique product, service or result” (PMI, 2008a, p. 5), many project managers still argue that projects “deliver benefits,” even if the term benefit does not appear in the PMBOK^® Guide's index, nor is it mentioned in the PMBOK^® Guide's Section 1.2 of Chapter 1, “What is a Project?” Where the confusion comes from and how does it impact project management practice?

The first area of confusion seems to stem from the different understanding of “what a project delivers” versus “what project management delivers.” Here it is important to say that although projects deliver unique results that take the form of products and/or services, what is now widely accepted and understood by “project management” is the wider field of project management practice, encompassing not only the management of “individual projects,” but also the areas of program, portfolio, and organizational project management, which together are expected to deliver benefits.

Literature and practice both point to the fact that “bridging the gap” between strategy and projects still accounts for most of project-based organizations' ongoing challenges. The problem often lies with people's ability to communicate, what they communicate, and how they do it. Hence, avoiding confusion in definitions and sharing a basic framework with a “common terminology” becomes of utmost importance.

Context

Already in 2005, the PM Network was devoting much of its content to new career challenges and career development for project managers, focusing on “moving up” the career ladder (Hildebrand, 2005; Kroll, 2005; Thiry, 2005; Whitten, 2005). Since 2005, PMI has developed a Project Career Framework that also proposed a path to higher management levels (http://www.pmi.org/CareerDevelopment/Pages/Individual-Career-Framework.aspx#ladder) (PMI 2012a). Concurrently, individual project managers and organizations have progressively explored new knowledge and practices such as strategic management, value management, portfolio management, value chain management and others, to evolve beyond the traditionally more restrictive roles and responsibilities initially defined, for example, by the PMBOK^® Guide (PMI, 2008a). With these changes as background, it was also repeatedly observed throughout the ‘90s that there was a definite lack of communication between the higher organizational strategic discourse of CEOs and the project-oriented tactical and technical discourse of project management (Hatch, 1997; Neal, 1995; Pellegrinelli & Bowman; 1994, Thomas, Delisle, Jugdev, & Buckle, 2000).

One would have hoped that with the progressive development of program management and other related fields between 2000 and 2010, the initial dichotomy between projects and upper management would progressively fade, and that this would considerably alleviate discrepancies in concepts and definitions that separate the two groups. More particularly, it is in the first edition of the Standard for Program Management (PMI, 2004), and then in the second edition, that one finds clear references to benefits: “A program is a group of related projects managed in a coordinated way to obtain benefits...” (PMI, 2008a, p. 5). However, as common practice shows, it is still commonplace to hear a group of project managers moaning about a boss, client, or sponsor not understanding “the benefits” their project will deliver. At the same time, project managers are frequently asked to deliver a product or service such as a building that will not bring any benefits if no roads are ever built leading to it, or being tasked to deliver an interesting new tool that can never be used without the necessary training.

As program management clearly outlines, even when on time and within budget, products, services, and results only deliver benefits when delivered in the appropriate context, which is usually not within the project manager's authority, not to mention that the definition of what constitutes a “benefit” may lie only “in the eyes of he beholder,” who may choose to either share his/her final intentions with, or keep them from, the project manager.

Too often project/program managers see themselves as victims of old mechanistic systems that make it difficult to obtain higher-level buy-in or support for projects. However, many project managers still struggle to communicate effectively, and having a poor understanding of a project's basic concept and definitions contributes dramatically to creating these communication gaps. In the specific area of referring to “benefits” as direct outputs of projects, most higher levels of management would see projects as an “expenditure” that might or might not yield eventual benefits once their results are either combined to other projects or integrated to business-as-usual activities. The unfortunate result is that higher-level management is left with the general impression that project managers perceive themselves as directly delivering benefits, rather than seeing themselves as spending the sponsor's money, and sometimes are left with the impression that project managers “just do not get the business side of things.”

There still remains an important “gap” between the corporate-level and the project-level concepts and their respective vocabularies, and in this case, project managers are not the victims but a part of the problem. Although this can be perceived as a negative criticism toward project managers, the positive aspect of being part of the problem is that this also gives us the power to change or fix it. The absence of a common framework and vocabulary further complicates the communication roles of program/portfolio and PMOs, as it is their role and responsibility to translate the corporate discourse to project managers and translate project management language to executives.

History shows that just as project managers might be using their own interpretations of project definitions, it has also been a long standing issue in projects that executives sometimes want to measure the return on investment and costs without recognizing the cumulative effects and co-dependencies of projects (Dinsmore, 1996; McElroy, 1996) in order to ensure that eventual benefits are consistent with and aligned to the indicators senior managers use to evaluate such offerings. One cannot help but excuse higher management for not grasping project concepts and vocabulary if this is not their specific interest; however, it is not acceptable for project managers not to master this particularly when they claim to be certified. But with two contradictory rhetorics and frames of references at work, poor understanding and use of project concepts and definitions at all levels, clear communication proves difficult or impossible to achieve.

Before the more recent development of program management, many authors had a tendency to attribute these differences between project managers and higher management levels to the fact that projects were so often set in more traditional organizational structures, hence explaining, in their view, that project-based activities seemed to display certain weaknesses, like the difficulty of linking projects to the organizational business processes and strategic-level goals (Gann & Salter, 2000; Lindqvist, 2004).

Projects and Value

Further confusion seems to come from the use of the word strategic. Traditional views confuse strategic goals with corporate or organizational goals. In such a frame, project processes have long been perceived as somewhat contradictory to strategic processes. Strategy exists at different levels, and more recent literature demonstrates the progressive use of the term strategy at the project level, such as in Patanakul and Shenhar's paper in the February 2012 Project Management Journal (Patanakul & Shenhar, 2012). In this paper, the authors defined and created a framework for project strategy based on Mintzberg's five P's model. They define project strategy as “the project perspective, position, and guidelines for what to do and how to do it, to achieve the highest competitive advantage and the best value from the project.” In keeping with previous strategy definitions, they describe the elements of project strategy as not fixed, and that “for many projects they may emerge and change as the project progresses” (Ibid, p. 7).

It is perhaps important to outline the fact that the term strategy, and hence strategic thinking as a whole, have come to us from a long legacy of not only defense (from the Greek military term strategos), but also from the publication of von Neumann and Morgenstern's games theory work in 1947, which strongly influenced both computer modeling and decision making theories through statistics, information theory, and economics. Mintzberg is among the well-known management authors who applied these concepts to business and defined a strategy as a direction, a plan, a guide, a course of action into the future, or a path to get from here to there (Mintzberg, 1994). Hence, a strategy can be devised in any context (simple or complex), as is often illustrated through a number of different games. A strategy is not restricted to the nature, the context, or the complexity of a task.

Needless to say that given the definition of the term strategy, project management processes could be seen as similar to a game tree model that “specifies a sequence of decisions...” and, together, these processes provide “a direction, a plan, a guide, a course of action into the future, or a path to get from here to there,” as defined by Mintzberg (1994). What then becomes important is the fact that one is using a strategy or strategic thinking in different areas or levels of management. It is, however, important to understand the difference between a strategy used by a child playing a game from the strategy used to organize the classroom and from the strategy at the school's administrative level. As is the case between projects, programs and higher levels of management, each level will be searching for the best sequence or path to get from here to there, with each level's present situation and future goal being quite different, but nothing prevents each level from approaching this either in a more rigid or emergent way.

It is time to simply recognize that project managers use strategic thinking to deliver specific results in the form of products or services and that these results may deliver benefits to the business at another level through the creation of synergies with other project deliverables. At the top of the pyramid, the goal is usually to increase value, and value is defined by the ratio of benefits over the resources invested to deliver these benefits. Therefore, the resources required to realize those benefits need to encompass those engaged not only within the project context, but those external to the project, such as program and business-as-usual resources, none of which are usually within the project managers' domain of knowledge, authority, or control. Given this situation, in most cases, it would be impossible for the project manager to even estimate the end value delivered to the business.

Projects and Strategy

Over the last 10 years, the program and project literature has been flooded with numerous means of tracking project results and the synergies they create at either the program level and/or once integrated to other business-as-usual activities, in order to link these to the eventual business benefits at higher levels of the organization. The bulk of research to this effect most clearly demonstrates that projects deliver “unique products and services” that reap benefits only once they are integrated with other project results or to business-as-usual activities. Hence, how does one justify or explain this inherent tendency of project managers to fail to appreciate the fact that they are tasked to deliver a specific result in the form of a product or service that “might or might not” deliver benefits when these potential benefits are not necessarily dependent on their project being on time or on schedule, but rather on the choices and decision making at higher levels of the organization? Higher-level decisions typically involve a number of “strategic decisions” made one or several levels above the project to reap those specific benefits and enable the organization to reach its own strategic goals, which are typically very different strategic goals from those of the project.

An important aspect of the concept of strategy is secrecy. As in simple games, the goal is not only to develop a strategy, but to keep it secret from our opponents and to try to discover theirs in order to gain competitive advantage over them by predicting their next move. In keeping with this basic thought process, at all levels of an organization, one will tend to publish the vision, mission, and goals (in order to get buy-in from stakeholders), however, most will not want to share their strategy, as it is seen as the essence of what gives them their competitive advantage. Just as a great project manager, who delivers faster, better, and on-time, might not want to share his tricks with a rival, it is usual that higher levels of management apply the same reasoning. A great example of this thought process can be found with Steve Jobs, who was always well known for his paranoid attitude in business and for expecting the highest level of secrecy from all levels of staff.

Without going to extreme examples, given that competitive advantage can only be maintained as long as the opponent cannot predict a number of moves, it is only reasonable to expect some level of secrecy when it comes to strategy. If anything, it is this element of “unknown to the opponent” and “not easily recognizable” that defines a move as strategic rather than straightforward. As in any group—friends, family, or organization—with secrecy comes the notion of trust, and the group needs to maintain either high levels of trust through a very solid psychological contract or have effective levers to ensure loyalty among those kept “in the loop.” Unfortunately, the history of project managers' employment as temporary resources plays against them, not to mention that project managers can tend to be territorial and to not easily accept that their project may be sacrificed for the greater good. Tomorrow they might be working for the competition. And in this context, it would be very unlikely that the organization profits by sharing higher-level strategy with the project manager.

If one is not aware of the higher-level strategy, it becomes very difficult to assess what constitutes a benefit that is defined as “something that is advantageous or good” (dictionary.com) given that advantageous and good are terms that might be considered such only through “the eyes of the beholder.”

To start, if one is unaware of the strategy, it would make it very difficult to understand at different points in time what constitutes a benefit, just as in a game, one cannot make sense of deliberately sacrificing a pawn (or even a bishop or rook) to position oneself better to corner the opponents' king or queen. To make sense of this, one must know the strategy of the player. For the observer of the moment, this could be seen as “bad” when for the experienced player, the same move might be perceived as “very good.”

Some less rigorous definitions of a project implicitly refer to the concept of benefits such as this one found on the Internet: “A project is a temporary endeavor with a defined beginning and end (usually time-constrained, and often constrained by funding or deliverables) undertaken to meet unique goals and objectives typically to bring about beneficial change or added value” (Chatfield, n.d.). In such a definition, even the notion of “beneficial change” is mitigated by adding the word typically, with some of the reasons most probably lying in the fact that these “benefits” might not be evidently linked in a direct cause-effect relationship (such as in the case of losing a pawn to the opponent), might be purposely hidden, or might be voluntarily masked by space and time to protect a higher-level strategic move.

In 2005, Thiry and Duggal asked: “Is there a project management glass ceiling? Is this glass ceiling preventing project managers from moving up the ladder?” (p.1). In this paper, the authors mentioned that project management has typically been viewed as a tactical, execution, and project delivery role, and that this prevents it (and project managers) from being an integrative link between strategic objectives and results. Among the interesting barriers to the rise of project managers in organizations, the authors mention: the supply barrier (lack of qualified capable project managers to take on management roles); the difference barrier (conscious and unconscious stereotyping, prejudice, and bias that project management is tactical); the organizational barrier (structures that prevent report and communications to strategic echelons); and the corporate climate barrier (culture that alienates and isolates project managers from management roles) (Thiry & Duggal, 2005). We are now in 2012 and I would add to the reasons previously mentioned by the authors that the temporary nature of projects (and project managers) has contributed to keeping project managers “out of the loop,” not those with whom to share the organizational secrets of the Gods.

Programs and Benefits

The last 10 years have brought many interesting changes in the project management discipline, namely the publication of PMI's first Standard for Program Management in 2004. Here, project managers are taken from the tactical level of product or service delivery to a benefits level, and this includes “elements of related work outside of the scope of the discrete projects in the program (e.g., managing the program itself)” (PMI, 2004, p. 5). PMI clearly stated that “the program manager coordinates efforts between projects but does not directly manage the individual projects” (p.7). In the comparative overview between project and program levels, at the project level success is measured by product and project quality, timeliness, budget compliance, and degree of customer satisfaction. At the program level success is measured by the degree to which the program satisfies the needs and benefits for which it was undertaken.

The exposure draft for the third edition The Standard for Program Management seriously addressed some of these concerns under Section 1.7 Role of a Program Manager (PMI, 2012b). This paragraph describes some organizations that refer to large projects as programs that include large individual projects or a large project broken to subprojects, and specifies that when the management of these efforts results in the delivery of benefits, then the effort becomes a program. The draft further clarifies that during their life, program components and projects produce individual products or services (outputs) while they collectively make up for program benefits (Section 4.4 Benefits Transition, p. 30). Furthermore, this document states that the Benefits Management Domain is central and unique to the successful conduct of programs (Chapter 4, p. 24).

Each year, our population of project managers migrating to a program orientation (and certification) grows and they are increasingly asked to link strategic decisions with business benefits and create value in organizations. Recent PMI statistics (Statistics of interest as of 31 January 2012, R.E.P. Update, Feb 2012, vol. 10, issue 2) showed a total of 728 already certified program managers. Project managers have been moving from the once temporary tactical role they were confined to and are increasingly understanding and helping executives and sponsors in tangible ways. Through program management, project management is no longer confined to the “product-centric” role of selling features and attributes when executives want to hear about “results and benefits,” as described by Thomas, Delisle, Jugdev, and Buckle (2002). With these changes to the profession of project management, it is even more important that project managers know the well-defined scope of projects that deliver products and services and how this differentiates them from program-level objectives that typically deliver benefits. There should be no confusion between the definition of a project and that of project management as a broader management field.

Through these changes, project management is progressively getting closer to Bill Smillie's predictions from 10 years ago, when he published “Bringing Project Management to the Boardroom” (2002). Smillie advocated that project management is “now the stuff of Boardroom Agendas” and that we were “not far from seeing a new role emerge in companies, that of Chief Project Officer (CPO).” Perhaps the CPO is the next level we will see added to PMI's career framework?

Conclusion

This paper has outlined the confusion in project and program managers' discourses concerning the unclear use of the words benefit and strategy to describe “what” and “how” they deliver.

The paper then outlined the fact that the PMBOK^® Guide is clear about project managers using processes (a strategy) to deliver results that take the form or products and services. The Standard for Program Management is equally clear about project results subsequently creating synergies with other project deliverables or being integrated to business-as-usual activities in order to deliver benefits. However, this is not reflected in many project managers' use of the vocabulary or concepts, even if these project managers are certified by PMI.

Several causes might be at the source of this confusion, among them (as outlined in the paper), some coming from project management's history:

• In the past, projects were often set in more traditional structures where executives wanted to measure the return on investment and costs without recognizing the cumulative effects and co-dependencies of projects, hence the use of the expression, “projects deliver benefits.”
• The Standard for Program Management, which defines benefits, is still young.

Perhaps these could be more directly addressed through our professional development units (PDUs) system by offering specific courses to “update” PMPs depending on their initial certification date?

Another possible explanation for the problem to persist is the fact that although both the CAPM^® and PMP^® handbooks specify a requirement for project management education, it has become more and more common for boot camps to focus on a 99% “passing the test” promise rather than learning about project management and transferring the knowledge and skills to the work setting.

The right understanding of definitions and key characteristics of projects is of significant importance for the discipline of project management to continue to develop at all levels of the organization, and with increasing numbers of project managers migrating to program management it is no longer acceptable for certified project managers to confuse project deliverables with benefits.

© 2012, Manon Deguire
Originally published as a part of 2012 PMI Global Congress Proceedings – Vancouver, Canada