PROJEKTMANAGEMENT AKTUELL
pm
2941-0878
2941-0886
UVK Verlag Tübingen
31
2000
111
Gesellschaft für ProjektmanagementMulti-Project Management
31
2000
Marcel Bhend
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.
pm1110004
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
