Successfully Designing Hybrid Project Management E-Book

Justus M. Dumont

• Herausgeber: Books on Demand
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 48

Veröffentlichungsjahr: 2021

Beschreibung

Many organizations find that the use of Scrum does not bring the expected positive effects. In addition, such projects often do not seem to be really controllable. Accordingly, attempts are made to achieve more control and controlling possibilities and better risk and quality management by combining Scrum with a project management methodology. Often it remains with the attempt, because thereby some fundamental considerations and realizations are not considered. Justus M. Dumont, a successful consultant and project manager for more than twenty years, has this to say: "Many customers believe that Scrum leads to productivity increases and cost reductions in every case. The fact that this is not automatically the case and, in many cases, leads to loss of control and poorer results makes them look for alternatives. Many believe they can find the best of both worlds, so to speak, by combining classic project management and Scrum, only to find that they are more likely to achieve the disadvantages of both approaches." In this book, the author presents an approach that has optimally combined agility and project control for more than two decades, thereby even enabling successful fixed-price projects.

Leseprobe

Table of Contents

Foreword

Taylorism

Surviving in the VUCA world

Cynefin framework

Theory X and Theory Y

Outcome and output

Planning and monitoring

The hybrid challenge

DSDM ® - Agile Project Management: An Introduction to the Framework

The basics

The process

MoSCoW - the hybrid decision

The roles

The roles at project level

The roles at solution development team level

The supporting roles

The products

Business oriented products

Solution oriented products

Management oriented products

DSDM in practice

DSDM as a hybrid alternative

DSDM ® or Scrum?

DSDM ® or traditional project management?

Afterword

Bibliography

Foreword

Since I've been managing projects - and have been doing so for well over twenty years - I've always run up against certain limits. Far too many projects go wrong. There are statistics which state that in Europe around 80% of all projects are not completed within the parameters agreed at the start of the project, and far too many projects are either not completed at all or do not achieve the target on which they are based. If you consider this figure to be even somewhat realistic, you have to ask yourself whether project management makes any sense at all. Who would entrust someone with a task in everyday life if they had to reckon with the probability of partial or complete failure being so considerable?

Now, one could simply assume that project managers or the methods and frameworks they use might not be all that good. While it can be assumed that not all project managers are equally well trained and equally experienced, such a large number of "failures" is statistically rather unlikely. So it makes sense to look for other reasons.

From my experience, many reasons exist for project failure. However, one thing must always be kept in mind: Projects are not implemented in a focused manner and in many cases are worked on by people alongside their day-to-day business. In many organizations, anyone who can control some money can launch a project uncoordinated, without ensuring that the project makes sense in the overall context of the organization and its goals. Resources are assigned from the normal teams and are expected to do the project work on the side. In the process, responsibility is readily shifted to a project manager.

In some organizations, there is a real ostrich policy here. Several colleagues who are "bought in" as external project managers for such projects tell me about a wide variety of projects for which they are supposed to send regular status reports to their steering committee or a program office. However, it is clear to everyone in the company: If you report "green", everything is fine; if you report "yellow" or even "red" - even if you provide a clear strategy for remedying the grievance - then you have to find a new client. Result: Report "green" until even the dumbest person can no longer ignore the problem, and look for a new project in parallel. The result is clear: projects that cannot be completed or can only be completed with considerable additional effort.

In short: Project management offers a great challenge for the client and its organization, the project control and the people who realize the deliverables. Leadership problems in organizations manifest themselves here very much, but also the disadvantages of teams which do not identify with the project and its goals because they are not "taken along for the ride".

This book will not focus on these topics. However, I do not want to simply gloss over them because I see how fundamentally important they are for the success of projects.

Rather, I would like to address a structural challenge of projects. Many organizations increasingly rely on agile frameworks and methods. Scrum, in particular, is experiencing a steady increase in the number of organizations using this framework. However, there are many misunderstandings because many mistakenly think Scrum is an agile project management framework. This is especially impressive because there is a central statement of Scrum, which is, "There is no project manager."

Those who "bring Scrum in-house" can achieve tremendous benefits in terms of productivity, quality, agility and employee motivation if they introduce it correctly and do not see Scrum merely as a toolbox, but understand that it is based on a certain idea of values and mindset. Only when these ideas - beyond the Scrum team - are lived, Scrum can unfold its full benefits.

However, Scrum is in no way a method or a framework for project control and project controlling etc. When users realize this, they try to compensate for these (supposed) disadvantages by combining Scrum with existing project management methods. In most cases, this is not so much a "win-win" as a "lose-lose" combination, because both participants have to give up or adapt central tasks and success factors.

This is exactly where this book comes in. Let's find out together whether this has to be the case or whether there is an alternative that realizes a true "win-win" relationship and thus combines the best of project management and agile development, so to speak.

I welcome you on the journey together

The author

Taylorism

The term "Taylorism" is often used very negatively today, especially in the context of agile companies. Frederick Winslow Taylor himself would most likely speak of process control ("task management") in connection with his research. He rejected the terms "scientific management" and "Taylor management" that are often used today in connection with his name.