Dealing with Severe Client Delay

Question

I am working on a website project for a large e-commerce site that is suffering from delay that can be mostly attributed to the client.

The client is requesting significant resource at our end (4 developers, 2 testers, 1 pm). We develop in a Kanban-style approach and wish to release every 3 weeks.

Whilst we complete between 6 and 10 user stories in the release timeframe, the client usually manages to do UAT on 1 or 2 only, frequently requesting changes - that we have a policy to accept.

The client is requesting backlog work to be started when resource is available. After 3 releases we now sit on a huge mountain of work that we deem ready for client approval.

I usually try to keep the inventory of unfinished work low, but in this case it keeps growing. We now regularly have issues with conflicts when merging feature branches to our release, costing us time and money that is not agreed with the client.

The situation has been raised with the client time and time again, to no avail. Our higher management is not willing to put too much pressure on the client, yet we have KPI's on estimates vs. cost that are heavily impacted by difficult merges. Our estimates were quoted to the client with a velocity factor of 1.5, we currently average at 2.8, making the team unprofitable.

I really would love to know how others in a similar situation have dealt with this.

Answer 1

Wow - your cup certainly runneth over with ALL of the usual challenges that software (or any other type of) project teams face - ever increasing backlog, unreasonable customer demands (and poor support for their own deliverables) and a management/ sales team that is unable to say No to the customer. I'm not sure how senior is the delivery team's manager - but clearly they are not able to make an impact so far trying to say No to the management either!

The interesting thing you have said is you are doing things "Kanban-style". I'm personally a big believer of Kanban. I'm co-founder at a company where we use Kanban for all our product development as well as for our customer-implementation projects - so your situation is very familiar. We started using Kanban about 3 years ago - and since then, we have rarely faced the situation you are in. We do the 3 basic things Kanban talks of - we visualize our work (so everyone, including our own management - and our customers - can see all of the work being done), we have WIP limits that we try and follow stringently (tho' we do have the occasional WIP limit violations) - and we manage flow.

In the last 3 years, we have been able to demonstrate what our teams' throughput is, we have historical data of what our team can deliver in a certain amount of time, and we have analysis of all the bottlenecks in the overall workflow. All of this has enabled us to completely change the way we manage our product development and run our projects.

1. We are no longer concerned about estimation and delivering to those estimates. (BTW - we also have a 3 week release cycle, tho' when needed or possible, we make that 2 weeks or 4 weeks). The key thing is that both management and customer know that they WILL get a release every 3 weeks - and they know that if something does get missed in a release, it will typically be definitely delivered in the next one.

2. The internal and the customer discussion has changed from resource utilization/ planned vs. actual monitoring to prioritization of work to make sure that the teams are working on THE MOST important features, enhancements, defects that they need to be working on. The customers love the fact they don't have to spell out everything and "freeze specs" up front - and that they can reprioritize requirements if needed, till the 'last responsible minute'.

3. It has made it easy for the 4 key stakeholders - the team, the team manager, senior management and customer - to have a transparent and rational discussions on what the team can deliver and what needs to be done in the next 2-3 release cycles. Moreover, it has made it possible for them to review what bottlenecks (blockers) hold up work the most (including customer-side delays) - and what needs to be done to resolve them so that the team itself can focus on delivering value.

Whether your Kanban system has historical data or not, there are a few things that you must do:

1. The team and your own senior management must have an open discussion on how to resolve the gridlock you are in - and find a way to move forward.

2. Your team and the customer need to have a similar discussion on what is possible and what is not - and get agreement on that.

3. Your senior management and the customer might need a separate discussion to ensure that all stakeholders are on the same page.

None of these are easy discussions to have, especially given that you may have already tried it. The ONLY way to change that would for your team leadership to say NO to what the team cannot do - and force a change.

Having a Kanban system with some good historical data would be invaluable to facilitate these discussions. If you don't have the data yet, start collecting it. That may also mean changing your method from 'Kanban-style' to 'Kanban'!

Cheers!

Answer 2

Defining the Problem

The client is requesting backlog work to be started when resource is available. After 3 releases we now sit on a huge mountain of work that we deem ready for client approval.

Your client is violating basic work-in-progress (WIP) limits by requesting work they are unprepared to review or accept. Whether or not this is deliberate, the real failure lies with your senior management since they are failing to manage the client's expectations or actively work to resolve the process issues your organization is facing.

Below are three simple rules for managing the client/vendor process, and ensuring that you aren't left holding the bag for pervasive process issues that are clearly owned jointly by the client and by your senior management.

Three Simple Rules for Preserving Your Sanity

Rule 1: The client doesn't get to dictate your internal processes. This should be made clear by the client/vendor relationship, your contract, and the collaboration process you hammer out jointly.

Rule 2: The client is responsible for timely performance of their responsibilities, which include providing feedback and user acceptance testing within agreed-upon time-frames.

Rule 3: If your client will not hold up their end of the cooperative process, or if your management team does not have the leadership skills to either incorporate client responsibilities into the contract or to address process problems with the client, then you should definitely start looking for a job where you will be more successful.

If you choose to ignore the rules, then (statistically speaking) you will join the 68% of IT projects that routinely fail. If you don't enjoy being a failure, then you can either assist your client and your management in reforming the process, or you can get out before the project implodes. It's your career, so the choice is entirely yours.

Answer 3

You can split the Kanban system into two separate systems. The system upstream from the user step, and the system downstream of the user step. The user step will not need any WIP limit. When reporting the statistics, you say something like "lead time from commitment until ready for UAT is 7 days and lead time from after UAT till go-live is 3 days". If you want to report the total lead time you can do that as well, and it may highlight the "issue" to the customer. However for general process improvement and planning purposes you should consider it 2 separate Kanban systems.

When the customer is ready and willing to be part of the Kanban system (which should not be forced), and they are prepared to limit WIP, and use pull etc, then you can join it back to a single Kanban.