Hi, welcome to this lesson where you will learn from me about the motivation for this course and also get a little insight into the daily practice.

Now to the content of this lesson:

Does the course content meet my practice requirements?

I created this series of courses not only because I want to make the shift from classroom training to remote training to more economically viable online basic training. In the past, I have also strongly focused my onsite and remote trainings and coachings on practical necessities and therefore orient the content to the course of the day and the project.

Team members, however, typically make their trainings topic-specific and then have to connect the training content to the appropriate situations with a great deal of skill and ability. Therefore, my approach is to combine the content of many different trainings into one training and to adapt the sequence of the learning content to the real daily and project routine. That’s exactly what you can do in the course series content already presented.

We start with the identification of challenges and the derivation of strategy requirements, then move on to project setup, the breakdown of strategic requirements, the functional requirement identification, and finally to the realization of the solution. We also go through the request objects and ceremonies in exactly the order actually practiced.

Does the course address challenges openly?

For me, this approach has worked quite well. I also go beyond the typical scope of agile project management training when it comes to content. If you ask a trainer what he suggests you do in critical project situations, he will mostly suggest a lot of creativity in the solution with a smug grin. Of course, there are always the same challenges in projects. However, solution approaches reach deep into individual structures. I like to burn my fingers, openly address the recurring challenges and also provide you with solution approaches. Because it is precisely these challenges that cause most projects to fail. I have come across good solutions and am happy to pass them on to you.

Does the course content adhere strictly to theories of methods and frameworks?

When I look around in projects today, we find a true competition of schools of thought in the area of project methods, in which the respective adherents defend the principles of their school of thought – indeed, downright argue and compete with each other, as if there were no left and right.

Once someone has attended a course and received a certificate, they now have a nice title and maybe even a few euros more on their salary slip. Everything learned seems set in stone, the only thing – well: it’s the only thing anyone without extensive project experience knows. And he clings to that because he has no solutions beyond that. Regardless of whether the learned solution is purposeful for the current challenge or not.

Older employees are attached to classic waterfall models, younger ones to Kanban or Scrum working models. Mostly because they are only familiar with their learned work processes. And others work as they always have, namely uncoordinated and chaotic.

Now, the fact is that a company’s requirements can rarely be ideally represented in a project method and, unfortunately, also change over time. Scrum, for example, is extremely flexible and efficient, making it ideal for pure software companies. However, pure Scrum quickly reaches its limits in industrial manufacturing companies. Kanban originated in industrial manufacturing at Toyota and is therefore well suited to their requirements, but not as flexible and efficient as Scrum. The waterfall model arose from the need to avoid errors, to plan as much as possible and to be able to provide a statement on the realization dates, the costs incurred and the personnel planning in the project, but anything but flexible, fast and efficient. And the work result, or the realization of its unachievability, is available extremely late in the waterfall model – when the entire budget has already been spent.

Hey, and somehow it always worked, even without Waterfall, without Kanban and without Scrum. Is it?

What are methods and frameworks for?

On the other hand, there have always been complaints about unmet budgets, implementation deadlines, unfulfilled requirements, or the eternally long implementation period from postponed requirements to availability. Not to mention the many unsuccessful projects that sucked budgets and resources to the bitter end. Consider the many late production starts that have required additional time, budget, resources, revisions, complete redesigns, given the competition an edge. Or prominent examples such as the Airbus A380 with its mismatched cabling, the Airbus A400M with its incompatible systems, the capital city airport BER with its uncoordinated interfaces and unfulfilled requirements, new ICE models that could only go into productive operation months and years later. The list can probably be extended down to each individual company.

What causes projects to fail?

Who of you does not know the situation? No sooner has the project started than the first questions come in about how far along the project is. These questions also come after one month, a little more emphatically after 3 months, after 6 months perhaps a little escalation would be nice? … and if the answer is still that the project setup is not yet completed, there is not even an approved system architecture result and the implementation does not yet show any significant result, then something is wrong. And then the patience of the budgeters and the collaborating departments also wears thin. The pressure grows – and then the muck begins.

Well, maybe we should learn from the experiences of others after all. This is because project methods contain nothing more than suggestions for action to avoid problems that others have long had and have developed avoidance strategies for. We’ll cover a mixture of methods in this lesson, each in the appropriate place and with the option to choose the way that suits you best. In doing so, I deliberately choose not to defend methodological principles, because I am guided little by theory and all the more by practical experience. For better insight into why we do things the way we do, I look not only at the inner workings of a team, but also how project requirements come about and how these upstream phases can be made efficient.

After hopefully giving you a little insight into the day-to-day practice with my preface, in the following lesson I will give you an overview of how I want to teach the basics for Agile Project Management. So, see you in a moment.

Leave a Reply