Who should bear the cost of upgrade? Client or Provider?

Question

We are in the middle of developing iPhone app.

iOS 5 is recently released.

Now if we run the same codes in iOS 5 we get lot of errors / crashes. Should we charge the client to get the code upgraded to iOS 5? Because when we agreed on the contract there was no mention of upgrade to iOS 5. Or is it our responsibility to give code which is working fine? Although iOS 5 upgrade was not in our control.

We did not spend time in testing the code in iOS 5 beta because we thought it would be duplication of efforts if we have to test the code again after iOS 5 release.

Please let me know how you would handle this.

Thanks!

Answer 1

To me, this is a simple answer. It is a change, and it does not matter if it was predicted or not. The original requirements and scope were developed based on the earlier operating system. The scope to be delivered is on the earlier operating system. So if the customer wants the application on the new operating system, estimate the effort, price it, get it under contract, and go to work.

Here's an analogy: You hire a construction team to build your dream house on a plot of land. Construction begins and the foundation is laid. You learn later the plot of land is toxic or over an ancient burial ground, whatever, and you have to stop work there and move your house 50 yards to the west. Will the construction team absorb those costs? Never!

Lessons learned for both of you, however, to make this type of change explicit in your contract in terms of how to deal with it.

Answer 2

I must admit that it's really a complex situation!! It appears to me that this is a fixed-cost contract. Even then I'll go forward and start conversation with the client and making them agree to share the cost of fixing the code-base. I will keep following points in my mind while doing the negotiation

• As a development team, it's my responsibility too to anticipate the changes. Due to that I would lower my prices for providing the fix. May be, no profit - no loss.
• I'll try to figure out whether the client see the relationship long-term or short-term. If they care to maintain the relationship they shouldn't mind paying extra for the effort I am going to put to upgrade the app. And if they don't care I would deny to produce the changes. I will take the risk, risk of losing them and they doing bad-mouthing about my organization.
• I'll be ready with the high-level estimates for the fixes before starting the conversation.

Answer 3

One of the things I learned through the years was having a good "platform specifications" document in place that is version controlled and associated with each particular release of a product. This becomes part of the specifications in that you can point your customer to it and say that so long your environment is listed in the "platform specifications" you are fine. If not then it is a new requirement.

For example we include the operating systems on which our software runs. If an operating system and/or version thereof is not listed we don't provide support of it. Initially that took some learning from our customers but now that we have established this it works very nicely. Of course customers expect that we add new platforms to the specs. But by the same token we retire old platforms that are no longer supported by the respective vendor.

As a result we have a much better defined target environment and can set the expectations appropriately. Our interactions with our customers have become much better because of this approach.

Specifically to your situation, you may not have the platform specs yet. However, if you haven't listed iOS5 initially when you shipped the software then your software has not been designed for it and you definitely haven't tested it either. Your customer would need to pay for making it work on newer or other platforms. You may have other commercial factors, though, that influence your decision about how you want to handle this.