No IT project runs exactly as planned. That is not a quality problem but the reality of project work. Work packages are reassessed, requirements change during implementation, the client expands the scope. What arises from this is a change request.
Key points:
- Additional effort is not assigned to the correct project budget
- Change requests remain billing-relevant but are not substantiated
- Fixed-price projects come under structural margin pressure
- Project managers cannot create a reliable change request invoice for the client
- Follow-on projects are calculated on the basis of incorrect effort data
What a Change Request Means Commercially
A change request (CR) is a formal requirements change within a running project. It arises when the agreed scope no longer matches the actual delivery scope. In IT project work, the CR is the central mechanism for documenting, assessing, and billing unplanned additional services.
Legally and commercially, a CR is an independent agreement between contractor and client. It must be documented in writing, assessed for content, and in fixed-price contracts explicitly approved before the service is rendered. Without this proof, the service provider has no basis in a dispute for invoicing additional effort.
Change Requests in the T&M Model
With time-and-material contracts, change requests are less commercially critical because every hour is recorded and billed anyway. Nevertheless, assignment to a CR category is useful: for internal project controlling, for client reports, and for later post-project calculation.
Change Requests in the Fixed-Price Model
Here lies the real commercial risk. With fixed-price contracts, the scope is contractually fixed. Every service outside this scope must be documented as a CR, approved, and billed separately. If this process is missing, the service provider bears the costs. According to a PMI study, uncontrolled scope creep is one of the most common causes of budget overruns in IT projects.
Where Project Time Tracking Fails on Change Requests
Many IT service providers record their project times. But recording alone is not enough. What matters is how granular and how structured this recording is.
The Hours Pool Problem
In practice, times are frequently booked to higher-level project numbers. Change requests do not appear as separate entries in this logic. They flow into the general hours pool, are offset against the original project budget, and arithmetically disappear into a variance that the project manager only notices at the next status meeting. By then the team may have delivered 30 to 50 hours of additional effort for which no separate billing basis exists.
The Excel Documentation Problem
Many project managers document change requests in separate Excel spreadsheets or email threads. This information is structurally separate from the actual time data. The result: there is a CR list somewhere, and there are time entries somewhere else. When the invoice needs to be raised, the clean proof is missing: who booked how many hours to which change request, and when?
The Cutover Problem
In IT implementation projects, a particularly large number of uncontrolled additional efforts arise around cutover and hypercare. Time pressure is high, communication runs across many channels, and structured recording falls away. Hours arising in this phase are often the most commercially critical because they lie outside the original scope and can rarely be fully substantiated.
Project Time Tracking with Change Request Logic: What Control Looks Like
The difference between documentation and control lies in the structure of time tracking. Reliable project time tracking in the CR context needs four levels:
1. CR-Specific Booking Structure
Each approved change request receives its own recording category. Hours are assigned to the project and explicitly to the CR. This creates a clean separation between contractually agreed scope and additional services.
2. Target-Actual Comparison at CR Level
As soon as a CR has a defined hour framework, this can be set against actually recorded hours. Project managers recognize early when a CR is running over budget and can take countermeasures or escalate before the overall project budget is affected.
3. Invoice-Ready Proof
Time entries with CR assignment are directly exportable as proof for the client. No manual consolidation from Excel spreadsheets and email threads. The invoice is generated from a single data source.
4. Historical Calculation Foundation
Change requests from completed projects show which scope changes generated how much effort. This data is the foundation for more realistic calculations in follow-on projects.
Practical Example: IT Consulting with Parallel Fixed-Price Projects
An IT service provider with 80 employees runs seven parallel ERP implementation projects. Each project has a fixed price and runs over six to twelve months. On average, three to five change requests arise per project that need to be renegotiated.
Without structured project time tracking at CR level, the project manager manually collects timesheets at the end of the month, reconciles them with the CR list, and creates the proof for the client in Excel. This process takes two to three hours per project per month. Errors arise, hours go missing, clients question the proof.
With CR-specific booking structures in ZEP Compact, team members book times directly to the approved CR. The project manager sees in real time how many hours are assigned to which CR, whether the framework is being exceeded, and can export the billing proof with a few clicks.
{{blog-cta}}
Documenting Additional Effort: From Hour to Invoice
The commercial impact of structured project time tracking for change requests shows itself in the systematic effect across all projects. If an IT consulting firm with 50 consultants cannot substantiate an average of five hours of additional effort per project per month, it loses €6,000 in non-billable services per month at a rate of €120 and ten active projects. Over a year that is €72,000, without hiring a single additional consultant.
Why Project Controlling in IT Projects Must Start Earlier
Many companies run project controlling retrospectively: after project completion or after invoicing. By that point nothing can be corrected. Margins that have disappeared into CR hours without assignment do not come back.
Project controlling at CR level means: making deviations visible before they become commercially critical. ZEP Compact provides exactly this controlling layer: tasks, time entries, resource planning, and project controlling on a single data foundation. Change requests can be mapped as separate work packages, target-actual comparisons run automatically, and project managers see in real time where budget is being consumed.
When Change Requests Become a Symptom
A change request is not a quality defect. It shows that a project is alive. The question is whether the company is structurally capable of dealing with this dynamic in a commercially sound way. Project service providers where change requests systematically lead to margin losses usually have a deeper management problem.
ZEP Professional closes the loop from CR entry to invoicing: invoicing and controlling reside on a single data foundation. Project-to-bill without media breaks is not a goal but the standard process.
Conclusion
Anyone wanting to secure change requests commercially needs three things: a CR-specific booking structure in project time tracking, a real-time target-actual comparison at CR level, and invoice-ready proof without manual reconstruction.
- Check whether every change request has its own booking category in your project time tracking.
- Ensure that your project manager can see daily how many hours are assigned to which CR.
- Test whether billing proof for a CR is possible today without manual reconstruction.
FAQs
How do I document a change request in a legally secure way?
A change request must be documented in writing before the service is rendered. It should contain the changed scope, the calculated additional effort in hours, the agreed price, and the client's approval. In the event of a dispute, this proof is the only basis for invoicing additional services.
What is the difference between T&M billing and fixed-price billing for change requests?
With T&M contracts all hours worked are invoiced, so change requests are billing-relevant but less critical for margin. With fixed-price contracts, every additional effort outside the original scope is not automatically billable. Without a written and approved CR, the service provider bears the costs themselves.
How do I recognize whether a change request is endangering my fixed price?
The early warning indicator is the target-actual comparison at project level: when actually recorded hours rise faster than project progress, either internal inefficiencies or unbounded additional services are arising. Project controlling at CR level shows what share is attributable to approved CRs and what part is unplanned.
Why is Excel not sufficient for change request documentation?
Excel structurally separates CR lists from actual time entries. When both systems are not connected, every billing cycle generates manual effort, error-proneness, and data loss. Client disputes are harder to refute because proof must be reconstructed and no cleanly documented time series exists.
How do I structurally map change requests in project time tracking?
Change requests should be mapped as separate work packages or booking categories within the project. Every recorded hour is assigned to a specific CR. This enables target-actual comparisons at CR level, automatic billing proof, and historical analyses for the project calculation history.
From when should an IT service provider use specialized software for project time tracking?
As soon as more than three active client projects are running in parallel, change requests regularly arise, and project managers spend more than two hours per month manually consolidating time data for client reports, the operational effort exceeds the benefit of Excel solutions. The commercial tipping point typically arrives earlier than expected because non-billable hours are barely visible.
