A software project is always in the area of tension between functionality, time, costs and quality. If this field of tension is not constantly controlled and kept in balance through appropriate measures, the parameters shift almost inevitably and often lead to unpleasant surprises at the end of the project at the latest.
After presenting the basics of project management in the first part and organization and communication in the second part, this third and final part of our series deals with controlling and managing risks in projects.
Controlling - an ongoing process
When managing a project, it pays to have plausible plans and target specifications. These specifications can be derived from the technical requirements. Controlling determines whether controlling measures are necessary to lead the project to success. Project controlling should be a permanent and ongoing process. It deals with the following questions:
• Is the project still on track?
• Is the project still on schedule?
• Is the project still on budget?
• Are functionality and quality as agreed?
• Are the goals achieved: In time? In budget? In quality?
Project controlling links project planning with higher-level corporate controlling. It is aligned with the goals of the project. Because it regularly monitors the progress of a project, it can indicate at an early stage if a project is in danger of going awry. In order to monitor the development, it makes sense to constantly document the project steps. The following areas can be considered:
• Information of the user about the project progress for his own disposition,
• Information of the user about risk areas and presentation of the type and size of the risk,
• Status Reports,
• Access rights of the user to development and manufacturing facilities,
• Arrange program and design reviews with user participation,
• Support the user in performing and evaluating his own tests.
Reporting within a project ensures that the client and contractor are constantly informed about the progress of the project. The task of the project controller is to ensure the transparency of the project events.
Uncovering risk drivers at an early stage
A risk is a potential problem. The risk becomes a problem when it occurs. Risks common to all projects include missing deadlines, exceeding planned costs, and failing to meet set quality and functional goals.
The earlier the most important risk drivers are uncovered, the sooner risk precautions can be taken. A project manager is therefore always also a risk manager. As such, he thinks about corrective measures before a problem occurs. Risk management encompasses all organizational regulations and measures for identifying and dealing with existing risks. Risk management is to identify, control and manage problems.
Avoid mistakes at the beginning
Unfortunately, risk management is lacking in many projects. Software vendors avoid the topic in the sales phase because they fear that mentioning risks could reduce their chances of winning the contract. Clients hope that any risks can be avoided simply by using a standard product. Both approaches are short-sighted. A software provider would be better off selling the information about existing risks as a consulting service that ensures the success of the project in the medium and long term. Clients should not blindly rely on the fact that the decision for a supposedly established system alone reduces risks.
Most later problems are already known as risks before the start of the project. If a user insists that a new system map the functionality of the old system 1:1 and also has this contractually secured, it is already clear before the conception that problems will occur. When implementing standard software, the demand for a 1:1 replacement of the legacy system is usually unrealizable, if only because the legacy system is rarely described in detail. If fixed prices are agreed even though the requirements are described superficially at best, a conflict is almost inevitable.
Evaluate and control risks
In order to manage risks, it is necessary to establish a risk management process. Active risk management includes three main activities to assess and control risks.
Risk identification - A list of project-specific items that threaten project success
Risk analysis - Probability of occurrence and amount of damage for each identified risk
Risk prioritisation - Prioritize risks. Risk factor = probability of occurrence x amount of damage
Planning of the risk event - Contingency plans for the critical risks
Risk reduction - Define measures to manage the risks
Risk monitoring - Ongoing monitoring to determine whether a risk has occurred
On this basis, it is possible to determine how risks are mitigated and monitored. Whether risk management is sufficiently taken into account can be checked using the following criteria:
• Is a risk list available that contains all core risks and also describes all project-specific risks?
• Is a risk discovery process established that also allows for open discussion of identified risks?
• Are there uncertainty diagrams available that are being used?
• Is each risk factor assigned an occurrence indicator that is continuously monitored?
• Is there a contingency plan and a risk mitigation plan for each risk?
• Is the level of risk evaluated for each risk?
Conflicts are the norm
In an IT project, conflicts inevitably arise sooner or later. Typically, deadlines are not met, work results are delivered with poor quality, information is not passed on contrary to the agreements and rivalries within the project team are fought out. According to the estimates of the Gartner Group, half of all software projects get into trouble at least once during their runtime. Therefore, it is necessary to deal with possible escalations when drafting the contract and to provide the contractual partners with framework conditions for the worst case that enable the project to be restructured.
Escalation is needed when a problem cannot be solved at the working level. The project management is responsible for controlling the escalation. It has many options in doing so: The contractual partners can use a mediator in the case of tensions, call in an expert in the case of technical issues, and use arbitration in the case of a profound dispute. In any case, project management should do everything possible to avoid a legal dispute.
Solve conflicts professionally
Mediation follows the principle that the mediator(s) mediate between the parties to the conflict and are guided by their (professional and economic) interests. Mediation strives for a conflict solution that is worked out jointly by all parties involved and is thus also supported with a high probability.
A conciliation procedure, on the other hand, relies on steering by the conciliator(s). Conciliation is mainly considered when the contractual partners want an out-of-court settlement of the dispute, but also want stronger external guidance and do not want to or cannot work out a solution themselves. There are a number of arbitration bodies; for IT projects, the arbitration procedure of the Deutsche Gesellschaft für Recht und Informatik e.V. (German Association for Law and Information Technology) (DGRI) comes into consideration.
Both procedures offer the advantage that the existing business relationship is not necessarily destroyed, but the contracting parties are given ways and means to continue working together.
Especially in complex IT projects, it is important to identify, minimize and counteract risks at an early stage. It is also illusory to believe that conflicts can be avoided. Rather, it is important to enable the project organization to manage risks and solve problems. 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.