Research changes direction. Halfway through an award you discover the sensor approach in your proposal cannot reach the required resolution, and a different architecture can. The question is not whether you are allowed to change your mind, it is whether the change stays inside the work the government agreed to fund or becomes something they have to approve first.
Inside scope or outside it
The practical test is whether the objectives and deliverables in your statement of work still stand. Swapping a component, changing an algorithm, reordering experiments, or substituting a test method to reach the same stated objective is normally execution, not a scope change. Those decisions belong to you, and you report them in the next progress update.
What crosses the line is a change to the objectives themselves: pursuing a different technical goal, dropping a deliverable, changing the intended application or end user, shifting substantial work to a subcontractor who was not in the plan, changing the principal investigator, or moving significant money between budget categories. Many of those require prior written approval regardless of how sensible they are, and the specific list varies by agency and by whether you hold a grant or a contract. Read your award terms; they enumerate this more precisely than any article can.
Encouragement is not authorization
This is the trap that catches good companies. You describe the new direction on a call, the program officer says it sounds much more promising, and you take that as a green light. It is not one. On a contract award, only the contracting officer can change the terms, and a technical representative's enthusiasm has no contractual effect. On a grant, the authority may rest with a grants management officer rather than the program officer you actually talk to.
The cost of getting this wrong is that work performed outside the approved scope may be disallowed, meaning you did it and will not be paid for it. Ask directly: who has to approve this, and can you confirm it in writing? Program staff are used to the question and it is far less awkward than it feels, particularly if you established that working relationship at kickoff.
Rebaseline honestly and write it down
When a change is approved, restate the plan rather than patching it. Update the milestone list, the schedule, and the budget together so that later reports have something coherent to be measured against, and make sure the next progress report explains the transition rather than quietly reporting against different milestones than last time. Keep the approval email with the award file; it is the document that answers a question years later at closeout or in a review.
Be honest with yourself about what the change means commercially, too. A pivot that reaches a technical goal by a different route is one thing; a pivot into a different market is the kind of decision that belongs in a wider look at whether to pivot the company, and it should be reflected in the commercialization story you carry into a follow-on proposal.
Projects House helps recipients evaluate a mid-project technical change before it becomes a scope problem. Describe the situation through the contact form.