Roland Dürre
Thursday July 21st, 2011

My Presentation – Project Management

A selection of German high-school students want to realize an ambitious project sponsored by the “Elite Promotion Program“. The person in charge of the program at the Bavarian Ministry of Education is a good friend of mine. Consequently, he asked me to speak about “Project Management” in front of those young people coming from all over Bavaria.

Trying to keep everything very simple, I  came up with the following presentation. Above all, I wanted to make my young audience understand all the things that go with a project.

Here is the concise manuscript. Enjoy!

Good Morning!

My presentation is about people, planning, teams, enterprises, intents, goals and – projects! After all, you all want to prepare and organize an ambitious event. You want the event to be effective in advertising, of high artificial value and economically successful. You want to reach a huge audience and create a lasting value for yourselves.

Working as a team, you will have a little more than half a year until you have to deliver many achievements in various dimensions – and you also have to integrate them. In other words: you are starting an ambitious project.

So what is a project?

It is not a good idea to talk about terms the meaning of which you cannot really explain. So now I will try and define the term “project” for you:
A project is a temporally limited co-operation of several people who want to finish a certain undertaking in a given time frame. That means a project is supposed to render a describable result in a finite time. So there is a starting point to every project. And there also has to be an end point. Eventually, the project is supposed to be finished and function successfully. So there is a certain task that has to be/should be finished after a previously defined time.

So what are the elements of a project?

There is always a goal! An undertaking is to be successfully realized. Consequently, we have to find and formulate a project goal.

If we manage to achieve this goal by the time the project ends, then we have been successful. But how to describe the goal? How to define success?

When is a project successful?

It will be helpful to define success criteria. We can determine what will be called a success within the project. If we manage to deliver at the proposed time, the project is a success. But you must be careful, success is multi-dimensional! The desired funtionality must be delivered, the quality must be acceptable, the desired added value must manifest itself, the cost should not exceed what you had planned, the deadline must be met and everybody on the team should have learned as much as possible from working on the project. If you define success criteria in advance, you will find it easier to determine whether or not a project was a success.

But before you just run around defining success criteria at random, you should remember that every project has a beginning and an end. Both, beginning and end must be clearly defined. Let us start with the beginning.

How to start a project?

It is important to find people who are willing to make a commitment and work in the project. Consequently, you will usually need a team for working a project. The team might well be a core team which can be extended as the progress demands, or as was planned initially. Or it might be a team that will be responsible for the entire project with members that cannot be replaced.

Why do we start out with looking at the team? Well, that is easy: because the team will have to have to face quite a few challenges. The team members will have to invest a lot of time, strength, brains and creativity. And, of course, the team must be up to the goal. It sounds easy, doesn’t it?
But that is not what it is. Because there is always a very important question to be answered:

Is the goal a realistic one?

This is something we can only say after we have learned what sources are at our disposal. And even then, it is hard enough. Because the future will always be something you cannot predict. And important project decisions will always be accompanied by some uncertainty.
There is an English proverb:

Birds of a feather flock together.

Why do I mention it now? Because the persons who will participate in the program will have to be able to form a team. Mind you, this does not mean that all the project team members have to be similar. On the contrary: we need pluralism and multi-diciplinarity (of course, this is also dependent on the kind of project you realize). But the people who eventually determine the “team spirit” will have to believe in a common set of values. So we are looking for a group of people who share values and yet are pluralistic and multi-disciplinary.

Team structure

For recruiting the team, two questions will be helpful:

What requirements must be met in order to make the undertaking a success?

And:

What should be avoided if we want to be a success?

So we have to recruit a team that is up to overcoming these kinds of problems. We must win persons who use their brains to think and want to do their share of the work.

In order to be a success, it is important that we build up a “real team”, rather than just a small “group of people”. When I say group, then what I mean is one person is the leader who dcides everything and then the others do the work as he says. There is a difference between a team and this sort of group. All team members are individually motivated (intrinsically), they want the project to be a success. Every one of them is aware of having to contribute considerably in a role that should fit their individual competence.

All members should belong to the type ”partner (P)“. In simple terms, that means that everyone on the team primarily considers the problems on the way to success their enemies and adversaries, instead of considering other team members their enemies. S-types (winner) are not welcome (and might easily jeapardize the project) if their main goal is catapulting themselves to the front of the group, for instance showing how great they are during meetings.

When we recruit the team and later when we integrate new members, we have to make sure that everyone agrees on this. It is helpful to give the project a name when you start the team..

As soon as you have reached that stage, i.e. as soon as you know what you want and who is going to join the team, you can cautiously start coming up with a plan. A project without a plan can easily (in fact: will mostly) fail.

The Planning Stage

You need experience in order to plan. If you still lack experience, there is only one way out: just test a few things in advance. Please note that you should always calculate your time frame forward – never backwards starting with the desired project result!

Even a good plan should always consider that something might not work out as planned. Such is life! So you need backup. It sounds very trivial – but is often forgotten. Nor will backup alone suffice. A good plan has a special quality: you can change it as you go along and see where modifications are necessary.

Because every project has its problems and surprises. Cost calculations are faulty. New awareness will make parts of the planning (or all of it) obsolete. An iterative planning process will make it possible for you to change plans before it is too late.

On top of planning, you should also think about methods. It is always helpful to come up with a project methodology.

Methodology and Roles

Especially for a team that has to cross new frontiers – and since you all are young people, this is naturally true for all of you – I recommend SCRUM as an iterative method. It is important to plan iteratively, because this is the only way to take advantage of important discoveries you make as you work on the project.

SCRUM has a number of advantages: the “milestones“ you work towards are only small steps (SPRINTs). As when jogging, small steps are better than huge steps. Each sprint will render something concrete and useful. The result of a sprint always has to have a reliable product quality. The motivation that is so important for the project will be achieved by the success, which is the felt and visible project progress. So please remember: small “Sprints”!

If you are strict in the use of SCRUM as a method, you are making sure that one person knows what the goal is (the Product Owner). And there is also another role – that of Scrum Master. He will see to it that there is a ”protected order“ in the project and for all team members. And – this is very important for all projects, but particularly important when many young people work together: there is a compulsory, written backlog.
Now you can start handing out roles. Each method will only come to life when the roles are held by the best possible player and then performed well.

Tools

But I almost forgot: you also should think about the tools you use. What might be necessary for the project? Perhaps a Wiki? Good tracking always makes sense, so maybe you want to use a tracker.

So here we go – our project can start!

Plan with responsibility: define the phases and dimensions of the project! Where do you have to work synchronously, where can you only work serially, because one step is dependent on the results of another step? What milestones make sense? What rules should we introduce for improving co-operation and communication? Does it make sense to introduce rituals, because they strengthen the team and motivate people? How to control progress? How to control quality – even prophylactically?

Yet you must never forget that common sense is indispensable. Never ”bury your head in the sand“. Less pleasant things that happen must never be ignored. All team members should also have enough courage and be willing to articulate their reservations appropriately. And always keep a healthy optimism and the belief in eventual success.

And if you managed all this with good motivation, you will, as a general rule, reach the goal quite well. It will never come without some pain and effort. You will also experience backdrops and small crises. Perhaps some of the desired but not absolutely necessary features have been deleted, but you will finally finish the project successfully. Your work is something to be proud of.

And what do you do after a project is finished? Stupid question – of course, you celebrate!

But that is not the end of the work. Something very important remains to be done. On top of a nice celebration party, you also should schedule a thorough final meeting! And you should make a list of Lessons Learned. This kind of exercise will help to improve the already achieved learning trajectory for all team members.

During a common review session, the entire project is discussed. What went well, what went poorly? What problems could have been avoided? Where and when did the communication go down the drains? When was the project crisis? What was the reason for the crisis? What would you do differently now?

It is very important for everybody to come out with fair but unrestrained feedback during the ”lessons learned“ session. The best way would be if you could motivate all team members to evaluate the achievement of all other team members as undistorted as possible. That is not at all a trivial goal. This is where an experienced moderator can contribute hugely.

In this way, the project will be doubly successful. It works and all parties concerned have learned a lot in the process.

I wish you all the best and nothing but success in your ambitious undertaking!

The presentation itself was great fun. What is most important: the German high-school students seemed quite happy with it. Hopefully, I have made a small contribution towards the success of the project.

And I think it is a pity that I did not have a video recording made. But who knows, maybe there will some day be a second time for me to give this presentation.

RMD
(Translated by EG)

3 Kommentare zu “My Presentation – Project Management”

  1. Bernhard Findeiss (Friday July 22nd, 2011)

    Ich finde es eine sehr anspruchsvolle Aufgabe, Projektmanagement in solch kurzer Zusammenfassung zu beschreiben. Von daher finde ich deine Zusammenfassung wirklich gut gelungen.

    Anmerkungen hätte ich spontan lediglich zu ein paar Details:

    – Du schreibst an einer Stelle “Iterativ ist wichtig, weil man nur so wichtige Erkenntnisse aus dem Projektfortschritt in die Projektarbeit geplant einbringen kann.” Ich denke, das sollte man noch ein wenig präzisieren. Scrum hat nämlich 2 verschiedene Feedback-Schleifen für verschiedene Zwecke eingebaut: Eine für die Verbesserung des Produkts (-> Sprint Review), und eine für die Verbesserung des Prozesses (-> Sprint Retrospective). Beide werden am Ende jeder einzelnen Iteration durchlaufen, um möglichst viel für das aktuelle Projekt zu lernen. Bei dir sieht es jedoch fast so aus, als würde das “Lessons learned” nur zu Projektende durchgeführt werden. Das ist natürlich ebenfalls richtig, aber für mich sind die beiden Feedbackschleifen in jedem Sprint mit die zentralen Erfolgsfaktoren für Scrum (->Kaizen).

    – Du sprichst im Kapitel “Werkzeuge” von einem Tracker und nennst als Beispiel dafür ein Wiki. Das würde ich durchaus unterschreiben, jedoch evtl. noch ergänzen, dass man das auch mit einfachen Klebezetteln an einer Wand machen kann. Für unerfahrene Zuhörer (von denen auch nicht klar ist, wie gut sie sich mit Technik auskennen) könnte sich das ansonsten nach einer Einstiegshürde aussehen, die sie erst überwinden müssen (-> Kostet das Geld? Wer kann so etwas aufsetzen? etc.). Ein einfaches Scrum Board mit ein paar Klebezetteln reicht aber in den allermeisten Fällen völlig aus – v.a. wenn man sich eh jeden Tag persönlich trifft (wovon ich bei Schülern derselben Schule einfach mal ausgehe :).

    Ich überlege mir übrigens seit einiger Zeit, ob ich etwas ähnliches nicht auch zum Thema Kanban machen soll. Kanban ist momentan gerade stark im Kommen, da es sich auch für Projektumfelder eignet, in denen Scrum nicht funktioniert, z.B. bei Support-Teams, wenn verschiedene Servicelevel im Spiel sind, oder ganz allgemein für Organisationen, in denen abrupte Veränderung ein Problem ist (Kanban ist hier wesentlich sanfter als Scrum).

  2. rd (Friday July 22nd, 2011)

    Danke Bernhard!

    Werde Deine Anregungen im Falle einer Wiederholung des Vortrages einbauen. Im Vortrag habe ich übrigens gleich zwei Werkzeuge empfohlen: Ein Wiki und einen Tracker! Aber Du hast völlig recht, auch hier gilt KISS (“Keep it simple and stupid” oder ironisch: “Keep it simple, stupid”), siehe auch meine Abhandlung dazu, von der ich immer noch begeistert bin! 🙂

    Eine kleine Korrektur: Die Schüler waren nicht von einer Schule, sondern kamen ihm Rahmen eines Eliteprogrammes aus ganz Bayern und mussten so auch verteilt zusammen arbeiten. Sie hatten sich übrigens schon vor meinem Vortrag auf facebook als Kommunikationsplattform geeinigt. Ist auch interessant – FB als Projekt Management Werkzeug! 🙂

    Zu Deiner Idee, einen einfachen KANBAN-Vortrag vorzubereiten, kann ich Dich nur ermuntern.

  3. bf (Tuesday July 26th, 2011)

    Hier übrigens noch ein ganz spannendes Tool aus dem Kanban-Bereich: http://flowkaizen.com/

    Damit kann man eine aus Klebezetteln bestehende Kanban- bzw. Scrum-Tafel per Bilderkennung vollautomatisch in ein elektronisches System überführen.

    Technisch basiert es auf einer Kombination aus festem (und daher bekanntem) Board-Layout, und QR-Codes, die auf die Klebezettel aufgebracht werden.

    Gibt aktuell nur 2 Probleme:
    – Es ist erst in der Beta-Phase (
    – Es wird auch in Zukunft ein reines “Cloud-Tool” bleiben, d.h. es gibt keine Version zum runterladen o.ä.

    Für unser professionelles Umfeld daher wohl nur unter gewissen Umständen geeignet, für weniger kritische Projekte aber absolut top und eine tolle Verbindung von analoger und digitaler Welt!

Kommentar verfassen

*