Managing IT Projects - Part 1: The Basics
The courses are set at the beginning - in addition to the technical planning, the contracts are to be drafted. Good IT project contracts not only contain provisions that take effect in the event of failure. Their main focus should be on regulations leading to the success of a project in the end, in particular by way of a good project progress. This includes a well-coordinated project management.
Particularly in complex IT projects, there are many different expectations on the part of the partners involved with regard to the scope of functions, operation, cooperation with contractual partners, etc. If a customer invests too little time and resources in managing its projects, they can often experience bad surprises during implementation. Many IT projects fail not because of inadequate technology, but because of non-transparent structures, poor organization and lack of communication. Frequently, at these occasions, too little attention is paid to the project management.
In this first part of our three-part series, we look at the basics of successful project management, followed by insights into project organization and communication in the second part, and finally we look at risk management in the third part.
Good preparation pays off
Project management does not come for free. Depending on the scope and duration of a project, the planning process requires extensive human and financial resources from both contractual partners. Frequently, the project participants want to save money at this point. In their offers, software providers measure the effort for the required project management too tightly in order to be able to offer it at a reasonable price. Customers instead consider it as potential for savings in the planning processes because they have purchased a “standard”.
Both partners to the contract overlook the benefits of consistent project management, which includes thorough planning:
• Project management can prevent chaotic and contradictory individual steps, duplication of work and hasty emergency solutions.
• Selection criteria and decision-making processes are disclosed to everybody.
• The risk of wrong decisions is being reduced.
• Deviations, disruptions and delays can be detected better and earlier and thus, can be intercepted and mitigated by timely measures.
Supporting processes with software
Those who have to deal with IT projects in trouble often have great difficulty in reconstructing the course of the project. Agreed extensions of the scope of services can at best be reproduced by evaluating the exchanged e-mails and a reliable risk assessment is hardly possible due to the lack of reliable documents. If there are any minutes of meetings at all, they are not signed, and the allegedly latest version is still in redline mode. It is almost impossible for consultants to ascertain what the contracting partners (could) have agreed upon.
Managing and monitoring IT projects is possible without the use of special software. But especially for more complex projects, it is advisable to use a common tool that facilitates the organization and management of resources and supports processes. Some project management software also offers communication tools, central data storage for documents (reports, specifications) and enables a uniform working environment for all participants. Friction losses due to different formats and standards can thus be avoided.
The number of project management software solutions is large and constantly growing. It is important that the contractual partners agree on a suitable software for their specific project and that the managed documents and data reflect the common understanding of the project. They should consider whether electronically exchanged documents meet the written form requirement and what binding force should be attached to the exchanged data and documents. Before making a final decision on the use of such software, the contractual partners should visualize how such software works, which functionalities shall be used and, above all, which requirements the contractual partners have and which project management processes shall be supported in detail.
Contractually design project management
Even without the discussion about § 631 BGB and the quality of software, projects involve considerable risks. This applies to the development of individual software as well as to the adaptation and implementation of standard software. The law itself does not offer a sufficient fall-back position with corresponding control mechanisms. The only remedy may be a contractual structure orienting itself to the risks in the specific individual situation and should include balanced regulations taking into account the interests of both contractual partners.
More security for the contractual partners
In order to make risks in IT projects more or less controllable, methods and procedures that provide more security for both contracting partners shall be taken into account as early as the contract drafting stage:
• Detailed and clear specifications where possible,
• detailed project planning,
• risk analysis of the project (before the project start),
• accompanying quality management,
• accompanying controlling and monitoring measures (ongoing),
• detailed tests, the timing of which is based in each case on the procedure model chosen by the contracting parties.
In all these arrangements, the partners shall bear in mind that the object of the project and the procedural model selected for project implementation determine the parameters for the contract and that it cannot be a supposedly sensible legal arrangement that determines the procedural model as a result.
The contractual control mechanisms include in particular the following elements:
• Factual determinations of performance outcome along with a project structure plan or schedule,
• provisions on how requirements are elicited in accordance with the chosen process model,
• regulations regarding changes to the content of the services in the sense of change management (with the priority according to necessity) and the corresponding effects on the agreed deadlines and remuneration,
• allocation of labour and segmentation between the staff involved on the side of the software provider and the customer, insofar as this is feasible by the process model,
• clear outline of the project also related to the remuneration agreement. Milestones to be reached shall be clearly defined in order to be verifiable whether the respective (partial) goal has been reached and thus whether a further (partial) payment is due,
• coordinated description of test and examination scenarios.
Coordinative or cooperative?
Cooperation in projects can be coordinative or cooperative, with all gradations in between. The coordinative form is characterized by delineated party interests, risk sharing, and limited information sharing. Although it is well known that improper or even unfair unilateral risk allocation significantly increases the likelihood of project disruption, this form is widely used. The same is true for restrictive information behaviour, which is considered one of the main reasons for failed projects. A cooperative approach, on the other hand, is reflected in a balanced distribution of burdens and risks. In case of doubt, this is also more appropriate for the newer process models, especially prototype models and agile models.
In order not to leave the successful implementation of IT projects to a chance and to minimize risks, especially in complex IT projects, the contractual partners should set the course right from the beginning and also anchor project management in the contract. We advise customers and software companies on the drafting of contracts and help them to identify and contractually cover the relevant topics and areas of responsibility right from the start.
Maren Bianchini-Hartmann, LL.M. (Fordham University School of Law), Rechtsanwältin | attorney-at-law (New York)