Managing IT Projects - Part 2: Project Organization and Communication
Many IT projects fail not because of the technology, but because of non-transparent structures, poor organization and a lack of communication. That is why it is important to define clear roles and responsibilities right at the beginning and to establish a communication culture that ensures the success of the project. In this second part of our three-part series, we look at the specific organization and communication involved in projects. In the first part we looked at the basics, and finally in the third part we look at risk management.
Define roles and responsibilities
The project organization ensures that roles and responsibilities are defined. Three levels are considered: steering, managing and delivering. Steering includes all decisions at the highest level, it forms the approval authority and is responsible for the phase completion release. Managing includes the day-to-day business of the project and ensures that milestones are met. Finally, delivering is about creating the work results according to the agreed requirements.
Important roles that should be defined are:
• Steering Committee
• Project Manager
• Team Manager
• Project support
The project organization always depends on the project size and the exact project object as well as the procedure model. For smaller projects, the project units remain anchored in the general corporate structures and are controlled from there. For large projects, autonomous project management is usually installed, which functions as a separate, largely independent mechanism. For medium-sized projects, a combination is also possible: only project management and project controlling are institutionalized; for the rest, employees and resources of the existing corporate units are used as needed.
Requirements for the organization
What good is a contract if its provisions are impractical? Both parties should therefore ensure that the agreed provisions are also enforceable and liveable. To this end, they should meet the following requirements:
• Competencies must be clearly regulated:
Who decides what?
• Tasks and areas of responsibility must be clearly delineated:
Who does what?
Who is responsible for which results?
• Keep decision-making paths as short as possible. Projects are often under time pressure.
• Decisions made must be comprehensible:
Who decided what, when, how and why?
What information and what level of knowledge was available at the time of the decision?
• Information must be passed on quickly, completely and correctly to the right target persons.
• Flexible adaptation to changed requirements and boundary conditions must be possible.
Typical roles in the project
A typical project organization for a medium-sized project provides for the following roles:
• User/client: person authorised to take decisions.
• Steering Committee: This is the overarching body for monitoring and controlling the project, is usually responsible for ensuring that objectives are met, and approves deviations and additions to the scope.
• Project management: Each partner involved appoints a person responsible for this task. The competences and the demarcation to the steering committee should be defined. The project management is responsible for the operational control of all project activities.
• Project team(s): This includes all external and internal employees who are involved in the project. As a rule, they are technically subordinate to the project manager of their own company.
• Special groups/teams: In order to carry out special tasks (quality assurance, tests), an organisation with separate staff is usually set up that is largely independent of the rest of the project in order to improve the efficiency of the work.
• Project Office: The project support takes over administrative tasks in the project office and provides the necessary tools.
Anchor communication in the project
A culture of exchange and trust cannot be contractually prescribed. But this should not lead to underestimating communication as a success factor for a project. If projects become distressed and the legal department or external legal advice is then called in, those involved tend to underestimate the influence of communication when considering the risks and prospects of success. If a deadline is not met, a software does not meet the agreed requirements or does not fulfil the agreed quality criteria, an often laborious search for causes and mutual apportioning of blame begins. It is often overlooked that project goals do not necessarily only fail due to hard criteria, but that the communication of the project participants also has a considerable influence.
In order for this influence to be effective, the following things should be taken into account when organising the project:
• Sharing information regularly: as a meeting or status report, can build trust and provide support.
• Learning from each other: The software provider must learn to understand the requirements and the user must learn about the technical possibilities so that everyone develops a common understanding of the subject matter of the project.
• Avoid conceptual misunderstandings: Language confusion can lead to the greatest project risks. Consistent terms should be used and defined in the terms of reference throughout the project documentation (including contractual provisions).
• Develop prototypes: they can help with difficult decisions.
De-escalate in case of doubt
Legal advisors who are called in during a crisis situation often tend to escalate and further undermine the already weakened confidence in the success of the project with correspondingly sharp attacks and formulations. It is important, especially in distressed projects, to carefully consider the wording. Consultants should analyse which measures they can use to achieve which successes. Above all, however, they should be fundamentally clear about whether the project can still be saved or whether it is ultimately only a question of the form of termination. Setting deadlines that are not in line with the agreed deadlines will usually lead to an escalation to the legal department or to the management level. This is more likely to jeopardize the success of the project than to promote it. An indicator of the project status is also the tone and choice of words in the correspondence exchanged between the contractual partners. It may also be advisable to de-escalate this and not to aggravate it further.
Clear rules for international projects
Cultural diversity can lead to diversity of ideas, but also to misunderstandings and conflicts: A German client concludes an IT project contract with a US software company that has German-speaking sales staff but not German-speaking developers and database designers. In addition, part of the development department is located in Israel. The different languages alone increase the complexity. If contractual partners from different cultural backgrounds are involved, project management should also take this into account. Our understanding is often shaped by specifically European values that are not necessarily shared or even understood in Far Eastern countries. Other cultures bring their own value systems, traditions and customs with them, which is sometimes already reflected in greeting rituals. These different value systems must be taken into account, especially in risk assessment. In multinational project teams, it makes sense to agree on simple, binding team rules that do justice to the different working views and conventions.
Criteria for a good information policy
Crisis situations often exacerbate existing problems. This also applies to information policy. Therefore, both contracting parties should pay attention to efficient information management right at the beginning:
• Efficient: How much effort does it take for stakeholders to stay informed?
• Continuous: The active and passive supply of information must be stable during the project.
• Personalized: Information should be individually useful.
• Accepted: Good information management can be recognized by the fact that the preparation and dissemination is carried out actively, naturally and voluntarily by all project participants.
Contractually regulate communication
Right at the start of a project, it is important to define and document certain key points of project communication. What goals are to be pursued with the project and what results are expected? Ideally, a well-balanced contract and a detailed performance description are available.
During a project, the reconciliations must be documented, especially if the service contents change (change requests). In this context, the new performance disturbance law plays a role: How is it supposed to be traceable in a comprehensive project whether the agreed program of duties was adhered to if the course of the project was not documented in writing: "A meeting for which there are no minutes did not take place".
The project-accompanying documentation documents the processes and the development in the project and thus comprises all documents that were created during the adaptation, introduction and implementation. It is advisable to define how the project documentation is to be structured at the start of the project and in connection with the contractual agreements.
Minimize risks through documentation
When it comes to project documentation, the lawyers' assessment of possible risk minimization often clashes with the project managers' view of "doing" and "daily life". From a legal point of view, project documentation cannot be comprehensive enough; from a project management point of view, there must still be sufficient time to devote to the actual project implementation. Status reports should be written regularly despite this tension.
Protocols become very important when conflicts arise in the project: they can be used to delineate the contents of services, to document the postponement of deadlines or to document certain quality assurance measures.
In order to minimize risks, especially in complex IT projects, and to ensure the success of a project, the organization and communication of the project play an important role. We advise clients and software companies on the drafting of contracts and help them to identify and contractually regulate relevant topics and areas of responsibility.
Certified Expert for IT Law, Certified Expert for IP Law