Proposals (2 of 3) – Terms and Conditions

November 30, 2010

Last week, we discussed submitting the proposal for your project including your sales teams. Of course, there is much you should include in your terms and conditions.

Intellectual Property

Your T&Cs should also address the intellectual property involved in the project. To begin with, there should be agreement on the ownership of the work. Is this work for hire? Or, is the purchase of solution including the licensing of the software? Ultimately, there can only be one owner. So, if you sell it, you can’t re-use it.

Many developers struggle with, or even overlook, the value of their software. But since there can only be one owner, it is important for your customer to understand that you will need to start from scratch, which will cost additional time and expense. In addition, you will not be able to re-use code from previous projects which will be more reliable and robust.

Eventually, Alliance Partners often develop standard modules for re-use. By branding these modules, it may be easier to charge your customer for its use. But don’t make the mistake of simply giving the value away. For instance, ‘Oh, I’ve don’t that type of project before, so I can reuse the code and do it in half the time, so I’ll charge half the price.’ No, the project value is still the same. Your efficiency should be your reward to keep.

Software Licensing

But, I’m not naïve. I understand that customers often want to ‘own’ the software. There is the brute force logic of we bought it, so we should own it. And, the common rationale that you might go out of business, so they just want to protect themselves. In which case, you need to explain the principal of ownership and licensing.

Don’t get me wrong. It is OK to appease the customer by giving them the source code, you just need to provide it with a license so you retain ownership. But, you should consider (and address) the following issues:

  • What if they copy/modify?
  • Can they transfer/resell?
  • Can they reverse engineer

But what if there is an issue with the proprietary nature of the application? No problem, simply define which aspects of the application are proprietary. Then, section out that work which will be done and the ownership will be transferred to them without possibility for re-use and therefore no licensing is required. However, all other development should be provided under license and re-use retained.


Project Commissioning – Part 2

September 22, 2009

In the first part of Project commissioning, we talked about final testing and preparation of the project including the actual shipping of the system. This, week we talk about the on-site commissioning.

Delivery and Installation

Since we completed the FAT, system delivery and installation is always a breeze. Right?  Well, just in case, you should have defined practices for field changes. What is acceptable? Anything that makes the system work? Gets the customer off your back, so you can get out of there? I guess whatever you decide is acceptable, but there should be a method to document the field changes and make sure that all project information is updated accordingly.

SAT Down with Your Customer

After the installation is complete, you should again have a process to validate its operation against the specified requirements. This time for sure, you should have a document validating customer approval before you leave the premises.

License to Drive

You should also have a process by which you clearly transfer all software licenses to your customer. Note that is not sufficient has just taken possession of the system. You should inform them that you are transferring the licenses and some way for them to accept the terms and conditions of those licenses. For instance, they have to break the shrink-wrap, an envelope, or container that contains the associated licenses.

Project Commissioning – Part 1

September 15, 2009

OK, so you are getting close to the finish line – almost done with your project development. You may running on schedule or rushing to meet the deadline, but it is still no time to let lack of project management lead to unnecessary and costly mistakes.

FAT and Happy

Make sure that you perform a thorough Factory Acceptance Test (FAT) as defined by your V-diagram process to validate that your system meets all of the specified requirements. Involve the customer if possible. But, regardless, there should be a formal sign-off sheet with initials by each met specification. Some Alliance Partners even have a formal approval process before the system can be shipped.

In Ship Shape?

While being FAT is good, you still want to be in ship shape. So, take steps to avoid errors and delays. Have you checked to see if your labeling meets any requirements that your customer must have? Do you have a way to verify the complete shipment (e.g. pack slips)? Do you have insurance guidelines for shipments?