Explaining Past Problems and Deductions to a Manager.
Comprehensive English Grammar. Lesson 9.
Sometimes you need to explain clearly what went wrong and what you think probably happened. In this lesson you listen to a short meeting where an employee explains a delayed project to their manager. You notice how third conditionals and modals of deduction, such as must have, might have and cannot have, express regret, speculation and conclusions about the past. You also see examples of reported speech and relative clauses adding precise detail. Through guided practice you build complex but well-structured sentences to talk about missed opportunities and alternative actions. You then prepare and deliver a short spoken explanation of a past problem from work, study or everyday life, first using notes and then speaking more freely. In a writing task, you draft a short follow-up email summarising causes and lessons learned. By the end, you can discuss past problems in a mature, professional way without losing clarity.
1. Understanding the delayed project meeting.
In this lesson, you are going to step into a realistic workplace situation. Imagine you are Alex, a project assistant in a small digital agency. Your team has been redesigning an important client’s website, but unfortunately the launch was delayed by a week. Your manager, Priya, is under pressure from the client and she wants a clear explanation of what went wrong and what you think probably happened.
In this first part, you will listen to a short extract from a meeting between Alex and Priya. Do not worry about every single word. Your main aim is to understand the situation: when the manager found out about the delay, what the main problem seems to be, and how Alex reacts. While you listen, pay attention to the tone as well as the content. Does Alex sound confident, defensive, or unsure? After listening, you will write a brief summary of what happened, using your own words. Focus on clear, simple sentences for now; we will build more complex grammar later in the lesson.
The situation.
You are Alex, a project assistant working on a website redesign for an important client. The website launch was planned for Monday, but it actually went live the following week. The client has complained, and your manager, Priya, needs to understand what happened.
In the audio at the top of this block, you hear the beginning of a short one-to-one meeting in Priya’s office. She asks you some direct questions about the delay. You try to explain briefly and honestly, but you also feel a bit nervous.
What to listen for.
When you listen, focus on these questions:
What was the original launch date?
When did the problem become clear?
What does Alex say went wrong?
How does Priya react to this explanation?
You do not need to catch every word. It is normal to miss some details the first time. If possible, listen twice. The first time, just get the general idea. The second time, try to pick out key phrases that show cause and result, such as because, so and as a result.
Later in the lesson, we will replay parts of this meeting to notice more advanced grammar, including third conditionals and modals of deduction. For now, your goal is to understand the situation and give a short, clear summary.
Your task in this block.
After listening, you will write 3–5 sentences explaining the delay in your own words, as if you were telling a colleague about the meeting. Try to answer the four questions above. Do not worry yet about very complex grammar; basic past tenses are fine at this stage. In later blocks, we will upgrade your language to sound more precise and professional when you explain past problems.
Practice & Feedback
Listen carefully to the short meeting between Priya and Alex in the audio below. You can listen more than once. After listening, write 3–5 sentences in your own words to explain:
what the original plan was,
what went wrong,
and how Alex explains the delay to Priya.
Imagine you are telling another colleague what happened in the meeting. Use simple past tenses and clear time expressions like on Monday, last week or at the weekend. Do not worry if you did not understand every detail; focus on the main storyline. If you are unsure about something, you can say you are not completely certain. Your summary does not need to be long, but it should be complete and easy to follow.
2. Noticing third conditionals for missed chances.
Now that you understand the basic story, we are going to zoom in on how Alex and Priya talk about missed chances and things that could have been different. This is where the third conditional is extremely useful. We use it to talk about unreal situations in the past, often with a feeling of regret or criticism.
In a later part of the same meeting, Priya asks what should have happened before the launch. Alex starts to say things like, 'If we had finished the full testing, the client would not have experienced any errors.' These sentences allow Alex to connect a past action that did not happen with an imagined, better result.
In this block, you will read part of that conversation and notice several third conditional sentences. Then we will break the structure into two parts: the if-clause and the result clause. You will see how changing one part of the sentence changes the meaning. After that, you will write a few third conditional sentences about the website project, using prompts to help you. This will prepare you to sound more reflective and professional when you explain what should have happened, and how problems could have been avoided.
Alex and Priya talk about what should have happened.
Read this short extract from later in the same meeting.
Priya: Looking back, what do you think we should have done differently?
Alex: If we had finished the full testing on Friday, the client would not have experienced any errors on Monday.
Priya: Yes, and if you had told me on Sunday evening, I could have warned the client about a possible delay.
Alex: You are right. If I had known the bugs were so serious, I would not have agreed to keep the launch date.
Priya: Exactly. This problem could have been avoided if we had checked the payment system earlier in the week.
What is the third conditional?.
These sentences all use the third conditional, which talks about unreal past situations and their imagined results.
Typical structure:
If + had + past participle, ... would have + past participle.
If we had finished testing, the client would not have experienced errors.
We can also use could have or might have in the result part to sound less certain:
If you had told me, I could have warned the client.
If we had checked earlier, we might have avoided the problem.
Notice that both parts refer to the past, but the result is unreal: it did not actually happen.
Mini noticing task.
Look again at the extract and answer these questions in your head:
Which sentence shows regret about Alex’s decision on Sunday?
Which sentence clearly expresses that the problem was avoidable?
Think about how this grammar allows Alex and Priya to analyse mistakes without just saying, 'It was bad'. It lets them be precise: if X had happened, Y would not have happened.
In the activity below, you will use this pattern to write your own third conditional sentences about the website delay.
Practice & Feedback
Read the extract above again and look carefully at the third conditional sentences. Then, using the structure If + had + past participle, would/could/might have + past participle, write 3 third conditional sentences about the website project.
Use these ideas to help you:
full testing / be completed / on Friday
the supplier / send / the correct files / earlier
the team / check / the payment system / before Monday
You can change the details, but keep the general situation. Make sure each sentence has two parts: the if-clause and the result clause. Try to include at least one sentence with could have or might have to show a less certain result. Focus on accurate verb forms and clear cause–result relationships.
Useful patterns from the meeting:
If we had finished the full testing on Friday, the client would not have experienced any errors.
If you had told me on Sunday evening, I could have warned the client about a possible delay.
If I had known the bugs were so serious, I would not have agreed to keep the launch date.
This problem could have been avoided if we had checked the payment system earlier in the week.
3. Guessing causes with modals of deduction.
When something goes wrong, we are often not one hundred percent sure why it happened. However, in a professional context you still need to offer a clear, logical explanation. This is where **modals of deduction for the past** are very useful. They help you say how probable you think a cause is, without pretending you know everything.
In our website project, Priya wants to understand the main cause of the delay. Some things are almost certain, some are possible, and some are clearly impossible. Listen to these examples in your head: 'The issue must have started when we uploaded the new payment plug-in.' 'The problem might have been caused by the old database settings.' 'It cannot have been because of the hosting provider; they confirmed there were no outages.'
Notice how *must have* shows a strong, logical conclusion, *might have* shows a guess, and *cannot have* shows that you are ruling something out. In this block, you will study these patterns in the context of Alex and Priya’s discussion and then write your own sentences about possible causes of the delay. This will help you sound more analytical and less emotional when you talk about past problems.
Talking about possible causes.
After discussing missed opportunities, Priya asks Alex to explain what probably caused the delay. Alex does not know every technical detail, but he has some evidence.
Here are some typical sentences Alex might use:
The issue must have started when we uploaded the new payment plug-in on Friday.
The delay might have been caused by the test server; it was very slow all weekend.
It cannot have been because of the hosting provider; they confirmed there were no outages.
The bugs could have come from the old code that we reused from the previous version of the site.
All these sentences use modals of deduction to talk about the past.
Meaning of key modals.
must have + past participle: you are almost certain about your conclusion.
The problem must have started during the final deployment.
might have / may have / could have + past participle: you are not sure; it is one possible explanation.
The delay might have been caused by a missing file.
cannot have / could not have + past participle: you are almost sure that this is not the explanation.
It cannot have been the client’s browser; several different users reported the same error.
Form.
The pattern is:
> modal (must, might, cannot, etc.) + have + past participle
This is true for all subjects:
The system must have failed on Sunday.
Our tests might have missed something.
The update cannot have completed correctly.
Your task in this block.
In the activity below, you will imagine you are Alex and write sentences about possible causes of the website delay. Use evidence from the meeting and logical thinking. Try to use a mix of must have, might have, could have and cannot have so that you show different levels of certainty.
Practice & Feedback
Imagine you are Alex, explaining possible causes of the website delay to Priya. Using the pattern modal + have + past participle, write 4–5 sentences about what you think happened.
Include at least:
1 sentence with must have for a very likely cause,
2 sentences with might have or could have for possible causes,
1 sentence with cannot have or could not have to reject an explanation.
Base your ideas on the story so far: incomplete testing, the payment plug-in, the test server, the supplier’s files, or any other realistic detail. Focus on expressing different degrees of certainty, not just repeating facts. Check that each sentence includes the auxiliary have plus a past participle, for example must have started, might have been caused, cannot have come.
Useful examples:
The issue must have started when we uploaded the new payment plug-in on Friday.
The delay might have been caused by the test server; it was very slow all weekend.
It cannot have been because of the hosting provider; they confirmed there were no outages.
The bugs could have come from the old code that we reused from the previous version of the site.
Remember the pattern:
modal (must, might, could, cannot) + have + past participle
4. Adding detail with reported speech and relative clauses.
So far, you have focused on your own perspective as Alex: what you think should have happened, and what you believe probably caused the delay. In a real meeting, though, you also need to show what other people have said and what documents show. This is where **reported speech** and **relative clauses** become very powerful tools.
Instead of repeating long direct quotes, you can report them in a smoother way, for example, 'One person who was involved said that testing started too late.' Relative clauses like 'who was involved' and 'which you asked for' help you add precise detail about people and things without starting a new sentence every time.
In this block, you will see how Alex might refer to colleagues’ comments and written reports while talking to Priya. You will notice some useful patterns with 'said that', 'explained that' and relative pronouns such as 'who', 'which' and 'that'. Then, in the activity, you will practise turning direct quotes into reported speech and adding relative clauses to make your explanation richer and more professional.
Bringing in what others said.
Imagine Alex wants to show Priya that he has checked with other people and looked at the evidence. Here are some examples of how he can do this:
One person who was involved in the testing said that the payment page failed several times on Sunday.
The developer who deployed the new plug-in explained that the logs showed errors on Friday night.
The report which you asked for yesterday shows that we did not run all the security checks.
In each sentence, the part in bold is a relative clause. It gives extra information about the person or thing just before it:
the person who was involved in the testing
the developer who deployed the new plug-in
the report which you asked for yesterday
We also have reported speech in these examples:
said that the payment page failed
explained that the logs showed errors
shows that we did not run all the security checks
Reported speech is useful because you do not need to repeat the exact words. You can summarise the message with verbs like said, explained, told me, mentioned and clauses with that.
Direct vs reported speech.
Direct speech:
The tester said, 'The payment page failed several times on Sunday.'
Reported speech with a relative clause:
The tester who was on duty on Sunday said that the payment page failed several times.
Direct speech:
Priya: 'We need a clear explanation for the client.'
Reported speech:
In the meeting, Priya explained that we needed a clear explanation for the client.
Your task in this block.
In the activity below, you will see some short direct quotes and simple noun phrases. Your job is to join the ideas together using reported speech and relative clauses, just as Alex would when explaining the situation to Priya or to a senior manager.
Practice & Feedback
Look at the direct quotes and simple noun phrases in the resource. Your task is to rewrite them as 2–3 longer sentences using both reported speech and relative clauses.
For each item:
Decide who or what you want to talk about first (for example, the developer, the tester, the report).
Add a relative clause to give more detail, using who, which or that.
Turn the direct quote into reported speech with verbs like said, explained, told me or mentioned, and a clause with that.
Write your sentences as if you are Alex describing the situation to Priya. Focus on smooth, clear sentences, not just copying word for word. Aim for at least two well-developed sentences.
Direct quotes and phrases:
Tester on Sunday: 'The payment page failed several times.'
Lead developer: 'We finished the deployment late on Friday.'
Incident report (you asked for it yesterday): 'Not all security checks were completed.'
Example transformation pattern:
One person who was involved in the testing said that the payment page failed several times on Sunday.
5. Chatting with your manager about the problem.
Meetings are not always long, formal events in a room. Very often, your manager will send you a quick message in a chat tool like Teams, Slack or WhatsApp to clarify a few final points. Your written answers still need to be clear, tactful and grammatically accurate, even if the format feels more relaxed.
In this block, you will imagine a short follow-up chat between Priya and you, Alex, later the same day. Priya wants to check that you have really understood what went wrong, what could have been different, and what the likely causes were. This is a perfect moment to use the grammar we have practised: third conditionals for missed opportunities, modals of deduction for likely causes, and reported speech with relative clauses to show what others said.
On the screen, you will see a short model chat with some typical questions from Priya and suitable answers from Alex. Use it as inspiration for tone and structure. Then, in the activity, you will write your own chat-style replies to a new set of messages from Priya. Remember: in chat you can be a little shorter, but you still need complete, clear sentences, especially when you are explaining a serious problem.
A model chat between Priya and Alex.
Below is an example of how a short chat conversation might look.
Priya: Hi Alex, I am preparing my notes for the call with the client. A quick question.
Alex: Sure, go ahead.
Priya: If we had done one thing differently last week, what do you think would have had the biggest impact?
Alex: If we had completed the full testing on Friday, the client would not have experienced any errors on Monday.
Priya: OK, and what do you think most likely caused the payment page errors?
Alex: Based on the logs, the issue must have started when we uploaded the new payment plug-in. The test server might have been too slow as well.
Priya: Did anyone on the team mention problems earlier in the week?
Alex: Yes. The tester who was on duty on Sunday said that the payment page failed several times, but we did not escalate it quickly enough.
What makes this effective?.
Even though this is a quick chat, Alex:
uses third conditionals to talk about missed chances (If we had completed... the client would not have...);
uses modals of deduction to describe likely causes (must have started, might have been too slow);
integrates reported speech and relative clauses to show evidence (The tester who was on duty on Sunday said that...).
The tone is polite and cooperative, not emotional or defensive.
Your task in this block.
In the activity below, you will see a new set of messages from Priya. Reply in a chat style as Alex, using short but complete sentences. Try to use at least one third conditional, one modal of deduction for the past, and one example of reported speech with a relative clause across your replies.
Practice & Feedback
Read Priya’s new chat messages in the resource. Then write your replies as if you are Alex.
Write 3–6 short messages. You do not have to copy the exact chat format with names, but you should sound like you are answering in a real-time conversation. Keep your tone polite, cooperative and solution-focused.
Across your replies, try to include:
at least one third conditional (If we had..., we would have...);
at least one modal of deduction for the past (must have, might have, cannot have + have + past participle);
at least one example of reported speech with a relative clause (The developer who..., The report which..., One person who... said that...).
Focus on clarity first, then check your grammar. Imagine Priya will copy parts of your messages into her notes for the client.
New chat from Priya:
Priya: Hi Alex, thanks again for the meeting earlier.
Priya: I am still trying to explain to the client why this delay was avoidable.
Priya: In your opinion, what should we have done differently in the week before the launch?
Priya: Also, what do you now think most likely caused the error on the payment page?
Priya: Finally, has anyone on the team said anything that I should mention in the call?
6. Writing a follow-up email about the delayed project.
You have now explored the situation from several angles: first understanding the basic story, then analysing missed opportunities, likely causes, and evidence from other people. In real working life, these conversations usually end with some kind of written follow-up, often an email to your manager or to the client.
In this final block, you will bring everything together in a short, clear follow-up email from Alex to Priya. The aim is to summarise what happened, what probably caused the delay, what should have been different, and what lessons you have learnt. This is your chance to integrate third conditionals, modals of deduction, reported speech and relative clauses in one coherent text.
On the screen, you will see a model email from Alex to Priya. Read it slowly and notice how the message is organised into clear paragraphs: introduction and apology, explanation of causes, reflection on missed opportunities, and lessons for the future. Then you will write your own version, perhaps using different details from your own work, study or everyday life if you prefer. By the end of this task, you should feel more confident about explaining past problems in a mature, professional way in writing.
A model follow-up email from Alex to Priya.
Subject: Summary of causes and lessons from website launch delay
Hi Priya,
Thank you for taking the time to discuss the website launch this morning. I wanted to summarise my understanding of the main causes of the delay and what I have learnt from the incident.
Based on the logs and the testing report which you asked for yesterday, the issue must have started when we uploaded the new payment plug-in on Friday evening. The test server might have been too slow as well, which could have hidden some of the errors. It cannot have been caused by the hosting provider, because they confirmed there were no outages over the weekend.
Looking back, if we had completed the full round of testing on Friday, the client would not have experienced errors on Monday. In addition, if I had informed you on Sunday evening about the unfinished tests, you could have warned the client about a possible delay.
The tester who was on duty on Sunday said that the payment page failed several times, and the developer who deployed the plug-in explained that some warnings appeared in the logs. I should have reacted more quickly to this information.
The main lesson I have learnt is that we need to finish testing earlier and escalate any serious issues immediately. This problem could have been avoided if we had followed that approach.
Best regards,
Alex
Why this email works.
This email is effective because it:
has a clear structure with paragraphs for causes, missed opportunities and lessons;
uses modals of deduction to show different levels of certainty about causes;
uses third conditionals to talk about unreal past situations and regrets;
includes reported speech and relative clauses to bring in evidence from others;
keeps a polite, responsible tone without sounding too emotional.
Your task in this block.
In the activity below, you will write your own follow-up email from Alex to Priya. You can follow the model closely, or you can adapt it to a different past problem from your own life (for example, a missed deadline at university, a late assignment, or a personal project that went wrong). The most important thing is to use the grammar from this lesson to explain causes and lessons clearly.
Practice & Feedback
Write a follow-up email of around 150–220 words as if you are Alex writing to Priya after the meeting.
Your email should:
briefly remind Priya of the situation (the delayed website launch or your chosen problem);
explain what most likely caused the problem, using modals of deduction (must have, might have, cannot have, could have);
describe at least two missed opportunities using third conditionals (If we had..., we would have...);
include at least one example of reported speech with a relative clause, bringing in what someone else said or what a report showed (The tester who..., The report which..., One person who... said that...).
Organise your email into clear paragraphs and keep a polite, professional tone. You can use the model above for inspiration, but try to choose your own exact wording. Check your email once more before sending to make sure the key grammar structures are accurate.
Model email structure (for quick reference):
Subject line that mentions the incident.
Short greeting and purpose sentence.
Paragraph explaining likely causes using modals of deduction.
Paragraph analysing missed opportunities with third conditionals.
Sentence or short paragraph adding evidence with reported speech and relative clauses.
Final paragraph with main lesson learnt and, if you like, a suggestion for the future.