You're listening to Business English Pod, the Business English podcast for professionals on the move.
Hello, and welcome back to Business English Pod.
My name's Edwin, and I'll be your host for our new series on English for Project Management.
For our first lesson, we're going to look at a kickoff meeting at the start of a project.
Whether or not you're a project manager, you surely know that every project is a unique and complex process.
Seeing a project through to completion on time and within budget takes a huge range of people, skills and business know-how.
And sometimes during a big project, it might feel like everything is working against successful completion.
But there are ways to minimize some of these challenges.
This is particularly true at the beginning of a project, when it's important to make sure you get off to a good start.
For one thing, you'll need to meet with the client to make sure the ground rules of the project are clear.
Otherwise, you'll be dealing with confusion mid-project.
Kicking off a project effectively also means outlining protocols or important procedures and explaining lines of communication.
After all, when a problem or challenge does arise, everyone should know exactly who to talk to and how to make the necessary changes.
The kickoff meeting is also a time for everyone to make their priorities clear.
If you are the client and sticking to the timeline is more important than keeping to the budget, you should make that known right from the start.
Of course, there may be competing priorities.
And as a project manager, you may have to manage client expectations carefully, which might involve setting some conditions when you agree to something.
In today's dialogue, we'll join Martin and Jill, who work for a software company called Optitech.
Their company is holding a teleconference to kick off a project to develop custom software for a logistics company that will help them manage and track shipments.
Martin is the project manager, while Jill is the lead developer.
On the call.
We'll also hear from Zahra, a manager at the logistics company, and Liam, their IT manager.
Together, they are all trying to get the project off to a good start.
As you listen to the dialogue, try to answer the following questions.
One, how does Martin say that Jill should deal with technical issues?
Two, what does Zara emphasize as her company's priority in the project?
Three near the end of the conversation.
What condition does Martin attach to the successful management of the timeline?
All right, moving on, let's talk a bit about communication.
Part of my role will be liaising with you about all major aspects of the project.
Timelines, invoicing, change requests, all that fun stuff.
So, any problems with those aspects, please come to me.
Sure thing.
And I'm hoping you're a phone person because that's how I like to operate.
No problem.
And feel free to call me whenever you need to, but anything contractual, like if we need to alter the scope, or anything like that, we should really put in writing.
And obviously invoicing and formal reporting will come through by email.
Yes, of course.
Sorry, Jill here.
Can I jump in here for a sec?
Martin, there's going to be purely technical issues that come up.
You don't really want that going through you, do you?
No, that's not necessary.
I mean, on technical matters, you should connect directly with... Liam?
Yeah, you bet.
I know you're going to need some info on our TMS and I'm sure there will be some other things that come up.
Okay, I'll be in touch soon.
And just so we're clear.
It's really critical that we're informed right away if you think there might be any delays or hold-ups of any kind.
Sure, of course.
Right.
Because we feel we're playing from behind a bit here.
So we're keen to get this up and running pronto.
By all means.
You'll be hearing from us weekly.
And as long as communication is smooth and we get the info we need, everything should go swimmingly.
Well, we run a pretty tight ship, so everything should be fine on our end.
Now let's go through the dialogue again and look at the language and techniques used during the meeting.
All right, moving on, let's talk a bit about communication.
Part of my role will be liaising with you about all major aspects of the project timelines invoicing, change requests, all that fun stuff.
So any problems with those aspects, please come to me.
As the project manager, Martin wants to make sure the client knows his role.
They need to know that he will be liaising or communicating with them on the project.
If you have any experience with projects, you know how important it is that people understand each other's roles and how they should be working together.
This is all part of what we might call setting ground rules for a project.
Ground rules are the basic ways that people should operate and work together.
Being clear about these ground rules at the beginning can help you avoid problems or miscommunication.
Let's practice some other ways we can set ground rules during a kick-off meeting.
Let's all agree to resolve major problems during these project meetings.
I think it's best if someone takes minutes and sends out a summary of what we discuss.
I'd like to make sure that quality assurance is kept informed of what's happening.
Let's avoid long email threads by just picking up the phone to discuss any small problems.
Besides clearly defining roles, it's important to be clear about procedures.
Let's listen to how Martin does this.
Sure thing.
And I'm hoping you're a phone person because that's how I like to operate.
No problem.
And feel free to call me whenever you need to, but anything contractual, like if we need to alter the scope, or anything like that, we should really put in writing.
And obviously invoicing and formal reporting will come through by email.
Notice that Zahra mentions that she's a phone person.
That just means a telephone is her preferred form of communication.
In this way, she's making others aware of her working style, which can also help avoid problems.
But while Martin agrees to communicate by phone, he also wants to point out that some issues need to be put in writing or be communicated through email or on paper.
In particular, he mentions contractual issues, like altering the scope of the project.
Altering the scope of a project means changing what is included or involved in the work.
It's common to change the scope of a project but, as Martin says, those changes should be communicated clearly in writing, not just on the phone.
Outlining procedures and processes when a project begins is critical.
What are some other ways we can do this?
Let's run through a few more examples.
We'll need one of you to sign off on each milestone as they are reached.
If you've got any questions about invoicing, please contact Bonnie.
So, I'd like it if we could meet face-to-face one week following each monthly report.
We'll provide you with a login for our project management dashboard so you can keep track of progress.
Now let's get back to the dialogue, as Jill wants to jump in or interrupt to clarify a point about communication.
Yes, of course.
Sorry, Jill here.
Can I jump in here for a sec?
Martin, there's going to be purely technical issues that come up.
You don't really want that going through you, do you?
No, that's not necessary.
I mean, on technical matters, you should connect directly with… Liam?
Jill wants to be clear about communication on the technical issues that might come up or arise.
As the project manager, Martin takes care of major aspects of the project.
But that doesn't mean every technical issue.
So it's important for him to assign the right communication channels.
In this case, that means telling Jill to contact the client's IT manager directly on technical matters.
Assigning the right communication channels helps projects run efficiently and prevents communication overload.
Let's try some more examples of assigning communication channels.
Please cc our lead developer on all emails regarding testing.
Dave, you'll be the primary contact for the technical writers on this.
Any questions about timelines and deliverables should come to me.
Ronaldo, I'm going to put you in touch with their marketing team so you can coordinate with them about the final release.
Jill and Liam are going to communicate on technical issues, so let's hear how they make a brief connection during the kickoff meeting.
Yeah, you bet.
I know you're going to need some info on our TMS and I'm sure there will be some other things that come up.
Okay, I'll be in touch soon.
And just so we're clear.
It's really critical that we're informed right away if you think there might be any delays or holdups of any kind.
The project kickoff is an opportunity not just for the project manager, but also the client.
Clients may want to lay down their own ground rules and expectations.
In this case, Zahra wants to make it clear that time is a priority.
She wants to be informed immediately if there are any delays.
What are some other ways we can state priorities clearly during a project kickoff meeting?
Let's practice with some more examples.
We're very concerned about costs, so whatever we can do to keep them down is great.
The most important thing to us is quality.
For us, everything comes back to good communication.
We've got a wide range of users, so ease of use is our number one priority.
Now, let's get back to the dialogue to hear Martin's response to his client's concerns.
Sure, of course.
Right, because we feel we're playing from behind a bit here.
So we're keen to get this up and running pronto.
By all means, you'll be hearing from us weekly.
And as long as communication is smooth and we get the info we need, everything should go swimmingly.
Zara has emphasized their concerns about time, quite strongly mentioning that they want to get the software up and running pronto.
In other words, they want to launch the new software as quickly as possible.
Martin understands that Zara is concerned about timelines, but project delays can be caused by the client, not just the developer.
And Martin wants to protect himself a bit by explaining that staying on track requires both sides to work effectively.
That is, he wants to say that they can do their job well if Zara and her team do theirs.
As he says, things will go swimmingly or very well as long as they get the information they need.
That condition clearly places some of the responsibility on Zara's side.
Let's run through some more ways we can agree to a client's demands or priorities with conditions.
Well, if you don't mind flexing the timeline a bit, we can do that.
There will be no problem getting this wrapped up by July, as long as we can get the data we need by June.
Of course, this will be totally secure, provided your server security is up to par.
Yes, we can add a budgeting tool, but we'll need another two weeks for that.
How does Zara respond to Martin's conditional agreement?
Well, we run a pretty tight ship, so everything should be fine on our end.
If you run a tight ship, you manage or organize things very strictly.
Zara seems pretty certain that there won't be any problems on their side or end.
But in some ways it doesn't matter whether she admits they might be the cause of any problems at this point.
The fact that Martin brought up the possibility offers some protection.
And overall, he's done a great job of getting the project off to a good start.
Now let's practice some of the language we learned in today's lesson.
Imagine you work as a project manager for a software company.
You are meeting with a client to get a project started.
You'll hear a statement by the client.
Then I'll give you a suggestion for how you can respond.
We'll guide you through each step in the practice and provide an example answer for each response.
Ready?
Let's give it a go.
Well, we're certainly excited to get this project going.
Start by agreeing.
Then say you'd like to keep in regular contact throughout the project.
Answer.
Yes, for sure.
And I'd like to keep in regular contact throughout the project.
That's great.
But will we sit down face to face at some point?
Now say that you'd like to schedule a monthly in-person meeting.
Answer.
Yes, I would like to schedule a monthly in-person meeting.
Sure thing.
And should we wait for that meeting to talk about testing?
Next, tell the client that they should contact your Lead Developer by email to discuss any issues with testing.
Actually, you should contact our Lead Developer by email to discuss any issues with testing.
Okay, that makes sense.
But you'll have someone come in to help organize the testing, right?
Now agree, but with the condition that site visits can be scheduled in advance.
Answer.
Yes, we can have someone help out as long as it's scheduled in advance.
Now let's practice some of the vocabulary we've covered in this lesson.
In a moment, you'll hear a series of sentences with a word replaced with a beep.
Repeat each sentence, including the missing word.
For example, if you hear I don't know if we'll be able to finish on time with all these hold, You can say I don't know if we'll be able to finish on time with all these hold-ups.
After each response, we'll provide the correct answer.
Let's begin.
Answer.
Now that we've agreed on the deal, let's put everything in writing.
Well, I think that's all for now.
I'll be in by email next week.
Answer Well, I think that's all for now.
I'll be in touch by email next week.
The meeting starts in 30 minutes, so we need to leave Answer.
The meeting starts in 30 minutes, so we need to leave pronto.
If you have any questions, then by all... Just call me anytime.
Answer.
If you have any questions, then by all means just call me anytime.
We've reached the end of this lesson, the first in our series on project management.
We've learned how to set ground rules, outline procedures, and assign communication channels.
We've also covered how to state a priority and how to agree with conditions.
In our next lesson we'll hear the rest of this project kickoff meeting and look at some more ways to get projects off to a good start.
Thanks for listening and see you again soon
