Communicating change impact to clients

Question

I am working with a technical client ( means he himself developed that website from some other developer by his instructions and code is now code is completely messed up ) and he has mentioned in the main document that he wants to change the raw code into a class based code and remove deprecated code and and performance issue of complete website code

However when we make changes the client angrily asks why we are cleaning up the code and pushes us to do only the tasks which they assign.

Actually we are doing only changes in those file but code is interrelated.

Suppose he said to change all mysql statements to PDO (PHP Data Objects as an abstraction layer used for accessing databases).

We have two options. Either we create PDO connections in every page or change the db object from config file. If we change in the config file then it will stop working with all other pages where mysql code is running.

So my question is, how can we tell the customer that the changes we are doing have an impact on overall project so they will take time?

Answer 1

Defining Your Problem

I am working with a technical client and he has mentioned that he wants to change the raw code into a class based code and remove deprecated code....we are doing only changes in those file but code is interrelated.

You have three core problems:

1. A client relations problem. Your client is requesting changes without articulating a value proposition. Your client is asking you to make technical changes to the way code is written, but has not articulated a business need or value proposition for doing so. Nothing in project management is free, so there is certainly a cost to making these changes, and the customer should acknowledge that—especially in light of the engineering and communications problems immediately below.
2. An engineering problem. You appear to have tightly-coupled code, and cannot make changes to one part of your code base without changing other portions of the code base as well. This represents technical debt, and must be paid for by the project (and therefore the customer) whenever changes are made.
3. A communications problem. Your team has not done an adequate job of educating your customer about the state of your code base (e.g. tightly coupled, and perhaps inadequately unit-tested), the impact of requested changes throughout the code case, and the potential costs of making changes to working code.

Potential Solutions

All your solutions boil down to improving communications with the client. Your client doesn't have to understand database interactions at a technical level, but the client does need to understand how requested changes will impact other areas of the code.

One way to do demonstrate complexity is through a Mikado Graph (see The Mikado Method). Alternatively, you can use RSpec unit tests in documentation format to show areas of the code that will be impacted by proposed changes. Regardless of how you do it, it is incumbent on the project manager to clearly articulate the costs associated with a change request.

Change requests should be welcomed, but the scope of the request should always be clearly understood and made a visible cost to the project. If your code base or process lacks maturity, it may be difficult to accurately scope a change or to estimate the costs of that change. If that's your case, then articulating the cone of uncertainty surrounding your estimate of the change request is the very least you owe your customer.

If changes are routinely bigger than expected by either the customer or the team, your job is to identify the technical debt that is creating inefficiencies. It is then up to the customer or Product Owner to determine whether paying down that technical debt should be a priority, or whether the project will simply accept the ongoing debt as a cost of doing business, and accept the additional costs and risks associated with continuing with the status quo.

Answer 2

Ultimately, the customer is paying for the changes. If you are undertaking more work than they requested, then they have every right to be angry with you as you are causing them to incur extra costs. You can explain the benefits to your proposed changes, but the ultimate decision has to remain with the customer, unless you are willing to undertake the extra work at your own expense.

Using your example, making a change to every page may be quicker in the short term, but it risks causing more expense in the longer term. Explain that, while your proposed change may take a little longer, the maintenance costs of making changes in future will be lower and the risk of introducing bugs will be lower. It then becomes their decision: higher cost now; or higher cost later.

Answer 3

Your problem sounds like you have an rather immature functioning change process at play. In a mature change process, when a change request is initiated, a board sanctions an impact analysis that is communicated to all affected stakeholders. This impact analysis would detail what has to change, all the impacts--such as to other code as you indicated here, impact to costs, schedule, and whatever else--and then the board approves or rejects the change. It appears an impact analysis and communication of same are missing.

You need to sponsor a change board and have an explicit process that takes a change request through the life cycle to final disposition. This will enable proper notification to your customer so they understand what is involved. If your customer does not want this, then your project and success are simply at risk.