In what position is your company in this example? One super critical piece is determining whether you have secured a sufficient commitment to support the application over time. The time period for support should be clearly specified and the responsibilities of both parties should be clear. If the application is basically built to your specs by a partner, the developer is going to produce an application that provides the specified functionality within those parameters. How will you address changing needs? Do you have the ability to raise changes based on future integrations and interoperability needs? Who pays for (what) changes?
One area of potential oversight is aligning the responsibilities as far as rollout of the application is concerned. Once the application is developed, it needs to be deployed in the client's system. The SOW should specify who is supposed to do what to install and integrate the application.
If the application is being developed for a third party (your customer, for example), then the agreement should take into account what responsibilities the developer will have with respect the application once deployed at the third party site or in the cloud. Who takes the lead in managing services with respect to the end customer?
I think you can see that a precise SOW with a responsibility matrix can be very useful. It should go without saying that you need to be sure the contract handles intellectual property rights and responsibilities correctly. You also should think about the wind down of support and potentially source code.
• Rio Tinto
The "must haves" are those things that are designed to mitigate the risks generally associated with these types of agreements. Those risks are cost and time blow outs. Because we all know that bespoke software ccan be inherently risk (ie it might not actually work....like ever!). I am also assuming you are advising from a customer (not supplier) perspective. In my view, the "must haves" are:
- clear specifications describing what the software will do. The reason will become clear shortly. If (like most customers) the commercial team doesn't quite know what they want the software to do then consider implementing the project via phases with the first phase involving the development of the specifications.
- ensure that you have a robust acceptance testing regime which will test the software and ensure that it works. The testing regime is generally linked to the specifications (so the better the specs, the more chance of being able to confirm that the software does what you want it to do).
- if the software doesn't pass the acceptance tests, then you have to think about what you want to happen. Ideally, customers should not have to pay for defective software. If customers do have to pay, then it is shifting the risk of the software working to the customer - and this is not what the customer is paying for (ie the supplier's skill at being able to create software). But before you get to that point, you would want to see a rectification scheme - giving the supplier a few chances at fixing it up before it is required to give up and refund cash.
- ideally, you want fixed fees for each project. There have been numerous examples of time and materials contracts getting out of control as good money is thrown after bad in trying to get the software working.
- you would also want the project to be delivered by a specific date and, if not, consider if you want to include a liqudiated credit regime. Fixed fees, milestones and liquidated credits are all designed to mitigate cost and time blow outs.
- also, if the project is large, then you might want to consider rolling it out in phases. That way you can ensure that earlier (potentially critical phases) can be achieved and you are not waiting to until the end to find out
- The "M" stands for support. Nothing new here. You want to see clear obligations to correct defects supported by service levels and service credits.
Of course, there are different types of ADM contracts. The must haves I have described above are where the customer intends to shift the risk of the software development to the supplier. If, however, the software development is being done as a "staff supplementation" type arrangement where the supplier is merely providing staff to create software at the direction of the client on the client's site then some of the above must haves are not always appropriate. It will depend on the nature of the engagement.
What does your Finance department hope to get out of this? Do they understand that during a long term contract that they may actually change the way they bank? And the contractual ramifications of that?
Will they consider including a line that directs other companies to your current payment processes and rules on a web page? That way if something changes on the backend, it doesn't effect the contract?
• Daiichi Sankyo Development Limited
Thanksk for your reply Mark. They are trying to push a back end process into the contract area. It's not just our bank details they want to include, but those of the supplier/provider as well. Basically they don't want to be responsible for collecting and commnuicating the information to the other party and think that the contract is the vehicle to do this. I disgree with this and have refused to include it. To my mind, this is not what a contract is for. We could put language in that means any future change would not affect the contract, but I am concerned that this would be the thin end of the wedge and that other departments would start requesting the same leeway.
This is not so unusual. If you have active ongoing contract management and your firm is not so large as to have a more developed electronic presence, it's actually not too difficult to manage this issue. You can say that the seller reserves the right to change it upon notice. You send out a letter with a countersignature/acknowledgement when it changes. At a certain scale, I would not recommend it. However, it's not as bizarre as it seems.
• Independent Consultant
I am not surprised to hear this as many departments don't want take the responsibility of collecting and controlling potentially variable data. You may try to make a contract requirement that vendors provide bank details in their invoice. Therefor it would be apparent to AP whenever an invoice is processed. Vendors may push back on this, although I feel in the future this will be common information provided by vendors to assist in prompt payment of invoices.
In my organization (global level corporation) our standard templates include a section for supplier banking information, but I have never seen it used. Instead, per guidance from our internal Legal, we fill in the blanks with N/A and then insert a one line statement to the effect that Company shall make payment to Contractor in accordance with the most recent electronic funds transfer authorization or banking information provided.
We did use an internally developed CIP timesheet just make good of MS Excel.
will be glad to share with you.
There are just so many options out there. Obviously the right solution depends a lot on the scale of use and exact purpose. Also, the extent to which you want integration with other systems - for example, billing or project recording - and the extent of reporting and analytics. Replicon has a fairly good name; I have heard some good things about Deltek and OroLogic.
Yes, change management is an essential part of effective Contract Management and every successful telecom company will have its own individual process and tools to support such process. Principles should be the same but process and tools will obviously vary so I don't think there is a std process per se. I would say that change mgt process in the telecom industry is not as well established as the construction industry where the discipline itself is well understood and implemented.
• Phillips 66
I would think the change management process for telecom wouldn't be substantially different than that for any industry. If you talking about construction or major works change management is essential to contract management. No scope of work is detailed enough on a major project to cover every nuance. So changes occur and the two parties should have a clear process for elevating change requests, approval, costing and then moving forward. This process should be clear enough and timely enough by both sides to not create delay or raise costs with the process. As in many instances time is also a crucial factor in costing for this work.
• TECHNIP INDIA LIMITED
There are a few basic rules to be followed in preparing for and presenting claims. These are:
1. Consider the possible areas for claims from the start of the Contract and plan accordingly; Don't wait until they happen.
2. Keep accurate records from the start of the contract - in particular a good, factual diary
3. Ensure that the records are such that it is possible to trace the number of Man-hours spent on revisions to each drawing and particular reasons why such revisions became necessary.
4. Make a record of the requirements for the giving of notices and ensure all key project personnel concerned are made aware of these.
5. Ensure that all correspondence with and from the employer which could have an impact on claims is reviewed, as are all minutes of meetings.
6. In presenting the claim, make sure that it contains :
a) a short executive summary
b) clear references to the terms of contract on which the claim is based
c) all essential data required in order to understand the claim
d) copies of the programme, minutes and other document supportive of the claim.
- Natarajan BALACHANDAR
I agree with the first responder to the question ("Anonymous"). I have seen a wide variety of approaches, including just ignoring it. Obviously, I cannot recommend the latter.
If you are going for a "best practice" orientation, I would suggest having at least SOMETHING in the contract concerning change management. The boilerplate clause to the effect that "all amendments, modifications, or changes of any kind must be approved in writing by duly qualified officers of the company "is NOT a sufficient description of a change management program. Do not let anyone tell you that it is enough.
Ideally, you want to include at least a brief provision describing a high level process or requirement. What the above suggests, however, is that there may be a big gap between what a contract drafter desires and what the operations/delivery team is equipped and trained to handle.
Candidly, the essential first step is sitting down with your team to understand what they are doing or NOT doing today. Then you will need to map the actual practices (or lack of them) to a reasonable change management workflow. Remember that every person's output eventually will be someone else's input or trigger. The workflow should flow back to a stakeholder who owns the profit/loss (or that person's delegate).
Natarajan's outline of basic rules looks very good (he is of course highly qualified, as you see from reading his profile), but even if you adopted this today you still need to ensure that your operations/delivery organization understands how a paper process meets the actual business needs. You also need to ensure that your business stakeholders have learned the importance of change management in preserving profitability and ensuring quality. If you do not secure this support, you may see a lack of acceptance of the change management process and ultimately discover that people will not follow documented processes.
• TECHNIP INDIA LIMITED
WELL SAID, MR. EDWARD WILLEY.
I will add one small point. In any change control process, make sure that, as far as possible, change requests/variations etc. are notified during the course of a project. Too often, I've had to try and deal with situations where these claims and variations are presented in a rolled-up claim/counterclaim process at the final account stage. Inevitably this leads to a confrontational situation that tends to slide towards litigation.
• TECHNIP INDIA LIMITED
Yes. I take the advise of Mr. David RuddiMn.
Thank you everyone for your comments and recommendation. I will take note and starting to implemented as soon as posible.
Cory, this is an important area, yet you are right that there is little specific guidance around. Assessment is complicated by issues of predictability. For example, in a logistics contract, you can most likely predict the risk that you will sometimes need part loads or rush items and you can therefore examine the cost of this and consider alternative terms that might generate overall savings. At the other extreme, you may know that supply disruptions due to weather conditions are likely, but youc annot easily predict when or which contracts they will affect.
There are various resources in the library, including some excellent material from Bob Endres at Synaptic Decisions (and I suggest you may want to discuss your project with Bob). Deloitte have also done some work on costing of supply chain risk and I could send you a copy of some of their suggestions. Finally, I'd be happy to schedule some time to talk through a few ideas and approaches I have used or observed, so get in touch if you would like to do this.
This is one of the items we are currently looking at here in Ericsson. The method we used was a risk assessment whereby we scored a test pool of contracts on a multi-part worksheet full of questions on a range of areas. We compared the results of the risk assessment to the financial performance of the contract. The test pool included different types of contracts so that we could get insight into several areas of the business. The major challenge in creating the risk assessment was creating the worksheet, including the right questions and the most useful answers. One of the big challenges to getting helpful results of such a study is that customer relationships have a big effect on the financial outcome of a contract or project. How much of the risk was mitigated by a strong sales team? The lawyer in me says this: The serious risk associated with many non-operations terms in a contract is not manifested until there is a serious dispute. Think about a clause like a cap on liability. You will not know how bad it is until the bridge collapses. Even if liability is capped at 100% of the contract value, a $2bn court judgement would take a serious hit for all but the largest companies. By contrast, you can more easily manage the operations terms such as the Statement of Work, commitments to following product specifications, a strong change management clause, recovery of costs for delays caused by the customer, etc. Those should have a direct, immediate benefit. I highly recommend that you take a look at these clauses.
I understand their point - although at the same time, they may be interested if this leads to price reductions. i guess it depends a little on what proportion of overall cost this supplier represents and the extent to which there are alternative supply sources. In general, customers do expect the supplier to manage the in[ut costs of its own product or service. if you face particular volatility, it is really your job - not theirs - to manage the risk part of that risk management will be to determine a frequency for price reviews and potentially the factors that will be considered in price changes.
Ask your bank for a form for a letter of credit...which you provide to your customer as the form of "guarantee" you would want. They will have the LC issued by their bank which will be confirmed by your bank. The terms for draw down as beneficiary (your organization) is also normally provided in the PO.
Call if you want to discuss.
Something may be lost in translation, but my understanding is that a bank guarantee is generally a mechanism activated on payment or performance default.
Maybe they mean something closer to a bank draft? However, I am a suspicious sort and would wonder why they do not undertake to pay you directly from their own funds in the normal course of business.
If all they are doing is adding an extra layer of security to their indebtedness to you, then all may be well and good. If not, it might be advisable to have the payment guaranteed by a reputable bank or investigate other mechanisms ( letters of credit, escrow accounts etc.)
• Uhde India Private Limited
I have never came across Bank Guarantee as a method of payment.
Bank Guarantee is an instruments which stands-by as a security against default.
Does Bank Guarantee as a Payment method means , encashing the Guarantee on due date ? during credit ratings - the defaults /encashment of any financial Instrument has negative imapct on the overall credit rating of the firm.
Pl rechack the understanding.
The letter of Credit is the most commanly practiced method of secured payment.
• SUN Pharma
PBG is also a method of payment.
As I understood from the brief query that the local customer is asking for Performance Bank Guarantee /PBG (may be Vendor is claiming % on contract value as an advance ) , Yah! another form is also Letter of Credit .
In case of PBG, the purpose is to secure the purchase price paid against the products and Bank's guarantee on the performance obligation under the contractual arrangement (e.g.P.O.). See below part clause, where we cn understand the intent of the customer for PBG.
"...... the purchaser, shall be the sole judge of and as to whether the supplier has committed any breach or breaches of any of the terms and conditions of the contract and the extent of loss, damage, costs and expenses caused to or suffered by the purchaser on account thereof and the decision of the purchaser that the said supplier has committed such breach or breaches as as to the amount or amounts of loss, damages, costs, charges and expenses including due to faulty design, faulty materials and bad workmanship caused to or suffered by or that my be cused to or suffered by the purchaser from to time shall be final and binding on us notwithstanding any difference between the PURCHASER and the SUPPLIER or any dispute pending before any court, tribunal application or any other authority to form. " Sometimes, a Contract Attorney includes a specific clause for conditional PBG in the contract/P.O./Supply Agreement/Tender and plz note it has a max. legal implication and consequences. Pay extra attention on the wordings mentioned in the Contract/P.O.; See whether this sentence is mentioned or not (i.e. "Time is the essence of this Contract"). If yes, then especially, we hv an obligation for delay in delivery. The PBG should be drafted/vetted in line with the main contract/P.O./Transaction document to mitigate the contractual risk .