Course image Professional English for the Modern Workplace

Reviewing Progress and Solving Issues in Meetings.

Professional English for the Modern Workplace. Lesson 6.
Clara

This mid-course lesson brings together your meeting, presentation and email skills in a realistic mid-project review. You will follow a case where a team discovers delays and quality problems shortly before a deadline. Through extracts from emails and a review meeting, you will see how colleagues raise issues, ask for clarification, share possible solutions and agree on a new plan. You will recycle and extend language from earlier lessons for giving updates, describing problems, showing understanding and suggesting next steps. Particular attention is given to tone: how to stay calm, avoid blame and keep the focus on solutions. You will then prepare your own short progress review based on a real or model project, combining a brief written update with spoken contributions in a meeting role play. By the end, you will feel more confident discussing problems in English while maintaining a professional, constructive atmosphere.

1. Understanding the mid project review situation.

Clara

In this lesson, you are going to step into a very typical situation in modern project work, a mid project review shortly before a deadline. I would like you to imagine that you are part of a small project team working on a new dashboard for a client called GreenTech. The official launch is in three weeks, but in the last few days some quality issues and delays have appeared. In this first block, we will focus on understanding the situation clearly. You will read two emails. One is from the client contact, Michael, who is worried about the timeline and the number of bugs. The second is from Emma, the internal project manager, writing to the team to prepare for a review meeting. As you read, pay attention not only to the facts, but also to the tone. Notice that both Michael and Emma manage to sound professional, even when they are under pressure. Emma describes the problems without blaming individuals, and she keeps the focus on solutions and next steps. After reading, you will summarise the situation in your own words. This is an important skill for any review meeting, being able to say clearly where you are, what the issues are and what is at risk.

The GreenTech dashboard project.

You are part of a small internal team building a new performance dashboard for a client, GreenTech Solutions. The dashboard is almost ready, but user testing has just revealed several bugs and speed problems. The original launch date is very close.

Before a review meeting, two important emails arrive:

1. Email from the client (Michael).

> Subject: Concerns about dashboard launch timeline

> From: Michael Howard, GreenTech

> To: Emma Lewis, Project Manager

>

> Hi Emma,

>

> I hope you are well.

>

> We have been testing the latest version of the dashboard this week. Overall, the design looks good, but we have identified a few issues with loading times and with the reporting export function. At the moment, some reports take more than 30 seconds to generate, which would be difficult for our sales team.

>

> As you know, we are planning an internal launch on 30 June. Could you explain how these issues affect the timeline? Do you still expect to be ready for that date?

>

> Many thanks in advance for the update.

>

> Best regards,

> Michael

Notice Michael’s tone. He is concerned, but he stays calm, uses facts and asks clear questions.

2. Internal email from the project manager (Emma).

> Subject: Today’s review meeting - GreenTech dashboard

> From: Emma Lewis

> To: Project team

>

> Hi everyone,

>

> As you saw, GreenTech have flagged some issues with performance and the export function. Overall, we are slightly behind schedule. This is mainly due to the extra rounds of testing we added last week, and the late change request on the reporting filters.

>

> I do not want to blame anyone, the important thing is to fix this and protect the relationship with the client. In today’s review at 15:00, we need to summarise the current status, understand the root cause of the problems and agree on a realistic revised plan if necessary.

>

> Please come prepared with a quick update on your area and at least one suggestion for how to move forward.

>

> Thanks a lot,

> Emma

Emma uses several useful patterns from your chunk bank, such as “Overall, we are slightly behind schedule”, “This is mainly due to…” and “I do not want to blame anyone, the important thing is to fix this.” She makes the situation clear, explains the impact and sets the purpose of the meeting.

In a real project, you often need to summarise this kind of situation quickly, for example at the start of a meeting or in a short call. Practising this summary now will help you later when you take an active role in the review discussion.

Practice & Feedback

Imagine Emma has just asked you, at the start of the review meeting: “Could you quickly summarise where we are for everyone?”

Using the two emails above, write 3–5 sentences that:

  • say where the project stands (on track or behind schedule),
  • describe the main problems, using neutral, professional language,
  • explain what is at risk if nothing changes,
  • and briefly comment on Emma’s tone (for example, how she avoids blame).

Try to reuse some useful phrases, such as “Overall, we are slightly behind schedule”, “We have identified a few issues with…” or “the important thing is to fix this.” Focus on clear, calm language, not on perfect grammar. Write as if you were speaking in the meeting.

Key information from the emails.

  • Client launch planned for 30 June.
  • Client testing found issues with loading times and the export function.
  • Some reports currently take more than 30 seconds to generate.
  • Emma says the team are slightly behind schedule.
  • Main causes: extra testing and a late change request.
  • Emma wants to avoid blame and focus on fixing the problem and protecting the client relationship.

Use these points to help structure your 3–5 sentence spoken-style summary.

2. Describing problems and impact without blame.

Clara

Now that you understand the basic situation, we will look more closely at the language Emma uses to describe the problems. In many organisations, the way you talk about issues is just as important as the technical content. If your language sounds emotional or blaming, people can become defensive and it becomes harder to solve the problem together. In this block, you will compare some unhelpful, emotional sentences with more neutral, professional alternatives. You will see how small changes, such as adding “slightly”, using passive structures, or focusing on processes rather than people, can completely change the tone. Phrases like “We have identified a few issues with…”, “This is mainly due to…”, or “From a timing point of view, we need to…” are very typical in English speaking companies. After you look at the examples on the screen, you will practise rewriting a few blaming sentences into calmer, solution focused ones. Try to imagine you are Emma, talking in front of your colleagues in the review meeting. Your goal is to make the situation clear while keeping everyone engaged and willing to help.

Turning emotional statements into professional language.

In stressful projects, it is easy to use emotional language.

> “You completely messed up the reporting export. Because of you, we will miss the deadline.”

This feels strong and may be honest, but it is not helpful in a professional review meeting. It focuses on blame, not on solutions.

Look at some useful patterns Emma and Michael use instead:

  • “We have identified a few issues with…”
  • “Overall, we are slightly behind schedule.”
  • “This is mainly due to the extra rounds of testing and the late change request.”
  • “I do not want to blame anyone, the important thing is to fix this.”
  • “Could you explain how these issues affect the timeline?”

These sentences:

  • focus on facts and causes, not on people’s character,
  • use softening words like “a few”, “slightly”, “mainly”,
  • keep the conversation open and solution oriented.

Comparing unhelpful and improved versions.

Unhelpful / blaming More professional / neutral
You missed the deadline again. We are slightly behind the original deadline.
The developers caused this mess. We have identified some issues in the latest build.
Because of Sofia’s testing, everything is late. The extra round of testing has had an impact on the timeline.
If you had done your job properly, the client would be happy. If we had caught this earlier, it would have been easier for the client.

Notice how the improved versions:

  • often start with “we” or with the process ("the extra round of testing"),
  • avoid strong negative verbs like messed up or caused this mess,
  • use indirect language such as “has had an impact”.

In your own projects, you can borrow these patterns. You still describe the problem and its impact clearly, but your colleagues are more likely to listen and collaborate.

Practice & Feedback

Below you will see several emotional or blaming sentences that would sound quite aggressive in a meeting. Your task is to rewrite at least three of them in a neutral, professional way, as if you were Emma speaking in the review.

For each sentence you choose:

  1. Keep the basic meaning (what went wrong), but remove the personal attack.
  2. Use some of the patterns from the table above, for example: “We have identified a few issues with…”, “We are slightly behind schedule”, “This is mainly due to…” or “has had an impact on the timeline.”
  3. Focus on facts, causes and impact, not on blaming people.

Write your answers as a numbered list: 1, 2, 3… with your improved versions.

Rewrite at least three of these sentences:

  1. You missed the deadline again and now the client is angry.
  2. The developers created a lot of bugs in the latest version.
  3. Because of Sofia’s testing, everything is delayed.
  4. Michael is exaggerating, the problems are not that serious.
  5. If the client had not changed the requirements so late, we would be fine.

Turn each one into a calm, professional sentence you could use in the review meeting.

3. Listening to clarification in the review meeting.

Clara

So far, we have focused on emails and on how to describe problems neutrally. In the actual mid project review meeting, another key skill is asking for clarification. When someone presents an issue, the rest of the team need to understand what exactly is happening and how serious it is. Clear clarification questions help you avoid misunderstandings and make better decisions. In this block, you will listen to a short extract from the GreenTech review meeting. Emma is chairing, and she asks Raj, the lead developer, and Sofia, from testing, to explain the situation. Pay attention to the questions Emma and Michael ask, and notice how they check the impact on the timeline. After listening, you will look at some example question patterns on the screen, such as “Could you explain how this affects the timeline?” or “Do we know the root cause of this problem?” Then you will write your own clarification questions, as if you were another team member in that meeting. This will help you feel more confident about jumping in with good questions in your own real life meetings.

Listening task: inside the review meeting.

In the audio below, you will hear a short part of the GreenTech review meeting.

  • Emma is the internal project manager.
  • Raj is the lead developer.
  • Sofia is responsible for testing.
  • Michael is the client contact joining by video.

As you listen, focus on clarification questions and on any phrases that check the impact on the timeline.

After listening once for general understanding, listen a second time and try to catch specific phrases such as:

  • “Could you explain how this affects the timeline?”
  • “Do we know the root cause of this problem?”
  • “What are the risks if we go live as planned?”

Useful patterns for clarification in review meetings.

Here are some flexible phrases you can use when you need more detail about an issue:

  • Checking impact
  • Could you explain how this affects the timeline?
  • How serious is this from your point of view?
  • What would be the impact on the client if we do nothing?
  • Asking about causes
  • Do we know the root cause of this problem?
  • Is this mainly due to the recent change request or something else?
  • Has this issue appeared before in earlier versions?
  • Clarifying details
  • Just to be clear, when you say “slow”, what exactly do you mean?
  • Can you give a concrete example from the test results?
  • So, if I understand correctly, the export works, but it is too slow?

These phrases show that you are engaged and thinking critically, without sounding aggressive. In your activity, you will create your own questions using these patterns, ready for your next real meeting.

Practice & Feedback

Listen to the meeting extract at least twice. First, just follow the story. Second, try to notice the exact phrases used to ask for more detail.

Then imagine you are another team member in this review meeting, perhaps from operations or support. You are worried about how the issues might affect your part of the work.

Write:

  1. Three clarification questions you would ask in the meeting about the problems or the timeline. Try to use some of the patterns from the list above (for example, “Do we know the root cause…?”, “Could you explain how this affects…?”, “Just to be clear, when you say…, what exactly do you mean?”).
  2. One short paraphrase where you check that you have understood correctly, starting with something like “So, if I understand correctly…”.

Write your questions and paraphrase as if you are really speaking in the meeting.

Clara

4. Proposing solutions and a revised plan.

Clara

You have now seen how the team describe the issues and ask for clarification. The next step in a productive review meeting is to move from problems to solutions. This means proposing realistic options, discussing risks and, if necessary, agreeing on a revised plan with new deadlines and responsibilities. In this block, you will read a short extract from later in the same GreenTech meeting. Raj and Sofia suggest possible technical solutions, and Emma steers the group towards a clear decision. Notice how they use phrases such as “One possible solution could be to…”, “Another option might be to…”, “What are the risks if we do that?” and “Can we agree on a revised deadline of…?”. On the screen, you will see this extract plus some useful language for proposing options and agreeing next steps. Your task will then be to write a short mini speech, as if you are Emma. You will briefly restate the problem, present two options and finish by checking that everyone is happy with the agreed plan. This will help you develop the confidence to speak clearly in the solution phase of real meetings.

From problems to options: a meeting extract.

Read this part of the GreenTech review meeting, where the team start to discuss solutions.

> Emma: Thanks, Raj. So we know the root cause is the way we generate PDFs. One possible solution could be to optimise the current code. Another option might be to generate the reports overnight and just show the results in the morning.

>

> Raj: Optimising the code is definitely the better long term option. Generating reports overnight would be faster to implement, but it adds complexity.

>

> Sofia: From a testing point of view, I would also prefer optimising the code. That way, we do not need to change the whole process.

>

> Emma: OK, that makes sense. What are the risks if we focus only on optimisation now?

>

> Raj: The main risk is that we do not find a solution within a week. In that case, we would need to push the launch date.

>

> Emma: Understood. Michael, can we agree on a revised deadline of 7 July for the internal launch? That would give us one extra week to fix the performance issue and retest.

>

> Michael: I understand your concern, and I appreciate the clear plan. From my side, 7 July is acceptable.

Useful language for solution focused discussions.

  • Proposing options
  • One possible solution could be to…
  • Another option might be to…
  • From a testing point of view, I would prefer…
  • The main advantage is that…
  • Exploring risks
  • What are the risks if we do that?
  • From my perspective, the main risk is that…
  • If we do not solve this, the impact will be…
  • Agreeing a revised plan
  • Can we agree on a revised deadline of…?
  • Who will be responsible for implementing this change?
  • Let us document the decisions and next steps in an email.

In your own meetings, this kind of language helps you sound constructive and decisive. You show that you understand the problems, but you keep the conversation moving towards concrete actions.

Practice & Feedback

Imagine the discussion above has just happened and it is your turn to speak as Emma to move things towards a decision.

Write a short mini speech of 5–7 sentences where you:

  1. Briefly restate the key problem in neutral language.
  2. Summarise the two options (optimising the code, or generating reports overnight).
  3. Make a clear recommendation for one option, with a simple reason.
  4. Propose a revised deadline and ask if everyone can agree.

Try to reuse at least three phrases from the useful language above, such as “One possible solution could be to…”, “Another option might be to…”, “From my perspective, the main risk is that…” or “Can we agree on a revised deadline of…?”.

Write it as if you are really speaking in the meeting, not as a formal email.

Key points from the discussion:

  • Root cause: the way PDFs are generated.
  • Option 1: Optimise the existing code.
  • Option 2: Generate reports overnight and only show results.
  • Testing prefers Option 1.
  • Main risk: optimisation may take more than one week.
  • Proposed new internal launch date: 7 July instead of 30 June.

Use these points to support your mini speech.

5. Practising quick internal chat before the meeting.

Clara

So far, we have focused mainly on emails and the review meeting itself. In many modern workplaces, there is an extra channel in the middle, internal chat tools such as Teams or Slack. Very often, teams quickly align on the key messages there before they go into a difficult conversation with a client. In this block, you will practise writing short, professional chat messages about the GreenTech situation. Imagine it is one hour before the review meeting, and Emma wants to make sure Raj and Sofia are prepared. She uses a chat group to check status, ask for their views and agree who will say what. On the screen, you will see an example chat conversation. Notice how the messages are short but still polite and clear. People say things like “Quick update on my side…”, “Any major issues on your side?” or “Thanks for flagging this.” They avoid very informal language or emojis, because the topic is serious. Your task will be to continue the story in a similar style. You will write several chat messages as Emma. I will then respond as your colleagues and give you language feedback, so it will feel like a small simulation of a real pre meeting chat.

Internal chat before a difficult review.

In many teams, a quick internal chat happens before speaking to the client. It is a chance to align on the story and avoid surprises.

Look at this short example in the GreenTech project chat group:

> Emma: Hi both, do you have five minutes for a quick sync on GreenTech before the review?

>

> Sofia: Sure, I am here.

>

> Raj: Yes, go ahead.

>

> Emma: Quick update from my side: Michael has raised concerns about performance and the export function. Overall we are slightly behind schedule. Any major issues on your side that I should be aware of?

>

> Sofia: From testing, the main problem is still the speed of larger reports. I have logged all the bugs in Jira.

>

> Raj: On dev side, we are focusing on optimising the PDF generation.

>

> Emma: Thanks for flagging this. In the meeting, could you both give a very short update, 1–2 minutes each, and then we will propose a revised launch date of 7 July.

Useful phrases for professional chat.

Even in chat, it is important to keep a professional tone, especially when discussing issues.

  • Starting and checking availability
  • Hi both, do you have five minutes for a quick sync?
  • Is now a good time to talk about…?
  • Giving brief updates
  • Quick update from my side…
  • On dev side, we are focusing on…
  • From testing, the main problem is…
  • Asking for input
  • Any major issues on your side that I should be aware of?
  • Is there anything you are worried about for the meeting?
  • Closing the chat
  • Thanks, that is very helpful.
  • Great, see you in the review at 15:00.

In your activity, you will write your own short chat sequence as Emma, so try to copy this balance of short, clear and polite messages.

Practice & Feedback

Imagine you are Emma in the GreenTech project chat, about one hour before the review meeting.

You want to:

  • check that Raj and Sofia are ready,
  • make sure there are no surprises,
  • and align on who will present what in the meeting.

Write a short chat style conversation of 4–6 messages from you (Emma). You do not need to write your colleagues’ replies, just your own lines.

For example, you might:

  • start by checking if they are available,
  • give a very brief update on Michael’s concerns,
  • ask if they have any major issues,
  • suggest who speaks first in the meeting,
  • and close the chat politely.

Keep each message to one or two sentences, using some of the phrases from the examples above such as “Quick update from my side…”, “Any major issues on your side?” or “Great, see you in the review at 15:00.” Write it in a natural chat style, but keep it professional.

Context reminder:

  • Client Michael is concerned about performance and the export function.
  • The team will probably propose a new internal launch date of 7 July.
  • Raj is working on optimising the code.
  • Sofia has logged all the bugs and knows the test results.

Use this information in your chat messages as Emma.

6. Writing a follow up email after the review.

Clara

In the final step of this lesson, you will combine everything: describing progress, explaining issues, presenting the solution and confirming the revised plan. A very common task after a mid project review is to send a short follow up email to the client, summarising what you discussed and what happens next. Imagine the GreenTech review meeting has just finished. Emma now needs to write to Michael to confirm the key points. This is a chance to show that the team has things under control, even though there were problems. The tone should be calm, positive and solution focused. On the screen, you will see a short summary of what was agreed in the meeting and a simple structure you can follow for your email. Your email does not need to be long, but it should include a clear status, a brief description of the issue and its impact, the chosen solution, the revised launch date and the next steps. This is your mini capstone task for the lesson. Take your time, and imagine that Michael will really read this email. Aim for around 150 to 200 words, and try to reuse some of the powerful phrases you have collected today.

Your final task: follow up email to the client.

The review meeting with GreenTech has finished. Here is what the team agreed:

  • The root cause of the slow reports is the current PDF generation process.
  • The team will optimise the existing code rather than change the whole process.
  • They will focus on this as a priority and add one extra developer for a week.
  • The internal launch date will move from 30 June to 7 July.
  • There will be an additional round of testing before the new launch date.
  • Emma will send a summary email and a brief status update in one week.

Your job is to write Emma’s email to Michael.

A simple structure you can follow.

Subject line

  • GreenTech dashboard – review meeting summary and revised timeline

Opening and thanks

  • I hope you are well.
  • Thank you for joining today’s review meeting and for your clear feedback.

Current status and issues

  • Overall, we are slightly behind schedule.
  • We have identified a few issues with performance, mainly related to the PDF export for larger reports.

Agreed solution and revised plan

  • One possible solution could be to…We agreed to optimise the existing code…
  • This is mainly due to…
  • Can we agree on a revised deadline of 7 July?We agreed a revised internal launch date of 7 July.

Next steps and reassurance

  • Our team will focus on this as a priority next week.
  • Sofia will run an additional round of testing before the new launch date.
  • I will send you a short update on progress by…

Polite closing

  • I understand your concern, and the important thing is to fix this and protect the relationship with your users.
  • Please let me know if anything is unclear or if you need more detail.

Use this structure as a guide, but feel free to adapt it so it fits your style.

Practice & Feedback

Write Emma’s follow up email to Michael after the review meeting.

Your email should:

  • have a clear subject line,
  • briefly explain the current status and the issues,
  • describe the agreed solution and the revised launch date (7 July),
  • mention the next steps the team will take,
  • and end with a polite, positive closing.

Aim for around 150–200 words. Imagine that Michael is an important client contact, so keep the tone professional, calm and solution focused. Try to reuse some useful phrases from this lesson, such as “Overall, we are slightly behind schedule”, “We have identified a few issues with…”, “One possible solution could be to… / We agreed to…”, “We agreed on a revised deadline of 7 July” and “Please let me know if anything is unclear.”

Write the complete email with greeting, body and sign off, as if you were really sending it.

Meeting outcome notes for Emma's email:

  • Today’s review confirmed the performance issue with large PDF reports.
  • Root cause is the current PDF generation approach.
  • Decision: optimise existing code, add one extra developer for 5 days.
  • Expected result: reduce report generation time to under 10 seconds.
  • Revised internal launch date: 7 July.
  • Extra testing: Sofia will run a full regression test on 5–6 July.
  • Communication: Emma will send a short progress update in one week and a final confirmation before launch.

Use these notes to make your email concrete and informative.

👈 Previous lesson Next lesson 👉