Recognizing_Contract_Risk

| Company Name Here | Memo To: From: CC: Date: [ 5/10/2010 ] Re: Recognizing Contract Risk and Opportunities Memo This memo is about the contract creation and management simulation of Span Systems, a California-based custom e-banking software developer and Citizen-Schwarz AG (C-S), a German bank trying to break into the fiercely competitive and profitable U.S. banking market. This simulation demonstrates the errors and mistakes taken during the contract performance causing these two companies to disagree on principle points of the contract, which eventually leads to Span Systems trying to salvage the contract through renegotiations (University of Phoenix). These contractual disagreements usually lead to loss of production, severance of business relationships, and expensive legal costs. This memo will examine the legal risks, opportunities presented, and alternatives for solving disputes in the simulation. The first contractual breach is the fundamental principle of Span Systems performance of the contract. C-S claims that Span Systems deliverables in the past few months are behind schedule and the quality of those deliverables is unacceptable with major bugs detected during the user testing stage. The contractual agreement on performance stated that neither party can cancel the contract when more than 50% of the promised specifications are completed (University of Phoenix). During the eight month there was a risk of rescission by C-S with Span Systems completing over half of the software requirements, this would breach the 50% completion clause of the contract. This part of the contract is favors Span Systems, except for the quality of the software containing five errors per deliverable, which is contrary to the baseline of zero errors required through the metrics the companies agreed on. Span Systems software developers on the project continually met C-S requirement changes and schedule demands which, unfortunately for the task quality took a beating in the time frame allotted. C-S is completely in its rights to complain the contract performance is substantial, due to the amount of work performed below the quality standards they agreed upon. Span Systems disputed substantial performance on the basis of the slight variances from the exact terms and over 50% of contractual obligations is complete during this point in the contract. Performance points need to be clearly understood and defined prior to signing any contract, especially with strict parameters of no defects allowed in the software programmer’s deliverables. An alternate solution to this part of the contract is the implementation of quality control measures that ensures Span Systems delivers the product agreed to in the performance clause of the contract, while holding C-S to the original software requirements without some type of review process for changes that are acceptable. C-S clearly violated the contract clause for internal escalation procedures for disputes with Span Systems. C-S failed to involve actively management through the progressive measures of a written notification to Span Systems project leaders for resolution and negotiation of the disputes prior to pursing any formal proceedings or litigation. The breach of the contract terms puts Span Systems in a favorable situation for re-negotiation of terms and conditions of the contract. In any contractual situation, both parties need to be held accountable to all the terms of the contract. This simulation shows a classical example of leniency in the contract performance on both side, which eventually leads to both sides expectation and performance beyond the scope and parameters of the binding contract. Any undermining of the terms and performance outside the legal contract need immediate dispute resolution to keep the contract binding and enforceable. Another area that created substantial problems in the contract for Span Systems is the increased user system requirements. The ordinary requirement changes were contractually agreed upon, although Span Systems believes these user and system changes are anything but ordinary. Unrealistic changes imposed on the software programmers made the situation difficult for Span Systems to accommodate within the originally agreed upon costs and timelines. The requirement change clause defined specific procedures for any ordinary changes needed for the user system, which states that C-S will notify Span Systems promptly during regular business hours and pay Span Systems any accruals at the contractually agreed upon rate (University of Phoenix). The terms in this clause are ambiguous and allow each party to subjectively interpret terms to their understanding. A clear and defined understanding of the contract terms and conditions is the baseline upon that all contracts operate under. This clarity between all parties reduces misunderstanding in the contract language, which will minimize time spent resolving disputes, promote a healthy business relationship, and increase productivity. The bottom line is that management must clearly express the full expectations and needs of the agreement prior to putting any contract together, which would also include defining all ambiguous terms as stated in article two of the Uniform Commercial Code (Cornell University Law School, n.d.). C-S and Span Systems communication and reporting requests are especially important on both ends of this business venture. Communication between everyone helps break down misunderstandings and problems encountered in programming the user system requirements. Reporting also, provides a systematic way of updating the project managers with accurate information with the progress, setbacks, and status of system implementations. The communication and reporting contract clause components are absent with C-S and Span Systems. They agreed upon some ambiguous scheduled meeting to discuss the status of the project, along with an obscure frequency and location of these occurrences. The product of these meetings are the minutes that would serve as the project status report. These project status reports to the C-S project manager are forwarded for updating key personal (University of Phoenix). Problems with the communication channels begin to deteriorate with both parties at this point. C-S for some undetermined reason changed the management structure eight months into this project. C-S review and approval communication channels ceased with the new leadership assignment to the project, which contributed to the stoppage of all meetings and the flow of the project status communication reports. Individual and collective reflection during this time determine that these contributing factors are at least the partial cause for the project experiencing some of the problems and major setbacks. In resolving these situations all parties should agree on clear communication channels to avoid any confusion during the project, which can lead to the blaming game between the parties involved. The meeting times, schedule and type of meeting should be concrete and consistent to bring about positive results and relevant information that is useful for all parties involved. The meetings schedule should be mandatory with no allowance for postponement or cancellations. The main objective in this particular area of the project is for everyone to talk from the same sheet of music and to resolve any disagreements. The final contract clause area for discussion deals with the intellectual property rights. The simulation demonstrates C-S program managers frustration with Span Systems programmers, which is evident with the deliverable products found with major defective bugs in the user testing stage. Span Systems is jeopardizing the one year goal for completing this project that ultimately will affect the release of the transactional software into the U.S. banking market (University of Phoenix). C-S at this point, demands immediate transfer of all finished codes along with the rescinding of the contract. The request for Span Systems to transfer all codes of finished work to C-S undermines the contractual agreement of the intellectual property rights, which states that all work remains vested with Span Systems until full payment is received. Span Systems has the upper hand with the contractual terms and the C-S request is not enforceable, until they make payment under the terms of the contract. Intellectual property law deals specifically with protecting the rights of those that create original works, along with encouraging new technologies, artistic expressions, and inventions while promoting economic growth (The Internet's Premiere Law Portal, n.d.). In creating a salvageable contract situation for both parties without rescission of the agreements in place, some concessions need to be made. First, C-S needs to understand that Span Systems holds all the intellectual property rights, until they make full payment. Second, if they receive all relevant codes, are they going to be in any better position in meeting their desired outcome, and finally, the size of the project has grown dramatically since the originally agreed upon software requirements. C-S needs to realistically determine their desired outcome and timeline they are looking to meet, while limiting any further upgrades that create major stumbling blocks for releasing this product into the U.S. banking industry. Companies with continual moving targets cannot expect outside vendors to meet production timelines without a concrete achievable goal in mind. In summary, project managers along with key personal need to be keenly aware of the terms and conditions in all contractual agreements. This simulation looked at five contract clauses that created various problems for Citizen-Schwarz AG (C-S) and Span Systems. The performance clause created quality performance issues between Span Systems and C-S, fortunately the contract completion percentage favored Span Systems. In handling all the disagreements, C-S clearly violated contract procedures in resolving disputes through not requesting senior management involvement. The clause for requirement change was in essence to vague and created a thorn in Span Systems programmers side. Consistent communication and reporting lacked proactive participation from both parties, especially during the changing of the project manager for C-S. Last, the intellectual property rights terms fell clearly within Span Systems rights to with hold all coding until they received full payment, which C-S misunderstood. In the final analysis this simulation presented opportunities for Span Systems to benefit from contractual events and present resolutions to improve the terms and performance of the long-term contractual relationship with C-S. References University of Phoenix. (). Contract Creation and Management [Computer Software]. Retrieved from University of Phoenix, Simulation, LAW 531 website. Cornell University Law School. (n.d.). UCC: Uniform Commerical Code. Retrieved from http://www.law.cornell.edu/ucc/2/article2.htm#s2-206 The Internet's Premiere Law Portal. (n.d.). Intellectual Property Information. Retrieved from http://www.alllaw.com/topics/Intellectual_property.