In an software development project where we are planning to release every three weeks, I have a client who has been delaying the UAT for a release candidate by about 4 weeks.

Senior management don't see the need to push them, but this is causing us issues. In order for the team not to get to a grinding halt we have started work on some future features, but these are after some minor change requests to the initial work conflicting and will take substantial time to integrate back into the next release.

The client relationship is difficult to say the best. How would you communicate the difficulties to the client. Requesting for funding is not an option.


I differ from the opinion of @CodeGnome. Processes and plans cannot be one-sided - they need to be agreed on by all parties to the project or any system. In your case, the client is clearly not in agreement with you - for reasons that you have not spelt our or perhaps you are unaware of. Neither is your senior management willing to work with you to solve your problem. Why is that?

You cannot have a "plan to release every 3 weeks" when the customer is delaying the UAT by 4. It would appear the client is not participating in prioritizing work for the next release, nor in reconciling change requests with original scope of the project (altho' your sentence "but these are after some minor change requests to the initial work conflicting" is not very clear.)

In my opinion, you have to either find someone who has the respect and/ or authority to conduct this discussion or take it upon yourself - it might very well be you since you are leading the team - to have an open and sincere discussion about the challenges you and your team are facing, and by that token, so is the customer and so also the management. After all, there is a financial cost of delay which the customer is incurring! By all means, also be prepared to offer solutions - such as getting your team to pitch in to write UAT cases (there must be a reason why they are delaying UAT!) or anything else that helps resolve things.

You all need to get to the root cause(s) of the situation, work out a process that everyone agrees to, and the objectives - both functional and financial - of the project. Only then can you see success moving forward.

In my (far too many) years of experience, I have gone thru many such experiences (difficult customers, reluctant management) - and what has ultimately worked is for sane men and women to get together, get some perspective and resolve things. Unfortunately, almost always, it takes far too long - and the people who suffer the most is the team working on the project.

Hope this helps - and you are able to have that conversation with the customer. Once you have agreement on the process, by all means, 'stop the line' the next time this situation develops.

  • 1
    Thanks Mahesh, I'm having these conversations. We make small - non-conflicting changes that we add to the features and provide our UAT cases - partially to confirm the actual requirements where they feel ambiguous and partially to help the client.
    – Hans
    Feb 26 '15 at 23:26

Use Jidoka as a Process Control

In Kanban, which heavily relies on the cooperation of all parties to adhere to the defined queues and work-in-progress limits, the correct thing to do when there is an error in the flow is to "stop the line."

This does a couple of useful things:

  1. It ensures that errors do not propagate downstream.
  2. It ensures that production/process errors are made visible throughout the organization.
  3. It prevents work-in-progress (WIP) limits from being violated, as incomplete work in the UAT queue should count against the agreed-upon global WIP limit.
  4. It prevents cascading errors caused by working on future iterations when the current iteration is incomplete.
  5. It makes the cost of the process error explicit, as the line can't continue until the process problem is resolved or the process is re-engineered.

This isn't a communications problem; it's a process problem. You need to treat it as such, and apply appropriate process controls to both radiate the information and to correct the deviation from plan. In this case, "stopping the line" is the correct process control.

  • I'm aware this is what we should do. But it also means I have a team of 3 developers with no planned work for them lined up. The client pay us by feature, not by time and materials (which I aim to gradually change). So stopping the line is not a viable option.
    – Hans
    Feb 26 '15 at 22:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.