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.
This paper presents the evolution of basic project and program definitions over the last ten years and then moves on to the implications and meanings of recent project and program definitions. Furthermore, the paper assesses the economic concept of value in relationship to benefits over resources.
Last, 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
According to A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 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?” One can question where the confusion comes from and how it impacts 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 forms of products and/or services, what is now widely accepted and understood by “project management” is the wider field of project management practice, which encompasses not only the management of “individual projects,” but also the areas of program, portfolio, and organizational project management that 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 the ongoing challenges of project-based organizations. The problem often lies in 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” become of utmost importance.
Context
In 2005, one issue of PM Network® (PMI, 2005) contained a 32-page section on new career challenges and career development for project managers that focused on “moving up” the career ladder. Since 2005, PMI has developed a Project Career Framework that also proposes 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 a background setting, it was also repeatedly observed throughout the 1990s 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 et al., 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 specifically, it is in the first edition of The Standard for Program Management in 2004 (PMI, 2004) and then in the second edition, where 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 the beholder” who, in terms of his or her final intention may choose to either share these with or keep them from the project manager.
Too often, project and 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 that refers 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 with other projects or integrated into business-as-usual activities. The unfortunate result being 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; in this case, project managers are not the victims but a part of the problem. Although this can be perceived as a negative criticism of 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 and portfolio managers and project management offices (PMOs) because 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 insure 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 in their specific interest; however, it is not acceptable for project managers to not master this, especially when they claim to be certified. However, with two contradictory types of rhetoric and frames of reference at work, poor understanding and use of project concepts and definitions at all levels, clear communication proves to be 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, such as 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 framework, 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 article in the February 2012 Project Management Journal® (Patanakul & Shenhar, 2012). In this paper, the authors define and create 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.” (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 the defense sector (from the Greek military term strategos), but also from the publication of von Neumann and Morgenstern's Theory of games and economic behavior in 1947 that strongly influenced both computer modeling and decision-making theories through statistics, information theory, and economics. Mintzberg is among the well-known management professionals who applied these concepts to business and defined a strategy as a direction, plan, guide, 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, context, or complexity of a task.
Needless to say, 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 forms 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 delivering 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 manager's 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 ten years, the literature on programs and projects 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 with 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 and discover their strategies 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 tends to publish the vision, mission, and goals (in order to get buy-in from stakeholders); however, most will not want to share their strategy because it is viewed 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 or her tricks with a rival, it is usual that higher levels of management apply the same reasoning. A great example of this thought process was 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 these elements of “unknown to the opponent” and “not easily recognizable,” that define a move as strategic rather than straightforward. As in any group, friends, family, 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 insure loyalty among those kept “in the loop.” Unfortunately, the history of project managers' employment as temporary resources works against them, not to mention that project managers tend to be territorial and do 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 opponent's 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, C., A short course in project management. Retrieved from http://office.microsoft.com). 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 and 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 mention 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 them “out of the loop,” not those with whom to share the overall organizational goals.
Programs and Benefits
The last ten years have witnessed many interesting changes in the project management discipline, namely the publication of Project Management Institute's first edition of The Standard for Program Management in 2005. Here, project managers are taken from the tactical level of product or service delivery to a benefits level, which 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 states 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 of the The Standard for Program Management, recently posted on the PMI website (http://ed.pmi.org/Pages/AncillaryDocuments/WelcomeLetter.aspx?DocumentId=18) seriously addresses some of these concerns under the heading 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 into 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 lives, 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, et al(2002). With these changes to the profession of project management, it is even more important that project managers know the well-defined scopes of projects that deliver products and services and how these differentiate 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 an article called “Bringing Project Management to the Boardroom” (The Seven Keys to Success, 2002). In his paper, Smillie advocates 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 outlines 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 into business-as-usual activities in order to deliver benefits. This, however, 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 the source of this confusion, among them (as outlined in this paper) are some 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 codependencies of projects; hence, the use of the expression: “Projects deliver benefits.”
- The Standard for Program Management, which defines benefits, is still new.
Perhaps these could be more directly addressed through our Professional Development Unit (PDU) system by offering specific courses to “update” Project Management Professionals (PMP®)s, depending on their initial certification date.
Another possible explanation for the problem persisting 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” grade promise rather than learning about project management and transferring the knowledge and skills to the work setting.
Understanding the correct 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. 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.
