Schedule & Customer Blame

Question

Here are work we are having some difficulty with, well, difficult customers during the implementation phase of a semi-custom SaaS product. Standard story, I guess, ship deliverable's and then nothing for a week, and then there are "emergency" fixes needed overnight.

If the work needs to get done, it'll get done, but how does one formally delay dates when the lag is the customers fault?

Specifically: Is there some standard (contractual) language, which nicely places fixed deadlines on the customer as well?

Answer 1

Short answer

Don't formalize. Communicate more often.

Long answer

I think this situation calls for better expectation management / communication. Make explicit what you need from the customer and when, and make explicit when they can expect something back and what.

"emergency" fixes needed overnight

If you mean that the moment the customer finds bugs, they need to be fixed "right now": is it fair for a customer to expect this? I think not. Bugs take time to fix and the team should get that time. Tell them beforehand, that they can expect their fixes "X" days after they report them. If they object, negotiate. In any case, make it explicit when they can expect their fixes.

then nothing for a week

So what's going on here? Are they not using the product or just not talking about it? Radio silence? Let me know and i'll update my reply.

Specifically: Is there some standard (contractual) language, which nicely places fixed deadlines on the customer as well?

Yes, you can: there are several ways to put everything down in formal documents (contract, time planning, Service Level Agreements, etc), but consider before proceeding:

1. Negotiating and documenting can take a lot of time, compared to the amount of actual work. You'll want to bill your customer to some extent for all this time spent, so effectively, you just become a more expensive supplier. Project size is key. The larger the project, the more sense this approach makes.
2. What do you prefer? To call the customer each other day and change the schedule if and as needed (negotiate) or grind down all the details beforehand in a contract?

Finally, instead of naming fixed dates, I would recommend to name your deliverables (update, patch, new release, etc) and indicate how much time is needed after the customer delivers their input/test results/etc. That way, when the customer is late with their results, they cannot expect you to deliver overnight.

Hope this is usefull. If anything incorrect / missing, let me know and i'll update my post.

Answer 2

I'm going to describe my experiences from the point of view of a project manager in Information Services. Some of the specifics might not exactly match your specific environment, but the principles are still the same.

This sounds like a classic case of breakdown in communication between the business resources and the technical resources. This can also be a symptom of poor design and poor communication during the early phases of the project.

These "emergency" changes usually stem from features that are perceived to be "missing" from the final product; i.e. The final user expected a feature that isn't there. This is usually the product of a lack of understanding about what the final product will consist of. It is so, so easy for the project team to say "Ok, here's what we need to make. This is what we talked about, this is what they want. Let's get to it." Everyone puts their nose to the grindstone and hammers out a product based on the initial design specs. However, as we all know, the final users typically:

1. Do not have a firm idea of what the final product is going to look like

2. Change their mind mid-project cycle and expect the technical team to read their mind and know exactly what they "really" wanted

To alleviate some of these emergency changes, there are a few things you can try.

1. Have frequent meetings (in-person, phone, video chat, etc.) with the final users to discuss progress on the project and current features. Make sure that everyone is on the same page during each interaction and stress what progress you've made so far and what features the users should expect by the next interaction.

2. Include the final users in all testing steps leading up to release. Make sure the users understand that the product is still in development, but include them in what progress you've made so far. The more interaction the users have with the product prior to release, the more understanding they will have of what to expect from the final product.

3. Document all discussed features and get sign-offs on everything. Write down every feature, produce mock-ups, and make sure that everyone involved in the final product has a firm idea of the rough final product. Having hard documentation of exactly what the users should expect from the final product, coupled with user approval (even if it's by email), will go a long way toward my next point:

4. Be able to say "No." Now, I understand this might be harder when you're producing products for external users, especially if you rely on their repeat business. However, having documented approvals of the features that will be included with the final product will assist you in your argument. If saying "No" is not an option, simply be realistic with the user. You're likely moving on to other projects that have also have a strict deadline, and the user needs to understand that you can only do so much. Add only the essential extra features, but remind the users that in the future, they need to document all necessary features up front while the product is being produced. Hurried "fixes" and "additions" to the final product will often result in a decrease in quality.

As far as "contractual" language, well, an actual contract would be your best bet. If you're able to document exactly what features the users expects, and get everyone on the same page during initial planning and design, then my personal opinion is that it's entirely acceptable to ask the client to sign a contract. Included in that contract should be the features the team has discussed during planning and design, as well as a hard cut-off date on when new features can no longer be requested. Optionally, you can also include a clause stating that any new features requested after the cut-off date will result in additional negotiations for price on those specific features being added to the final product.

For the actual contracts themselves, you can draft your own and put in the specifics I've listed above. You can also edit an existing template to fit your needs. Some templates can be found on 10 Freelance Web Design Contract Templates and Samples by develop-a-website.com.

No matter which you choose to do, I would also get a legal entity to evaluate it for soundness.

I hope that this has helped. If you need me to elaborate on any of these, or if you need additional information, let me know.

Answer 3

You certainly need to formalize this. These are controlled via service level agreements. You have desired objectives for level of severity and criteria to determine at what identified defect will be placed. Then, you simply perform against those SLAs and awarded / penalized pursuant to your performance.

In other cases, you have a cadence for delivery. Some deliverables do not produce findings like a new release of production software but are verified and validated by the customer with findings, then the delivery organization addresses those findings for redelivery. This cadence is spelled out contractually. For example, draft delivery, 10 days for V&V, 10 days for fix, final delivery. If the customer is late for V&V, like 12 days, then you have 10 days after the 12th day. All spelled out EXPLICITLY in the contract. No ambiguity.