CPM/U2 Topic 1 Understanding the Project Contract
Contract is an agreement between two or more parties, to exchange providing a specific work (Scope of Work) with agreed compensations (mainly cost and/or any others specified in the contract) include terms and conditions. The Contract terms and conditions including both parties’ obligation, liability, payment, and other terms and conditions are legally binded. The Contract dispute settlement process and change management work process are a part of contract. In addition to being a signed document, resulting from acceptance of offers by award notices, letters of intent (LOI), and other orders such as POs are one of the contracts.
For example, a project contract may take the form of an agreement between a builder and a property owner in which the builder agrees to build a house on the property by a certain time in a certain way, and, in exchange, the property owner makes certain remuneration. Project contracts are important to have in the event of a dispute.
The Importance of the Project Contract
The success of a project largely depends on the comprehensiveness and the character of the Project Contract. The Contract defines how delivery and acceptance for the product and service will be conducted. However, a lack of legal acumen in Pakistan pertaining to the software industry means that the contracts are loosely defined and rarely referred to. A weak contract for software vendors puts the vendors in a weaker position in terms of asserting delivery against defined scope. IT Managers have their performance benchmark defined by non-IT management and it is always in terms of support availability and cost performance.
Due to pressing demands of enterprise support, IT Managers bank heavily on the vendors for project execution and often pass the buck to them in case of support failure. Furthermore, they demand service beyond the contract and agreed schedule in the name of business necessity, which for lack of a better word was precipitated for budget allocation; especially in the public sector.
Usually in project deadlocks where the contract looks like a distant dream which one can abide to, alternate agreements can be made to baseline requirements at that point in time. Thereafter, onsite presence, over communication of risks and schedule delay and a proactive communication management plan can help vendors close the project. However, all of this can be minimized by showing less exuberance to close the deal and more focused on the contractual details before signing it. To find a regimented way out of such situations vendors can offer a progressive solution delivery model in the project contract, which is to propose a hybrid delivery model that gels Microsoft Solutions Framework with Joint Application Development. This MSF-JAD hybrid delivers a solution through the standard lifecycle until Administrative Acceptance (acceptance by customer IT staff) phase arrives. Project deadlock usually occurs at the Acceptance stage. At this point, if the contract has a provision for progressive solution delivery through which the vendor then outsources the same production staff to the customer on a subscription fees whereby succession, architectural guidance and functional knowledge is provided by the vendor and the administrative management for the operationalization of software solutions becomes the prerogative of the client IT management.
The selling point is that customers outsource project development to vendors simply because they lack the resources and time. Therefore after making the project structure stand on a solid ground, around Acceptance the same resources can be given to the client to manage it themselves for going live with the applications, where the vendor continues to provide architectural guidance and resource succession so that it doesn’t disrupt their operations. The key is in the realization that business ownership of technology enablement is largely the responsibility of the business unit who must be held accountable for it. Therefore the operationalization has to be at a pace where they are held accountable for the progressive cost of resource subscription. Both vendors and customers must realize that project successes come through ownership and conviction, made binding through a model that ensures it in the Contract.
After the administrative sign off the client will be at his own discretion when he chooses to go live with the solution rather than the customer being stuck in the loop of making it go live unable to bear the cost of idle time for its resource when the customer organization is stuck in its indecision to go live.
Such models have been able to work at a decent level where long haul and large deployments can be successful, but usually risk is owned by the organization at the contract level. Until Pakistan achieves maturity in the legal framework for software services and actual litigation cases determine how professional issues in computing are dealt with, vendors will have to rely on innovative methods at the contract level for driving through the environmental issues in Pakistan that lead to project failures.