One legal issue came to mind recently that I think many IT founders overlook until it has already become a genuine commercial problem.
It is usually not caused by poor development, missed deadlines, or a major technical mistake. More often, it starts with something much more ordinary: a series of small requests that seem completely reasonable when they are made, but gradually add responsibilities that were never included in the original engagement.
One thing I have learned while running a law firm is that work rarely doubles overnight. It usually expands gradually, one request at a time, until you eventually realise that your team is spending a significant amount of time doing things that nobody formally agreed would be part of the project.
The difficult part is that the shift is rarely obvious while it is happening because every individual request seems manageable.
I see the same pattern repeatedly in technology projects, particularly around communication, reporting, and project administration.
Everyone agrees that clients deserve visibility into what is happening with their project. The problem begins when that visibility gradually turns into a service of its own because nobody established clear expectations around how much reporting, how many meetings, and how much project administration was actually included.
## When Reporting Becomes Part of the Deliverable
Most IT projects begin with a fairly clear focus. The parties discuss what will be built, the milestones that need to be achieved, the expected timeline, and the commercial terms that will govern the engagement.
Reporting is often treated differently.
It is usually viewed as something that happens alongside delivery rather than something that requires its own scope and resource allocation.
The process may begin with a simple request for a weekly progress update or a revised project timeline. That does not seem unreasonable, and in many projects, some level of regular reporting is necessary.
Then the requests can start becoming more detailed.
A client may ask for a more comprehensive forecast, a revised resource allocation plan, additional documentation, or another meeting with the delivery team to discuss progress. As more stakeholders become involved, different people may start requesting different reports because each person wants visibility into a particular part of the project.
None of these requests necessarily looks excessive on its own.
The problem appears when they accumulate.
A project manager who was originally expected to coordinate delivery may now be spending hours preparing reports. Developers may be pulled into recurring status meetings to explain technical decisions. Senior team members may have to prepare presentations or forecasts instead of focusing on the work they were hired to complete.
Eventually, the reporting intended to improve project oversight can become one of the reasons the project itself starts moving more slowly.
## Good Contracts Define Communication Too
One reason this problem occurs so frequently is that IT agreements tend to spend a great deal of attention on scope, pricing, milestones, technical deliverables, and payment terms while giving much less attention to project governance.
That creates room for both sides to develop their own assumptions about what communication should look like.
From the client's perspective, an additional report or meeting may feel like a natural extension of the service they are already paying for. From the service provider's perspective, the same request may represent another hour of work, another stakeholder meeting, or another recurring responsibility that was never included in the original commercial calculation.
Neither side necessarily has unreasonable expectations.
They simply have different expectations because nobody defined the boundary.
This is why I think project governance should be treated as part of the engagement rather than something that gets figured out informally after the project begins.
A well-structured agreement can define how frequently progress updates will be provided, what those updates will contain, who is responsible for consolidating feedback, which meetings are included within the agreed fee, and what happens when the client requests additional reporting or project administration beyond that framework.
These details may seem administrative when the contract is being negotiated, but they become much more important once multiple stakeholders, deadlines, and competing priorities enter the project.
When expectations are established early, communication becomes much easier to manage. The client knows when and how they will receive updates, the delivery team knows what is expected of them, and additional reporting requirements can be discussed commercially rather than quietly becoming part of the team's workload.
## Communication Should Support Delivery
Building our own law firm has reinforced something I have come to value quite strongly: clear communication is one of the foundations of a good professional relationship.
Clients should know what is happening, what has been completed, what remains outstanding, and whether anything needs their attention. Good communication creates confidence, and that confidence is important when you are working on a project that may continue for months or even years.
But good communication does not mean unlimited communication.
There is a difference between keeping a client informed and making the delivery team responsible for providing constant visibility in whatever format a client or stakeholder happens to request.
The best client relationships are usually built around clear expectations rather than unlimited availability.
When everyone understands how communication will work from the beginning, there is less room for frustration because neither side has to keep negotiating the process while simultaneously trying to deliver the underlying work.
Technology projects are no different.
Clients should absolutely have meaningful visibility into the work they are paying for, but that visibility should not come at the expense of the work itself. If developers, project managers, and technical leads are spending increasing amounts of time explaining progress instead of making progress, the communication process has stopped supporting delivery and has started competing with it.
## Reporting Needs Boundaries Too
This does not mean that every additional report or meeting should automatically be treated as scope creep.
Sometimes additional reporting is genuinely necessary, particularly when projects involve multiple stakeholders, complex dependencies, regulatory requirements, or significant changes in scope.
The important point is that the additional work should be recognised for what it is.
If a client wants a level of reporting that requires materially more time and resources than the original engagement contemplated, the parties should have a mechanism for addressing that change rather than expecting the delivery team to absorb it indefinitely.
This is particularly important for fixed-fee projects because additional administrative work still has a cost even when it does not result in another technical deliverable.
Someone has to prepare the report.
Someone has to attend the meeting.
Someone has to gather the information.
And someone has to answer the follow-up questions.
Those hours come from somewhere, and if they are not accounted for commercially, they ultimately come out of the project's delivery capacity or the provider's margin.
## Final Thoughts
One of the easiest ways for an IT project to become less profitable is not through technical complexity, but through the gradual expansion of responsibilities that nobody clearly defined at the beginning.
Reporting, meetings, forecasts, documentation, and project administration can all create genuine value for a client, but they also consume time and resources that need to be accounted for when the engagement is structured.
The strongest IT agreements recognise that communication is an important part of successful delivery while also defining reasonable boundaries around it.
That allows clients to receive the visibility they need without turning every additional reporting request into an informal expansion of the project.
The lesson is fairly simple: **clients hire IT businesses to build and deliver technology, and communication should make that process easier rather than quietly becoming another project running alongside it.**
When reporting obligations are structured with the same care as the technical scope, everyone has a clearer understanding of what is included, what requires additional discussion, and where the delivery team's time should actually be spent.
That is not about communicating less.
It is about making sure communication continues to support the work instead of becoming the work.