Tom,

In my experience in these situations you’ll typically run in to issues with the client regarding ownership.  Most require that if they’re paying for the services they own the assets.  We use to share ownership (but didn’t allow them to resell it).  This seemed to resolve the issue of support since they owned and could modify the code and we didn’t guarantee compatibility with future versions.  We’d usually engage in a paid capacity to make changes.

I can’t think of a time in which we provided a warranty with the work.  At the time our engagements were T&M and everything operated under those circumstances.

Should the asset make its way back in to the product we would inform the customer so they knew they could upgrade to get similar functionality.

Not sure how helpful this is but thought I’d share the experiences.  Feel free to contact me if I can help further.

Don

My team has been discussing similar questions. We are frequently asked to provide custom extension or integration modules between our
products and our customers’ pre-existing hardware/software. The discussions go around and around and end up on the 4 topics that you
listed.

When a PS team does these customizations, it gives us as vendors a lot of power. The customer is dependent on some code that is limited in
support, maintenance, or upgrades. And this little bit of code generally also impacts a much larger software purchase and
relationship between us and our customer. Our product just got very sticky, and we’ve got the customer in a vulnerable position when it
comes to future incremental services.

At the risk of being philosophical, I find myself representing a pretty liberal opinion on some of these positions. These
customizations and extension requests usually represent a feature that the customer wishes the product had. When we provide these features
in a service offering, the customer returns to their normal business, and they’re happy with what they purchased - and they consider the
extensions we wrote as part of the product transaction! The subtle distinctions between the product part and the services part are
generally a source of confusion for the customer, so we should cleave as close as possible to the terms of the product-support agreement.

My recommendations:
- Ownership: This is the key part. If the customer CAN maintain the deliverable (if it’s a perl script, or some sort of wrapper), then
give them ownership. You’re off the hook for upgrades, support, etc. It’s their code now - of course, you’re prepared to sell them some
support, but they’re not beholden to you; they have another option.  Conversely, if the customization is compiled code or is IP of the
crown-jewels level, then we have an obligation to provide some sort of mechanism for Warranty, Support, and Maintenance (and we’re suddenly
dragged in the product business...)

- Warranty, support, and compatibility: Picture yourself as the customer. How does your language read to them? Usually, we write
these so that it protects us. My team came to the compromise position similar to what you discussed. We provide 90 days as part of the SOW,
and we pre-negotiate a weekly rate (hopefully lower than standard), so they can invoke that clause and pay us on an ad-hoc basis. The big
benefit here is that all of the contracts are in place - when they need us, we’re executing, not starting a contract negotiation. Make
sure you include your standard lead-time language and any associated
travel-expenses clauses.

- Communication: At the completion of the SOW, we have a closure meeting and covers in very pointed and explicit detail exactly what
parts of their purchase apply to the separate support arrangements.  We also provide a copy of the deliverables to our support center so
the support folks can reference the already-communicated support boundaries, and the whole company is [hopefully] communicating the
same message. Important point: All calls go to the support center - the support center escalates to PS as appropriate. The support center
NEVER says “that’s not part of the support agreement; you have to call the PS team”. (this will happen unless you head it off)

I guess all of this early morning blather really boils down to a short list of concepts:

- first, try to get ownership onto the customer. Yes, you give up some IP, but you also release yourself from support obligations.

- be careful with this language and make sure that it’s equitable.

Avoid the urge to use this language to only protect yourself. If one of your providers gave you this language, would it build trust?

- we’re PS, so we our business model dictates that we charge for things like support, warranty, and upgrades. Pre-negotiate the rates,
T&Cs, and like matters. When you customer has their hair on fire, this frees you up to be more responsive.

- as always, clear and explicit expectations are key. We, the vendor, have to provide consistent messaging. We also have to over
communicate to the customer.

My 2c - as always, comments and disagreements encouraged!

Carl I.

We do the same thing on IP, give dual ownership with the restriction that they can’t re-sell it. We’ve run into a couple situations where a client simply won’t budge, they want full ownership and no re-use on our part, we generally just cancel the contract and dis-engage in those situations. Being part of a product company, we get the same requests from many different clients and it’s not worth the hassle of keeping track of all the IP restrictions.

We don’t generally do maintenance agreements either. We give them 60-90 days after delivery to report issues, after which it’s a T&M deal if they need fixes or changes made. Our projects are smaller (<150 hours) fixed-bid deals, where we’re integrating our products into other 3rd party apps or extending existing product functionality.

Matt

Hi Tom,

This is a fairly common occurence in our industry and my responses below:

1. IP: this is usually negotiated and I agree with your starting position. You may end up at a joint ownership where you have the right to distribute but they dont.

2. Warranty: I typically do 1 month for PS work though it is not that meaningful. Once the work has been accepted, a 1 month gives the client extra ‘comfort’ - - thats all.

3. Support: You could offer that if you own the IP completely, you will provide support. If you dont own the IP, then, you cant support it. And you can package in some days for support.

The other option, if not tied to IP, is to just offer it as n% of PS fees (20% or so) and you will support it.

4. Compatibility is always subject to IP ownership and additional PS work atleast.

Tom,

I’ve had similar experiences as noted by some of the replies (build and deliver - get the customer to own it) but have also had a completely different take when it involved solutions with software products.

In the case where a customer wanted extended functionality to a database or a whole developed application on my company’s programming language or middleware, the customer couldn’t take ownership as there is no ability to maintain the code (they don’t have robust IT or the development tools required, for example).  And since the functionality wasn’t technically part of the products, the product support/maintenance didn’t cover it.

What we ended up doing is setting up a small PS Support center which got calls routed from Product Support or directly from the customer to support the build solution.  This commanded an additional support fee similar to a product based pricing (x% of the solution price) which then had to have a strict SLA around what was covered (compatibility with upgrades, etc.).  A whole support model was put in place, etc.
What ended up happening is the solutions were delivered to multiple customers then engineering determined it would be added to the product base.  When this happened, the customer support agreements were modified to switch over to strictly product support again.  It was an interesting evolution in the product/customer relationship - where PS ended up being the middle man to meet the needs of the market place when the product team didn’t want to invest in large, possibly un-reusable/un-resellable, product changes.

Thanks,

Jodi C.

I agree with Bala’s comments but I would just add that any warranty from professional services on software may impact the revenue recognition of said software and therefore should be limited. This is only a major point for PS efforts that are part of a software company such as BMC, CA, HP, Oracle.

In other words where software is sold as a package and PS work is required to customize or adapt that software, the revenue usually can not be recognized for the entire software sale until the warranty on the additional work has expired.

This can lead to conflicts between PS and software sales and affect revenue flows.

Cheers ....  Alan

Very interesting Jodi,

We’ve always turned those opps down, because of the support and upgrade headaches. How did you work around the cart/horse problem, where you need several clients doing this to make it worthwhile to setup the PS Support center, but you typically need a PS Support center setup before you can offer this kind of solution to a client? Was this a corporate initiative with front-end investment, or did it just evolve over time into a more formal setup as you added clients under this model?

If you’re willing to share, of course....

Matt - there were a couple of advantages that made the PS support make sense.
1) client feedback through executive councils/user groups were requesting essentially the same functionality - but only larger clients
2) the opportunities were sizable ($500K to $2mil) which allowed more funding flexibility
3) a focused team ended up evolving around the development/delivery of the extended solution since it was repeated - and the team performed ad-hoc support in addition to delivery (shadowing giving a knowledge transfer to other resources)

Feel free to talk with me offline if you’d like more info

Thanks,
Jodi C.