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 today's lesson, which continues our look at a project kickoff meeting.
Anyone who's been involved with projects should know just how important it is to have good communication with a client.
And good communication starts right at the beginning, at a project kickoff meeting.
That's when you'll have the chance to make sure a client understands how you work and how the project should run.
In our last lesson we looked at some of the basics that you need to cover in your first project meeting.
Today, we'll look at some more ways of increasing your chances of avoiding problems and ensuring that a project runs smoothly.
In many cases, it can be a good idea to actually bring up potential obstacles in your meeting.
If you see something that might impact the timeline or the budget, you can let the client know about it.
And that might mean that you have to educate the client about your work process.
When you educate a client about your development process, you might find yourself using too much technical language.
But if you want the client to really understand, you might have to rephrase that information in simpler terms.
Of course you don't want to focus too much on potential problems, and for that reason you should know how to redirect the discussion away from problems and toward other issues.
For example, you might need to ask the client for important information to get the project started.
In today's dialogue, we'll rejoin Martin and Jill.
Their company, Optitec, is starting a new project to develop software for a logistics company.
Martin and Jill are kicking off the project by holding a teleconference with Zara, the manager of the client company, and Liam, their IT manager.
In this part of the dialogue, Martin and Jill are making sure Zara and Liam understand potential obstacles and the development process.
As you listen to the dialogue, try to answer the following questions.
One, what does Martin say is a cause of some potential obstacles?
Two, what is Jill's simple explanation of a technical idea that Zara didn't understand?
Three, when Martin redirects the discussion away from obstacles, what does he say he wants to discuss?
Well, we run a pretty tight ship, so everything should be fine on our end.
Great to hear.
And I mention that because there's always X factors in projects like this.
What do you mean exactly?
Jill, you want to take this?
Sure.
Well, there's a lot of testing involved, and that's fundamental to how we work.
We design build test, release and doing all this testing and getting the feedback can cause bottlenecks sometimes.
You mean you find out that things don't work the way you anticipate it?
Well, not just that.
Testing drives design in a sense, and there are inherent challenges to integrating new software with legacy systems, figuring out APIs, porting new data into your TMS and things like that.
Hang on a sec.
Sorry, but could you give that to me in English?
Basically, what I mean is that we need to fit this new software into what you already use.
Okay, I get that, but that's something you always have to do, isn't it?
Um, yeah, most times.
Key thing is that we're going to need cooperation from the developer of your existing TMS.
Oh, I see.
That won't be a problem.
Great.
Now, the other big thing around testing is getting good feedback in a timely manner.
So drivers, receivers, clerks, they're all going to have to provide input on how the app functions.
Then we tweak things and we test again, and so on.
Okay, so Liam, you'll take care of that.
I mean, coordinating input and feedback from the different users?
Yeah, sure, I can certainly do that.
Great.
So I'll be connecting with you about how we go about testing.
And of course we've built space into the timeline for all these things.
We're generally very good at plotting things out realistically.
Just wanted to underline that.
But I think we should get back to talking about where we're going to focus first.
All right then.
So what happens next?
You guys sit down and design the system for us, right?
Well, not exactly.
As Jill mentioned, design is partly driven by testing, so we work the system up in functionality as we go.
And we thought root optimization would be the best place to start?
Yeah, I think that would work.
Okay, and before we actually get started, we'll need quite a bit of info from you guys, mostly technical stuff.
Like logins and repo?
Yeah.
Basically, I've got a whole list that I'll pass on, including everything like branding and style guides and such, which we won't really need till later, but it's good if we can get everything at once.
Now let's go through the dialogue again and look at the language and techniques used during the teleconference.
If you listened to the last lesson, you heard Martin emphasize the importance of smooth communication.
Let's hear how the discussion continues.
Well, we run a pretty tight ship, so everything should be fine on our end.
Great to hear.
And I mention that because there's always X factors in projects like this.
What do you mean exactly?
Martin has brought up X-factors, which are basically unknown possibilities.
At this point, he is trying to gently introduce potential obstacles.
Let's listen as Jill explains more.
Jill, do you want to take this?
Sure.
Well, there's a lot of testing involved.
That's fundamental to how we work.
We design build test, release and doing all this testing and getting the feedback can cause bottlenecks sometimes.
What Martin introduced and what Jill is explaining are potential obstacles to the smooth running of the project.
She mentions that getting feedback on all the testing they must do can cause bottlenecks, which is just another way of saying obstacles or problems.
It's a good idea to caution a client about potential project obstacles like this, especially if the client might be the cause.
Jill and Martin have surely been involved with lots of projects and they know that getting feedback from a client can be challenging.
So they are trying to bring the issue up now at the kickoff meeting to be sure the client understands their responsibilities.
Let's run through some more ways of cautioning a client about potential obstacles.
One thing that might cause some challenges is integrating this with your existing database.
With many staff on holiday over Christmas, we might see some delays.
One way these projects can get bogged down is with poor communication.
I can see some challenges here if customers don't understand why you're implementing a new system.
Next, Jill is asked to explain these potential obstacles further.
You mean you find out that things don't work the way you anticipated?
Well, not just that.
Testing drives design in a sense, and there are inherent challenges to integrating new software with legacy systems, figuring out APIs, porting new data into your TMS and things like that.
Hang on a sec.
Sorry, but could you give that to me in English?
Jill is a software developer and her explanation includes a lot of terms like legacy systems and APIs and porting that a non-technical person like Zara might not understand.
So Zara asked Jill to give her the explanation in English.
That's just a way of asking someone to explain in non-technical or simple language.
Let's continue.
Basically, what I mean is that we need to fit this new software into what you already use.
This explanation is much easier to understand.
Jill has basically summarized all the technical information into one easy sentence.
And whether you work in software development, construction or finance, you should be able to rephrase technical information so that people can understand.
Let's try some more examples of rephrasing technical information in simple terms.
In other words, the software can't run on your old system.
Basically we need to find any errors and fix them before moving on.
What I mean is that we have to figure out which features need to be built first.
Think of it this way.
If your network isn't secure, anyone could steal your data.
Now let's get back to the dialogue.
Okay, I get that, but that's something you always have to do, isn't it?
Um, yeah, most times.
Key thing is that we're going to need cooperation from the developer of your existing TMS.
Oh, I see.
That won't be a problem.
Martin is asking for cooperation from the developer of the client's TMS.
If you tuned in last time, you may remember that means transportation management system.
And, as you can see, Martin is emphasizing certain client responsibilities that are important to running the project smoothly.
And he has another important point to make.
Great.
Now, the other big thing around testing is getting good feedback in a timely manner.
So drivers, receivers, clerks, they're all going to have to provide input on how the app functions.
Then we tweak things and we test again, and so on.
Martin and Jill brought up the X-factors in testing earlier.
At this point, Martin is educating Zahra and Liam a bit more about the testing process, and he emphasizes how important it is for them to get feedback in a timely manner.
A client might not realize how development works, so it's important to explain any relevant processes, especially those that will need input from the client.
The kickoff meeting is the perfect time to educate a client about process, So let's try some more examples.
First, we run a bunch of tests in our lab.
Then we can test with your staff.
We'll need you to approve what we've built before we can go on to the next stage.
Each of these phases, which we call sprints, will last about two weeks.
Just so you know, the user interface won't be fully implemented until the end.
How do Zahra and Liam respond to Martin's explanation?
Okay, so Liam, you'll take care of that.
I mean, coordinating input and feedback from the different users?
Yeah, sure, I can certainly do that.
Great.
So I'll be connecting with you about how we go about testing.
And of course we've built space into the timeline for all these things.
We're generally very good at plotting things out realistically.
Just wanted to underline that.
But I think we should get back to talking about where we're going to focus first.
Martin and Jill have been focusing on potential obstacles and educating their client so they can avoid those obstacles.
But you shouldn't focus too much on obstacles during the kickoff meeting.
After all, you don't want the client to think you're not a good project manager.
So, as Martin shows, you may have to redirect the discussion to other issues.
And before he does so, you'll notice that he emphasizes that they're usually good at plotting things out or planning.
What are some other ways we can redirect a discussion away from obstacles?
Let's run through some different examples and notice how we minimize the possibility of problems, before pointing the discussion in another direction.
Anyway, I don't expect that to be a problem, so let's move on to discuss who does what.
In any case, those are just possible challenges.
Better we focus on functionality for now.
I mention those obstacles just in case they come up.
Now, let's discuss the initial specs.
Let's just put communication issues aside for now and look at the timeline.
Sir Martin has redirected the discussion away from potential obstacles and now he wants to talk about what part of the project they will focus on.
First, let's listen, all right then.
So what happens next?
You guys sit down and design the system for us, right?
Well, not exactly.
As Jill mentioned, design is partly driven by testing, so we work the system up in functionality as we go, and we thought route optimization would be the best place to start.
Yeah, I think that would work okay, And before we actually get started, we'll need quite a bit of info from you guys, mostly technical stuff.
As you can hear, Zara is not totally clear on how the development process works.
And while Martin briefly restates the process, his main point is that they want to start with route optimization.
In a logistics company route.
Optimization is about how to move vehicles and goods around in the most efficient manner.
And in order to get started, Jill needs to request some information.
When you start a new project, especially a software project, there's usually a lot that you need from the client.
And the project kickoff meeting is a great time to ask for that information.
What are some other ways we can request information?
Let's practice some more examples.
One thing we'll need is a list of all the staff and their email addresses.
Before we begin, we'll need your server login and domain information.
Could you please pass on your site analytics data for the last 12 months?
If you could give us your most recent product data sheets, that would be great.
So exactly what kind of information will Jill need?
Like logins and repo?
Yeah, basically.
I've got a whole list that I'll pass on, including everything like branding and style guides and such, which we won't really need till later, but it's good if we can get everything at once.
As you've heard throughout this dialogue, the client doesn't always know exactly what information they need to give you, nor exactly how you will manage the project.
That's why the kickoff meeting is so important.
It's your chance to tell the client all about potential obstacles and processes and to request important information.
Now let's practice some of the language we learned in today's lesson.
Imagine you work for a software development company and you're meeting with a client at the start of a project.
You'll hear a cue 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.
So the timeline looks great to me, as long as we can stick to it.
Start by saying that sticking to the timeline depends on a smooth testing process.
Answer.
Yes.
Well, sticking to the timeline depends on a smooth testing process.
Oh, really?
But if we schedule testing for a slow week, it should be fine, shouldn't it?
Now say that testing happens continuously as you integrate each new iteration.
Well, testing happens continuously as we integrate each new iteration.
I'm sorry.
I'm not sure exactly what you mean.
Next, explain more simply that you will be constantly designing and testing new features.
Answer.
Basically, we'll be constantly designing and testing new features.
Oh, I see.
Well then, how do we get started with everything?
Finally, ask the client for their server and database login.
Answer.
I'll just need your server and database login.
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... Managing time and costs are...
You can say... After each response, we'll provide the correct answer.
Let's begin.
It's important that the client is informed of changes in a timely...
Answer.
It's important that the client is informed of changes in a timely manner.
With a project of this size, there are many X that can cause delays.
Answer.
With a project of this size, there are many X factors that can cause delays.
The website looks good overall, but I think we need to... the colors a bit.
Answer.
The website looks good overall, but I think we need to tweak the colors a bit.
Poor communication created major... in the project.
Poor communication created major bottlenecks in the project.
We've reached the end of this lesson, the second in our series on project management.
We've learned how to caution about potential obstacles, rephrase technical information and educate a client about process.
We've also looked at how to redirect the discussion away from obstacles and how to request information.
In our next lesson we'll hear what happens when Martin delivers the initial test build of the software.
Thanks for listening and see you again soon.
