In my software development project, the type of contract is fixed and the client gave the requirements. In the requirements, there are detailed specifications The client then asked for additional work that is related to the scope of the project.
Are these additional tasks considered as out of scope?
Staring at a 20-page SOW and contract in the IT world, it sometimes is very hard to determine if a request is out of scope, so looking at your three-line description is even more difficult. It would depend on what you mean by "detailed" and how the additional work related to those details.
Also, you commingled terms: specifications describe what will be finished and work describes (for many) the action to derive what will be completed.
So it is unclear if by work you mean they are asking to you for three additional coats of paint to the two you already completed (in scope) or asking for another wall to be painted (out of scope) or to hang fifteen paintings and pictures on your completed wall (out of scope) or to replace the electric outlet and light switches plates (iffy but likely in scope--this would depend on your assumptions, exclusions, etc., clearly articulated in your contract).
Since this question is difficult to answer, I hope the wall analogy would help you derive additional questions that would help you yield your answer.
If it's "required" to allow the project to work as it was functionally described in the specification, but it came out as you were working on the project, then it's both parties fault and you need to negotiate the terms with the client (costs/timelines).
It might be good for you to give further details for a better answer.
First acknowledge the clients' great idea.
Then confirm that you are going to add it to the backlog for consideration once the team has delivered the agreed functionality, as you agreed in the contract in the section covering this eventuality.
Finally make it clear you don't want to distract the team from delivering the project as agreed and that you will commit to reviewing all of the additional work identified by the client for a second project. Make it clear that the customer would be wise to run the delivered software for a while to gain an understanding of how it works in production and how it can be improved in the light of experience.
This will be managed with communication skills.
If you produced a scope statement that was approved by them and you really know that the scope was like 1+1=2 and now is like 1*2=2, try to evaluate if the goal of the feature produce same results and if they are willing to accept it if this does not change all the process. It will depend on how your product or service is delivered. (easy to fix?)
If you believe, after an analysis, that your on track with the project and it does not represent a huge impact or rework, try to evaluate if you can assume it with disclosure that this will be handled as an exception.
If it is completely risky, try to make reason the customer and try to deliver a release v1 and then v2 on a later phase with another scope and budget.
If the change was produced by a huge reengineering by the customer then there is no choice that they should assume this change with the impact in time and cost. If you maybe can prioritize some features and you can still deliver basic functions, you may produce an outcome.
Try to negotiate first before to make a change or go up in hierarchy.
If there is no chance to close a deal then produce a formal change request since your baseline was modified and make validate by customer formally specifying how much time and money will cost.
If there was not scope declared even if these come from fixed contract, you jeopardized your project. It will cost you money and time. You should have stated the limits/scope for each requirement that customer requested from SOW.
