Digital Project Practice E-Book

Dr. Tobias Endress

• Herausgeber: tredition
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 295

Veröffentlichungsjahr: 2020

Beschreibung

This book provides hands-on insights and encourages readers to challenge existing methods and processes. The management of digital projects requires professional and state-of-the-art methods, tools, and techniques. In this book, the authors pass on practical approaches from their experiences in the field. The authors also critically acclaim existing methods and discuss their limitations. In particular, the book covers the following topics: - Methods and Best Practices; - Tools and Techniques; - Soft Skills, Team Dynamics, and Human Resources. Thirteen international subject matter experts contributed to this book. The objective is two-fold. First, the authors aim to further the discussion on business practices and methods. Second, the authors aim to stimulate the professional community. Senior professionals can benchmark their activities, while junior professionals can apply proven methods from this book.

Leseprobe

Dr. Tobias Endress (Editor)

Digital Project Practice

Managing Innovation and Change

© 2020 Dr. Tobias Endress

Cover Design: D. B. M. Bandaranayaka

Illustrations: Olena Shkavron (cover image and figures 2, 7, 12, 14, 18, 19, 21, 23, 28), Danushka Sandaruwan (figures 5, 8, 9, 15, 17, 20)

Editing: Dr. Tobias Endress

Translation: Dr. Tobias Endress (chapter: Implementing Change)

Proofreader: Dr. Jessy Brown, Chukwuemeka Princewill

Other Contributors: Aditya Chandak, Dr. Majid Dadgar, Ralf Dick, Elena Dinman, Günter Jeschke, Dr. Stephan Meyer, Dr. Marc Nathmann, Dr. Anton Pussep, Girish Ramachandra, Beatriz Alzate Richter, Dr. Bernd Thommes, Patric Zeier

Publisher (Verlag + Druck): tredition GmbH, Halenreie 40-44, 22359 Hamburg, Germany

ISBN

Hardcover

978-3-347-09723-0

Paperback

978-3-347-09722-3

e-Book

978-3-347-09724-7

The publication, including its parts, is protected by copyright. Any use is prohibited without the consent of the publisher and the author. This applies in particular to electronic or other reproduction, translation, distribution, and making it publicly available.

Table of Contents

Preface

Methods and Best Practice

Why Projects Fail

Manage the Perception of Project Success

DIY Agile: How to Re-think Your Own Method

Scaling Agile

Tools and Techniques

Stakeholder Management in an Enterprise

Knowledge Creation by Practitioners and Designers

Ideas and Requirements for Digital Innovations

Legal Advice on Innovative Technologies and Business Models

Time-Management

Culture, Soft Skills and Human Resources

Team and Project Management Values

Talent Challenges in the Age of Digitalisation and Globalisation

Implementing Change

Managing Massive Moments of Change

Appendix

List of Figures

Index

Final remarks from the editor

Preface

Dear Reader,

The management of digital projects is an activity that requires a high level of professionalism and knowledge of appropriate tools and techniques. Decision-makers and practitioners should be well educated and always informed about new business ideas and have the latest methods in their ‘bag of tricks.’ Still, you might think that there are already many books and courses that aim to address this need. Why read another book in this domain?

We started this book project because we felt that many books about digital innovation and project management are either very theory-heavy, outdated, or just want to sell a particular method. We wanted to prepare a book that introduces the methods, but also covers the practical aspect, critically acclaims existing approaches and practices, and shows the limitations. I.e., the book touches appropriate methods as well as human/social aspects. Actually, the human aspect is one of the running themes in this book. It also addresses issues that may not be covered by ‘classical or agile project management literature’. You can regard it as a contribution to the ongoing discussion on business practices and methods. It also aims to nourish and stimulate dialogue in the professional community.

I’m also very delighted to present to you a very international book. We have co-authors from almost all over the world, and many of them have gained experience in international environments and with heterogeneous teams distributed all around the globe.

In short, this book is about practice, experience, and opinions from experts in the field. I hope you enjoy reading it and that it can help you to reflect on the current practice in your organisation.

With best regards,

Dr. Tobias Endress

Rikitea, 30th June 2020

Methods and Best Practice

Why Projects Fail

How to decide whether a project is a failure

Dr. Stephan Meyer

StephanMeyer.com

Abstract

This chapter takes a closer look at change projects and discusses whether the rumours are true that so many of them are complete failures. In a nutshell, whether a change initiative is considered a ‘success,’ or a ‘failure,’ is mostly dependent on classical project baselines, but also the observer’s perspective and the observer’s expectation. However, these differentiations are often ignored when making blunt statements about change projects.

Beware of Numbers often Quoted but Badly Documented

Recently I discussed with a professor who told me that from her point of view, change projects are almost futile since it is a wellknown fact that 70% of all change projects fail. Is that so? I decided to play detective to find out where that mysterious percentage originated from. I did some research on the scientific papers she referred to, and this is what I found out.

The literature is full of blunt statements about a supposed high failure rate of change initiatives, often without much evidence to back up these statements. Someone makes up an arbitrary percentage of change failures, someone else refers to it, and suddenly the rumour of a supposed high failure rate leads a life of its own. For example, Beer and Nohria claimed “the brutal fact is that about 70% of all change initiatives fail”,1 without referring to any evidence. How the authors came up with that number remains mysterious. Other authors2 then presented this 70% failure rate as a number etched in stone and backed up their claims with reference to Beer and Nohria3. Another author4 referred to a second group of authors5, who made a reference to both Beer and Nohria6 and to a third group of authors7 who once again referred to Beer and Nohria8. In other words, while there is hardly any doubt that some projects do fail, in this case, the oftquoted statement that almost all projects fail seems to be rather based on rumours than on facts.

How to Judge Project “Success” and “Failure”

A project can be understood as a temporary initiative to establish a change in an organisation. The most fundamental question about the outcome of a change initiative is whether it is a ‘success’ or a ‘failure.’ While at first sight, this may seem to be an easy question to answer; upon closer inspection, it is just as complex as questions such as “what is radical change” or “how should change be managed.” Categorising a change initiative as either a ‘success’ or ‘failure’ depends on a set of parameters, of which the most relevant seem to be:

• Classical project baselines

• Perspective

• Expectation

Here is a suggestion on how these project parameters can be used to judge the success of a project.

Project

Figure 1: Key Factors for Project Success

The classical project baselines as they are represented in the PMBOK Guide consist of scope, time, and cost.9 ‘Scope’ refers to the question of what kind of change initiative is being evaluated. As there is a broad range of possible ‘changes,’ it may be challenging to put all of them in one basket: Small versus big ones, short-term versus long-term ones, changes performed half-heartedly by overworked line managers versus changes performed fulltime by experienced change agents, and so forth. ‘Time’ refers to the question of which time is evaluated when deciding about success or failure. In other words, this is a question of sustainability. ‘Cost’ refers to the amount of money spent and generally follows the rule, the less, the better.

‘Perspective’ refers to the question of who is to evaluate the change’s success, as different observers may come to differing conclusions. For example, the financial stakeholders of an organisation may apply entirely different success criteria from those applied by the organisation’s employees. ‘Expectation’ refers to the question of what the person judging about the change expects to achieve from it. A financial stakeholder may be happy because his expectation is fulfilled when a change initiative saved his investee organisation from bankruptcy. At the same time, a relocated employee may not find his expectation fulfilled because his local plant had to be closed down to enable the organisation’s survival. From his perspective, the change initiative may not be considered a success.

Figure 2: Judgement Depends on a Persons Perspective and Expectation

Different Perspectives cause Conflicting Success Criteria

Here is an anecdotal example of a different perspective and, thus, different expectations about a successful project. I had my own experiences with internal line managers with short-term contracts. I would like to compare for a moment the perspective of such a line manager to the perspective of the owner of a family business.

The line manager: I once had a consulting mandate at a client who hired their top management externally and gave each manager a short-term contract with a duration of two years each. In other words, every two years, the financial stakeholders decided whether the contract should be extended or not. If the stakeholders were satisfied, the contract could be extended almost indefinitely until the manager’s retirement, at least in theory. However, this procedure meant that 18 months into the contract, the negotiation between the stakeholders and the manager would start about whether the contract should be extended. The consequence of this was that every manager was geared toward short-term wins that could be presented during the negotiations. Those short-term wins were often detrimental to the organisation’s long-term success or even its long-term survival. The manager calculated that he would not be part of the organisation on a long term anyway. Such a line manager with a short-term contract had a completely different perspective from the owner of a family business.

The owner of a family business: The owner of a family business may think even in periods of several generations. He may plan, for example, to lead the company for another ten years, give or take a few. After that, the company will either be sold or be transferred to a member of the next generation in the owner’s family. In either case, the company owner will do everything to ensure that the company’s value will be as high as possible ten years from now. In contrast to the line manager with a short-term contract, the company owner will not sacrifice the company’s future for a quick win in the next 18 months.

The success of a change initiative may be judged entirely differently, depending on whether you look at it from a short-term or long-term perspective. The question of the time scale chosen is related to the concept of an organisational life-co-founder-optimal. Generally speaking, categorising a change initiative as either ‘success’ or ‘failure’ is rather preposterous without considering all of the parameters mentioned above.

Figure 3: Perspectives of Line Manager and Business Owner

Example for specific expectations: The financial stakeholder

Generally speaking, how the outcome of change is evaluated is a stakeholder perspective issue. While the average employee may have a somewhat subjective expectation about the outcome of organisational change, such as an improvement of the organisational culture, the financial stakeholder will always focus on the hard facts concerning the profitability of the organisation. He is the one to initiate the change project and thus has high expectations about the improvement of profitability. More specifically, Crone et al. suggest the following kinds of key performance indicators (KPIs) for organisational change: KPIs for rentability analysis, KPIs for working capital analysis, KPIs for liquidity analysis, KPIs for financial analysis, KPIs for crisis investors.10 Here are a few examples of these KPIs:

• KPIs for rentability analysis, e.g., return on equity, return on assets, return on capital employed

• KPIs for working capital analysis, e.g., working capital, networking capital efficiency, duration of liabilities, duration of assets

• KPIs for liquidity analysis, e.g., liquidity 1st grade to 3rd grade, cashflow I to III

• KPIs for financial analysis, e.g., equity ratio, borrowing ratio, gearing ratio

• KPIs for crisis investors, e.g., EBITDA, total net leverage, interest coverage, revenue growth

It hopefully becomes obvious that these criteria for a successful project, and thus, the expectations about the project outcome are not equally shared by everyone involved. This is why you always have to consider that different stakeholders may have different expectations.

Figure 4: Different Expectations of Project Stakeholders

Causes of Project Failure

So, after having considered the three project parameters baselines, perspective, and expectation, what are now the causes of possible project failure? Explanations for a potential failed change initiative in the scientific literature are varied, with a broad range of causes mentioned and astonishingly little overlap between them. The most consensus can be found about the following cause of project failure: The quality of leadership and thus the choice of appropriate change agents is considered essential by several authors.11

Apart from that, many authors come up with additional ideas of why projects fail. Here are a few sources and the cause they claim to be the culprit. Raelin and Cataldo attribute failure of change to a lack of empowerment of middle management.12 Grady and Grady attribute it to a loss of stability caused by an organisational change initiative.13 Acord attributes it to procrastination.14 Another explanation is a lack of alignment between the value system of the change intervention and of those members of an organisation changing.15 Also, an inappropriate organisational reward system may be the cause.16 A high level of complexity may make planning change initiatives almost impossible.17 Lack of clarity of need, clarity of problem, and clarity of outcome may lead to failure.18 According to Sisco, the two general reasons that cause IT projects to fail are poor definition of project scope and ineffective communication.19 It is important to consider that the previously identified causes of change failure are always dependent on the definition of what change failure really is. This also applies to the following ‘top of the pops list’. Please note that the quality of leadership mentioned above shows through in several of these items. Antony & Gupta present the “top ten reasons for process improvement project failures.”20 They are

1. Lack of commitment and support from top management

2. Poor communication practices

3. Incompetent team

4. Inadequate training and learning

5. Faulty selection of process improvement methodology and its associated tools/techniques

6. Inappropriate rewards and recognition system/culture

7. Scope creepiness

8. co-founderoptimal team size and composition

9. Inconsistent monitoring and control (lack of expert supervision)

10. Resistance to change (partial cooperation by employees).

How to Minimise the Probability of Failure

The previous annotations may convey the impression that the success of a project lies in the eye of the beholder, and rightfully so. Here are some brief suggestions on how to appropriately handle this challenge: In the early stage of the project, when the project charter is written, try to understand better the customer who initiated the project by researching his perspective and expectations. At a later stage, when the stakeholder analysis is written, list the different stakeholders, as well as their perspectives and possible expectations. Also, if the authors of the project management literature are right, try to raise the quality of leadership by carefully choosing the most appropriate change agents for your project.

Lastly, the Cynic’s Perspective

While the information listed above may be a little too matter-offact for some readers, I would like to end this chapter with a tidbit for the cynics among us. On a more humorous note, the former West German chancellor Helmut Schmidt once explained failing projects by quoting an anonymous satirist who characterised the development of project stages in the following six steps:

a) Enthusiasm,

b) Doubt, c) Panic,

d) Search for the guilty party,

e) Punishment for the innocent and

f) Rewarding those who are not involved.21

Summary

It seems wise to be sceptical about general statements of the kind: “as everyone knows, X% of all change projects fail.” As my previous elaboration hopefully shows, there is often little substance to these claims. And even if there is any, the question of whether a change initiative is successful depends at least on parameters such as the classical project baselines, plus perspective and expectation. The perspective is always relevant to the expectation. It is advised to better understand the customer who initiated the project by researching his perspective in the project charter. Also, the stakeholder analysis should contain information about the stakeholders’ perspectives and possible expectations.

Among the projects that do fail, the scientific literature lists a broad range of possible causes. The most agreement among the authors can be found in the statement that failed projects are due to the quality of leadership and thus to the choice of appropriate change agents.

References

Acord, Terry. “Why Do Projects Fail?” FDM 71 (9). 1999. 20–23. https://doi.org/10.4324/9781351134156-7.

Antony, Jiju, and Sandeep Gupta. “Top Ten Reasons for Process Improvement Project Failures.” International Journal of Lean Six Sigma 10 (1), 2019, 367–74. https://doi.org/10.1108/IJLSS-11-2017-0130.

Avots, Ivars. “Why Does Project Management Fail?” California Management Review 12 (1), 1969, 77–82. https://doi.org/10.2307/41164208.

Balogun, Julia, Veronica Hope Hailey, and Stefanie Gustafson. Exploring Strategic Change. 4th ed. Harlow, England: Pearson, 2016.

Beer, Michael, and Nitin Nohria. “Cracking the Code of Change.” Harvard Business Review, no. May-June 2000: 11. https://doi.org/10.1163/156854074X00730.

Brown, Derek Robert, Dennis Rose, and Ray Gordon. “De-Commoditizing Change Management: A Call for the Re-Positioning of Change Management on IT Projects.” Journal of Organizational Change Management 29 (5), 2016, 793–803. https://doi.org/10.1108/JOCM-07-2015-0116.

Burnes, Bernard, and Philip Jackson. “Success and Failure in Organizational Change: An Exploration of the Role of Values.” Journal of Change Management 11 (2), 2011, 133–62. https://doi.org/10.1080/14697017.2010.524655.

Crone, Andreas, Henning Werner, Paul Abel, Arnd Allert, Frank Bisson, André Große Vorholt, Christof Hettich, et al. Modernes Sanierungsmanagement (Insolvenzverfahren, Haftungsrisiken, Arbeitsrecht, Sanierungskonzept Und Steuerliche Aspekte) [Modern reorganization management (insolvency proceedings, liability risks, labor law, reorganization concept and tax aspects)]. Vahlen, 2012.

Gal, Yoav, and Efrat Hadas. “Why Projects Fail: Knowledge Worker and the Reward Effect.” Journal of the Knowledge Economy 6 (4), 2015, 968–77. https://doi.org/10.1007/s13132-013-0168-1.

Grady, Victoria M., and James D. Grady. “The Relationship of Bowlby’s Attachment Theory to the Persistent Failure of Organizational Change Initiatives.” Journal of Change Management 13 (2), 2013, 206–22. https://doi.org/10.1080/14697017.2012.728534.

Matta, Nadim F., and Ron Ashkenas. “Why Good Projects Fail Anyway.” Harvard Business Review, September 2003, 1–12.

Moyce, Cliff. “Why Do Projects Fail?” Management Services 58 (2), 2014, 40–41.

Nag, Rajiv, Kevin G Corley, and Dennis A Giola. “The Intersection of an Organisational Identity, Knowledge and Practice: Attempting Strategic Change via Knowledge Grafting.” Academy of Management Journal 50 (4), 2007, 821–47.

New Zealand Institute of Management. “NZIM: When IT Projects Fail Blame Management. Major Information Technology Projects Frequently Fail to Fly. But Why? Some New Research Says Management, Not the Technology, Is the Root Cause of the Problem.” New Zealand Management, March 2003, 18–19.

Project Management Institute (PMI). Pmbok Guide: A Guide to the Project Management Body of Knowledge. 6th ed. Newtown Square, Pennsylvania: Project Management Institute (PMI), 2017. https://doi.org/10.1002/pmj.20125.

Raelin, Jonathan D., and Christina G. Cataldo. “Whither Middle Management? Empowering Interface and the Failure of Organizational Change.” Journal of Change Management 11 (4), 2011, 481–507. https://doi.org/10.1080/14697017.2011.630509.

Schiff, Anshel. “Ready or Not…” Journal of Change Management 7 (1), 2007, 3–11. https://doi.org/10.1109/MPE.2010.939949.Schmidt, Helmut. “Why Some Projects Fail.” Journal of Accountancy 155 (3), 1983, 32.

Sisco, Mike. “Why Are My Projects Failing?” CIO; Framingham, Jun. 26 2019, 1–4.

Todnem By, Rune. “Organisational Change Management: A Critical Review.” Journal of Change Management 5 (4), 2005. 369–80. https://doi.org/10.1080/14697010500359250.

About the Author

Dr. Stephan Meyer is an expert in radical organisational change. He works as a freelance management consultant and interim manager, orchestrating successful change initiatives in the field of digital transformation. Dr. Stephan Meyer has more than 25 years of experience in managing projects with up to 300 members. His former roles include CEO, Member of the Board, Project Leader, Program Manager, Mentor, and Coach. He is a former employee of Accenture and the cofounder of a Private Equity company. His education includes a Diplom in Business Psychology (Diplom-Psychologe) at the RWTH Aachen University (Germany). In 2019, he received a PhD at the University of Gloucestershire (UK) in Business Administration with a dissertation about radical change by killing sacred cows in organisations.

1 Beer and Nohria, Cracking the Code of Change, p. 2.

2 Burnes and Jackson, Success and Failure in Organizational Change.

3 Beer and Nohria, Cracking the Code of Change.

4 Todnem By, Organisational Change Management.

5 Balogun et al., Exploring Strategic Change.

6 Beer and Nohria, Cracking the Code of Change.

7 Nag, et al., Intersection of Organizational Identity, Knowledge and Practice.

8 Beer and Nohria, Cracking the Code of Change.

9 Project Management Institute, Pmbok Guide, p. 105.

10 Crone et al., Modern reorganization management.

11 E.g. Avots; Brown, Rose, & Gordon; New Zealand Institute of Management.

12 Raelin and Cataldo, Whither Middle Management?

13 Grady and Grady, The Relationship of Bowlby’s Attachment Theory to the Persistent Failure of Organizational Change Initiatives.

14 Acord, Why Do Projects Fail?

15 Burnes and Jackson, Success and Failure in Organizational Change.

16 Gal and Hadas, Why Projects Fail.

17 Matta and Ashkenas, Why Good Projects Fail Anyway.

18 Moyce, Why Do Projects Fail?

19 Sisco, Why Are My Projects Failing?

20 Antony and Gupta, Top Ten Reasons for Process Improvement Project Failures.

21 Schmidt, Why Some Projects Fail.

Manage the Perception of Project Success

Dr. Anton Pussep

Project Manager

Abstract

Executives and project managers will generally be interested in seeing their projects being a success. However, a project is rarely either a perfect success story or failure. There is often room for interpretation, resulting in the risk of your project being deemed as less successful or even failure when it is not. This also poses a threat to organisations that want to pursue and learn from the successful projects in their portfolios.

In order to avoid an improper perception of your project’s success, you must be aware of the uncertainty regarding project success and manage it. Uncertainty arises and can be managed along multiple dimensions: baselines, processes, and benefits. This chapter introduces the dimensions, the sources of uncertainty, and a mental framework with techniques on how to manage the perception of your project’s success.

Introduction

As an executive, you might be familiar with the following situation. There is a project that needs to be done for the sake of your firm’s future. Let’s say it’s the introduction of an IT system to replace a legacy system. You appoint a highly qualified and wellpaid project manager. You provide a considerable budget to carry out the project. It even delivers the agreed scope fully. All acceptance criteria are met. At this point, you think this project can be declared a success, closed, and allow you to focus more on your day-to-day business or other projects.

However, something seems off. Your CEO says the project result did not contribute anything to help the company maintain its market share in the current economic downturn. The users complain that the new system is just as labour-intensive as the old one. The CFO points out the considerable cost-increase by 40%. A fellow executive claims that the project manager did not even create a stakeholder management plan.

Whereas the first paragraph seemed to indicate a perfect success story, the second paragraph might make you conclude that the project was, in fact, a failure for the following reasons:

1. The market share is falling.

2. The new system is more labour-intensive than expected.

3. The project exceeded its cost baseline by 40%.

4. A project document has not been created.

But considering the following additional argument, improving the market share was not an objective of the project. It was even documented as not being an objective. Lowering the workload with the new system was an objective. But the reason why it is as labour-intensive as the old system is because more features are being used. The project was more expensive than expected, but that is just because the original estimate was done before a detailed plan was available. The approval of the cost increase followed the standard procedure for change requests. Finally, not a single project in your firm ever had a stakeholder management plan. All major stakeholders have been included in the project, though, and they have been managed according to the few standards set by your firm.

With this argument, you might reconsider your previous judgement. It now seems that the project was, in fact, a success. Nevertheless, the discussion could go on and on as ever more details are discussed that might shift the perspective. The range can be quite considerable; the judgement thus far could be anywhere from severe failure to a solid success story.

Moreover, the more details come to light, the more you will find that the decision is not easy to make. Take the issue of the cost increase, for example. A cost-increase by 40% sounds terrible. But what if the original estimate was just a first best guess? Was the estimate just very rough but reflected all the information available at the time? Or was the person responsible for the estimate just too inexperienced or not diligent enough to get more relevant information? Or did the project fail to control its costs, which led to unnecessary expenses? This alone could be an endless discussion.

Before we explore strategies to avoid such confusion and endless discussions, it is helpful to understand the sources of uncertainty better when judging project success. For that, we first explore the multi-dimensional nature of project success. These are dimensions at which project success can be measured, perceived, and managed. A major difficulty is that a project can be successful in some dimensions while failing at others. This and other sources of uncertainty in judging project success will be discussed after the introduction of the dimensions. Finally, we will discuss how to deal with the given uncertainty and even use it to our advantage.

Three Dimensions of Project Success

The previous section highlighted exemplary criteria by which the fictional project was evaluated. If the project had been successful in all criteria, it would be easy to declare the project a success. But what if the project succeeded in some but not in other? For instance, would you regard the project a success if the cost objective was achieved but proper documentation missing? There is no definite answer that would fit all projects. That is because depending on the context of the project, the importance of each criterion may vary. Some criteria might be even irrelevant to a specific type of project. For instance, small projects are likely to require much less documentation and project management processes than large projects. However, it is possible to define standard dimensions that are relevant to any project. Three common dimensions are baselines, processes, and benefits.

In literature, the most common way to evaluate projects is by looking at its baselines22. Did the project finish in time? Did the project deliver the promised scope? Did the project cost as much as it was supposed to? Those three baselines occur throughout different standards, such as PMBOK23 and PRINCE224. In an empirical study, the baselines have also been commonly named across practitioners and academics alike.25 It should be noted that baselines do not have to be restricted to time, scope, and cost. However, those three are always present as baselines.

Beyond baselines, some products are created as a result of processes within a project. Those products include project management products, such as a project plan and specialist products, such as a requirements document in a software development project. Relevant questions to determine a successful project along this dimension may include: Did the project management team follow best or good practices in project management? Did the subject matter experts follow the methods that are generally expected in their field for this type of project?

The final dimension is that of benefits. This dimension measures whether a project achieved its business objectives, such as an increase in productivity or a higher margin. Benefits may also be far more strategic, such as an increased market share or better firm image. While benefits are also a baseline in terms of PRINCE226 and may well be defined as a measurable objective of a project, there will usually be many benefits that are affected by a project but not controlled by it. For example, a project may focus on reducing production costs and keep track of those. But at the same time, it will impact the firm’s image, the mood of the workforce, the future strategic position, and so on. Those could be measured in theory, but in practice, it will be virtually impossible to control all the different aspects being affected by a project.

Moreover, the measurement of benefits may extend well beyond the end of a project. Therefore, benefits may well be considered a dimension in its own right. An empirical study found that benefits to stakeholders were the most important success factor named by practitioners and academics.27

It is essential to note the different nature of those dimensions. The execution of processes is limited to the lifetime of a project. Most often, they will span just certain parts of the overall lifetime. Processes are also well in control of the project team; after all, it is this team that executes the processes and creates the results. Baselines may be well in control of the project team, but they might be profoundly affected by the overall organisation. For example, the top management might decide to reprioritise its project portfolio and postpone an individual project. This project will then exceed its original baseline for the schedule. There is also a difference in accountability between processes and baselines. Whereas controlling the baselines will be generally regarded as the responsibility of the project management, creating specialist products may well be considered to be the sole responsibility of subject matter experts. Benefits may further be much more long-term than processes and baselines. Strategic benefits, in particular, may still be relevant many years after a project ends.

The distinction of project success in three broad dimensions demonstrates the main point of this chapter. The point is that multiple dimensions are not necessarily dependent. Since each dimension encompasses a multitude of aspects, it may be possible to define even more dimensions. However, the three dimensions processes, baselines, and benefits are sufficient to demonstrate the diversity and difficulty in judging and managing project success. The following section discusses the sources of uncertainty arising from these dimensions.

Sources of Uncertainty

As discussed in the previous section, a project may succeed in some dimensions but fail at others. This may lead to different views on whether a project is successful overall. This creates uncertainty for those responsible, such as the project manager and the executive(s), on how the project will be perceived. The source of uncertainty is that success in the different dimensions is not necessarily correlated. This source of uncertainty we call disparity.

Disparity applies across dimensions but also to each dimension individually, as each dimension is comprised or multiple criteria. E.g., the baselines dimension encompasses at least time, cost, and scope. There are two further sources of uncertainty: ambiguity and instability of project success.

Ambiguity arises from the subjective evaluation of a project. We’ve discussed an example of this earlier. Our project exceeded the original cost estimate by 40%. The increase in costs was approved by following the standard change request process. A new baseline was established and kept by the project. Is this project failure because it didn’t keep the original baseline, or was this project a success because it established and kept a realistic baseline once the information was available? The ambiguity arises from the fact that both perspectives can be taken. In fact, a stakeholder can argue in favour of any of the perspectives, depending on his or her personal agenda. Therefore, subjectivity gives rise to ambiguity when it comes to judging project success.

Instability means that a judgement about a project’s success may change over time. Just think about a project that delivers all the desired results in time and budget. The project ends here and is declared a proper success. But then, a few years down the road, the operating costs start to explode, because maintaining the deliverables turns out to be much more costintensive than expected. Considering the operating costs, the project failed to achieve a positive return on investment and is now considered a failure. In this example, it takes years for the perception to change, from a successful to a less successful project.

The three sources of uncertainty (disparity, ambiguity, and instability) explain why project success may be so difficult to grasp. The disparity makes it difficult to judge project success for even a single individual. Ambiguity may create different views in a group of people. And instability may make the judgements change over time. Consider that all this happens simultaneously at multiple dimensions, and you find yourself in a complicated situation. Given the many unknowns and soft factors, there is no perfect way out, but armed with this knowledge, the situation can be managed with the recommendations in the following section.

Perception Management

The previous sections introduced several sources of uncertainty when it comes to the judgement of project success. They also introduced the different dimensions at which progress can be measured and perceived. This conceptual background is used in this section to provide a recommendation on how to control the perception of your project’s success. This deliberate control is called perception management. Active management of perception can help to shape the perception of your project in the right light.

A large body of literature focuses on best and good practices for project management. The standards of PMBOK and PRINCE2 cover processes and baselines extensively. PRINCE2 also has a particular focus on benefits management. Perception management does not replace widely accepted practices in project management but enhances them with additional focus on how your project’s success will be perceived.

Figure 5. Perception of Project Success: Same Thing, but Different Opinions

In order to succeed in all dimensions, you might find it useful to imagine that you would rate your project. There are three dimensions: processes, baselines, and benefits. Each dimension can be rated from one to six stars, with six being the best. You can now take the point of view of the major stakeholders and rate your project. Let’s say your processes are working quite well. You keep your baselines, but you don’t know much about the actual benefits achieved.

You, therefore, rate your project as 4 (processes), 6 (baselines), and 2 (benefits). An exemplary visual representation of this is shown in Figure 6. This explicit rating of each dimension suggests that the benefits dimension poses the highest risk as to how your project may be perceived. Even if the benefits are not a priority for a good reason, you should probably communicate those reasons to your stakeholders and try to achieve a higher rating in this dimension.

This simple technique should raise your awareness of the following. You must manage all dimensions simultaneously. If you neglect one dimension, then this dimension might lead to the final judgement of your project. It might not matter that you performed much better in the other dimensions. The weakest one might set the bar.

Figure 6: Visual representation of a project's rating along different dimensions. This could be printed on a poster to visualize the rating to all those involved in the project.

The suggested technique is also very transparent. You can easily create a poster and hang it in your project war room. You can make it transparent to your team and stakeholders. This might help to raise the awareness and help to join efforts to address the dimensions that are at risk.

You should further notice that the responsibility of addressing the perception of the dimensions has not been limited to any single role. Instead, everyone with interest in seeing the project being a success