eJournals

Zusammenfassung Zu viele Projekte, eine komplexe Materie und wechselnde Arbeitsumgebungen sind einige Gründe, weshalb mancher Projektleiter den Eindruck gewinnt, keinem seiner Projekte gerecht zu werden. Wie kann ein Projektleiter bei minimaler Präsenz vor Ort dennoch optimale Projektresultate erreichen? Meine persönliche Erfahrung mit drei zeitgleichen Projekten an drei verschiedenen Orten bei Kunden aus unterschiedlichen Branchen zeigt mir, dass dies nur mit einer besonderen Form des Projektmanagements zu bewerkstelligen ist: Ich nenne es „verteiltes Projektmanagement“. Mit dem Ansatz des verteilten Projektmanagements wird ein Weg aufgezeigt, mit dem durch einfache Verhaltensweisen die vorhandenen Schwierigkeiten überwunden und Projekte erfolgreich abgeschlossen werden können. Auf einen Nenner gebracht bedeutet „verteiltes Projektmanagement“ einfach, dass der Projektverantwortliche sowohl sein Wissen als auch die Verantwortung mit dem Projektteam teilt. Abstract Managing several projects at different sites the same time requires a unique approach to project management. What to do when it seems impossible to give each project one hundred percent of your time because several of them are running simultaneously at different sites? Too many projects at the same time, the complexity of the subject matter, and constantly changing work environments - should we wonder why project managers sometimes feel torn because they cannot devote enough of themselves to each project? The approach discussed here, the strategy of “shared project management” provides some valuable insight how to overcome the difficulties and provides a guideline for project managers facing the same challenge. In short it can be said that the project manager must share project control and project know-how to ensure overall success. Schlagwörter Führung, Mehrprojekttechnik, Projektmanagement, Projektorganisation, Teamentwicklung, Teilung der Verantwortung 1. BACKGROUND When it became necessary for me to direct three different projects at three different sites at the same time, I realized that only a form of joint or “shared” project management would lead to a successful conclusion. In each situation that deals with extremely knowledge-based work, direct control by the project manager will decrease, and an active information exchange benefiting all team members will increase [1]. Especially with projects that operate under heavy time constraints, in which highly qualified experts develop innovative products in a unfamiliar environment, that is, at the customer’s site, a necessary base of trust must first be built up. As time is scarce, however, an information exchange must begin at once, i.e. during the phase of consolidation, also known as “storming phase” [4], and must be successful. For this to work, each team member does not just have to focus on his/ her own skills, but must be familiar with each communicational interface. Seen from the project manager’s viewpoint, the situation with three projects that run simultaneously is 4 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 Multi-Project Management How to manage several projects simultaneously - and succeeding M A R C E L B H E N D Internationalisierung des Projektmanagements Seit langem gibt es in dieser Zeitschrift englischsprachige Abstracts, um ausländischen Kollegen die PM-Themen im deutschsprachigen Raum zu illustrieren. Nun wollen wir einen Schritt weiter gehen und englischsprachige Autoren zu Wort kommen lassen, damit sie uns ihre Themen für die Entwicklung des Projektmanagements vermitteln können - und das gleich im Original, um die feinen Nuancen zu wahren. Das werden in erster Linie Autoren aus englischsprachigen Ländern und deren PM-Gesellschaften APM und PMI sein; hier können aber auch Autoren aus unseren deutschsprachigen PM-Gesellschaften Vorträge publizieren, die sie auf englischsprachigen Tagungen halten und wesentliche Themen unserer englischsprachigen Kollegen „treffen“. Einen Beitrag je Heft in wechselnden Rubriken bieten wir als Innovation für das neue Millennium an. represented by figure 1. The lines of communication between the project manager and each project team are clearly visible as well as the interactive web between project team and customer representatives. This “shared project management,” as I call this form of team work with minimal overhead, requires project teams to know more about communication structures; they also will have to be able to translate project management know-how into success with the project. Thus, the definition of the term “shared project management” turns on two meanings of “shared”: Shared project management means that project managers “share” their capacity for work with different projects; it also means that they “share” their knowledge with all the members of each project team. 2. EXPANDING THE KNOWLEDGE BASE With highly complex projects, we rely on experts who are responsible for just one field of expertise. In most cases, only one person has the depth of knowledge required for the field in question. The difficulties encountered when trying to objectively evaluate the work results of such highly qualified people automatically leads to the necessity of creating a common ground for understanding, especially since deficits, if any, in such a person’s work tend to become visible only at a late state in project development. This common ground consists of project management knowledge [2], as shown in figure 2. 3. OBSERVE BASIC RULES 3.1 Understand project management functionally Besides being responsible for the project’s overall success [5], a project manager’s position within the project is also functional, see figure 3: he/ she is equally necessary as are the other team members. The project managers’ activities will only be accepted if they fill their position in a way that makes the other members recognize them as useful. If project managers do not make a visible contribution to the project, they will be regarded as superfluous overhead. 3.2 Give team members responsibility Apart from providing a professional and agreeable working environment, it is essential that each team member is being assigned responsibility for a specific piece of work, as outlined in figure 4. Experience in complex projects shows that especially the highly skilled staff is capable of higher achievements, if their contributions are appropriately acknowledged. 3.3 Let the team organize itself A productive and efficient team must be able to organize itself and its workflow, as shown in figure 5. All of the team members sit in the same boat! The team as a whole must develop a sense of responsibility for the success of the project. 3.4 Direct the team towards a common goal It seems matter of fact that a team must work toward its common goal. Nonetheless, while the project is progressing, the team’s common Fig. 1: Managing three projects simultaneously with three different project teams Fig. 2: Extending the knowledge base is essential for the experts as well as the project manager 5 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - G R U N D S A T Z B E I T R A G goal must be kept in sight over and beyond each team member’s individual responsibilities. To work purposefully, each team member must stay aware of his/ her own contribution toward achieving the common goal, see also figure 6. 3.5 Make project methodology transparent Project work will only be effective if the project methodology applied is accepted and understood by each team member [3]. In order to achieve an in-depth understanding for each project phase, the project plan should be developed together with the team, and modified according to the team members’ input, see figure 7. Besides the admittedly high requirements from the project team, there are clear differences between their assignments and the role of the project manager. I do not refer to such differences as administrative tasks, project calculation or supplier contacts, but to some essential prerequisites for a shared project management to succeed. 3.6 Protect the project team Trust means openness, and openness in turn leads to vulnerability, that is, if project team members take charge of a part of the project, and thus take responsibility for a share of the project management, they must be able to feel confident that this will not hurt them, as shown in figure 8. For project managers, this means that they must stand by their responsibilities for the whole project, and to defend their teams’ decisions as if they were their own. If team members do not feel shielded and able to work relatively undisturbed by external influences, “shared management” is doomed to failure from the outset. If team members feel that they have been abandoned, they will immediately turn to their own area of expertise, and limit themselves to it, which in turn will mean that the project managers’ physical presence on site will be required much more frequently. By contrast, if the team members feel protected and able to do their share, project managers will only have to leave them their number to call, and to provide “moral assistance” by phone. If project managers adopt the teams’ decisions as their own, the teams’ burden of responsibility will become much lighter, and they will know that they are not left alone. 3.7 Avoid micro-management Shared project management requires that project managers give up Fig. 3: Functions within the project team and how they relate to each other 6 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 Fig. 4: Every team member is responsible for his/ her work package, and for the direct communication with his/ her counterpart at the customer on trying to achieve a long-term understanding of all the technological details of their projects. They will have to live with evaluating their projects from personal conversations with project teams and customers. Only occasionally, time constraints will allow them to view work results directly; moreover, their lack of technologically detailed knowledge will not allow them to test the system directly, outlined in figure 9. Success in “shared” project management is therefore to a high degree based on well-working communication channels to their team members. 4. OPPORTUNITIES AND RISKS 4.1 Opportunities 4.1.1 Highest potential team performance As a rule, a team performs better than any single member of the team, a statement that can easily be verified by group experiments. Mostly, the team’s performance is indeed better than the average solution of each of its members, but at the same time, the team’s performance is not as good as the best single solution. While such group experiments usually confine themselves to general questions, such as “Which items would you take to a lonely island? ”, for which everybody has a plausible answer, a complex project environment poses a set of issues to which any one team member alone cannot provide a solution, because they will lack the skilled knowledge of all the fields involved. Hence, group and single performance can no longer be compared, as nobody alone can come up with the grand total. Therefore, the group dynamic process for finding an optimal solution is somewhat different. The team is forced to work together to find its solution. Thus, a major requirement for achieving an above-average solution will be met automatically, because no other way is feasible. Furthermore, the team will consist of experts in their respective fields who will act responsibly and Fig. 5: A selforganizing team knows how to organize their work 7 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - G R U N D S A T Z B E I T R A G Fig. 6: A common goal for the team includes both the final product and a happy customer Fig. 7: The project methodology provides a guideline for the project team are motivated to achieve an optimal performance. 4.1.2 Optimized use of the project manager’s time Project managers, too, are specialists. The difference is that they do not work on single technological aspects but on how to use the combined resources put at their disposal to achieve a project’s goals. Some activities, such as protocol preparation and finance reporting, do not demand that the project manager is physically present on site. But communication and integration are core aspects of a project manager’s job that must be done together with the team. The better the common ground for understanding, the simpler it will be to integrate all activities toward achieving the project’s goals. Moreover, it leaves more time for a project manager’s other major responsibility: communication. Regular project meetings must take place, and there must be channels for informal communication. For reasons of efficiency, it is recommended that information be exchanged in a compressed form, e.g. for two hours in the morning, as system designers depend on being able to work out their problems quietly, whereas project managers can only devote a limited amount of time to each project. Last but not least, frictions occur in each project, and therefore a major part of the time a project manager will spend on site must be devoted to solving problems. 4.1.3 Strong identification of the team with the project If a person’s range of effectiveness is enlarged, his/ her satisfaction will increase accordingly. An increased satisfaction in turn leads to a stronger identification with the workplace, in this case the project. As in a severely time-constrained project certain tasks are handled by certain persons alone anyway, it is simple to take this fact into account, and make them responsible for this task. Nothing promotes team members’ identification with a project more strongly than the visible contribution they are making. The recognition they will receive for it acts as a further incentive. 4.1.4 Direct communication between team and customer Communication is another matter that is often made difficult, although it can be easy. It is an unarguable fact that the customer must understand that communication flow is part of the project structure. A key figure is the project manager who is the person responsible for the project and the pointman for decisions. It does not make sense, however, to have a project manager act as a kind of information buffer into which all partners pour their inquiries, requests, complaints and answers. It is much more effective for a project manager to participate in the meetings on technological matters at the beginning of each project stage, but afterwards to let a communication culture develop, in which all participants have access to the information required and keep the team informed at each step of the way. Parallel work efforts and avoiding bottlenecks are important at each stage and level, as it would require a project manager’s perma- Fig. 8: The project manager’s job is to absorb external influences and to protect the team 8 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 Fig. 9: Especially in software projects the results are difficult to verify, so information about the progress made comes directly from the developers nent presence on-site, if he/ she would be attempted to directly monitor the communication flow, as shown in figure 1. 4.1.5 Efficient use of the project methodology Project methodology consists of processes and contents, that is, project phases and work packages, logically linked to one another. Too often, the basic tenets of a project have not been worked out clearly and in detail, which leads to lack of understanding between project management, project teams and customers. To avoid such lack of understanding, one needs a kind of safety net that prevents the worst misunderstandings. A consistent project methodology is such a safety net, as everyone will understand it, and everyone will be able to relate it to their own work as well as to that of others. This methodology allows early recognition of obviously wrong starts, without requiring excessive control. 4.2 Risks 4.2.1 Project team takes part of the control Project managers must realize that any delegation of parts of their responsibilities means a delegation of parts of their control. Requiring that such control should be handed back is acceptable only if it is a case of abuse of power, or ineptitude. Otherwise, project managers must accept the risk, as it is directly connected to a basic prerequisite of shared project management, the delegation of responsibility. 4.2.2 Uncontrolled communication between team and customer If technical experts from a provider and a customer talk to each other about technological issues for a longer period of time without consulting the project manager, the results of these conversations may come to contravene the project’s goals. It is tempting to try for the implementation of a perfect solution without sufficient consideration of the costs involved or the effects this may have on other project areas. Such problems should of course be detected at an early stage, either through formal means, by holding regular status meetings, or through informal means, by other team members who will exert a certain amount of control. 4.2.3 Project manager’s lack of presence If projects run well, project managers will not be needed, but if they run badly, project managers may be accused of a lack of commitment that prevented them from exercising appropriate control over their team. Almost all project managers have probably experienced a situation like this. Admittedly, this is a difficult issue, since in (seeming) crises, the on-site presence of those responsible for the project will explicitly be requested by customers. The accusation of a lack of presence will require a difficult balancing act that can quickly endanger other, well-running projects, even though some of the risks can be mitigated without the presence of the project manager simply by deploying additional resources or calling in outside help, such as for independent reviews. 4.2.4 Project manager cannot assume additional tasks An increase of a project manager’s on-site presence will be requested not only when difficulties with a project arise, but also when a project manager is required to take on additional tasks. As the time a project manager is required to be present on site is usually agreed upon in a contract, there will at least be no legal problems arising from this situation. Atmospheric disturbances affecting customers or teams may be recognized too late: If project managers are incapable of assessing the situation on-site correctly, either because they are insufficiently informed, or because the whole project team is misreading the situation, the customer’s mood can very quickly turn sour and distrustful. In such a situation, project managers must immediately find out how messages they have received should be taken, and how the senders of such messages should be regarded, and try to gain a correct understanding of the project status. If this cannot be done, an increased presence on site is inevitable. Experience shows that there are always periods in which a project manager will have to spend more time with customers, and in which other projects must be put on a back burner for a short time. Such crises, and the increased workload that comes with them, cannot always be avoided, but can be handled with some additional effort. 5. A PROJECT MANAGER’S GUIDELINE Let us restate the most important findings of this paper in the form of a general guideline. Experience 9 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - G R U N D S A T Z B E I T R A G shows that the three points listed below are the critical ones which require the biggest change of the project manager’s behaviour. 5.1 Trust the team members and their skills This point is critical for success or failure of a shared project management. In good times, delegation of control is not a problem. The litmus test of a project manager’s commitment to the concept will come when problems arise, perhaps even from faulty decisions made by the project team. At this point, it will become clear if project managers are able and willing to stick in practice with their theoretically accepted principles. If at the first difficulty, project managers take away control from a team member, their behaviour will be seen as a breach of trust, and in consequence, they will afterwards have to spend considerably more time with the project than originally intended. 5.2 Accept not to understand all details To control a project also means complete understanding of everything that is going on, and of how each item relates to all the other items. Given the complexity of the technological environment, lack of time will make this kind of deep understanding impossible, even if a project manager was able at one time or other to do a significant amount of work himself/ herself. For one, knowledge of technological details will become obsolete quickly, and for another, new fields, in which project managers may not have had the time to gain hands-on experience, are constantly evolving. For our long-term success as project managers, it may be better if we preserve our basic understanding of the matter, of the big picture so to speak, and above all to work on constantly updating and enlarging our conceptual knowledge. 5.3 Focus on process management Sometimes, something comes up, and you think, “I know this stuff, I can do it better”, and you are tempted to proceed to do it immediately on site. Hopefully, you will pull back in time to remember that this particular task is the responsibility of one of your team members, and that your philosophy is one of non-interference, of “shared project management”. If you discover an occasional mistake, you should treat this as a normal aspect of each project, provided the causes are corrected afterwards, and the development process is improved. In addition to the development process, the processes to focus on include: change management, agreements with customers, etc. If process parameters are framed by certain setpoints, such as regular team meetings with customers, and documentation of all requests for changes, you have created the conditions that will make the results fall in line with the project goals. Afterwards, an indepth review of work results will occur only when official acceptance deadlines are approaching, when customer requirements are unclear, or when newly identified issues require a partial redesign. 6. CONCLUSION Is shared project management a new term for a new situation? Not quite, as two points derived from this paper show: One, the paper is based upon a situation in which one project manager is dealing with several projects simultaneously. This situation is not new, but the pressure on a project manager to perform with speed under tight deadlines has increased, as it is aided by the now universal employment of fast communication devices, such as e-mail and cellular phones. Two, the foreground of the paper is characterized by so called - and well known - soft factors, that is, by unmeasurable factors such as the delegation of control and responsibilities. The conclusion offered by this paper may therefore seem incongruous: despite increased technological complexities and specialization, it is not the sophisticated technology-oriented attitude that will be the future key for project success, but rather the ability to communicate and the willingness to expect and overcome conflicts. In summary, I would like to point out that requirements regarding project team members and project managers will increase in the future. Team members must learn the basics of project management, and project managers must train themselves in new behavioral attitudes, and must accept that the focus of their jobs is moving away from the knowledge of technological details and shifting toward a conceptual way of thinking. If a project manager and others who are involved in a project “share” according to the guidelines presented above, the 10 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 probability of success for a project, as well as the efficaciousness with which it is managed, will increase exponentially. ■ References [1] Drucker, Peter F.: Post-Capitalist Society. Harper Collins Publishers 1993, Chapter 4 [2] Duncan, William R.: A Guide to the Project Management Body of Knowledge (PMBOK). Project Management Institute 1996, p. 9 [3] NCR: Scalable Data Warehouse Methodology. NCR Publications 1998 [4] Moxon, Peter: Building a Better Team - A Handbook for Managers and Facilitators. Gower 1993 [5] Whitten, Neal: Are You a Benevolent Dictator? You Should Be! In: PM Network 12/ 1998, p. 17 Author Marcel Bhend has more than 14 years of experience of mainly projectrelated work in the information processing industry. He graduated as electrical engineer from the ETH Zurich, Switzerland, and has a masters degree in project management from the George Washington University. During his career he has held different positions ranging from marketing and sales, system engineering to project management. He has worked for several companies, among them Andersen Consulting and NCR Corp. In his current position as Data Warehouse Project Manager at NCR he is responsible for presale consulting and implementation of data warehouse solutions. Among his customers are major leading companies in the retail, telecommunication, pharmaceutical and financial areas. He is also the author of several articles, speaks at conferences and provides data warehouse workshops. Address NCR GmbH Hahnstraße 43e D-60528 Frankfurt Phone: 0172/ 82 38 527 Fax: 069/ 66 529-220 E-Mail: marcel.bhend@germany.ncr.com 11 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - G R U N D S A T Z B E I T R A G Zusammenfassung Die Managementkybernetik konzentriert sich auf die Entwicklung von Lenkungsmodellen, mit denen komplexe Systeme unter Kontrolle gehalten werden können. Diese Lenkungsmodelle könnten somit auch für das Management komplexer Projekte geeignet sein. Der Beitrag fasst die Ergebnisse des Forschungsprojektes „Systemdynamik im Projekt und PM“ zusammen, in dem das Modell lebensfähiger Systeme (MLS) von Stafford Beer auf seine Eignung für Projekte und für das Projektmanagement überprüft und einige Gestaltungsregeln für das Management komplexer Projekte erarbeitet wurden. Sie wurden auf dem Deutschen Projektmanagement Forum 1998 in Dresden vorgestellt. Abstract Management cybernetics as a management science focuses on the development of models for the control of complex and dynamic systems. These models could be used just as well for the management of complex projects. This article summarizes the results of the research project “System Dynamics in Project and PM” which has examined the suitability of the Viable System Model of Stafford Beer for projects and project management. Some rules for the management configuration of complex projects have been elaborated. They were presented to the participants of “The German Project Management Forum 1998”. Schlagwörter Autonomie, Kybernetik, Managementkybernetik, Modell lebensfähiger Systeme, Projektmanagement, Projektmanagement 2. Ordnung, Rekursion, Systemtheorie 1. EINFÜHRUNG IN DAS PROJEKT: ANLASS UND RAHMEN Das Projektmanagement wird heute vielfach noch als ein Instrument betrachtet, mit dem sich komplexe Vorhaben wie eine Maschine konstruieren, bauen, steuern und kontrollieren lassen. Die Praxis zeigt jedoch ein anderes Bild. Viele Projekte enden mit einem so nicht geplanten Ergebnis, einer Termin- oder Kostenüberschreitung oder schlicht in einem Fiasko. Die Vermutung, dass wir vielleicht ein anderes Verständnis des Projektmanagements benötigen würden, wird selten formuliert. Weit verbreiteter ist hingegen die Bekämpfung von Symptomen: Für Projekte in der Krise gibt es jetzt das Krisenmanagement, für Konflikte das Konfliktmanagement. Andere Projekte mutieren zur Selbsterfahrungsgruppe. Und die Listen der Projekt-Erfolgsfaktoren sind mittlerweile ähnlich lang wie die Listen von Qualifikationsanforderungen an die Projektleiter. Dies alles hat seine Berechtigung, weil es auf die eine oder andere Art und Weise der Weiterentwicklung des Projektmanagements dient. Es trägt aber zur Lösung der Probleme nur partiell bei. Das Programm „Neue Wege im Projektmanagement“ unter der Leitung von Dipl.-Ing. M. Saynisch geht einen anderen Weg. In diesem Programm werden Auswirkungen und Konsequenzen erarbeitet, die sich aus neuen Sichtweisen und Erkenntnissen in den Wissenschaften für das Projektmanagement ergeben. Nach der Evolutions- und Chaostheorie sind in den letzten Jahren Teilthemen aus dem Gegenstandsbereich von Systemtheorie und Kybernetik in Form von Forschungsprojekten detaillierter untersucht worden. Ansatzpunkt für das im Jahr 1996/ 97 durchgeführte Forschungsprojekt „Systemtheorie und 12 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 Das Modell lebensfähiger Systeme und seine Anwendung im PM Ergebnisse des Workshops auf dem Deutschen PM Forum 1998 M A N F R E D S A Y N I S C H , G E R H A R D M E K E L B U R G , P E T E R M . F R I E S S soziale Systeme im Projektmanagement“ (GPM Projekt 96002) war die enge Vernetzung von Systemtheorie und Projektmanagement. Die Systemtheorie ist die Wissenschaft von der Struktur, den Verknüpfungen und dem Verhalten komplexer Systeme. In diesem Projekt standen die strukturellen Aspekte der Gestaltung von Projekten und des Projektmanagements im Vordergrund. Zielsetzung dieses Projektes war es, neuere systemtheoretische Konzepte (wie z. B. Selbstorganisation, Chaostheorie, Autopoiesis) auf die Gestaltung von Projekten anzuwenden, in denen neben der Leistungserstellung auch die Interessen verschiedenster Gruppen und Personen oder politisch-kulturelle Einflussfaktoren eine wesentliche Bedeutung haben. Unter dem Titel „Zur Gestaltung der sozialen Architektur von Projekten - Das Zusammenwirken von sozialen, technischen und komplexen Systemen“ wurden die Arbeiten und Ergebnisse publiziert [1]. Das im Jahr 1997/ 98 durchgeführte Forschungsprojekt „Systemdynamik im Projekt und PM“ (GPM Projekt 97012) knüpfte an die Forderung an, die Erkenntnisse der Managementkybernetik in die Belange des Projektmanagements umzusetzen. Die Managementkybernetik betrachtet Komplexität als Grundproblem des Managements. Sie konzentriert sich auf die Entwicklung von Lenkungsmodellen, mit denen komplexe, sozio-technische Systeme „unter Kontrolle zu halten“ sind. Das zentrale Lenkungsmodell der Managementkybernetik ist das Modell lebensfähiger Systeme (MLS) von Stafford Beer. Die Zielsetzung des Projektes war es, dieses Modell auf seine Eignung für Projekte und für das Projektmanagement zu überprüfen und Gestaltungsregeln für das Management komplexer Projekte zu erarbeiten. Die Arbeiten zu diesem Projekt sind im Tagungsband des Deutschen PM Forum 1998 veröffentlicht und im Workshop W5 interessierten Teilnehmern präsentiert worden [2]. Der vorliegende Beitrag stellt kurz die theoretischen Grundlagen dar und zeigt dann die Ergebnisse des Projektes mit Konsequenzen für die Praxis auf. Anschließend werden die Ergebnisse des Workshops diskutiert. 2. DAS MODELL LEBENSFÄHIGER SYSTEME - EIN ÜBERBLICK Als Ende der 50er Jahre die noch junge kybernetische Wissenschaft ihren großen Durchbruch hatte, begriff Stafford Beer, dass diese Erkenntnisse auch für das Management von Bedeutung sind, und wurde so zum Begründer der Managementkybernetik. Bei seinen weiteren Arbeiten erkannte er, dass das Zentralnervensystem des Menschen ein lebensfähiges System repräsentiert, das mit allen für das Überleben notwendigen Funktionen und Beziehungen ausgestattet ist. Stafford Beer identifizierte im menschlichen Zentralnervensystem fünf Subsysteme, von denen jedes relativ autonom gewisse Funktionen für das Gesamtsystem wahrnimmt. Diese Subsysteme interagieren über Kanäle permanent 13 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - G R U N D S A T Z B E I T R A G miteinander und halten sich selbst und damit das Gesamtsystem - ohne zentralistisch-hierarchische Steuerungsinstanz - in einer Unzahl von Zuständen und Situationen in einem Gleichgewicht - eben unter Kontrolle. Beer fasste das in einem Modell zusammen, welches auf der Erkenntnis der Neurophysiologie aufbaut, dass die biologische Lebensfähigkeit eines Organismus nicht auf den Eigenschaften seiner Organe beruht - vielmehr ist sie das Resultat der Verknüpfung der Organe (s. Abb. 1). Beer kam nun auf die Idee, eine Parallele zu ziehen zwischen der Funktionsweise des zentralen Nervensystems des Menschen und einem Unternehmen, denn die Überlebensfunktion ist für beide eine entscheidende Größe. Beer ging davon aus, dass die im zentralen Nervensystem gefundenen Subsysteme und ihre Verknüpfung in allen komplexen Systemen und damit auch in Unternehmungen zu finden sind. In einem Prozess des Verstehens, Erklärens und Vergleichens von Zentralnervensystem und Management leitete er die Grundprinzipien des Modellaufbaus und der Verwendung des Modells ab. Besonderes Kennzeichen des Modells ist seine charakteristische Struktur aus fünf Subsystemen, die als Lenkungseinheiten oder Systeme 1, 2, 3, 4 und 5 bezeichnet werden (s. Abb. 2). Wichtige Erkenntnis dabei ist, dass bei der Übertragung auf das Unternehmen das klassische Prinzip des Organigramms aufzugeben ist und vor allem die wichtigsten Funktionstypen (Subsysteme) in den Vordergrund rücken. Das Modell lebensfähiger Systeme ist somit weniger durch eine Analogiebildung entstanden, sondern mehr das Ergebnis der Suche nach den grundlegenden und notwendigen Prinzipien, nach denen in Natur und Gesellschaft selbstregulierende, lebensfähige Systeme funktionieren. Das Modell lebensfähiger Systeme ist in den letzten Jahren weiterentwickelt worden. Dabei wurde es Abb. 1a/ b: Die Generalisierung des neurophysiologischen Regelungssystems des menschlichen Organismus durch Stafford Beer 14 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 für die Anwendungen bei einer Unternehmensführung gründlich untersucht und beispielsweise in das St. Galler Management-Konzept eingebaut. Ein neuer Schwerpunkt liegt dabei auf der organisationalen Intelligenz, unter welcher die Fähigkeit von Organisationen zur Transformation zu verstehen ist. Ein weiterer Schwerpunkt ist das ebenfalls von Beer entwickelte Team Syntegrity Model, eine neue Form der Zusammenarbeit von bis zu 30 Personen, welche die Abstimmungsprozesse in den Unternehmungen revolutionieren und damit auch für das Projektmanagement geeignet sein könnte. Dieses war jedoch nicht Gegenstand dieses Forschungsprojektes. 3. DIE ERGEBNISSE DES FORSCHUNGSPROJEKTES Das Projekt hat das Modell lebensfähiger Systeme auf seine Eignung für Projekte und Projektmanagement überprüft. Die Ergebnisse sind in Form von vier Thesen komprimiert dargestellt. Diese ergänzen die 9 Thesen, die im Projekt „Systemtheorie und soziale Systeme im Projektmanagement“ erarbeitet worden sind [1]. Diese beiden Ergebnisse sind Grundlage für die Formulierung von Gestaltungsregeln für das Management komplexer Projekte. 3.1 These 1 Das Management komplexer Projekte soll dem Bild der „Matroschka“ entsprechen - Projekte, Teilprojekte, Prozesse und Organisation müssen nach den Prinzipien der Rekursion gestaltet sein. Lebensfähigkeit und Autonomie sind zwei weitere mit der Rekursion eng vernetzte Prinzipien, die dabei als Gestaltungsparameter einfließen. Erläuterungsbeispiel: Im Projektmanagement gibt es allgemein anerkannte Gestaltungsregeln (im oft recht abstrakten Kontext) für die Bildung von Teilprojekten und großen Arbeitspaketen. Abb. 2a/ b: Die Umsetzung der neurophysiologischen Regelung in ein Modell der Unternehmensführung durch Stafford Beer 15 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - G R U N D S A T Z B E I T R A G Die Aufgabe ist beispielsweise derart abzugrenzen, dass wenig Schnittstellen entstehen und dass die Zuordnung von organisatorischen Einheiten eindeutig erfolgen kann. Mit den Prinzipien der Lebensfähigkeit, Rekursion und Autonomie können diese Gestaltungsregeln präzisiert und ergänzt werden. ● Nach dem Prinzip der Lebensfähigkeit sind Teilprojekte so zu gestalten, dass für diese - vergleichbar einer Konzernholding und ihren Divisionen - ein eigenständiges Management gerechtfertigt ist und auch implementiert werden kann. ● Nach dem Prinzip der Rekursion sind Teilprojekte so zu gestalten, dass deren Management die gleiche Struktur aufweist, wie das Management des Gesamtprojektes. Beispielsweise sind Controlling-Funktionen auf Projekt- und Teilprojektebene einzurichten - Aufgabenumfang und Betrachtungshorizont bleiben jedoch unterschiedlich. Darüber hinaus sind Gesamtprojekt und Teilprojekt vereinfacht formuliert nach dem Prinzip der überlappenden Gruppen miteinander zu verknüpfen. ● Nach dem Prinzip der Autonomie sind Teilprojekte so zu gestalten, dass sie im Interesse der Performance des Gesamtsystems möglichst autonom agieren können. Es sind aber Regeln zu vereinbaren, nach denen der Gesamtprojektleiter diese Autonomie im Interesse des Gesamtprojektes situativ und für jedes einzelne Teilprojekt separat anpassen kann. 3.2 These 2 Das Management komplexer Projekte muss die normative, strategische und operative Ebene berücksichtigen, damit die unterschiedlichen Sach- und Zeithorizonte im Projekt angemessen bewältigt werden können. Erläuterungsbeispiel: Das heutige Projektmanagement fokussiert auf die Planung, Steuerung und Kontrolle der operativen Leistungserstellung. Jedes Projekt weist jedoch auch Randbedingungen mit ganz unterschiedlichen Sach- und Zeithorizonten auf, welche die operative Arbeit vorsteuern. Diese Randbedingungen können strategische Bedeutung für das Projekt haben, wie zum Beispiel die Teamentwicklung über den Projektablauf, oder sie können normativ sein, wie zum Beispiel die Ziele des Auftraggebers. Ein Projektleiter, der beim Projektstart die ihm bekannten Vorgaben und Randbedingungen seines Projektes in die normative, strategische und operative Ebene einordnet, gewinnt drei Vorteile: ● Die gesamte Managementaufgabe wird transparenter. ● Er kann wichtige Aufgaben für das Management des Projektes schneller erkennen und Aufgabenträgern innerhalb wie außerhalb des Projektes zuordnen. ● Er kann die unterschiedlichen Zeithorizonte der Aufgaben besser berücksichtigen und damit möglichen Projektkrisen besser vorbeugen. Diese Strukturierung benötigt sicher nicht in jedem Fall ein umfassendes Planungsmodell, wie es mit dem Bezugsrahmen zum Management komplexer Projekte dargestellt ist (s. Abb. 3). Abgeleitet aus dem Bezugsrahmen kann das Management komplexer Projekte zum Beispiel bereits durch folgende Fragen verbessert werden: 1. Welche Vorgaben und Werthaltungen meines Auftraggebers sind mir bekannt? 2. Wie kann ich die Struktur und Kultur meines Projektes gestalten, um diesen Vorgaben und Werthaltungen zu entsprechen? 3. Welche kritischen Erfolgsfaktoren resultieren aus der Struktur und Kultur meines Projektes? 4. Welche Maßnahmen muss ich durchführen, um den kritischen Erfolgsfaktoren meines Projektes gerecht zu werden? 5. Bis wann müssen diese Maßnahmen durchgeführt werden? 6. Wer führt die Maßnahmen durch? 3.3 These 3 Für das Management komplexer Projekte ist es nicht entscheidend, wer oder was die fünf Managementfunktionen des Modells lebensfähiger Systeme wahrnimmt, sondern dass diese Funktionen überhaupt und aufeinander abgestimmt wahrgenommen werden. Erläuterungsbeispiel: Diese These spiegelt die Alltagserfahrung in Unternehmungen und Projekten wider, dass es weniger darauf ankommt, wer eine Auf- 16 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 gabe macht, sondern dass sie überhaupt erledigt wird. Die Identifikation der fünf Managementfunktionen kann mit den folgenden Fragen erfolgen: 1. Politik: Wer oder was bestimmt die Funktion meines Projektes im Unternehmen oder in der Umwelt, wer oder was legt Prinzipien und Normen für das Projekt fest, und wer oder was gleicht die internen und externen Anforderungen an das Projekt aus? 2. Intelligenz: Wer oder was erfasst, analysiert und beschreibt das Projekt und seine Umwelt, und wer oder was berichtet mir darüber? 3. Steuerung: Wer oder was sorgt für den internen Ausgleich im Projekt durch Steuerung oder durch die Zuteilung von Mitteln oder durch die Wahrnehmung von Synergien? 4. Koordination: Wer oder was stimmt die Teilprojekte oder Arbeitspakete meines Projektes miteinander ab, und wer oder was gleicht zwischen diesen aus? 5. Implementierung: Wer oder was managt die Teilprojekte oder Arbeitspakete? Nach dieser Identifikation sind die Managementfunktionen im Bedarfsfall zu vervollständigen oder neu festzulegen, ihr Zusammenspiel aufeinander abzustimmen und der Informationsfluss zwischen ihnen zu regeln. 3.4 These 4 Über einen „Parasympathikus“ können wichtige Informationen für die Projektsteuerung gewonnen werden. Dies ist bei allen Projekten, in denen wie bei IT- oder Organisationsprojekten human-soziale Systeme eine Rolle spielen, von besonderer Bedeutung. Erläuterungsbeispiel (siehe auch Kasten „Parasympathikus“): In komplexen Projekten sind somit alle drei Informations- und Steuerungskanäle, 1. Befehlsachse/ somatisches Prinzip, 2. Formale Information/ Sympathikus und 3. Informale Information/ Parasympathikus), bewusst zu planen, zu implementieren und am Leben zu erhalten. Dies kann zum Beispiel durch ein Management by walking around, durch das Fragen und Zuhören in Kaffeeküchen und Raucherecken, durch ein Intranet-Forum oder wie bei Siemens Österreich durch eine Projektbörse, an der die Projektmitarbeiter anonym auf den Erfolg des Projektes spekulieren können, erreicht werden. Wesentlich bei dieser Planung und Implementation ist die enge Kopplung aller drei Informations- und Steuerungskanäle. In dem umfassenden Ansatz für das Management komplexer Vorhaben, dem „Projektmanagement 2. Ordnung (PM-2)“ [1], wird diese Vernetzung beispielsweise gewährleistet. Darüber hinaus integriert PM-2 gleichzeitig die normative, strategische und operative Ebene und das Prinzip der Rekursion (Thesen 1 und 2). PM-2 ermöglicht mit seiner Differenzierung in vier Welten das Zusammenspiel von harter und weicher Methodik, von linearen, nichtlinearen und zyklischen Prozessen oder von Räderwerken und Netzwerken. PM-2 manifestiert somit ein neues Verständnis von Projektmanagement. 4. DER WORKSHOP AUF DEM DEUTSCHEN PM FORUM 1998 4.1 Der Ablauf und die Ergebnisse des Workshops Der Leiter des Forschungsprojektes „Systemdynamik im Projekt und PM“, Dipl.-Ing. Manfred Say- Abb. 3: Managementebenen und Funktionen des Projektmanagements 17 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - G R U N D S A T Z B E I T R A G Harte Faktoren Weiche Faktoren Systemische Faktoren Managementebenen und Funktionen Orientierungsgrundlagen Zielgröße Normatives Management Politik System 5 Projektdefinition Werthaltungen Projektkultur Teamarbeit Motivation Kompetenzen Transformation Identität Entwicklung Strategisches Management Intelligenz System 4 Operatives Management Steuerung System 3 Koordination System 2 Implementierung System 1 Projektstrukturen Kritische Erfolgsfaktoren Teamentwicklung „Kollektive Intelligenz“ Projekt-/ Umweltabgrenzung Selbstorganisation Autonomie der Subsysteme Identifikation mit dem Ganzen Frühwarnung Lebensfähigkeit Erfolgspotenziale Projektfortschritt Arbeitspaketfortschritt Phasenschema Meilensteine Arbeitspaketspezifikationen Zeithorizont Komplexität nisch, eröffnete den Workshop W5 auf dem Deutschen PM Forum 1998 in Dresden mit der Begrüßung der etwa 25 erschienenen Teilnehmer. Er stellte zunächst die Ziele und die Arbeit im Rahmen des Programmes „Neue Wege im Projektmanagement“ vor. Anschließend erläuterte Dr.-Ing. Peter M. Frieß den Teilnehmern den geplanten Ablauf des Workshops, der sich aus Input-Referat, Gruppenarbeit und deren Präsentation im Plenum zusammensetzte. Den ersten Part des Input-Referates übernahm Dipl.-Ing. Manfred Saynisch. Er zeigte auf, wie Stafford Beer das Modell lebensfähiger Systeme aus der Struktur des menschlichen Zentralnervensystems entwickelt hat, und führte die Teilnehmer damit in das Modell ein. Im zweiten Part des Input-Referates präsentierte Dipl.-Verw.-wiss. Gerhard Mekelburg die Ergebnisse des Projektes. Er erklärte zunächst das Prinzip der Lebensfähigkeit und die fünf Managementfunktionen im Modell lebensfähiger Systeme. Anschließend erläuterte er die Prinzipien der Rekursion und der Autonomie, die für das Verständnis des netzwerkartigen Aufbaus des Modells wichtig sind. Den größten Raum des Input- Referates nahm die Erklärung des von der Projektgruppe weiterentwickelten Bezugsrahmens für das Management komplexer Projekte ein. Zum Abschluss des Input-Referates wurden den Teilnehmern die vier Thesen vorgestellt, welche die Ergebnisse der Projektarbeit zusammenfassen. Nach der Vorstellung der Thesen bat Peter M. Frieß die Teilnehmer, kleine Gruppen von etwa 5 Personen zu bilden, um die Thesen zu bearbeiten. Diese Bearbeitung sollte sich an den folgenden drei Leitfragen orientieren, welche den Gruppen zusammen mit den Thesen und Antwortkärtchen ausgehändigt wurden: A) Wie könnten Sie diese Aussagen in Ihrer PM-Praxis umsetzen? B) Welche konkreten Probleme sehen Sie bei der Umsetzung? C) Was sollte darüber hinaus aus Ihrer Erfahrung bei der Anwendung des Modells lebensfähiger Systeme beachtet werden? Die folgende halbe Stunde war von teilweise sehr intensiven Diskussionen, zum Teil aber auch von einer zögerlichen Annäherung an die anspruchsvolle Aufgabenstellung geprägt, wobei die Moderatoren mal bremsend, mal erklärend und mal provozierend unterstützten. Nach Ablauf der für die Diskussion eingeplanten Zeit benannten die Gruppen jeweils einen Sprecher. Dieser stellte die Ergebnisse der Diskussion im Plenum vor und ordnete sie in die bereitstehende Auswertungsmatrix ein, in welcher die vier Thesen und die drei Leitfragen einander gegenübergestellt waren (s. Abb. 4). 4.2 Interpretation der Gruppenarbeit Bei der Präsentation der Ergebnisse der Gruppenarbeiten zeigte sich, dass sich die Gruppen vor allem auf drei Themenschwerpunkte konzentriert haben, die ihren individuellen Interessen und Erfahrungen am nächsten standen. Diese Schwerpunktbildung kann wie folgt interpretiert werden: Bei der These 1, der Gestaltung der Projektorganisation nach dem Bild der Matroschka, befürchteten die Teilnehmer wohl aufgrund ihrer Erfahrungen mit den heutigen Teilprojekten Schnittstellenprobleme, Informationsdefizite und Kompetenzgerangel. 18 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 Was ist ein „Parasympathikus“? Das menschliche Zentralnervensystem kennt drei Kanäle zur Information und Steuerung: die zentrale Befehlsachse (das somatische Prinzip, der Strang im Rückgrat), den formalen Informationsweg (den Sympathikus bzw. das sympathische System) und die informellen Kanäle, die als Parasympathikus (parasympathisches System) bezeichnet werden. Übertragen auf das Unternehmen bedeutet das: ● Die Planvorgaben laufen über das somatische System (zentrale Befehlsachse) zur operativen Ebene. ● Über den formalen Informationsweg (Sympathikus) laufen die offiziellen Informationen über die Erfüllung der Planvorgaben (meist in standardisierten Berichten). ● Über den Parasympathikus sind auch Informationen zugänglich, die in den offiziellen Berichten gar nicht enthalten sein können und die deshalb nicht zur Kenntnis genommen werden. Solche „parasympathischen“ Informationen können komplexe Situationen repräsentieren, wie zum Beispiel neuartige Entwicklungen bzw. Situationen aus der Umwelt oder Widerstand gegen Veränderungen. Der Parasympathikus ist deshalb ein wichtiges Instrument für die Bewältigung von Komplexität. Manfred Saynisch Bei der These 2, der Berücksichtigung der drei Managementebenen, kann der Eindruck entstehen, dass diese in der Praxis bereits mehr gelebt wird, als dass sie schon Niederschlag in der Theorie oder den Instrumenten des Projektmanagements gefunden hätte. Bei der These 3, der Wahrnehmung der fünf Managementfunktionen, könnte die Trennung zwischen den fünf Managementfunktionen und den bestehenden hierarchischen Positionen in den Organisationen noch zu weit von der alltäglichen Erfahrungswelt der Teilnehmer entfernt gewesen sein. Bei der These 4, dem Parasympathikus, entstand eine Diskussion über die Bedeutung der weichen Faktoren im Projektmanagement, deren Intensität zur Eröffnung einer Spalte mit freien Antworten in der Auswertungsmatrix führte. Diese vier Thesen ergänzen die 9 Thesen, die im Projekt „Systemtheorie und soziale Systeme im Projektmanagement“ erarbeitet worden sind [1]. Diese beiden Ergebnisse sind Grundlage für die Formulierung von Gestaltungsregeln für das Management komplexer Projekte. 5. FAZIT Wesentliches Ergebnis des GPM Projektes 98012 ist der Nachweis, dass die fünf Managementfunktionen des Modells lebensfähiger Systeme auf das Projektmanagement übertragen werden können. Projektleiter profitieren von der Kenntnis dieser hinreichenden wie notwendigen Funktionen des Managements komplexer Systeme in zweifacher Hinsicht: 1. Sie können Mängel im Management ihrer Projekte besser diagnostizieren. 2. Sie können derartige Mängel durch eine entsprechende Gestaltung des Projektmanagements korrigieren und zukünftig vermeiden. Ein weiteres wichtiges Ergebnis ist der Bezugsrahmen für das Management komplexer Projekte. Dieser konkretisiert zum ersten Mal die drei Managementebenen begrifflich und konzeptionell auch für das Projektmanagement, indem er diesen Ebenen bekannte Konzepte, Methoden und Tools des Projektmanagements zuordnet. Die Praxis profitiert von diesem Bezugsrahmen, indem die abstrakten Managementfunktionen und -ebenen mit den vertrauten Methoden und Instrumenten bei der Planung von Projekten berücksichtigt werden können. Und die Theorie hat schließlich einen wichtigen Ausgangspunkt für die weitere Entwicklung des Projektmanagements gewonnen. Dieser sollte ebenso wie das Prinzip des Parasympathikus, der ein wichtiges Instrument für die Bewältigung von komplexen Projekten ist, anderen umfassenden Ansätzen des Projektmanagements als Muster dienen, wie beispielsweise bei dem Konzept des Projektmanagements 2. Ordnung (PM-2). ■ Literatur [1] Saynisch, M./ Engelke, V. (Hrsg.): „Neue Wege im Projektmanagement“. Zur Gestaltung der sozialen Architektur von Projekten - Das Zusammenwirken von sozialen, Abb. 4: Die Auswertungsmatrix des Workshops 19 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - G R U N D S A T Z B E I T R A G Auswertung Gruppenarbeit These 1 Das Management soll dem Bild der Matroschka entsprechen. These 2 Das Management muss die drei Ebenen berücksichtigen These 3 Es ist entscheidend, dass die Funktionen abgestimmt wahrgenommen werden These 4 Über den Parasympathikus können wichtige Informationen gewonnen werden Freie Antworten Leitfrage A: Wie könnten Sie diese Aussagen in Ihrer PM-Praxis umsetzen? - Puppen als Ergebnisse von Phasen - Teilprojekte definieren - Informationsfluss bis zur untersten Ebene - im Bereich Raumfahrt, Wehrtechnik - wird schon umgesetzt - verschiedene Organe - Projekt sorgfältig machen - Teamkultur, Teamzusammensetzung, offene Kommunikation - Personenkreis abstimmen (Quertreiber) - Instinkt als Funktion? Als Begriff für Parasympathikus? - Parasympathikus, Plausibilitätskontrolle, „Validierung“ - Ziele Leitfrage B: Welche konkreten Probleme sehen Sie bei der Umsetzung? - Kosten für „Reusables“ - Kompetenzgerangel - fehlender Informationsfluss - Schnittstellen - Informationsverlust - Projektorganisation sorgfältig und genau strukturiert - die Leute halten sich nicht daran - Kompetenzprobleme - Informationskultur bestimmt durch formale Kultur - George Orwell,1984, Überwachung - Struktur - viele Verfahren Leitfrage C: Was sollte darüber hinaus beachtet werden? - strategische Ausrichtung - Denunziantentum angewendet ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ technischen und komplexen Systemen. In: Lange, D. (Hrsg.): Aufbruch zu neuen Ufern - innovative Konzepte erfolgreicher Projektteams. Deutsches Projektmanagement-Forum 1997. Dokumentationsband. GPM, Nürnberg 1997, S. 3-6-0-1 bis 3-6-7-11 [2] Bundschuh, M./ Hadjis, A./ Mekelburg, G./ Saynisch, M.: Neue Wege im Projektmanagement: Das Modell lebensfähiger Systeme und seine Anwendung im Projektmanagement. In: Lange, D. (Hrsg.): Deutsches Projektmanagement Forum 1998. Dokumentationsband. GPM, Nürnberg 1998, S. 225-284 Autoren Manfred Saynisch, Dipl.- Ing. Er gehört mit über 30 Jahren Erfahrung zu den Pionieren des Projekt- und Konfigurationsmanagements in Deutschland und beeinflusst auch heute noch die weitere Entwicklung. 1985 gründete er die „SPM-CONSULT - Systeme und Service im Projekt- und Prozessmanagement“. Neben der Beratung von Unternehmen und Projektorganisationen, der Konzepterstellung, der praktischen Unterstützung und der Einführung von PM und KM führt er auch Forschungstätigkeiten aus und nimmt Lehraufträge wahr. Gründungsmitglied der GPM. Gerhard Mekelburg, Dipl.- Verw.-wiss., Jg. 1963. Studium der Verwaltungswissenschaft an der Univ. Konstanz, Promotionsstudium an der Hochschule St. Gallen, Projekt-Controlling von internationalen FuE-Projekten im Anlagenbau, Hochschullehrer für Projektmanagement an der FH Vorarlberg, seit 1998 Global Project Manager für ein international tätiges Unternehmen der Verpackungsindustrie. Schwerpunkt der wissenschaftlichen Arbeit ist die Entwicklung eines integralen PM auf der Grundlage des Modells Lebensfähiger Systeme. Peter Michael Frieß, Dr.-Ing., Jg. 65. Diplomingenieur Luft- und Raumfahrttechnik. Promotion zum Dr.-Ing. an der Univ. Bremen über systemisches Organisationsprojektmanagement. Projektmanager IT und Koordinator für Kosten- und Prozessmanagement bei Philips Semiconductors, Hamburg; zuvor Beratung von Unternehmen und Behörden sowie Qualifizierung von Führungskräften in den Bereichen Organisationsgestaltung und -entwicklung, EDV-/ Telekommunikationssysteme und Projektmanagement. Assessor für den Deutschen PM-Award 1998 und 1999. Anschrift der Autoren Dipl.-Ing. M. Saynisch SPM-CONSULT Düppeler Straße 19 D-81929 München Tel.: 089/ 93 93 09 51 Fax: 089/ 93 93 09 52 E-Mail: ms.SPMC@t-online.de Das Buch zum Thema: 20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Neue Wege im Projektmanagement Herausg. von M. Saynisch und D. Lange mit Beiträgen von M. Bundschuh, N. Degele, V. Engelke, P. M. Frieß, A. Hadjis, U. Kramer, G. Mekelburg, M. Saynisch erscheint Februar 2000, ca. 200 S., DM 46,- GPM Region Stuttgart/ Karlsruhe Fax 07 11/ 6 87 39 69 Wie geht es weiter? Die an den bisherigen Forschungsarbeiten beteiligten Autoren werden ihre Arbeit im Hinblick auf den Beitrag des sozial-konstruktivistischen Projektmanagements und der Managementkybernetik für das Konzept des Projektmanagements 2. Ordnung wie auch im Hinblick auf deren Anwendung in der Praxis fortsetzen. Darüber hinaus stehen im Rahmen des Programms „Neue Wege im Projektmanagement“ folgende Themen zur Bearbeitung an: „Evolutionsprinzipien und Evolutionsdynamik im Projekt“ mit dem Kernthema „Evolutionäre Algorithmen und ihr Einsatz bei der Projektgestaltung“. Als weiterer zukünftiger Themenbereich ist beispielsweise die Auswirkung der revolutionären Erkenntnisse der Hirnforschung im jetzigen „Jahrzehnt des Gehirns“ angedacht oder die Anwendung der neuronalen Netze im Projektmanagement. Ebenso kann die Anwendung von System Dynamics im Projektmanagement oder die „Widerspruchsorientierte Projektgestaltung“ ein Thema sein. Für die Bearbeitung sind die Autoren auf Ihre aktive Hilfe angewiesen. Daher hat die GPM auf ihrer Website www.gpm-ipma.de im Bereich der Facharbeit eine eigene Webpage für das Programm „Neue Wege im Projektmanagement“ aufgebaut. Erfahrungen und Kommentare können Sie via E-Mail direkt an die Autoren schicken. Interessenten, die aktiv daran mitarbeiten oder auch einen neuen Themenkreis vorschlagen möchten, setzen sich bitte mit oben stehender Adresse in Verbindung. Zusammenfassung Ziel dieses Artikels ist es, auf Aspekte aufmerksam zu machen, die bei der Auswahl und erfolgreichen Einführung von EDV-basierten Projektmanagement- und Projektbearbeitungs-Werkzeugen wichtig sind. Eingegangen wird dabei nicht auf konkrete Produkte, sondern auf die unterschiedlichen Lösungswege der Anbieter. Anhand eines fiktiven Dialoges werden die verschiedenen Ideen und Konzepte von Anbietern vorgestellt, miteinander verglichen und bewertet. Dabei zeigt es sich, dass von Seiten der Anwender häufig technisch nicht realisierbare oder organisatorisch schwer umsetzbare Anforderungen an Systeme gestellt werden. Erst nach einem systematischen Zusammentragen der Anforderungen im Unternehmen können die verschiedenen Möglichkeiten der Systeme sinnvoll bewertet und eine geeignete Auswahl getroffen werden. Abstract The selection and successful implementation of IT-based tools for projectmanagement and project documentation need careful thinking. This article will show the different aspects which should be considered before the decision will be made. The aim is not to mention special products, but to show the different ways of the software vendors for solving the problems. Shown by a non-real dialogue the several ideas and concepts of the software vendors will be presented, compared and rated. The users ideas for system-modifications are one important aspect due to their limited ability for implementation. Mostly it’s not possible to implement them for technical or organisational reasons. Only the careful collection of the users expectations within the companies will help to rate the different systems and to prepare the best decision possible. Schlagwörter EDV-Werkzeug, Knowledge-Management, Projektbearbeitung, Projektdokumentation, Projektmanagement, Projektstrukturierung, Qualitätsmanagement, Ressourcensteuerung 1. MANAGEMENT BY PROJECTS Die projektorientierte Denkweise wird heute nicht nur in projekttypischen Umfeldern wie dem Bau- und Architekturbereich oder dem Schiffsbau angewandt, sondern hat sich auch als Instrument zur Unternehmensführung und -strukturierung etabliert. Dabei werden häufig die bisherigen matrixförmigen Organisationsstrukturen aufgebrochen und durch flache projektorientierte Strukturen ersetzt. Unter dem Schlagwort Management by Projects kommt der Kunst des Projektmanagements, also der erfolgreichen Abwicklung einer komplexen Gesamtaufgabe mit vielen Beteiligten, heute unter dem hohen wirtschaftlichen Druck und bei schwindenden Margen eine besondere wirtschaftliche Rolle zu. Das Projektmanagement kann je nach Größe des Projekts auf verschiedene Schultern verteilt werden. In Großprojekten ist eine Aufteilung auf bis zu vier Strukturebenen üblich: ● Projektlenkungsinstanz 21 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - V E R F A H R E N / K O N Z E P T E Effektive EDV-Werkzeuge für integrierte Projektbearbeitung S T E F A N F R I T Z ● Projektverfolgungsinstanz/ Projektcontrolling ● Projektkoordinator ● Projektleiter. Durch diese Struktur, die die einzelnen Projektmitarbeiter möglichst effizient zu leiten und zu unterstützen helfen soll, können in großen Organisationseinheiten zumindest einige der Arbeitsplätze der neuen schlanken Unternehmen gerettet werden. Kleinere Organisationseinheiten können durch Bündelung von Verantwortungsgebieten auf einzelne Personen schlagkräftige Projektgruppen zusammenstellen. Ziel dieses Artikels ist es nicht, diese bereits in vielen Artikeln und Büchern beschriebenen Strukturebenen weiter zu erläutern, sondern auf Aspekte aufmerksam zu machen, die bei der Auswahl und erfolgreichen Einführung von EDV-basierten Projektmanagement- und Projektbearbeitungs-Tools wichtig sind. 2. WESENTLICHE ASPEKTE FÜR EDV-LÖSUNGEN 2.1 Wer soll mit einem Projektmanagement-Werkzeug unterstützt werden? Das Ziel nahezu jedes am Markt befindlichen Softwarepaketes ist die optimale Unterstützung des Projektmanagements als Schlüssel für die erfolgreiche Projektdurchführung. Das Projektmanagement erhält umfangreiche Angaben über kritische Pfade, drohende Terminverzögerungen, bisher aufgelaufene Kosten oder den letztlich realistischen Projektendtermin (Abb. 1). Aber: Woher kommen die Informationen zur Unterstützung denn überhaupt? In der Regel kann der Projektleiter nicht der erfahrene Kapitän sein, der durch eine fünfminütige Positionsbestimmung und die schnelle Messung der Einflussfaktoren Windstärke und Windrichtung seine Kurskorrekturen vornehmen kann, um in kürzester Zeit und mit minimalem Ressourceneinsatz sein Ziel zu erreichen. In der Realität erhält der Projektleiter seine zur Positionsbestimmung erforderlichen Größen wie die Stundenaufschriebe seiner Crew, die kostenträgerbezogene Auswertung der Finanzbuchhaltung oder die zur Beurteilung des Leistungsstandes erforderlichen Projektberichte erst mit mehrwöchiger Verspätung, und er benötigt für die Datenaggregation nicht nur fünf Minuten, sondern einige Stunden. Sind diese Daten erst einmal in eines dieser hoch gelobten Werkzeuge eingegeben, so erhält der Projektleiter auf Basis des Projektstandes von vor einigen Wochen hoch präzise Szenario-Analysen und Charts für die nächsten Monate! Dies kann durch den Einsatz von Groupware-Technologien wie Lotus-Domino/ Notes oder Webbrowser-Tools geändert werden, wenn den Projektmitarbeitern Funktionen bereitgestellt werden, die eine strukturierte Informationsbeschaffung direkt an der Basis selbst ermöglichen. Diese sollten auf die Unterstützung der Arbeitsprozesse der Mitarbeiter ausgerichtet sein. Dadurch können die Informationsbeschaffungszeiten für den Projektsteuerungsprozess drastisch reduziert werden. Dies wiederum ermöglicht, eine häufigere und regelmäßigere Bestimmung des aktuellen Ist-Standes (Positionsbestimmung) ohne zusätzlichen Aufwand für das Projektmanagement zu generieren. Damit der Projektmanager zu aussagefähigen Fakten gelangen kann, müssen nicht nur die Projektmanager, sondern auch die Projektmitarbeiter leistungsstarke Arbeitsmittel an die Hand bekommen. 2.2 Strukturierte Erfassung? Mit modernen Applikationen sollte dies heute eigentlich kein Problem sein: Die Kostentreiber wie Mitarbeiterstunden und Reisekosten werden durch eine der vie- Abb. 1: Eine einfach zu formulierende Anforderung, die in der Praxis häufig schwer umzusetzen ist. Hier bieten die verschiedenen Systeme am Markt unterschiedlichen Freiraum für die Interpretation zur Umsetzung dieser Anforderung 22 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 len verfügbaren Anwendungen direkt erfasst, aggregiert und an das Zentralsystem übergeben. Grundsätzlich eine gute Idee, aber wie bewege ich Mitarbeiter dazu, Daten mit einem für sie zusätzlichen Aufwand zu erfassen, damit der Projektmanager sein Projekt besser steuern kann? Die Manager der alten Schule haben hierauf schnell eine Antwort: Die Mitarbeiter bekommen ihre Leistungen nur dann bezahlt, wenn alle Stunden und die Reisekosten ordentlich dokumentiert worden sind. Für einige Bereiche mag diese Art der Integration der Mitarbeiter ein probates Mittel sein. Die hiervon nicht Betroffenen müssen noch einen Schritt weiter denken: Wie motiviere ich Mitarbeiter dazu, Informationen strukturiert zu erfassen, damit die Mitarbeiter selbst von anderen besser gesteuert werden können? 2.3 Unterstützung der Projektbearbeitung durch Kontext-Informationen Für eine langfristige Motivation des Mitarbeiters, in ein IT-System Informationen einzuspeisen, müssen ihm Hilfsmittel an die Hand gegeben werden, die seine täglichen Arbeitsschritte erleichtern und von denen er persönlich einen Nutzen hat. Dazu gehören vor allem Kontext-Informationen wie ● sorgfältig gepflegte Adressen (die das Führen eines eigenen „richtigen“ Adressbuches überflüssig machen) ● Zugriff auf Musterdokumente (Verträge, Vorlagen, Formblätter) ● Überblick über Termine anderer Kollegen (Gruppenterminkalender) ● Integration des Qualitätshandbuches. Diese Informationsquellen können von wenigen Personen erstellt und gepflegt werden und eignen sich damit besonders bei der Einführung eines Systems, um Berührungsängste abzubauen und Benutzer zur Nutzung der neuen Werkzeuge zu bewegen. Neue Bedeutung erhält die sinnvolle Kontextverwaltung durch das Schlagwort Knowledge-Management (KM), das momentan in vieler Munde ist. Die damit verfolgten Ziele sind in Abb. 2 zusammengefasst. Sind wir damit am Ziel einer optimalen Unterstützung des Mitarbeiters mit elektronischen Werkzeugen? 2.4 Der elektronische Projektordner Nein, für die Perfektionisten und Hundertprozentigen gibt es noch eine Steigerung: die vollständige elektronische Projektdokumentation! Das Ganze scheint mit modernen Werkzeugen schnell gemacht: Eine weitere hoch integrierte Office-Lösung zur Unterstützung des täglichen Schreibaufkommens, der Dokumentation von Besprechungsprotokollen und wichtigen Anrufen muss her! (Abb. 3) Sicherlich, die Zeiterfassung muss direkt mit der Dokumentation der Besprechung möglich sein. Aber natürlich muss man Zeiten auch ohne großen Aufwand dokumentieren können, wenn man den ganzen Tag nur an einer Zeichnung oder einem Softwareprogramm gearbeitet hat. Gibt man die Zeiten in ein zentrales System ein, sieht man sie vielleicht nicht in dem elektronischen Projektordner an der entsprechenden Stelle. Wo und wie dokumentiert man, welche Stunden in Aufwandsprojekten kontrolliert bzw. schon abgerechnet sind? Wie kann man aus einem Besprechungsprotokoll die verteilten Aufgaben direkt in die persönlichen Aufgabenlisten der Mitarbeiter befördern? Wie kommt die aktuelle Projektstruktur aus dem Managementsystem in den elektronischen Ordner, damit man sehen kann, welche Vorgänge, Maßnahmen, Aktivitäten und Auf- Abb. 2: Die Verwaltung von Wissen wird sowohl innerhalb eines Projektes als auch über die Projektgrenzen hinweg für die Unternehmen immer wichtiger 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - V E R F A H R E N / K O N Z E P T E gaben schon angelaufen und abgeschlossen sind? Wo pflegt man Adressen, in einer Adressdatenbank oder in dem speziellen Projektordner? Viele Fragen und mehr als eine Antwort: Neben Detaillierungsgrad und Umfang der angebotenen Lösungen ist hier vor allem die Anpassbarkeit an unternehmensspezifische und persönliche Belange letztlich für die Qualität des Systems entscheidend! 2.5 Die persönliche Organisation Aber es sollte noch individueller gehen: Was nützen die besten Projektcontrolling-Systeme und die beste elektronische Projektdokumentation, wenn man keinen Überblick über alle Projekte hinweg auf seine persönlichen Projekttermine, seine Aufgaben und Wiedervorlagen hat? Dazu ist in der Regel die persönliche Maildatenbank bestens geeignet: Durch die entsprechenden Vorarbeiten der Marktführer Microsoft und Lotus/ IBM kann es sich eigentlich kein Software-Anbieter erlauben, die wesentlichen Funktionen eines Calendering und Schedulings noch einmal in seinem System nachzubilden, sondern muss für eine Integration mit den Standardsystemen sorgen. Zwar sind die Aufwendungen für eine totale Integration der Termin- und Aufgabenfunktionalität der persönlichen Maildatenbank in die Projektstrukturierung und -bearbeitung beachtlich, aber der Nutzen für den Anwender ist enorm. Er kann nicht nur auf ein spezielles Projekt bezogen alle Termine und Aufgaben in der Projektdatenbank für sich und alle Kollegen abrufen, sondern hat in seiner Maildatenbank seine ganz persönliche Sicht auf alle ihn betreffenden Aufgaben, Termine und Aktivitäten. Als Bonbon sollte eine vollständige Integration der Projektdaten in den Time-Planner via Organizer oder Schnittstellen zu Palm-Pilot, Psion & Co. das persönliche Bild abrunden. 2.6 Projektstrukturierung und Aufgabenverteilung Bisher haben wir den Aspekt der Projektstrukturierung mit dem Argument vernachlässigt, dass es für diesen Bereich genügend verfügbare spezialisierte Software (MS Project, CA Superproject etc.) gibt. Nach so vielen neuen Möglichkeiten und Ideen wollen wir doch einmal schauen, ob bei genügend tiefer Betrachtung nicht auch dieser Bereich noch ein paar Besonderheiten zu bieten hat: Dazu sollten wir uns einmal in die Lage des Projektleiters versetzen und uns erinnern, was seine eigentliche Kernkompetenz sein sollte: Projektmanagement ist die Kunst, eine komplexe Gesamtaufgabe in Vorgänge, Maßnahmen und Aktivitäten zu zerlegen und für diese Aufgaben Verantwortliche zu bestimmen. Mit diesem Prinzip versucht der Projektmanager eigentlich, etwas Unmögliches zu erreichen: Die Teilung von Verantwortung im Rahmen einer eigentlich hierarchischen Struktur! Die Kunst für den Projektmanager und damit auch für das unterstützende Werkzeug besteht darin, die Ebene zu bestimmen und zu unterstützen, auf der die Strukturierung des Projektmanagers aufhört und die Ebene der Selbstkoordination, Selbstorganisation oder Firmenhierarchie für eine weitere Unterteilung der Struktur sorgt. (Abb. 4) In einem integrierten Konzept gewinnt der Gedanke des Qualitätsmanagements eine neue Dimension. Das Qualitätshandbuch mit seinen unternehmens- oder bereichsspezifi- Abb. 3: Die Dokumentenlenkung kann in einer dezentralen Umgebung über ein zentrales Ablagesystem und die Versendung von Hyperlink-Verweisen auf diese Daten vereinheitlicht und vereinfacht werden 24 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 schen Verfahrensanweisungen und Checklisten kann helfen, den Strukturierungsaufwand des Projektleiters und die durch hohen Aufwand geprägte Selbstkoordination auf der untersten Ebene deutlich durch projektübergreifende Handlungsmuster zu reduzieren. Die Frage nach den Grenzen der drei Strukturierungsebenen tritt erst bei einem integrierten Projektmanagement und -bearbeitungssystem richtig zu Tage, da der Anspruch bestehen sollte, Aufgaben jeglicher Granularität vom Vorgang bis zur einfachen Aktivität in einheitlicher Form behandeln zu können. Dies ist im Hinblick auf zwei weitere Anforderungen an ein integriertes System besonders wichtig: ● die Verwirklichung einer optimalen und effektiven Ressourcenplanung, von der alle Firmenchefs und Manager träumen; ● die bereits angesprochene Integration in die persönliche Arbeitsorganisation des Mitarbeiters (Organizer). 2.7 Ressourcenplanung Aus praktischen Gründen ist es sinnvoll, zwischen zwei Aspekten der Ressourcenplanung zu unterscheiden: ● mittel- und langfristige Planung zur groben Projektplanung sowie generellen Überprüfung von Kapazitäten in Multiprojektumgebungen; ● kurzfristige Planung, um einen möglichst genauen Überblick über den Zeitraum bis zu drei Wochen zu erhalten. Die mittel- und langfristige Planung ist für den Unternehmenserfolg und die absolute Effektivität von Projekten sicherlich sehr wichtig. Allerdings entsteht hier bei einem hohen Genauigkeitsanspruch auch in einem hoch integrierten System sicherlich immer ein manueller Angleichungsaufwand für die vielen Vorgänge eines Projektes. Zwar ist die technische Berechnung auch in Multiprojektumgebungen zumindest mit einigen Systemen heute möglich, aber der enorme Pflegeaufwand wird bei der lapidaren Anforderung an eine Ressourcenplanung meist drastisch unterschätzt. Um hier den Änderungsaufwand möglichst gering zu halten und doch die langfristige Ressourcenplanung zwar in einer etwas ungenaueren Form, aber mit ausreichendem Prognoseergebnis durchführen zu können, hat sich ein Konzept mit einem zusätzlichen System zur tagesgenauen Ressourcenplanung mit einem Planungshorizont von bis zu drei Wochen als sehr effektiv herausgestellt. Damit können Projekte im aktuellen Zeithorizont mit einer hohen Genauigkeit gesteuert werden! Häufig wird nach einer Einführung beider Systeme nur das Instrument zur kurzfristigen Ressourcenplanung intensiv benutzt, da hieraus für die Kundenzufriedenheit die meisten Vorteile abzuleiten sind. 2.8 Der Kreislauf: Einbindung des persönlichen Organizers Das kurzfristige Planungsinstrument berücksichtigt sinnvollerweise auch die Aufgaben und Aktivitäten auf der Selbstkoordinierungsebene, die vom Projektmanager gar nicht bei seiner Planung berücksichtigt werden können. Das ist nur durch eine Einbindung aller beim Mitarbeiter auflaufenden Aufgaben möglich und sinnvoll. Dies bedeutet in seiner Konsequenz, dass für die kurzfristige Ressourcenplanung die persönlichen Aufgabenlisten aller Mitarbeiter ausgewertet werden müssen. Abb. 4: Jedes Unternehmen muss herausfinden, ab welcher Ebene eine Projektunterteilung durch häufig benutzte Geschäftsprozesse sinnvoll und möglich ist, und dies in der Organisationsstruktur oder dem QM-Handbuch verankern 25 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - V E R F A H R E N / K O N Z E P T E 26 P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 Projektstruktur Für viele Projekte hat sich folgende Struktur als sinnvoll und anwendbar herausgestellt: Projekt Als Projekt bezeichnen wir eine umfassende Gesamtaufgabe mit einem festen Ziel, einem definierten Anfang, einem definierten Ende sowie festgelegten oder zumindest beschränkten Ressourcen und Budgetmitteln. Multiprojekt Oberste Zuordnungsebene für komplexe und umfangreiche Projekte, wenn verschiedene Verantwortliche Teilprojekte mit hoher Eigenverantwortung führen und eine Aggregation auf höherer Ebene für ein umfassendes Controlling, eine einheitliche Terminplanung oder eine unternehmensweite Ressourcenplanung unumgänglich ist. Vorgang Ein Projekt kann hierarchisch auf mehreren Ebenen in Vorgänge strukturiert werden; eine besondere Form ist die Unterteilung in Projektphasen, wenn eine zeitlich strenge sequentielle Abarbeitung möglich ist. Zwischen den einzelnen Vorgängen lassen sich Abhängigkeiten und logische Verknüpfungen herstellen. Ein Vorgang beschreibt gegenüber dem Projekt eine abtrennbare Einheit mit Teilzielen. Einem Vorgang lässt sich eine feste Ressource zuordnen; diese Ressource kann eine einzelne Person, ein einzelnes Betriebsmittel oder im Falle einer anderen gewählten Granularität auch eine Gruppe, Abteilung oder eine ganze organisatorische Einheit sein. Maßnahmenplan In diesem Strukturgebäude nehmen wir an, dass sich in der untersten Ebene eines Vorgangs jeweils ein Vorgang genau einem Maßnahmenplan zuordnen lässt. Ein Maßnahmenplan besteht aus einer Checkliste, einem Hinweis auf ein Dokument aus einem QM-Handbuch oder einer klar verständlichen Liste von ausführbaren Aufgaben. Einem Maßnahmenplan können in gleichberechtigter Form Aufgaben oder Aktivitäten untergeordnet werden. Aktivität Die Aktivität ist eine elementare Handlung eines Mitarbeiters in seinem Arbeitsprozess. Dazu können Besprechungen/ Besprechungsprotokolle, Anrufe oder ein- und ausgehende Korrespondenzen gehören, aber auch im Unternehmen klar festgelegte elementare Geschäftsprozesse. Zur Erledigung eines Maßnahmenplans können von jedem Mitarbeiter unterschiedliche Aktivitäten erforderlich sein. Aufgabe Auch ein Aufgabendokument auf dieser Ebene beschreibt im Wesentlichen, wer bis wann und mit welchem Aufwand eine gewisse Tätigkeit zu verrichten hat. Damit unterscheidet sich die Aufgabe nur in ihrer Granularität vom Maßnahmenplan, Vorgang oder Projekt. Die Aufgabe ist damit die elementare Handlungsanweisung für eine Person. In komplexen Fällen können Aufgaben aus einzelnen Aktivitäten bestehen. Kernfrage: Bis zu welcher Ebene unterstützt der Projektmanager die Projektstrukturierung? Die Unterteilung in Vorgänge kann mit Werkzeugen wie MS Project direkt durch den Projektmanager erfolgen; die weitere Gliederung kann über ein Dokumentenmanagementsystem auch direkt durch den Projektmitarbeiter erfolgen An dieser Stelle wird deutlich, dass diese Anforderungen nur mit einem hoch integrierten System zu leisten sind und dass der Erfolg und die Genauigkeit der Aussagen immer vom schwächsten Glied in der Informationskette abhängen! 2.9 Eine Oberfläche als integrierendes System für viele Anwendungen Bei so vielen Abhängigkeiten und Anforderungen ist die Abwicklung mit einem einzigen Werkzeug oder System kaum vorstellbar. Benötigt werden hier Systeme, die es verstehen, die Integration mehrerer Applikationen unter einer Oberfläche zu erreichen. Hier sind je nach den Anforderungen an die Dezentralität Lotus Notes Domino- oder Web-basierte Integrationslösungen am Markt erhältlich. Darunter verbergen sich dann die Spezialisten für die Einzelaufgaben: ● Zur Projektstrukturierung und Struktur-Darstellung haben sich Programme wie MS Project oder CA Superproject vielfach bewährt. Entsprechende bidirektionale Schnittstellen sind von mehreren Anbietern erhältlich. ● Eine Finanzbuchhaltung gilt es bei allen Anforderungen einzubinden, bei denen auch externe Kosten berücksichtigt werden müssen. Dabei ist zu beachten, dass eine Schnittstelle oft nicht ausreicht, da Daten im Umfeld des Projektcontrolling anders bewertet werden als in der Finanzbuchhaltung. ● Bei größeren Unternehmen trifft man häufig auf SAP R/ 3- Lösungen. Je nach Anforderung sind Module wie FI oder CO zu integrieren. ● Erstaunlicherweise liegen bei den Unternehmen eine Vielzahl unternehmensrelevanter Daten in Excel-(tabellenorientierter) Form vor. Einige Skeptiker gehen davon aus, dass diese einen Prozentsatz von deutlich über 80 % ausmachen. Aus diesem Grund ist es für viele Unternehmen vorteilhaft und wichtig, wenn eine Schnittstelle von hier in das Gesamtsystem bereitgestellt werden kann. ● Neben diesen Applikationen liegen Daten häufig in SQL-Datenbanken oder anderen Systemen vor. Auch hier gibt es eine Reihe individueller Lösungen der Applikationsanbieter zur Integration. 2.10 Was bedeutet die Forderung nach einer echt dezentralen Lösung? Natürlich sollte ein integriertes System überall funktionieren: auf dem Notebook, zu Hause, am Standort in Flensburg und in Garmisch-Partenkirchen. In der Tat gibt es Hersteller, die auch hierfür eine Lösung versprechen. Aber auch auf dieser hohen Stufe gibt es genügend Fallstricke, die es zu beachten gibt: Und was ist, ● wenn eine Adresse auf einem Notebook erstellt wird und danach eine eindeutige Referenzierung in allen Projektdokumenten, dem Projektreporting und der Finanzbuchhaltung erforderlich ist? ● wenn ein Mitarbeiter, egal an welchem Standort, nur Stunden auf laufende Projekte aufschreiben soll und dabei immer auf die aktuellen Vorgänge und Maßnahmenpläne zurückgreifen muss? ● wenn Stunden, die in Flensburg erfasst worden sind, von einem Gruppenleiter in Berlin genehmigt werden sollen und in München aggregiert werden müssen? ● wenn große Dateien, die sich häufig ändern, wie z. B. CAD- Zeichnungen, an verschiedenen Orten benötigt werden, aber eine einfache Replizierung ein nicht zu vertretender Aufwand wäre? ● wenn es ein bereichs- oder kostenstellenorientiertes Projektmanagement und -controlling gibt, die Arbeitsteams also an unterschiedlichen Projekten, an unterschiedlichen Standorten und mit jeweils unterschiedlichen Projektmanagern arbeiten? Wie kann sichergestellt werden, dass jeder Mitarbeiter trotzdem seine individuelle Sicht auf „seine“ Projekte erhält und trotzdem alle projektrelevanten Informationen auf seinem Notebook führen kann? Das sind sicherlich keine abwegigen Beispiele. Sie eignen sich hervorragend als Prüfsteine, an denen man messen kann, ob sich ein Entwicklerteam Gedanken über den praktischen Einsatz seiner Software gemacht hat. 3. PASSENDE UND AUSGEWOGENE LÖSUNGEN ALS ZIEL Das Reizvolle für einen Systemanbieter an dem Ziel, ein integriertes Projektmanagement- und -bear- 27 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - V E R F A H R E N / K O N Z E P T E beitungssystem als universelles Werkzeug zu schaffen, ist es, die verschiedenen Aspekte mit einem Konzept in möglichst ausgewogener Form zusammenzufassen. Dabei sollte ein einheitliches Werkzeug für alle drei an einem Projekt beteiligten Ebenen entstehen: ● Manager, ● Projektleiter, ● Mitarbeiter. Diese drei Personengruppen sollten von der Planung des Projektes über die Projektstrukturierung, die Projektbearbeitung bis hin zum Projektmanagement und dem Projektcontrolling in ihren jeweiligen individuellen Tätigkeitsbereichen unterstützt werden. Hilfreich für einen Anbieter ist es, etwas über die Projektbearbeitungsstruktur im anfragenden Unternehmen zu erfahren. Dazu gehören neben den statistischen Angaben wie durchschnittliche Projektgröße, Anzahl der Projekte pro Jahr und Anzahl der zu steuernden Ressourcen auch Informationen zu den Zielen, die durch ein Projektmanagement- und Bearbeitungswerkzeug erreicht werden sollen. Die schriftliche Fixierung der Anforderungen an ein solches System dient nicht nur dem Anbieter, sondern auch dem Anfragenden zur Orientierung. Häufig sind die Anforderungen der einzelnen Bereiche oder Abteilungen nicht auf wenigen Blättern zusammenzufassen. Neben den Systemeigenschaften wie verwendetes Datenbanksystem und Programmiersprache können, sollten die benötigten Merkmale und deren Ausprägung mit einem Fragebogen bei den Anbietern abgefragt werden: ● Korrespondenzbearbeitung und Adressverwaltung ● Elektronischer Projektordner ● Terminplanung für Personen und Gruppen ● Einbindung in persönliche Organisationswerkzeuge ● Unterstützung bei der Projektstrukturierung ● Ressourcensteuerung ● Zeiterfassung, Leistungsabrechnung sowie Leistungsdokumentation ● Berichtswesen und Kennzahlensystematik ● Integration in Helpdesksysteme (optional für Softwarehersteller). Die meisten am Markt befindlichen Softwaresysteme lassen sich nicht nach absoluten Qualitätskriterien beurteilen. Wichtig ist ihre auf den jeweiligen Zweck abgestimmte Brauchbarkeit. Denn das Wesentliche hinter dem System ist die Philosophie - und die muss zu Ihrem Unternehmen und zu Ihren Anforderungen passen! ■ Autor Dipl.-Phys. Stefan Fritz, Studium der Physik an der RWTH Aachen. Danach Leiter der EDV-Abteilung eines Planungsbüros. Dort u. a. zuständig für die EDV-Unterstützung des Projektmanagements von Großprojekten und die Planung von großflächigen Netzwerken. Seit Sommer 1993 geschäftsführender Gesellschafter der synaix - Gesellschaft für angewandte Informationstechnologien mbH. Tätigkeitsschwerpunkte sind die Konzeption und Einführung von unternehmensweiten Workgroup-Computing-Systemen zur Unterstützung von Projektmanagementabläufen, Controllingfunktionen und QM- Systemen zur Vorgangsbearbeitung. Anschrift synaix Gesellschaft für angewandte Informations-Technologien mbH Brüsseler Ring 67 D-52072 Aachen Tel.: 02 41 / 70 10 31-0 Fax: 02 41/ 70 10 31-66 E-Mail: sfritz@synaix.de 28 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Zusammenfassung Der Beitrag spiegelt die umfangreichen Erfahrungen mit der Einführung und dem Einsatz von KM-Systemen im Unternehmen wider. Die wesentlichen primären Anforderungen an ein KM werden inklusive der Lösungen dargestellt und begründet. Zusätzliche Aussagen über die Leistungsfähigkeit und Funktionalität eines KM sowie auch die damit verbundenen Prozess- und Qualitätsverbesserungen werden aufgezeigt. Das Ergebnis daraus ist eine Steigerung der Effektivität und der Wettbewerbsfähigkeit. Ein hoher Stellenwert ergibt sich auch durch die Vergleiche zwischen Aufwänden und Vorteilen in der Produktentwicklung und der Fertigung. Gestützt auf Erfahrungen wird vom Einsparungspotential (Kosten und Personal) der hohe Wirkungsgrad des Einsatzes eines KM abgeleitet. Eine vorgeschlagene praxisorientierte Einführungsstrategie soll zu einer kurzfristigen Einführung eines KM mit hoher Akzeptanz in Unternehmen/ Projekten führen. Die wesentlichen Aspekte des Themas sind mit Beispielen, Statistiken, Gegenüberstellungen von Vor- und Nachteilen im Detail und im Gesamten praxisnah und umfassend beschrieben. Abstract This present contribution reflects the extensive experiences with the introduction/ implementation of Configuration Management (CM) systems in the company. The essential primary requirements on a CM are represented and established including solutions. Additional statements about the capability and functionality of a CM as well as the process and quality improvements combined with it are shown. The result is an increase of the effectiveness and of the competitiveness. A high significance also results through the arrangements between expenditures and advantages in the product development and/ or in manufacturing. Supported by experiences the high efficacy for use of CM is derived from the saving potential (costs and personnel). A proposed practical introductory strategy should lead to a short-run introduction of a CM with high acceptance of company/ projects. The essential subjects are described practically and comprehensively with examples, statistics, comparisons of advantages and disadvantages, of partial and total aspects. Schlagwörter Hardwareentwicklung, Konfigurationsmanagement, Lebenszyklus, Produktentwicklung, Qualitätsmanagement, Softwareentwicklung, Telekommunikationsindustrie I n der Siemens AG, im ehemaligen Bereich Private Communication Networks (ex PN), wurde die Bedeutung eines effektiven EDM/ PDM mit einem KM frühzeitig erkannt und sukzessive realisiert. Als Ausgangslage gab es im BS2000 eine Vielzahl von Tools, Verfahren mit Prebzw. Postprozessoren teilweise kommunizierend über Schnittstellen, die in Summe eine Funktionalität im Sinne eines Konfigurationsmanagements ergaben. Der Auftrag, ein neues KM-System einzuführen und damit die Ablösung von BS2000-basierenden Systemen auf Unix zu erreichen, bezog sich ausschließlich auf die Hard-/ Firm-/ Loadware-Entwicklung im genannten Bereich. Auf der Basis des KM-Produkts DMS/ PIMS von Sherpa und mit aufwendigem Customizing wurde eine KM-Applikation entwickelt und in unser Information Management System (IMS von ex PN) integriert. 29 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - M E T H O D E N / I N S T R U M E N T E Konfigurationsmanagement in der HW-/ SW-Entwicklung und -Produktion für Produkte der Telekommunikation U D O L E M K E In der Vergangenheit entsprachen die auf dem freien Markt angebotenen KM-Systeme bei weitem nicht unseren Anforderungen. Aus diesem Grund setzten sich überall in den Bereichen eigenentwickelte Lösungen durch. Erst in den letzten Jahren hat sich die Situation wesentlich gewandelt. Die Leistungsfähigkeit und Flexibilität der angebotenen KM-Systeme führender Hersteller haben sich wesentlich verbessert, so dass allgemeine Standardfunktionalität inklusive benutzerfreundlicher Benutzeroberflächen verfügbar ist. Dieser Fortschritt wirkt sich insbesondere positiv auf die Anschaffungskosten (Produkt plus relativ geringem Customizing) und durch die schnellere Einsatzfähigkeit eines neuen KM- Systems aus. Wie aus Presseberichten bekannt wurde, führte die Siemens AG in 10/ 98 eine umfangreiche Umstrukturierung durch. Es wurde u. a. der Geschäftsbereich ICN (Information and Communication Networks) aus den ehemaligen Bereichen ÖN (Öffentliche Kommunikationssysteme) und PN gegründet. Dieser neu gegründete Geschäftsbereich gliedert sich in viele Geschäftsgebiete. Eines davon ist CM (Manufacturing Center) in der bewährten Kombination der zusammengelegten Hardware- Entwicklung und Fertigung. Hier werden u. a. die Netzwerk-Produkte HICOM (Kommunikationssystem) vom Prototyp bis zur Serienreife entwickelt und in dazugehörigen Fertigungen produziert, einschließlich der Fertigungskompetenz für EWSD (Digitales Vermittlungssystem). Einer der Hauptgründe zur Aufstellung von ICN ist in der Nutzung des Synergie-Potenzials zu sehen. Diese Herausforderung gilt auch für die Themen EDM (Electronic Data Management) und PDM (Product Data Management) und damit auch für das KM in diesem Geschäftsbereich/ diesen Geschäftsgebieten. Als ein erfolgreicher Wettbewerber strebt ICN CM künftig an, eine homogene Toolkette einzusetzen, um Wettbewerbsvorteile durch nahtloses Kommunizieren zu verbessern. Eine wirtschaftliche Weiterentwicklung/ Pflege der anzupassenden Software-Komponenten innerhalb eines jeden Bereichs (worst case) ist nicht mehr vertretbar. Hierzu soll ein effektives, möglichst einheitliches KM-System für einen umfangreicheren Breiteneinsatz realisiert werden und seinen Beitrag zur Verbesserung der Marktposition leisten. 1. KONFIGURATIONSMANAGEMENT (KM) Die primäre Aufgabe des KM ist, Ordnung und Eindeutigkeit bei den Ergebnissen aus der Entwicklung (z. B. Design-, Produkt- und Logistikdaten) zu erreichen und dauerhaft zu gewährleisten sowie bedarfsgerecht zu kommunizieren. Für den folgenden Text wird KM definiert: ● KM ist eine Methodik zur Steuerung von Entwicklungsvorhaben, Produktion und Service. ● KM betrachtet Entwicklungsvorhaben als eine Folge von kontrollierten Änderungen an gesicherten Zwischen- und Endergebnissen. Außerdem leistet es seinen Beitrag zu den tangierenden Themen der Qualitätssicherung, ● für die KM dazu eine gesicherte Informations- und Datenbasis bereitstellt, und zur Wertkostenanalyse, für die das KM einen idealen Ansatz für die Änderungssteuerung bietet, weil das Änderungsgeschehen sehr präzise unter Kostendenken zu steuern ist. Insgesamt ist das KM eine zentrale Drehscheibe sämtlicher Informationen/ Daten des Entwicklungs-, Änderungs- und Produktionsprozesses mit entsprechender Transparenz und einer detaillierten Steuerung/ Ergebniskontrolle. Aus der automatischen Ableitung von Entwicklungsergebnissen bzw. mit manueller Ergänzung beschreibt das KM versionsgenaue, freigegebene Konfigurationen als Strukturen mit den zugehörigen Objekten (z. B. Konstruktionselemente, Baugruppen, Bauelemente, Firmware, Loadware) für die Entwicklung, Fertigung und den Service. Jedes Konfigurationsobjekt besitzt Attribute und muss durch Name-Typ-Version eindeutig identifiziert sein. Für den Einsatz beim Service sind zusätzlich Alternativ-Konfigurationen mit funktional gleichwertigen, ohne Risiko austauschbaren Objektversionen enthalten. Alle Entwicklungsergebnisse (Konfigurationsobjekt) sind über den gesamten Lebenszyklus eines Produktes eindeutig identifiziert und verfügbar. Die Konfiguration als zentrales Objekt eines KM leistet einen erheb- 30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 lichen Beitrag zur allgemeinen Problemlösung (Abb. 1). Um die Abdeckung der heutigen Anforderungen bzw. derjenigen in naher Zukunft zu erreichen, ist ein offenes KM-System mit integrierten Tools und einheitlicher Benutzeroberfläche, integriert in ein homogenes Information Management System, anzustreben. Dabei sind Checkout- und Checkin-Funktionen, automatische/ manuelle Versionierung sowie ein überschaubares, wirkungsvolles Workflow Management zur Steuerung von Abstimmungs- und Freigabeprozessen unabdingbar. Es hat die weltweite HW-Planung inklusive der hardwarenahen Software (Firmware, Loadware), Entwicklung und Fertigung aktiv und passiv unter Beteiligung eines gekoppelten elektronischen Archivsystems zu unterstützen (Abb. 2). Sie beinhaltet alle Objekte (versionsgenau) zur Produktion eines Systems einer bestimmten Version. Eine Konfiguration dient als Basis für den weltweiten HW-/ SW-Entwicklungs- und Release-Prozess. Jeder zugriffsberechtigte Entwickler (entsprechend seiner Rolle) eines Objektes (z. B. Baugruppe oder Konstruktion) weiß bei Änderungen, wer betroffen ist, was zu tun ist, welche Bauelemente (z. B. Chips) betroffen sind und zu welcher geplanten Systemversion die Änderung gehört. Alle sind auf dem gleichen Informationsniveau. Ein integrierter Workflow und eine standardisierte Schnittstelle zu tangierenden Systemen unterstützen die Prozessabwicklung, wobei ergebnisorientiert E-Mails an bestimmte Empfängerkreise versendet werden (Abb. 3). Das KM-System muss multiuserfähig sein, um u. a. wirkungsvoll das Concurrent Engineering zu unterstützen. Ein einfaches Navigieren (top down/ bottom up) in den Strukturen (über alle Hierarchiestufen) der Konfigurationen ist uner- Abb. 1: Konfigurationen lösen Probleme 31 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - M E T H O D E N / I N S T R U M E N T E Abb. 2: Prinzipieller Entwicklungsprozess Abb. 3: Konfiguration im Entwicklungsprozess lässlich. Für den Development Design Process werden vom Design Process Support die benötigten Basisdaten dem Entwickler in seinem Directory zur Verfügung gestellt. Das elektronische Archiv archiviert und verwaltet alle Entwicklungsergebnisse, Metadaten und Quelldaten/ Produktdaten und führt einen Historiennachweis bei Bedarf objektbezogen für alle Änderungen während des Lebenszyklus aller HW-Projekte durch (Abb. 4). Es wird überall weltweit allen Entwicklern und Fertigungsstätten (Berechtigung vorausgesetzt) ein gleichzeitiger Zugriff auf alle Objekte gewährt. Über eine Abonnement- Funktion wird eine optimierte Verteilung erzielt. Der Zugriff erfolgt mittels SUNs, HPs oder PCs. Es gibt Schnittstellen zu den wesentlichen Entwicklungstools, z. B. Mentor, IDEAS, HICIS (HICOM Component Information System, enthält alle Daten der Bauelemente inklusive Zulassungsprüfung), ARCIS, AVV (Archivierung & Versorgung Volldigital), E-Mail, SAP R/ 3 und zur zentralen Mitarbeiterdatenhaltung (mit Namen, Dienststelle, Telefonnummer, Fax, E-Mail-Adresse usw.). 2. ZIELSETZUNG BEI SIEMENS Es galt, eine Anzahl an bestehenden KM-Systemen (Altsystemen), überwiegend Eigenentwicklungen, zu eliminieren. Jederzeit sollte ein Austausch von übergreifenden Informationen und Daten (auch aus anderen Bereichen) möglich sein. Die Gewährleistung der Y2K-Konformität war unabdingbar. Die technische Integration von neuen Tools des Marktes im Rahmen von EDM/ PDM und die damit verbundene Lösung des Problems, auf kurzfristige Prozessveränderungen mit teilweise unzureichender Prozesssteuerung bzw. Workflow-Unterstützung in den Projekten und in der Zusammenarbeit mit anderen Bereichen bzw. kooperierenden Firmen agieren bzw. reagieren zu können, ist zwingend nötig. Künftig sind die Entwicklungsergebnisse der Telekommunikation noch schneller zur Serienfreigabe neuer Produkte und Systeme zu führen und gleichzeitig ist die Qualitätssicherung für ein fertigungsgerechteres Design sowie erhebliche Kosteneinsparungen zu garantieren. Die Zusammenarbeit zwischen Entwicklung und Fertigung ist noch wirkungsvoller zu unterstützen und eine Produktunabhängigkeit zu gewährleisten. Ziele und Wirkungen KM ist ein unabdingbarer Bestandteil eines EDM-/ PDM-Systems ● Ordnung schaffen und halten mit Konfigurationen und versionierten Objekten im komplexen Umfeld ● Eindeutige Definition von Konfigurations-Objekten unter Berücksichtigung von Versionen, Varianten usw. mit nachvollziehbarer Historienführung ● Globale, schnelle und exakte Info-Basis für Planung, Kalkulation, Entwicklung, Produktion und Service Abb. 4: Objekte und Informationen 32 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 Abb. 5: Integration im Systemverbund Wichtig: Ein neues CM muss reibungslos zum richtigen Zeitpunkt im Einsatz sein! Die Lösung liegt in der Gewährleistung eines praxisgerechten Miteinanders von unterschiedlichen Tools, wobei deren Outputs untereinander zu verarbeiten sind (Abb. 5). Bei der Realisierung eines neuen KM-Systems ist das Optimum an Funktionalität und Automatisierung von Prozessunterstützungen aufgrund aller Anforderungen und Wünsche der künftigen Anwender anzustreben. Sie darf aber nicht zu kostenintensiv sein, und das KM- System darf im Einsatz aufgrund seiner Anwendungskomplexität nicht insgesamt zu schwerfällig werden. Prinzipiell sollte sich ein neues KM-System in die bestehenden und bewährten Prozesse eingliedern. Andererseits sollte aber die Anpassung der Prozesse an das neue KM- System nach Abwägen von Kosten/ Nutzen kein Tabu sein. Manuelle Eingriffe in KM-Ergebnisse sollten minimiert werden, aber unbedingt für Sonderfälle möglich sein. Ergebnisorientierte Informationen via Mailsystem, gezielt an Einzel-/ Gruppenempfänger, sind erforderlich. Intelligente Schnittstellen (teilweise bidirektional) müssen zu den CAx-Systemen vorhanden sein. Um ein neues KM mit seiner komplexen Funktionalität und Wirkung einzuführen, ist dies als Projekt mit breiter Zustimmung der Entscheidungsträger, geklärtem Budget und Ressourcen zu führen. Ansonsten wird der Erfolg kaum, verzögert oder nie eintreten. Das Projekt zur Entwicklung und Einführung ist im klassischen Stil mit Lenkungskreis, Projektleitung, Definitionsteam, Realisierungsteam und Akzeptanzmanagement einzurichten. Die Realisierung basiert auf den Rahmenbedingungen des Projektmanagements, entsprechend dem HW-Entwicklungshandbuch mit seinen Prozessbeschreibungen und Regeln. Die Ablösung mehrerer historisch gewachsener Alt-KM-Systeme bedingt aber auch das Berücksichtigen bestehender Produktdaten aus diesen Systemen. Migration der Altbestände ist aufgrund von Reparaturverpflichtungen und juristischer Aufbewahrungs- und Nachweisverpflichtung erforderlich. Eine Ablösungsstrategie ist erforderlich. 3. PROJEKTANFORDERUNGEN IM BEREICH ICN CM Nachfolgend sind nur die allgemein interessierenden Key-Requirements aufgeführt. ● Unterstützung des Entwicklungs- und Fertigungsprozesses zur Steigerung der Wettbewerbsfähigkeit. Das KM in seiner strategischen Position hat dafür zu sorgen, dass von der Produktidee bis zum Produktende ein lückenloses, transparentes, offenes und flexibles System inklusive der Archivierung zur Verfügung steht ● Unterstützung beim Wechsel vom funktionszum prozessorientierten Vorgehen ● Keine Einschränkungen bei den gängigen Objekttypen, z. B. Dokument, Daten, und ihren Formaten, z. B. Word, Frame- Maker, ASCII, TIFF usw. ● Absolute Eindeutigkeit für jedes Objekt in Name-Typ-Version ● Ständige Verfügbarkeit sämtlicher Objekte mit notwendigem Zugriffsschutz ● Visualisieren, Ausdrucken und Verändern von Konfigurationsstrukturen ● Flexible Systemstruktur, um auf Innovationszyklen bei der Produktstruktur und dem Entstehungsprozess reagieren zu können ● Unabhängige Hardware-Plattform (Unix/ Windows NT) inklusive Client-Server ● Integration einer relationalen/ objektorientierten Datenbank ● Um den Ansprüchen eines weltweit agierenden Unternehmens gerecht zu werden, ist die Infrastruktur durch ein wirkungsvolles Server-Konzept mit verteilten Datenbanken (z. B. Oracle) inklusive Replikationsfunktion zu ergänzen. Durchführen synchroner (ergebnisorientiert, sofort)/ asynchroner (in regelmäßigen Zeitabständen) Upgrades ● Eigene temporäre Datenhaltung mit gekoppeltem Kurz- und Langzeitarchiv ● Standort-Server sollten entweder stets mit allen benötigten Objekten 1 : 1 automatisch geladen oder bedarfsorientiert vom Master-Server upgedatet werden ● Bei der Infrastruktur ist aus Sicherheitsgründen an einem weiteren Standort ein aktuelles Spiegel-Archiv (Backup-System) zu installieren 33 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - M E T H O D E N / I N S T R U M E N T E ● Eine optimale, mehrsprachige (einstellbar), einheitlich durchgängige, anwenderfreundliche Benutzeroberfläche mit Icons, Menüs und Help-Buttons ● Kopplung an das weltweite Siemens Intranet zur schnellen und einfachen Datengenerierung/ Verteilung unter Verwendung von Netscape und MS Explorer ● Der Datenaustausch (teilweise bidirektional) hat über zertifizierte, bidirektionale Schnittstellen zwischen verschiedenen Systemen in der Entwicklung, z. B. Mentor, SDRC (IDEAS), ClearCase, sowie SAP R/ 3 in der Fertigung stattzufinden ● Ein flexibles Berechtigungskonzept (produkt-/ projektorientiert) inklusive Rollenvergabe ● Performanter Daten-Highway und Server der kommunizierenden Entwicklungs- und Fertigungsorte ● Unterstützung von Upgrades des KM-Systems durch einfache Skripts, Setup-Files in der Konfigurierung/ Installation ● Toolunterstützte Migration mit manueller Eingriffsmöglichkeit für „Altlasten“ ● Recherchemöglichkeiten nach sämtlichen Attributen und innerhalb von Textbereichen der Objekte sowie deren Ausgabe sind erforderlich ● Differenzanalyse zwischen zwei beliebigen Objekten muss möglich sein ● Generell ist ein einheitliches KM-System anzustreben, aber nicht mit der höchsten Priorität durchzusetzen (Optimierung von Aufwand und Nutzen) 4. REALISIERUNGS-, BEREIT- STELLUNGS- UND AKZEPTANZPHASE DES KM In der Vorphase zur Realisierung eines KM-Systems (Soll-Architektur) wurden weitest gehend Synergien genutzt. Das heißt, es wurde eine Bestandsaufnahme der am Markt angebotenen KM-Systeme verschiedener Hersteller durchgeführt und darüber hinaus die Erfahrungen anderer Bereiche analysiert. Projektablauf ● Einhaltung der klassischen Phasen (Definition, Planung, Realisierung, Einführung) ● Phasen-Unterstützung durch Experten-Teams ● Voraussetzung sind auch Sponsoren, die hinter dem Projekt stehen und es „vorantreiben“ ● Regelmäßige Projektberichterstattung an „alle“ über Fortschritt, Probleme und Maßnahmen ● Wichtig: Vereinbarungen jeglicher Art sind von allen Beteiligten strikt einzuhalten! Planungsphase des Projektes KM ● Angebots- und Nachfrage-Analyse ● Requirements ● Synergien nutzen ● Akzeptanz und Motivation prüfen ● Kosten/ Nutzen feststellen ● Migration vorhandener Daten klären ● Bedingungen klären, z. B. Sponsoren, Budget, Einsatztermin, Manpower ● Leistungsmerkmale definieren ● Meilensteinplanung Wir entschieden uns zunächst für die Zusammenarbeit mit Sherpa und dem Produkt DMS/ PIMS. In einer Spezifikation wurden alle Anforderungen gemeinsam mit den künftigen Anwendervertretern und von Sherpa festgelegt. Realisierungsphase ● Stets abgeschlossene Teilfunktionen den Usern übergeben (Akzeptanzförderung und Früherkennung von Missverständnissen) ● Änderungen an den definierten Vorgaben in spätere Steps legen ● Rapid Prototyping ● Bei der Software-Entwicklung sind kritische Programmierungstechniken zu vermeiden ● Usergruppen sind in den Prozess zu integrieren Akzeptanzphase ● Schulungen professionell durchführen ● Ausbildung (Schneeballsystem) hat sich bewährt ● Rechtzeitige elektronische Help- Unterstützung ● Cookbooks für Ersteinsteiger vermindern die „Schwellenangst“ ● Auf die kleinen Probleme der User eingehen, aber nicht die Zielvereinbarung verlassen Ein Schwerpunktthema neben den allgemeinen KM-Anforderungen waren das Bestimmen des Datenmodells, der Produktstruktur und das Festlegen des Datenmigrationskonzepts. Die Entwicklung des neuen KM wurde in verschiedenen Arbeitspaketen realisiert. Hierbei erfolgte eine Arbeitsteilung zwischen Abteilungsentwicklungen und dem Customizing durch den externen Hersteller. Um den Anwendern das künftige KM-System 34 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 näher zu bringen, wurden frühzeitig und sukzessive fertig gestellte Abschnitte vorgestellt und teilweise zum Piloteinsatz freigegeben. Parallel wurde die Voraussetzung für die umfangreiche Migration der Altdaten aus dem abzulösenden System realisiert und durch Testläufe erprobt. Hierbei ist das neue KM- System der Master und das Altsystem fungiert als Slave. Aus der Sicht des KM waren die erzielten technischen Ergebnisse bezüglich Funktionalität positiv. Eine verzögerte Weiterentwicklung ergab sich durch ständig neue Anforderungen und Prioritätsänderungen. Daraus resultierte, dass wir bei einigen Funktionen an die Grenzbereiche der Systemflexibilität des Herstellerproduktes stießen. Lösungen konnten nur teilweise durch erheblichen Zusatzaufwand erstellt werden. Aufgrund der sich abzeichnenden, umfangreichen organisatorischen Veränderungen in der Siemens AG wurde u. a. dieses Projekt gestoppt. Hinzu kam die Entscheidung, die Altsysteme im BS2000 aus Sicherheitsgründen doch Y2Kfähig zu machen. Ab jetzt galt es übergeordnete Zielvorgaben, nämlich Synergien aus den organisatorischen Veränderungen, zu erzielen. Wir streben an, ein weitgehend einheitliches KM- System zu realisieren für den Einsatz bei ICN insgesamt. 5. DIE INTEGRATION VERSCHIEDENER KM-SYSTEME IM ENTWICKLUNGS- UND PRODUKTIONSPROZESS Im Laufe der Zeit haben sich KM- Systeme aus der Anfangsphase im BS2000 und später unter Unix bewährt. Diese Systeme sind Eigenentwicklungen und wurden nach den Anforderungen sukzessive entwickelt. Hierbei handelt es sich um die Systeme TGD (Technische Grunddaten), KONVIS (Konfigurations-Verwaltungs- und Informationssystem) und IMS (Information Management System). Unter dem IMS wurde ein übergeordnetes System realisiert, mit dessen Hilfe auch Schnittstellen zu den zuvor genannten bestehen. Somit haben wir in der Entwicklung eine Plattform geschaffen, mit der das KM wirkungsvoll unterstützt und durchgeführt werden kann. Über eine einzige Schnittstelle (MRIF = Manufacturing Reelles Interface) werden die Fabriken mit den Entwicklungsergebnissen versorgt. Aufgrund der Konfigurationslisten werden die Logistik und die Fertigung versorgt. Die Daten finden Aufnahme im SAP-System. 6. DAS KONZEPT UND SEINE EVOLUTION BEI ICN CM Die im Einsatz befindlichen Systeme sind als Applikationen im Verbund mit IMS integriert (Abb. 6). Damit haben wir eine ständige Transparenz aller Objekte und ihrer Attribute erreicht. Konfigurations-Objekte ● Objekte, z. B.: Konstruktionszeichnungen, Change Notice, Stücklisten, Service-Listen, Stromlaufpläne, Bauschaltpläne, Mentor Design Tree, SDRC- (IDEAS-)Tree, Spezifikationen, Bibliotheksdaten ● Formate, z. B.: Word, Frame- Maker, PowerPoint, Tiff, ASCII, PDF, Bitmap, HTML, Calcomp Die Prozesse werden optimaler unterstützt, und der Einsatz eines Workflow (Change Notice) erhöht erheblich die Qualitätssicherung. Der Transfer von Ergebnissen erfolgt stets kurzfristig auf elektronischem Weg. Die Bereitstellung von freigegebenen Konfigurationen erfolgt heute fast auf Knopfdruck. Alle diese erreichten Ergebnisse führten sukzessive zu erheblichen Verbesserungen und Kostenreduktionen. Abb. 6: Konzept 35 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - M E T H O D E N / I N S T R U M E N T E Verbesserungen ● Kürzere Bereitstell- und Durchlaufzeiten ● Qualitätssteigerung, stets eindeutige „Originale“ ● Time to Market ● Transparente und kostengünstigere Prozesse ● Effektivere weltweite Produktionsvorbereitung (Logistik) und Entwicklung, weniger Manpower ● Unterstützung der Standardisierung in der HW/ SW ● Entscheidungshilfe für Planung, Entwicklung … ● Basis für Innovationen Kostenreduktion ● Kaum noch Papiertransfer, d. h. nur noch minimale zusätzliche Kopie-/ Verteilungskosten ● Rechtzeitige und komplette Bereitstellung aller Produktunterlagen für die Fabrik, minimierte Wartezeiten, Recherchierzeiten ● Logistik ist jetzt frühzeitiger involviert und basiert auf verlässlichen Werten, dadurch wesentlich verbessertes Time-to-Market-Verhalten ● Qualitätsverbesserungen durch exakte Bestimmung der Produktunterlagen, dadurch erheblich verminderte Fehlerschleifenanzahl ● Vermeidung von Produktionsengpässen, da im Bedarfsfall jeder Produktionsstandort sofort auf alle notwendigen Produktunterlagen zugreifen kann, keine teuren Überstunden und Einhaltung der Liefervereinbarungen ● Verteilungsaufwand von Teil-/ Endergebnissen an arbeitsteilende Entwicklungsstandorte entfällt, dadurch verminderte Entwicklungskosten 7. ERFAHRUNGEN UND AUSBLICK Wichtig für die Bereitstellung eines neuen KM-Systems ist der richtige Zeitpunkt, nicht zu früh und nicht zu spät. Die Definitionsphase sollte nicht zu lange dauern, sie ist zeit- und kostenintensiv und birgt die Gefahr in sich, immer neue Anforderungen zu finden. Bei einer komplexen Toolentwicklung wie der eines KM-Systems ist ein Mittelweg zwischen einer konservativen Entwicklung (ausgehend von einer präzisen Spezifizierung aller Details mit den künftigen Anwendervertretern) und einem reinen Rapid Prototyping ein guter Lösungsweg mit kürzerer Entwicklungszeit. Es sollte mit den heute am Markt angebotenen KM-Systemen möglich sein, mit einem geringen Customizing auszukommen. Darüber hinaus ist zu versuchen, dieses vom Hersteller realisieren zu Abb. 7: KM-Entwicklungs-Erfahrungen 36 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 Abb. 8: Konzept des neuen KM-Systems lassen und sukzessive in die Kern- Software zu integrieren. Dies spart künftige Probleme beim Versionswechsel (Upgrades, Schnittstellenänderungen) usw. (Abb. 7 und 8). Wir setzen unser Projekt unter den geänderten Rahmenbedingungen fort, um ein neues KM-System zu realisieren. Die bisherigen Erfahrungen sind hierbei von großem Nutzen. Um eine breitere Akzeptanz, d. h. über den bisherigen Organisationsbereich hinaus, zu erreichen, führt dies zum Wechsel des Herstellers. Aufgrund der umfangreichen Zusammenarbeit zwischen der Siemens AG und der Eigner & Partner AG bezüglich des Produkts CADIM ist dies als eine neue Ausgangsbasis unter Nutzung bisheriger Realisierungsergebnisse geplant. Ein wesentliches Argument für die Wahl dieses Produkts war neben der Leistungsfähigkeit, der Funktionalität und dem hohen Abdeckungsgrad der benötigten Anforderungen der Einsatz/ die Zusammenarbeit in ca. 30 Projekten. Wir sind zuversichtlich, damit eine gute Ausgangslage für die Akzeptanz im Breiteneinsatz zu schaffen. Für die FW/ LW werden wir weiterhin ClearCase nutzen, und für Dokumente werden wir NetInfo mit dem Produkt Hyperwave einsetzen. Ausblick Von der Idee bis zur Produktion eines neuen Produkts benötigen wir künftig noch kürzere Durchlaufzeiten auf allen Ebenen. Anforderungen für ein zukünftiges integriertes KM: ● 100%ige Digitalisierung ● eine Vervielfachung der Netzwerk-Leistungsfähigkeit ● mehr Standardisierung für einen transnationalen Einsatz; aber ausreichende Flexibilität ● direkte Einbindung in den Workflow ● Zugang über das Intranet ● virtuelle Entwicklungsunterstützung ■ Autor Dipl.-Wirtsch.-Ing. Udo Lemke, Manager für Toolstrategy in der Siemens AG in München, im Geschäftsbereich Information & Communication Networks (ICN CM) für Telekommunikation im Geschäftszweig Manufacturing Center. Zuständig im Hardware-/ Firmware-/ Loadware-Entwicklungsbereich für EDM/ PDM inklusive der tangierenden Tools und Verfahren. Anschrift Siemens AG Abt. ICN WN ES HW 410 Hofmannstraße 51 D-81359 München Tel.: 089/ 7 22-3 70 95 Fax: 089/ 7 22-3 29 77 37 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - M E T H O D E N / I N S T R U M E N T E ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ KM im Hause Siemens Der Beitrag in diesem Heft von Dipl.- Wirtsch.-Ing. Udo Lemke „Einsatz des Konfigurationsmanagements bei der HW-/ SW-Entwicklung und Produktion für Produkte der Telekommunikation“ basiert auf seinem Vortrag, den er bei der 3. Fachtagung zum Konfigurationsmanagement „Änderungsmanagement mit System - Schlüsselfaktor Konfigurationsmanagement“ gehalten hat. Er schildert die ausgefeilten Konzepte und breiten Erfahrungen, die mit Konfigurationsmanagement (KM) bei der Siemens AG gemacht wurden. Dabei konnte er auf einer langen Tradition im Hause Siemens zum Thema KM aufbauen. In Interaktion mit den Arbeiten an meinem ersten Buch über KM in 1984 [1] erstellte der damalige Datenverarbeitungsbereich bei Siemens das IT-Tool für Software-KM „KMS-Konfigurationsmanagement-System“ auf BS2000. Dieses wurde bei der ersten Fachtagung über KM im Jahre 1985 vorgestellt [2], [3]. Aufbauend auf diesen Arbeiten vertiefte der damalige Zentralbereich Technik das Thema [4]. Diese Erfahrungen wurden nun in den Bereich der Kommunikationstechniken übertragen, aus dem Herr Lemke den neuesten Stand wiedergibt. KM in der Zeitschrift PROJEKT- MANAGEMENT Aufgrund der Aktualität des KM erschienen ausgewählte Beiträge von KM- Tagungen wie auch originale Fachbeiträge: Saynisch, M.: Änderungen im Griff. Bericht 2. Fachtagung 1997. PROJEKT- MANAGEMENT 2/ 98, S. 45-48 Schuppert, G.: Projektänderungen in einer virtuellen, globalisierten Welt. PRO- JEKTMANAGEMENT 4/ 98, S. 22-27 Saynisch, M.: Was ist Konfigurationsmanagement? PROJEKTMANAGE- MENT 2/ 99, S. 12-25 Neemann, C.: Konfigurationsmanagement und Änderungsmanagement - Ein Interview mit M. Saynisch. PRO- JEKTMANAGEMENT 2/ 99, S. 42-46 Schreiber, W.: Konfigurationsstruktur - Grundlage des Konfigurationsmanagements. PROJEKTMANAGEMENT 4/ 99, S. 38-41 Dokumentations-Band zur 3. Fachtagung zum Konfigurationsmanagement Die dritte Fachtagung zum Konfigurationsmanagement fand am 22. und 23.6.99 in Stuttgart mit über 100 Teilnehmern statt. Die Grundsatz- und Anwenderreferate mit konkreten Lösungsansätzen kamen aus der Automobilindustrie (AUDI, BEHR, BMW), Softwarebranche (CRISTAL, EIGNER, it- Research, SAP, sd&m), Telekommunikation (Bosch-Telecom, Siemens) und System- und Anlagenbau (DASA, LFK, LURGI). Weitere Literatur zum KM [1] Saynisch, M.: Konfigurationsmanagement - Entwurfssteuerung, Dokumentation, Änderungswesen. Verlag TÜV Rheinland, Köln 1984 [2] Tomahogh, D.: Konfigurationsmanagement bei Softwareprojekten. In: Schelle, H., Saynisch, M. (Hrsg.): Symposium Konfigurationsmanagement. GPM, München 1985, S. 61-78 [3] Faltenbacher, P./ Mittermaier, P.: Rechnergestütztes Konfigurationsmanagement mit KMS. In: Schelle, H./ Saynisch, M. (Hrsg.): Symposium Konfigurationsmanagement. GPM, München 1985, S. 79-90 [4] Platz, J./ Schmelzer, A.: F+E-Management. Springer-Verlag, Berlin 1986 Manfred Saynisch ■ 412 S., DM 54,- (für Mitglieder DM 42,-) bei GPM Region Stuttgart/ Karlsruhe, Fax 07 11/ 6 87 39 69 38 P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 Konfigurationsmanagement Kommentare, Fakten, Literatur Deutsche Gesellschaft für Projektmanagement e.V. Manfred Saynisch Dietmar Lange (Herausg.) Änderungsmanagement mit System - Schlüsselfaktor Konfigurationsmanagement Dokumentationsband der Tagung Zusammenfassung Dieser Artikel spiegelt die Einführung von Projektmanagement in unserem Unternehmen wider und setzt sich mit dem Problem eines klassischen Entwicklungsprojektes auseinander, in dem zwar die Vorstellungen aller Beteiligten definiert, aber konkrete Ergebnisziele noch nicht greifbar sind. Der hier geschilderte Fall zeigt auf, dass auch während des laufenden Projektes Ziele in fortgeschrittenen Projektphasen immer wieder umdefiniert werden können. Abstract Here we try to explain the introduction of project management in our company dealing with problems of classical development projects. In this case very often ideas of team members are defined but concrete goals concerning the results are not available yet. We want to point out that project goals could also be (re-)defined in progressing project states as shown here. Schlagwörter Entwicklung, Lotus-Notes-Datenbank, Projektmanagement, Prozessorientierung, Software, Zieldefinition 1. EINLEITUNG Viele zertifizierte Unternehmen stehen vor der Herausforderung, die resultierenden Qualitätsdokumente zu verwalten und dabei ein größtmögliches Maß an Informationen für alle Mitarbeiter bereitzustellen. Diese Aufgabe ist nicht immer leicht zu bewältigen, denn endet sie nicht allzu oft als ungelesener und nicht verstandener Papiertiger? Zudem setzen immer mehr Unternehmen auf breite Information und tiefe Einblicke in das Unternehmensgeschehen, um die Mitarbeiter zu motivieren und sie über deren wichtige Rolle beim Unternehmenserfolg aufzuklären. Es gibt viele Softwareangebote, die eine Verarbeitung und Bereitstellung dieser Informationen über lokale Netzwerke in den einzelnen Unternehmen ermöglichen, doch aufgrund der allgemeinen Übertragbarkeit auf viele Arten von Unternehmen sind diese Angebote oft nicht spezifisch oder müssen mit einem hohen Kostenaufwand an vorhandene Unternehmensstrukturen angepasst werden. 42 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 Projektmanagement in der Lotus-Notes-Datenbankentwicklung S U S A N N E K L E I B Ö M E R „Projektmanagement-Fachmann/ -frau“ ist ein Ausbildungsgang, dessen Absolvent(in) „über ● gute Schulbildung und Berufserfahrung verfügt, ● umfassendes Wissen in allen Bereichen des Projektmanagements und die Fähigkeit besitzt, die Kenntnisse anzuwenden, ● fähig ist, als Mitglied im Projektleitungsteam eines komplexen Projekts in irgendeinem Projektmanagement-Bereich zu arbeiten, ● Leitungsfunktionen in einem Projekt übernehmen kann“. In der Ausbildung wird daher nicht nur der Wissensspeicher genutzt, der auf über 1.200 Seiten der inzwischen 5. Auflage des Buches „Projektmanagement-Fachmann“ niedergelegt ist, sondern weitere Methoden und Medien werden in der Vermittlung und vor allem in der Umsetzung des erworbenen Wissens eingesetzt. So hat jede angehende Projektmanagement-Fachfrau und jeder angehende Projektmanagement-Fachmann während der Ausbildungsdauer ein „Arbeitsprojekt“, in dem die erworbenen Kenntnisse anzuwenden und die damit gemachten Erfahrungen zu reflektieren sind. Die Beschreibung ihres Arbeitsprojekts hat Frau Kleibömer für diese Veröffentlichung überarbeitet und zur „Fallstudie“ weiter entwickelt. 2. VON DER IDEE MIT PM ZUM NICHT VORHERSEHBAREN ZIEL Aus dieser Situation heraus haben wir in unserem Unternehmen ein Projekt ins Leben gerufen, das eine „all round“-Datenbank entwickeln sollte, die Information und Dokumentenlenkung gleichermaßen bereitstellt und dabei auch noch gerne und mit viel Freude von den Mitarbeitern angenommen wird und nicht teurer sein darf als ein Produkt von „der Stange“. Man könnte sagen, dass diese Anforderung gleichzeitig eines der wichtigsten Ziele für unseren Geschäftsführer war und für das Projektteam selbst der einzige Hinweis auf das, was nun zu tun sei. 3. EIN PROJEKT WIRD ZUM PROJEKT Das Projektteam setzte sich aus den Mitarbeitern zusammen, die hauptsächlich an der Dokumentenlenkung, sprich Dokumentenverwaltung, im Unternehmen beteiligt waren und somit alle Stärken und Schwächen eines papiergelenkten Dokumentensystems nach DIN EN ISO 9000 ff. kannten. Diese Mitarbeiter kamen sowohl aus den Produktionsbetrieben als auch aus dem Verwaltungsbereich. Als Projektleiterin befand ich mich zum Zeitpunkt des Projektstartes selbst in der Ausbildung zur Projektmanagement-Fachfrau und konnte die Systematik eines geregelten Projektmanagements aufzeigen. Die Erfahrung hat gezeigt, dass gerade in Organisationsprojekten nicht nur die fachliche Qualifikation, sondern vielmehr auch das organisatorische Geschick und die Kenntnis der Unternehmensstrukturen von besonderer Bedeutung sind. Ich wusste daher, wenn sowohl die „DIN-ISO-Pessimisten“ als auch deren „Fahnenweher“ im Projektteam sind, dann wird das System am Ende dem Anspruch des Geschäftsführers wohl gerecht werden. Also fragte ich die potentiellen Projektmitglieder, ob sie gerne im Projekt mitarbeiten möchten, und erhielt fast ausschließlich eine positive Resonanz. 3.1 Definition der Datenbasis und Plattform Da im Unternehmen bereits ein Notes Server mit entsprechender Anbindung an alle vorhandenen PCs installiert war und auf jedem PC eine Lotus-Notes-Datenbank zwecks E-Mailing installiert ist, beschloss das Projektteam während der zweiten Projektsitzung eine Lotus- Notes-Datenbank zu entwickeln und zu programmieren. Wir kannten aus verschiedenen Vorführungen Lotus-Notes-Datenbanken zur Dokumentenlenkung und konnten durch diese Entscheidung die Kosten für zusätzliche Hard- oder Softwareankäufe vermeiden. Außerdem waren die Mitarbeiter durch die Lotus-Notes-E-Mail- Komponente bereits zum Teil mit Notes-Anwendungen vertraut. All diese guten Voraussetzungen wollten wir nutzen, um die spätere Akzeptanz unserer Datenbank zu erhöhen. Zu diesem Zeitpunkt hatte ein Teil der Projektmitglieder aus anderen betrieblichen Gründen bereits eine Inhouse-Schulung zur Lotus-Notes-Datenbankentwicklung, die alle notwendigen Basiskenntnisse vermittelte, bekommen. 3.2 Zielgestaltung Viele Ideen zur Gestaltung dieser Datenbank waren bereits vorhanden, da wir im Bereich Qualitätsmanagement einmal damit begonnen hatten, einen ähnlichen Ansatz in HTML zu programmieren. Doch die Möglichkeiten einer echten Datenbank sind viel umfassender und lassen den Ideen freien Lauf. Wir verwendeten daher zur Zieldefinition das klassische Brainstorming und die Metaplantechnik. Wir visualisierten sämtliche genannten Ziele zu Aussehen, Gestaltung, Inhalt und Möglichkeiten der Datenbank und prüften, ob diese Ziele erreichbar, d. h. unter den vom Auftraggeber vorgegebenen Kriterien für uns umsetzbar waren. Dann überlegten wir, ob die gesetzten Ziele auch den Vorstellungen und Ansprüchen der späteren Anwender genügen würden, denn gerade bei Entwicklungsprojekten sind oftmals die eigenen Ideen und Vorstellungen nicht gleichzusetzen mit den Erwartungen der späteren „Adressaten“ oder „Kunden“. Hierzu führten wir eine Befragung in einem repräsentativen Kreis durch, in dem wir unsere Ziele als offene Fragen gestalteten. Hierdurch war es möglich, die wesentlichen Ziele herauszufiltern und gleichzeitig den einzelnen Zielen eine entsprechende Gewichtung zu geben. Einige Ziele waren zu diesem Zeitpunkt noch nicht bekannt, da sie erst später, mit dem wachsenden Verständnis um die Möglichkeiten der Datenbankprogrammierung, hinzukommen sollten. Die Ziele, die im weiteren Verlauf aufgeführt werden, stellen das dokumentierte Endergebnis dar. 43 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - F A L L B E I S P I E L / F A L L S T U D I E 3.2.1 Ergebnisziele Ein wesentliches betriebliches Ziel war die Bereitstellung aller QM-Dokumente und Informationen des TQM-Systems für alle Notes- Anwender in attraktiver Art und Weise zur Erhöhung des Informationsgrades aller Mitarbeiter. Die Lenkung von QM-Dokumenten bis zu deren Archivierung muss rechnergestützt erfolgen. Die Kosten und der Aufwand der Mitarbeiter zur Aufrechterhaltung des QM-Systems nach DIN ISO 9001 sollen um mindestens 50 % von bisher ca. 15.000 DM/ Jahr auf 7.500 DM/ Jahr reduziert werden. Die Entwicklungskosten dürfen einen Rahmen von 20.000 DM nicht überschreiten, da sonst eine extern gekaufte Anwendung billiger gewesen wäre. Die Mitarbeiter der Dokumentenlenkung sollen mit geringem Aufwand Dokumente selbst erstellen, lenken, revidieren und verteilen können. Der Betriebsrat soll die Möglichkeit der Veröffentlichung seiner Informationen erhalten. Eine Hauszeitung soll integriert werden. Bezugsdokumente, Anlagen und Formblätter müssen untereinander über „Hot-Spots“ verknüpft sein und in ihrer Darstellung an das Internet erinnern, um den Bezug zu modernen Kommunikationstechniken herzustellen. Ein Diskussionsforum innerhalb der Datenbank soll zur Verfügung stehen. 3.2.2 Verfahrensziele Die Datenbank muss soweit möglich allein mit Notes entwickelt werden. Wenn es notwendig ist, bei den Formblättern und Anlagen auch auf MS-Office-Anwendungen zurückzugreifen, müssen diese als Anlagen eingebunden werden können. Die Entwicklung, Administration und Weiterentwicklung der Datenbank müssen innerhalb des Unternehmens erfolgen. 4. PROJEKTPHASEN UND TERMINPLANUNG Die Projektphasen konnten zunächst nur grob definiert werden. Das als Abb. 1 gezeigte Phasenmodell entstand erst, nachdem wir bereits die Phase 3 erreicht hatten. Bis zu diesem Zeitpunkt musste der Projektstrukturplan und auch der Terminplan immer wieder angeglichen werden, da aus dem Projektteam heraus, mit der wachsenden Einsicht in die Möglichkeiten des Systems, immer mehr Ideen geboren wurden, die wir in das System integrieren wollten. Wir erstellten daher eine Liste aller anfallenden Aufgaben und Arbeitspakete und ordneten sie nach Bereich und Ablauffolge innerhalb der Projektabwicklung ein. Der sich daraus gleichzeitig ergebende Projektstrukturplan lässt sich in einem entsprechenden Softwareprogramm zusammen mit der Terminplanung sehr gut abbilden. Die Dauer für die einzelnen Aufgaben haben wir geschätzt, da wir hierzu noch keine Erfahrungen sammeln konnten. Zusammen mit den immer wieder neu hinzukommenden Ideen und den „geschätzten Terminen“ verschob sich dann auch im Laufe der Zeit das für Mai geplante Projektende auf den 30. Juni 1999. Wir hätten aber keine Kosten gespart, indem wir z. B. die Ressourcen erhöhten; auch wollten wir nicht auf die Integration der Ideen verzichten. Somit konnten wir den Auftraggeber nur damit überzeugen, dass unser Fertigstellungswert am Ende höher liegen würde als geplant. Aus dieser Art des Vorgehens haben wir allerdings viel gelernt. Es ist durchaus legitim, Termine und Aufwände zu schätzen, wenn keine Erfahrungswerte vorliegen, doch erlauben dies nur Projekte, deren Fertigstellungstermine kostenunabhängig sind. In unserem Fall entstanden zwar Mehrkosten durch eine längere Entwicklungszeit, doch hatten wir am Ende auch einen höheren Fertigstellungswert und somit eine gewisse Kostenneutralität. Wäre der Endtermin aber ohne höheren Fertigstellungswert überschritten worden oder gar mit einer Pönale belegt, hätten wir das Projektbudget deutlich überschritten. Wenn man wie in unserem Fall auf Schätzungen in der Terminplanung angewiesen ist, dann sollte man immer darauf achten, nicht nur die aufeinander folgenden Arbeitspakete möglichst mit Pufferzeiten zu belegen, sondern auch mit Abb. 1: Projektphasen 44 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 dem Auftraggeber über das späteste Projektende zu verhandeln. Auf jeden Fall sollte man bei notwendigen Terminkürzungen nur die Arbeitspakete kürzen, deren Dauern bekannt sind. Geschätzte Dauern in Arbeitspaketen sollten gekennzeichnet sein und hier außen vor bleiben, denn „Schätzungen“ zu kürzen macht wenig Sinn. 5. DATENBANKENTWICKLUNG Zunächst entwickelten wir eine Auflistung der bisherigen Anforderungen an die Dokumentenlenkung und deren Funktionalitäten und ermittelten die Funktionen, die künftig automatisch, halbautomatisch oder manuell bei Bedarf, durchgeführt werden sollten. Des Weiteren ergaben sich aus diversen „Brainstorming-Sitzungen“ die Arten der Dokumentenauswahlmöglichkeiten, die verschiedenen Kriterien für Ansichten von Dokumenten, die Gestaltung der Navigatoren als Menü-Oberfläche und routinemäßig ablaufenden Agenten sowie die Dokumentenmasken, in die viele Funktionen integriert wurden. In diesem Stadium der Ideenfindung und Prüfung der „Programmierbarkeit“ war es äußert wichtig, die definierten Ziele immer wieder zu prüfen und zu konsolidieren. Bei allen Entscheidungen galten die Fragen: Ist es komfortabel und logisch für den Anwender? Erleichtert es die Arbeit? Findet man ein Dokument schnell und ohne Aufwand? Hat man einen guten Überblick über alle Dokumente? Und sehen die Ansichten und Masken ansprechend aus? Während der Phase der Datenbankentwicklung wurden viele zusätzliche Ideen geboren, die in die Funktionalität der Dokumentenlenkung, sprich Funktionsleisten der Dokumentenmasken, eingebettet werden sollten. An dieser Stelle war es von besonderer Bedeutung abzuschätzen, inwieweit die Verwirklichung der Ideen in den Terminplan integriert werden können, wie sie sich dort auswirken und wie sich das Informationsmanagement über etwaige Änderungen des Plans gestaltet. Wir hielten es daher für angebracht, über Änderungen und Ideen immer gemeinsam während der Projektbesprechungen abzustimmen. Bei von uns program- Abb. 2: Datenbankeinstieg Abb. 3: Hauptnavigator 45 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - F A L L B E I S P I E L / F A L L S T U D I E miertechnisch nicht zu lösenden Problemen wurden wir von einem externen Consulting unterstützt. 6. DER DOKUMENTENIMPORT Der Dokumentenimport verlief recht problemlos. Allerdings sind wir in der Terminplanung davon ausgegangen, dass alle Teammitglieder zu 80 % für diese Tätigkeit zur Verfügung stehen würden. Dies war leider ein Irrtum, denn diese Arbeit für das Projekt war eigentlich mehr eine Nebensache für die Teammitglieder. Um hier unseren Terminplan einhalten zu können, haben wir einen Auszubildenden unseres Unternehmens gewinnen können, uns für 10 Tage Vollzeit zu unterstützen. Diese Lösung war dann auch sehr effektiv, und wir haben für weitere Projekte gelernt, mit der Ressourcenplanung sorgfältiger umzugehen und mit den betroffenen Mitarbeitern alle Eventualitäten für den anfallenden Aufwand durchzugehen. 7. DER TEST Schon zu Beginn der ersten Programmierversuche, also in der Konzeptphase, haben wir mit Tests begonnen. Mittlerweile gehen wir davon aus, dass EDV-Entwicklung „eine einzige Testphase ist“. Das Testen beziehen wir daher auf die Tests der Anwender und inwieweit diese problemlos mit der Anwendung arbeiten können. Damit die Testphase erfolgreich verlaufen konnte, wurden alle Testpersonen ausführlich über die Funktionen der Datenbank informiert und geschult, damit wir die Benutzerführung eventuell optimieren konnten. In dieser Phase erhielten wir von den Mitarbeitern noch viele Verbesserungsvorschläge und Anregungen, die wir soweit möglich in die Datenbank einbauten. Wichtig war an dieser Stelle, dass die Datenbankdokumentation fertig gestellt und das Rechtekonzept geklärt war. Diese Projektdokumentation wurde regelmäßig geführt. Eine gültige Fassung dieser Dokumentation lag jeweils auf einem Fileserver im Netzwerk sowie in Papierform im Projekthandbuch. Normalerweise wird an dieser Stelle von den meisten Entwicklern in Projekten Abb. 4: Dokumentennavigator Abteilungsübersicht Abb. 5: Dokumentenmaske 46 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 die Dokumentation nicht mehr gepflegt, da in dieser Endphase sämtliche Anstrengungen darauf verwendet werden, das Produkt möglichst schnell „an den Mann oder die Frau“ zu bringen und die erhofften Lorbeeren zu ernten. Dann fällt auch schon mal das Benutzerhandbuch, die Hilfedatenbank oder gar die Freigabe durch eine übergeordnete Stelle hintenüber. Diesen Fehler konnten wir nicht begehen, da unser IT-Administrator unsere Datenbank ohne diese Hilfsmittel nicht auf dem Server freigegeben hätte. Diese moderne Art der Erpressung betrachte ich aus heutiger Sicht als unverzichtbar, denn wir hätten auch den Fehler begangen und diese wichtige Dokumentation und Hilfestellung für den Anwender vernachlässigt. Ich kann daher nur jedem Entwickler empfehlen durchzuhalten und die Dokumentation bis zur Fertigstellung zu pflegen und alle Änderungen darin festzuhalten. 8. INBETRIEBNAHME Vor der Inbetriebnahme erfolgte ein letzter Vergleich mit den gesteckten Zielen. Ein wesentliches Ziel, dass die Mitarbeiter dieses System gerne nutzen, scheint nach 4 Monaten Betrieb erfüllt zu sein. Wir hatten in den letzten 51 Tagen 1.400 Besuche, in denen 23.700 Dokumente gelesen und 521 Dokumente oder Informationen geschrieben oder revidiert wurden. Selbst erklärend scheint unsere Datenbank aber dennoch nicht zu sein, denn trotz Hilfedateien und leichter Benutzerführung kamen immer noch sehr viele Fragen auf. Wir haben uns daher entschlossen, die neue TQM-Doku-Datenbank während der jährlichen, für alle Mitarbeiter in unserem Unternehmen stattfindenden Qualitätsschulung vorzustellen. 9. RESÜMEE Die Einführung von Projektmanagement in ein Unternehmen bedeutet nicht allein die Einführung einer ordentlichen Terminplanung, sondern bringt auch viele Ansätze einer neuen Unternehmenskultur mit sich. Projektmanagement bedeutet zugleich Teamarbeit, Disziplin, Termintreue sowie interne und externe Kundenorientierung. Die tief greifende Planung und die Berücksichtigung aller Aspekte und Ideen innerhalb eines Projektteams, unterstützt von einem guten Informationsfluss sowohl nach innen als auch nach außen, vermeiden teure Projektnachbereitungen und verdrängen langsam die heute immer noch üblichen „Chaos-Projekte“. Abb. 6: Dokumentenauswahl- Ansichten Abb. 7: Rechte 47 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - F A L L B E I S P I E L / F A L L S T U D I E Doch es ist nicht immer einfach, in eingefahrenen Unternehmen diese neuen und doch alten Methoden einzuführen. Zur Zeit bearbeite ich das dritte Projekt nach modernen Projektmanagement-Methoden innerhalb unseres Unternehmens und konfrontiere daher alltäglich viele Kollegen mit dieser Art des Vorgehens. In letzter Zeit werde ich des Öfteren angesprochen und um Rat gefragt, oder es gibt Aussagen wie: „Lasst uns doch hier auch so systematisch vorgehen …“ Ich bemerke, dass der Sinn eines guten Projektmanagements für viele Kollegen immer mehr offenbar wird und dass eine einfache Vorbildfunktion oftmals viel effektiver ist als die Einführung per Anordnung oder mit dem Anschein der „Besserwisserei“. ■ Autorin Susanne Kleibömer, Jahrgang 1963. Chemotechnikerin und Projektmanagement-Fachfrau (RKW/ GPM). Seit 1990 tätig bei KG Deutsche Gasrußwerke in Dortmund. Schwerpunkte: Qualitätsmanagement, TQM- Koordination, Organisationsprojekte. Anschrift KG Deutsche Gasrußwerke GmbH & Co. Weidenstraße 70-72 D-44147 Dortmund Tel.: 02 31/ 85 92-3 01 Fax: 02 31/ 85 92-3 79 E-Mail: kleiboemer@gasruss.de Abb. 8: Benutzeraktivität 48 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Projektmarketing sichert den Projekterfolg! ● Projektmarketing - Ansatzpunkte und Methoden (Dr. Dietmar Lange, ICCON International Consulting GmbH, Stuttgart, und Vorstand GPM Region Stuttgart/ Karlsruhe) ● Kunden mit Projektmarketing früh gewinnen (Dipl.-Kfm. Dieter Wagner, Siemens AG, Frankfurt [pm award 97]) ● Öffentlichkeitsarbeit - ein Werkzeug für das Projektmarketing (Oliver Steeger, Journalist, Bonn) ● Viele Betroffene erreichen mit Projektmarketing (Dipl.-Kfm. Jürgen Tuscher, DB Projekt GmbH Stuttgart 21, Stuttgart) ● Bessere Lieferantenbeziehungen durch TANDEM (Dipl.-Ing. Erik Jahn, DaimlerChrysler AG, Stuttgart) ● Die Mitarbeiter im Projekt begeistern - Projektmarketing nach innen (Michael Müller, Siemens Business Services GmbH & Co. OHG [pm award 98]) ● Roll Out von 83 Briefzentren - Projektmarketing für 180.000 veränderte Arbeitsplätze (Dipl.-Verww. FH Frank Bettgenhäuser, Deutsche Post AG, Bonn [pm award 99]) ● Empfang 29. 2. 2000, 10-18 Uhr, Stuttgart (DM 280; DM 210 für Mitglieder) Information und Anmeldung: GPM Region Stuttgart/ Karlsruhe, 07 11/ 6 87 39 69 Fax 8. Projektmanagement-Tag Südwest