Project Scope Management – The Power of Communication.

How to Improve Communication with Clients?

Initially, when drafting this article, I began listing numerous problems encountered in project management, such as how choosing Kanban methodology impacts projects and the challenges it brings.

Reflecting on all the projects I managed, stories of projects ending in failure or even bankruptcy emerged. Each issue led me back to the same conclusion: there is no such thing as multiple distinct problems.

All these "problems" always stem from one source—poor communication between the vendor and the client.

In this article, I'll illustrate this with examples, beginning with one frequently cited "issue": changes to project scope during the project.

What is Project Scope?

Simply put, project scope is a list of all functionalities, objectives, and values that define when a project is considered successfully completed as expected.

Changes in Project Scope During Work – My Opinion

It's common to perceive scope changes as problematic—I don't fully agree. The reason is simple: we cannot always predict life two or three weeks ahead—sometimes even a few days. Projects similarly face unforeseen situations daily, significantly impacting project scope realization.

Of course, we use risk management to anticipate these issues, including vacations, team conflicts, business environment changes, or scope changes.

Scope changes are difficult to budget (ignoring workflow and application quality), primarily due to their inherent "dependency."

My favorite phrase, "it depends," fits perfectly here. Consider a change requiring 30 minutes, where the whole task takes 15 hours; this minor adjustment has minimal budget impact.

But what if a change requires 10 additional hours? That's an increase of two-thirds, significantly affecting the budget.

Budgets aside, imagine receiving negative feedback on a core feature through User Research (more details available in our related article). Implementing necessary changes might then save the application from failure or user dissatisfaction.

Reading the above examples, you might conclude that a "30-minute change is acceptable, while a larger change is problematic." But what exactly constitutes a small change?

This brings us to a critical topic—communication between the vendor (e.g., software house) and the client.

Communication – The Forgotten Element

Effective communication and phrasing are dear to me, something I emphasize greatly. Why?

Many problems in projects, personal or professional life could be avoided if information was clear to both parties. Arguments with partners, family, or friends—how many times looking back have you thought, "this argument was pointless, we misunderstood each other"?

Translate that into project communication.

Imagine completing the UX/UI phase and being halfway through implementation. Suddenly, the client requests a "minor change," later revealed to require 40 hours. The client feels deceived because, from their perspective, it's "small." This isn't their fault; clients aren't obligated to understand development processes.

Choosing appropriate communication and a clear language understandable by both parties prevents such scenarios.

Another example:

During a team meeting, everyone agrees that the application "must be friendly for blind users." Immediately, the team wonders, "What does friendly for the blind mean?" Designers might consider interface arrangement and contrast, while developers think about implementing voice synthesizers. Solutions are ultimately agreed upon during planning, but will the client be satisfied with our interpretation and decisions?

This leads to another crucial element—the Product Owner on the client’s side.

Product Owner – Why It Matters

Who is a Product Owner (PO)?

"The Product Owner represents end-users and product stakeholders in IT projects. Their role is prioritizing, creating and managing task lists, and maintaining constant stakeholder communication. All decisions regarding functionality and project priorities are made by the Product Owner."

Nice definition, right?

Indeed, it's true. However, communication appears at the end, portrayed merely as "maintaining constant contact." What's the point of constant communication if it’s unclear? That’s why we emphasize communication and the Product Owner’s role.

A Product Owner ensuring aligned views between the client and vendor significantly improves the project’s development process. Key principles to establish from the start:

Communication method – email, phone calls, online meetings (Google Meets), or in-person?

Communication frequency – depends on Agile or Waterfall approaches; daily, weekly, monthly communication—no universal answer exists. Consider project specifics, team availability, PO, Project Manager’s time, etc.

Appropriate language – use language understandable to both sides. Avoid overly technical terms when clients have limited technical knowledge.

Openness to questions – sometimes, we don’t fully understand our interlocutor. Feeling embarrassed to ask for clarification is a mistake. Ensuring we correctly understand prevents future disagreements and unnecessary project changes.

Improving Communication – My Advice

Frequent communication and "Daily" meetings have many advantages, though it's not always feasible. If a client lacks a PO and appointing one creates additional challenges (time, costs, etc.), efficient time usage becomes critical. If daily meetings aren’t possible and communication occurs weekly, I recommend written meeting summaries.

Meeting summaries, such as emails from the Project Manager detailing discussions, conclusions, and future plans, help ensure clarity.

Clients/PO should acknowledge receipt. Written summaries greatly reduce future misunderstandings, providing documented references in case of discrepancies.

Phone or online meetings – Personally, I prefer direct conversations over writing, as verbal communication quickly conveys more information and ensures clarity.

Additionally, Google Meets offers recording capabilities (with consent), providing security and reference points for future review.

Combining phone calls with written summaries complements and strengthens overall communication.

Summary

"The power of communication" is often underestimated but brings significant benefits. The main advantage for project teams is peace of mind. Appropriate communication frequency and methods streamline collaboration, reduce stress, and save time. Written meeting summaries optimize everyone's time and facilitate future communication—ideally shared via email. If there’s one takeaway from this article, it’s this: potential "problems," like scope changes during work, only become issues when communication between the client and vendor is neglected.