What if project change management were a PMBOK® knowledge area?
Project Change Management (PCM) is a critical element in successful project implementations, but it lacks a consistent understanding and appreciation. This paper builds on a previous paper that described the basics of change itself and the application of those basics to Project Management (including the various elements of PCM plans). Specifically, this paper examines PCM from a process perspective, similar to other project management processes described in A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 3rd Edition. The paper describes an example PCM process using the standard project management process terminology of inputs, tools and techniques, and outputs.
Project Success and Failure
Is project success just the opposite of project failure? This seems intuitive. Further, anecdotal data suggests we tend to focus on the positive rather than the negative. The results of recent Internet searches (in Exhibit 1) showed that there were approximately 50% more entries for project successes than project failures.
Exhibit 1 – Internet Search Engine Results
Can a project be both a success and failure? Nelson (2005) discussed Information Technology (IT) projects that were initially deemed to be successes that, upon reevaluation, were considered to be failures. Bourne (2007) also discussed projects that went both directions – project successes that were later considered failures, and failed projects that were considered successes in retrospect.
This project success (or failure) question actually has two components – the criteria by which the project is judged to be a success or failure, and the causes that result in those criteria being met (or missed). This paper will initially focus on the first component – the success criteria.
Jugdev and Műller (2005) discussed the evolution of project success criteria since the 1960s. In particular, they noted: “Early mechanistic definitions of project management focused on the variables of time, cost, and scope…” (p. 20). Jugdev and Műller, along with Bourne (2007), used the term “iron triangle” to describe these three criteria. The PMBOK® Guide and other authors such as Ward (2000) refer to these as the “triple constraint”. Regardless, these three criteria typically represent the focus of many project managers.
A part of the attraction of these three criteria may be that they are generally measurable at the time the project comes to an end. Jugdev and Műller (2005) described this practice of assessing project success at the end of the project life cycle as “erroneous” (p. 22). This suggests that additional criteria, at some point beyond the end of the project life cycle, must also be incorporated into the overall assessment of success. Cooke-Davies (2002), as referenced by Jugdev and Műller, differentiated “project management success” from “project success”. Specifically, project management success is measured against the triple constraint, while project success is measured against the reasons for undertaking the project in the first place. However, this distinction may be too specific.
Various authors have expanded the project success criteria using various approaches. Bourne (2007) identified three “pillars of project success” (p. 3). The first of these pillars was labeled “Delivering Value”. The criteria in this pillar were cost, time, scope, and benefits realization. Bourne's other two project success pillars were “Managing Relationships” (viz., managing stakeholders) and “Managing Risk” (corporate governance and procurement).
Kendra and Taplin (2004) used a 2x2 model to categorize project success factors. The four cells that comprised the 2x2 model were labeled to reflect “the micro and macro levels of ‘social’ and ‘technical’ organization design elements” (p. 31). The triple constraint criteria are classified as micro-technical along with other variables such as business objectives and user satisfaction.
Nelson (2005) proposed two broad categories, with three criteria in each. The process-related category was composed of time, cost, and product (in essence, the triple constraint). The outcome-related category included use, learning, and value. Use implied the project results were being used. Learning reflected the organization's knowledge and preparation for future challenges. Value represented organizational improvements as measured by Net Present Value (NPV) and other related metrics. These outcome-related metrics represent, in a way, stakeholder satisfaction.
These three models have some commonality. Specifically, they each include the triple constraint plus some measure of value to the organization. Still, the primary use of the triple constraint as the measures of project success is alluring. Robertson and Williams (2006) noted: “Most frequently a project is considered a failure if it fails to meet its targeted cost, time, or scope” (p. 56). This suggests that favorable outcomes for these three criteria constitute project success. But Robertson and Williams added: “Commonly a fourth criterion is also included, the benefits accruing to the organization as a result of the project” (p. 56). This is consistent with Bourne's “Delivering Value” pillar of project success, Kendra and Taplin's “micro-technical” category, and Nelson's overall model.
However, there is a lingering question about whether the project manager (or project team) should be held accountable for benefits realization. This can be particularly problematic when (a) the assessment of benefits realization can't be accurately measured at the time the project is completed, and (b) the project management team is composed primarily of contract personnel who typically disband shortly after the project is completed.
Why Project Change Management (PCM) is Important
Clearly, overall project success involves more than achieving the targets of cost, schedule, and scope. The achievement of the benefits that were part of the original project justification is also a component of project success. Particularly for IT projects, the effectiveness of the end users impacts the benefits realization. Further, stakeholder management is a typical element of an overall project plan, and end users represent a major stakeholder constituency. Project plans typically include end user training (both development and delivery). However, there can be a disconnect between the beliefs of the project team and the end user community regarding what is needed to effectively facilitate the change from the status quo to the results of the completed project.
Nelson (2005) used the results of 72 IT project retrospective analyses to develop the model discussed above. As previously described, Nelson's model had two broad categories – process-related and outcome-related – each with three success criteria. Nelson also identified five stakeholder groups: project manager, project team members, users, sponsor, and top management. For 15 of the 72 retrospective analyses, Nelson asked these five stakeholder groups to assess the importance of the six success criteria (using a scale of 1 to 10). For each stakeholder group, the assessments were rank ordered. The results (shown in Exhibit 2) were interesting.
Exhibit 2 – Stakeholder Assessment of Importance
Stakeholders internal to the project team assessed process-related criteria as the most important. Conversely, stakeholders external to the project team assigned the top importance to outcome-related criteria. Without an effective Project Change Management Plan, the differences between these internal and external project team perspectives may lead to the user frustration, at best, and the inability to capture the project benefits, at worst.
The Nature of Change
It is important to understand what and how change occurs, in general, before addressing change management and then project change management.
Ways in Which Change is Viewed (Change Models)
Van de Ven and Poole (1995) proposed a taxonomy of four categories of change models. According to the life cycle approach, change is prescribed and deterministic. The evolution approach states that change is also prescribed, but is more of a probabilistic progression. Both of these categories seem adaptable to biological processes. The third change model category, teleology, assumes that change involves a movement toward a goal or end state. The fourth category is dialectical models. In this category, change (and stability) results from opposing forces. These latter two categories of change models appear more applicable to understanding change management from a project perspective. This taxonomy is useful in describing the initiators of change. Other authors discussed what happens once change is initiated.
Goodstein and Burke (1991) discussed several models of change. One attributed to Lewin described change as a three-phase effort. Specifically, the phases of change are unfreeze, change, and refreeze. Goodstein and Burke also discussed another change model, attributed to Beckhard and Harris, which described the three phases as present state, transition, and future state.
Kűbler-Ross (1969) formulated a five-phase model of change while working with terminally ill patients. According to Kűbler-Ross, change involves denial, anger, bargaining, depression, and (finally) acceptance.
Thus, there are multiple ways that the change process is viewed. It is unlikely that a project stakeholder makes a conscious choice of which change model to follow during a project implementation. Moreover, it is probable that each stakeholder views the changes in different ways. A part of the rationale why this occurs can be attributed to differing paradigms.
Effects of Paradigms
Paradigms function as filters that enable individuals to see, or not see, data. Kuhn (1996) described paradigms from the perspective of accepted scientific theories and models. Specifically, Kuhn suggested paradigms represent the consensus of the scientific community; i.e., a structure for classifying data about a particular subject. A paradigm's filtering mechanism can misclassify or even ignore relevant data. It tells an individual what's possible and what's not possible. This helps explain how scientists can sometimes ignore data that they consider “anomalous”.
Barker (1992) described paradigms from a business perspective: “A paradigm is a set of rules and regulations (written or unwritten) that does two things: (1) it establishes or defines boundaries; and (2) it tells you how to behave inside the boundaries in order to be successful” (p. 32). Thus, paradigms are the rules that enable each individual to interpret the world.
As words, “leadership” and “power” frequently invoke strong reactions from individuals, and those reactions are directly related to their paradigms. It's necessary to briefly discuss them here in order to reset paradigms (at least temporarily) regarding what power is and whether it's good or bad.
Leadership involves influence. There are many definitions for leadership. One approach is to view leadership as a process involving influence by the leader to get followers to pursue some course of action – to accomplish some objective. Cartwright (1959) noted that power is the influence exerted by some people over others. This includes the influence that a leader exerts over followers. As contributors to Cartwright's book, French and Raven (1959) described five different types of power:
- Reward…based on a follower's perception that the leader will provide rewards if expectations are met
- Coercive…based on a follower's perception that the leader can punish the follower if expectations are not met
- Legitimate…based on a follower's belief that the leader has a legitimate right to influence and that the follower has an obligation to accept that influence
- Referent…based on the follower's desire to have an identity with the leader
- Expert Power…based on the follower's perception that the leader has special knowledge…in relation to his own knowledge as well as against an absolute standard
Leaders are typically regarded as individuals who occupy the head of an organizational unit by virtue of election, appointment, or other mechanisms. This paradigm holds that only a few people in the organization are leaders, and therefore only a few people in the organization have power.
However, each individual in the organization can exert influence at times, based on his or her special knowledge or skills. Typical organizations have many individuals who have such expert power, but who do not have formally designated leadership positions. Most (if not all) individuals become somewhat resistant when faced with a loss of power. The loss of expert power can occur when something happens to make the expert's special knowledge or skills irrelevant.
Barker (1992) described this scenario as the “going-back-to-zero rule” (p. 140). This occurs when there is a paradigm shift (like the implementation of a new system). In this situation, everyone starts over with respect to their knowledge (and expert power). Individuals who have significant knowledge and experience in the old system potentially have a lot to lose, and therefore may be more resistant to the changes. Barker was succinct: “New paradigms put everyone practicing the old paradigm at great risk” (p. 69).
Implications for PCM
Project success depends on more than meeting the triple constraint of time, cost, and scope. Stakeholders must be enabled to capture the benefits that were included in the project justification. The focus of project team is primarily on the triple constraint, if Nelson's (2005) data can be extrapolated. At the same time, key stakeholders are typically focused on the impending changes that result from the project. For some stakeholders the changes may forebode the personal loss of expert power. This divergence of focus can lead to eventual frustration and potential conflict. An integrated approach within the project is needed to manage this change. PCM can help fill this void.
The previous section of this paper discussed paradigms. The Pygmalion Effect is a particular paradigm that is sometimes referred to as a self-fulfilling prophecy. This is well documented in educational settings. A teacher's expectations for a student (either to do well, or to not do well) impact how the student ultimately performs. The expectations a project leader communicates, both spoken and non-verbal, impact the way stakeholders ultimately react. If the project leader or project team believes PCM is not an important in the overall achievement of project success, stakeholders will recognize this. The result may be one of those failed success stories documented by Bourne (2007) and Nelson (2005).
Various Traditional Definitions
There are multiple perspectives on how change management is defined within a project context. A narrow view focuses on version control of programs and systems in an IT setting. Schiesser (2006) is typical of this view: “Change management is a process to control and coordinate all changes to an IT production environment” (p. 119). Others consider change management as the project scope control effort. Even the PMBOK® Guide portrays this narrow view of change management. There can also be confusion with personal and organizational change management from an organizational development perspective.
A Broad View of PCM
If change is the movement from a current state to a future state, then change management can be defined as the mechanism or process to facilitate that movement. In the context of a project, this becomes PCM. Craddock (2007) described PCM as “the leadership of the process to enable groups of individuals to move from a pre-project current state to a post-project new state” (p. 3). This definition has several components. The leadership and the movement from a current to new state have been discussed in previous sections of this paper. The process aspect will be explored in a later section.
The multiple perspectives regarding what constitutes change management or project change management contribute to the difficulties in communicating what is involved. As with many project activities, narrow definitions seem to make it easier to complete the tasks. This same narrow view can lead to considering the project complete when all of the project activities are deemed “checked off” as complete. However, it's easy to discount the “soft” aspects of project change management and focus on the verifiable aspects.
Typical PCM Plan Elements
In addition to the PCM plan itself, the minimum elements are the communications, training development, training delivery, and assessment of stakeholder readiness. There is value, from a stakeholder perspective, of including user community development as a PCM plan element. If needed from a project management perspective, additional elements can be included in the PCM plan. These are discussed in a later section.
Characteristics of Processes
Process Definitions and Components
There are many definitions of a process. Three are included here:
- Harrington (1991) stated that a process is “Any activity or group of activities that takes an input, adds value to it, and provides an output to an internal or external customer. Processes use an organization's resources to provide definitive results” (p 9).
- Hammer and Champy (1993) defined a business process as “a collection of activities that takes one or more kinds of input and creates an output that is of value to the customer” (p. 35).
- The PMBOK® Guide (2004) considered a process as “a set of interrelated actions and activities that are performed to achieve a pre-specified set of products, results, or services” (p. 38). In subsequent pages, the PMBOK® Guide introduced the notion of process inputs and outputs.
Each of these three definitions has three common elements. All of three of the references utilized the words “input” to imply something that flows into the process, and “output” for the results of the process. They differed in the terminology for what happens during the process. The first two definitions used the word “activities”. The PMBOK® Guide used the notion of people applying tools and techniques instead of using the word “activities”. It described a tool as “something tangible, such as a template or software program” (p. 378). The definition for technique included a “systematic procedure employed by a human resource to perform an activity” (p. 377). In this broad context, the overall description of a process in the PMBOK® Guide is similar to the two other definitions.
Thus, the three elements of a process are inputs, activities, and outputs – using the first two definitions. The PMBOK® Guide elements are inputs, tools and techniques, and outputs. This paper will utilize the tools and techniques terminology.
Thomas (1995) noted that: “all processes are subject to variation over time and no two outputs of any process will be exactly the same in all respects; variation is inevitable” (p. 45). If the three overall elements of processes are inputs, tools and techniques, and outputs, two of the three are likely sources of variation. Projects are unique endeavors, by definition. This means there will most likely be some differences in inputs from previous projects. Similarly, the tools and techniques may be updated based on the lessons learned from previous projects. These two broad sources of variations will have an impact on the variability of the output of processes, including the PCM process.
The fact that people are involved increases the likelihood of variability in the PCM process. Thomas also observed: “Of course individual performance is influenced by individual ability and motivation but these in turn are largely determined by the vagaries of chance interactions between the multitude of organizational factors that influence them” (p. 60). Among these organizational factors are the project leader's and project team's attitudes toward PCM. The Pygmalion Effect is indeed powerful.
Potential PCM Processes
Applicable Processes already in the PMBOK
The PMBOK® Guide has several chapters that discuss elements of PCM. Much of Chapter 10 (Project Communications Management) applies. In particular, three processes within Communications Management are directly applicable to PCM: communications planning, information distribution, and manage stakeholders.
Potential PCM Processes
There are six basic PCM processes:
- PCM Planning
- Training Development
- Training Delivery
- User Readiness Assessment
- User Community Development
Several additional processes may be considered as part of the overall PCM scope. These include:
- Go-Live Support
- Business Process Reengineering
It's generally recognized that project communications, both internal and external to the project team, are important for all stakeholders. These include both routine and ad hoc communications. Obviously, internal project team communications are impacted by the size and location(s) of the project team.
The expected end users of the project are a critical subset of the project's stakeholders. Although a few end users may be on the project team and therefore have access to current information about the project, most end users are dependent on the project team to provide periodic communications. These periodic communications help to shape the end users' paradigms about the project, and ultimately impact the degree of acceptance of the project results.
Training is a two-phase effort. The first phase involves the assessment, design, and development of any training required to enable the end users to use the project's result. Essentially all of the end users will need an overall orientation to the system or product. For some, this orientation will be sufficient. Many end users will need more specific training to enable them to use the system or product for their particular work responsibilities. The training development effort should result in both materials used in the direct training and reference material to be used by the end users after the project has been completed.
The second phase of training involves the delivery of the training to end users. In addition to the traditional instructor-led classroom approach, there are other options that allow scheduling flexibility. If the end users to be trained are geographically dispersed, a distance learning tool can allow a real-time, instructor-led class with students in their individual work locations. Further, these distance learning sessions can be recorded for later playback – either by the participants or by end users who were unable to attend the “live” session. This recorded session approach allows the end user students to absorb the task-specific training at their individual pace.
Ultimately the success of the implementation is a function of the end users' adoption of the project results. Projects sometimes use the term “Go-Live” to refer to the point in time at which the new system or product becomes operational. The process to make the Go Live decision, particularly for IT system implementations, can involve the assessment of a number of key factors. The readiness of the end users for using the new system should also be a Go-Live decision variable, even though it may be subjective.
User Community Development
At some point, users must become self-sufficient. The expert power of some individuals will be restored as they transition to the post-project environment. New experts may also emerge. The deliberate development of a user community can contribute to stakeholder satisfaction and the realization of project benefits.
There are several additional elements that could be included in the PCM plan, depending on the needs of the project and the Project Manager. These include the Support Plan for both the Go-Live event and the immediate timeframe following the Go-Live event. The latter is sometimes referred to as the “storm period”. If appropriate, the PCM plan could also include business process reengineering (BPR). At a minimum, BPR impacts the training effort. It's possible that the BPR may be a direct result of the new system.
Process Group (IPECC) Mapping
The PCM processes map to the Planning, Executing, and Monitoring and Controlling Process Groups. Specifically, the PCM Planning Process is included in the Planning Group. The Communications, Training Development, Training Delivery, and User Community Development Processes primarily overlap with the Executing Process Group. The Stakeholder Readiness Process maps to the Monitoring and Controlling Process Group.
Example PCM Process Description
Exhibit 3 shows the PCM Planning process in the traditional PMBOK® Guide process format:
Exhibit 3 – PCM Planning Overview: Inputs, Tools & Techniques, and Outputs
The PCM Planning inputs are primarily the traditional planning items: the project management plan, the project scope statement, and organizational process assets. The stakeholder information is not traditional, but is needed here to ensure the PCM planning focuses on the successful change of all stakeholders. Since planning is an iterative process, stakeholder information may be refined based on subsequent analyses.
Tools and Techniques
There are two primary tools and techniques used for the PCM Planning Process: the use of templates and the application of expert judgment. This is similar to many other processes in the PMBOK® Guide.
Not surprisingly, the outputs of the PCM Planning Process are plans and analyses. The primary output is the PCM Plan itself. The Training Development Plan and the Training Delivery Plan may be included in the PCM Plan or maintained as stand-alone documents linked to the PCM Plan. The Stakeholder Analysis later serves as input to both the Training Development and Training Delivery Plans.
The PMBOK® Guide defines knowledge as “understanding a process, practice, or technique, or how to use a tool” (p. 363). The ways in which this understanding is obtained include observation, education, and experience. All three of these can be incorporated in training stakeholders for the ongoing operations after the project is successfully completed.
Richie (2007) noted that there is not a universal definition of knowledge management. The definition ultimately adopted by Richie was: “the process of connecting people to people and people to information to create a competitive advantage” (p. 3). This definition seems more suited to ongoing operations than project change management.
There are other “knowledge” terms to consider such as knowledge sharing and knowledge transfer. King (2006) observed that although these two terms are sometimes used interchangeably, they are not the same. Specifically, King defined knowledge sharing as “the exchange of knowledge between and among individuals, and within and among teams, organizational units, and organizations”, and added that the “exchange may be focused or unfocused, but usually does not have a clear a priori objective” (p. 498). This seems somewhat haphazard and not suitable for a project environment.
In contrast, King defined knowledge transfer as “the focused, objective-seeking communication of knowledge between individuals, groups, or organizations such that the recipient of knowledge (a) has a cognitive understanding, (b) has the ability to apply the knowledge, or (c) applies the knowledge” (p. 498). This focused approach seems exactly what is needed for the project team to effectively enable the stakeholders with the knowledge necessary to continue ongoing operations after the project is completed.
As is sometime said, that is only half of the equation. The project team can initiate the knowledge transfer, but the stakeholders must receive and apply that knowledge. The latter involves adult learning theories.
Adult Learning Theory
Merriam and Caffarella (1999) discussed five different adult learning theories, but noted that the best known of these is the andragogy concept developed by Malcolm Knowles. Merriam and Caffarella quoted Knowles as differentiating andragogy (“the art and science of helping adults learn”) from pedagogy (“the art and science of helping children learn”) (p. 273).
Beich (2005) summarized the six overall assumptions inherent in andragogy. Specifically, adult learners:
- want to know why the subject is being taught,
- want to direct their own learning experiences,
- already have a lot of experience,
- react better to relevant material,
- focus their energy on things that will help them, and
- respond more to internal motivations.
There are several implications for stakeholder training. The overall context (the “why”) of the training should be established up front. The training should include an opportunity to practice the skills (or demonstrate the knowledge). If possible, the training should leverage the experience of the participants. (This is an opportunity to recognize the expert power of the participants.) All of this seems like common sense, but these concepts should be explicitly included in the training development and training delivery plans.
Why PCM Can't Be a “Cookie Cutter”
The approach to Project Management can't be a rote application of a previous methodology. Neither can Project Change Management. Every project is different. Obviously, lessons learned from previous projects can and should be applied to PCM efforts. As with any methodology, this check and adjust approach will strengthen the PCM processes.
Project success is a function of many variables. The achievement of project time, cost, and scope metrics are necessary for project success. However, they are not sufficient. Benefits realization and the satisfaction of at least some stakeholders are also necessary components of project success.
PCM offers a process-based methodology that will increase the likelihood of stakeholder satisfaction and ultimately benefits realization. But PCM goes beyond the Communications Knowledge Area processes in the PMBOK® Guide
Because it involves people-base processes, PCM has inherent variability. This is no different than other project management processes. However, the deliberate approach to PCM as one of these PM processes should lead to more project successes.
Barker, J. A. (1992). Future edge; Discovering the new paradigms of success. New York: William Morrow and Company, Inc.
Beich, E. (2005). Training for Dummies. Hoboken, NJ: Wiley Publishing, Inc.
Bourne, L. (2007, January). Avoiding the successful failure. PMI Global Congress 2007, Asia-Pacific, Hong Kong, China.
Cartwright, D. (Ed.). (1959). Studies in social power. Ann Arbor, MI: The Institute for Social Research, The University of Michigan.
Cooke-Davies, T. (2002). The “real” success factors in projects. International Journal of Project Management, 20(3), 185-190.
Craddock, W.T. (2007, January). A broad view of project change management. PMI Global Congress 2007, Asia-Pacific, Hong Kong, China.
French, J. R. P., Jr. & Raven, B. (1959). The bases for social power. In D. Cartwright (ed.), Studies in social power (pp. 150-167). Ann Arbor, MI: The Institute for Social Research, The University of Michigan.
Goodstein, L. D. & Burke, W. W. (1991). Creating successful organization change. Organizational Dynamics, 19(4), 4-17.
Hammer, M. & Champy, J. (1993). Reengineering the corporation; A manifesto for business revolution. New York: HarperBusiness.
Harrington, H.J. (1991). Business process improvement; The breakthrough strategy for total quality, productivity, and competitiveness. New York: McGraw-Hill
Jugdev, K. and Műller, R. (2005). A retrospective look at our evolving understanding of project success. Project Management Journal, 36(4), 19-31.
Kendra, K. and Taplin, L.J. (2004). Project success: A cultural framework. Project Management Journal, 35(1), 30-45.
King, W.R. (2006). Knowledge sharing. In D.G. Schwartz (Ed.), Encyclopedia of knowledge management (pp. 493-498). Hershey, PA: Idea Group Reference.
Kűbler-Ross, E. (1969). On death and dying. New York: The Macmillan Company.
Kuhn, T. S. (1996). The structure of scientific revolutions (3rd ed.). Chicago: The University of Chicago Press.
Merriam, S.B. & Caffarella, R.S. (1999). Learning in adulthood; A comprehensive guide (2nd ed.). San Francisco: Jossey-Bass Publishers.
Nelson, R.R. (2005). Project retrospectives: Evaluating project success, failure, and everything in between. MIS Quarterly Executive, 4(3), 361-372.
Richie, P. (2007, January). Project management knowledge management: Moving from standards to leadership. PMI Global Congress 2007, Asia-Pacific, Hong Kong, China.
Project Management Institute. (2004) A guide to the project management body of knowledge (PMBOK® Guide) (3rd ed.). Newtown Square, PA: Project Management Institute.
Robertson, S. and Williams, T. (2006). Understanding project failure: Using cognitive mapping in an insurance project. Project Management Journal, 37(4), 55-71.
Schiesser, R. (2006). Change management – Part I. In G. L. Richardson & C. W. Butler (Eds.), Readings in information technology project management (pp. 119-124). Boston: Thomson Course Technology.
Thomas, B. (1995). The human dimension of quality. London: McGraw-Hill.
Van de Ven, A. H. & Poole, M. S. (1995). Explaining development and change in organizations. Academy of Management Review, 20(3), 510-541.
Ward, J.L. (2000). Project management terms; A working glossary (2nd ed.). Arlington, VA: ESI International.
© 2007, William T. Craddock
Originally published as a part of 2007 PMI Global Congress Proceedings – Budapest