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:
- 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.
- 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.
- 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.
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.