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 on project management meetings.
In this lesson, we're going to look at delivering an initial test build to the client.
In our last lesson we looked at how important it is to set clear expectations with a good project kickoff meeting.
But no matter how well you've educated the client about your work process, you've still got work to do when you deliver an initial test build.
You can't just hand it over to the client and wait for their feedback.
It would be nice if project management was that simple, but it's not.
Handing off an initial test build needs to be dealt with carefully.
For one thing, you need to manage the client's expectations.
That means making sure they understand that you're not delivering a final product.
Rather, you're giving them something to try out or test.
In this way, project management involves collaboration or working together with a client.
And that's something you will want to emphasize when you deliver the initial test build.
Collaboration is especially important during the testing process and it's a good idea to outline the procedures very carefully for the client.
If you don't, then you're likely to encounter obstacles.
When you hand over a test build, you might also discover the client's needs have changed or that they want something new.
In this case, it's important to clearly identify a change in the project scope and you need to make sure the client understands that there may be cost overruns connected to a change of scope.
In today's dialogue, we'll hear Martin, a project manager with Optutech.
He's been leading the development of new software for a logistics company.
Martin is having a teleconference with Zahra, a manager at the client company, and Liam, their IT manager.
They are discussing Optitec's initial test build.
As you listen to the dialogue, try to answer the following questions.
One at the start of the conversation.
What does Martin want to focus on when they look at the initial test build?
Two, what does Martin say is the first step in the testing process?
Three, how does Martin respond to Zahra and Liam's request for load tendering tools?
Okay, so let me just walk you through what we've done so far.
But just remember that at this point, it's all about functionality.
We need to figure out if everything works the way it should before we get into the next sprint.
I'm good with that.
It'll be nice to have something to start testing.
Yeah, and because this is the first release, there's going to be a bit of a learning curve to deal with.
Sure.
I understand staff will need some training, at least those involved in the testing process.
Of course, and Jill will be on site to do a lot of that with your help, Liam.
But just want to emphasize that this is going to be a collaborative process.
I mean, we all need to work closely to make sure the software is doing what we need it to do.
Okay then.
So, can we have a look?
Can you put it up on the screen?
Yeah.
Uh, but first, let's just make sure we're on the same page about testing.
For starters, we'll need to get your entire group in one room to talk about what they need to do and how they will be providing feedback.
Then we'll coach them on how to actually use the software before they go out and start testing.
So I think this all looks pretty good for our own fleet.
But I don't see a tool there for load tendering.
You know, for when we exceed our fleet capacity.
Load tendering tools?
I don't remember seeing anything about that before.
Yeah, I don't see it in the specs.
Well, it should be in there.
It's definitely something we need.
I know we discussed it, but honestly I can't remember when.
In any case, it's pretty important.
Okay, so just to be clear here, load tendering tools weren't part of the initial specs, right?
Well, yes, I guess it looks like that, but as Liam says, it's definitely something we need.
All right, no problem.
It's something we've done before.
But before we talk about a scope change, we need to look at the issue of cost.
This is going to have an impact on development time and we're going to have to rework some of the backend to make this work.
The backend?
You mean the database?
Yes.
Yeah, we're going to have to look at the database schema and probably a few other things.
Once we get done here, I'll take a closer look and get back to you before the end of the day.
Now let's go through the dialogue again and look at the language and techniques Martin used during the meeting.
Okay, so let me just walk you through what we've done so far.
But just remember that at this point, it's all about functionality.
We need to figure out if everything works the way it should before we get into the next sprint.
Martin wants to walk Zara and Liam through the initial software build.
That just means he wants to show them how it works step by step.
Of course, the software won't look like the final piece of polished work.
As Martin says, an initial test build is about functionality.
Clients don't always realize that, which is why you need to manage their expectations carefully.
You need to tell clients what they should be looking at and what they should ignore.
If you don't, they'll probably be disappointed.
Let's practice some more ways of managing a client's expectations.
Just so you know, this is not exactly how it's going to look in the end.
Remember that we've just started with three key features here.
This is just an initial test build, not a finished product at this point.
Just focus on how it works for now, not how it looks.
Let's hear how Liam and Zara respond to Martin.
I'm good with that.
It'll be nice to have something to start testing.
Yeah, and because this is the first release, there's going to be a bit of a learning curve to deal with.
Sure.
I understand staff will need some training, at least those involved in the testing process.
Martin mentions a learning curve, which is the natural process of learning about something new.
Martin is just making sure his client understands that they'll need to do some work and, as Zahra mentions, that they'll need training.
This is all part of managing a client's expectations.
Now listen as Martin emphasizes another important point.
Of course, and Jill will be on site to do a lot of that with your help, Liam.
But just want to emphasize that this is going to be a collaborative process.
I mean, we all need to work closely to make sure the software is doing what we need it to do.
Martin is directly emphasizing the collaborative nature of the testing process.
Collaboration is when people work together toward a common goal.
In this case, they're trying together to figure out if the software is working effectively.
Clients might not always understand the collaborative nature of software development or projects in general, and Martin has probably encountered problems with such clients before.
For this reason, it's a good idea to emphasize collaboration when you deliver an initial test build.
Let's try some more examples of emphasizing collaboration.
This is really about working together to achieve the best design solution.
If we can all collaborate on this whole testing process things will work out great.
We need everyone to come together here to decide if this is going in the right direction.
This isn't just us developing things for you.
It's about you working with us on development.
As you can hear next, the client is eager to look at the software.
But Martin needs to cover one more important idea before he actually shows them the test build.
Okay then, so can we have a look?
Can you put it up on the screen?
Yeah, but first, let's just make sure we're on the same page about testing.
For starters, we'll need to get your entire group in one room to talk about what they need to do and how they will be providing feedback.
Then we'll coach them on how to actually use the software before they go out and start testing.
Martin has already discussed the importance of collaboration, and now he wants to outline the testing procedure in more detail.
His purpose, as he says, is to make sure they're on the same page.
That means everyone has the same understanding of what's going to happen.
As Martin has been demonstrating, it's very important to make sure everyone's on the same page before showing the client anything.
If you listened to our last lesson, you heard Martin and Jill explain that the testing process is where problems are likely to occur.
For this reason, Martin is being very careful to outline the procedures clearly.
What are some other ways we can do that?
Let's try some more examples.
First, we'll need everyone to log in and just get a feel for the software.
We'd like the testers to just use the app for three full days before giving any input.
One of our developers will be coming in to observe how your staff are using the software.
We've got some feedback forms to fill out and then we'll do some follow-up interviews.
Now let's skip ahead in the meeting, after Zara and Liam have had a chance to look at the software.
So I think this all looks pretty good for our own fleet.
But I don't see a tool there for load tendering.
You know, for when we exceed our fleet capacity.
Load tendering tools?
I don't remember seeing anything about that before.
Yeah, I don't see it in the specs.
Zara has brought up the issue of load tendering.
When a logistics or transportation company doesn't have the capacity or enough space to handle everything, they will look to other companies to help out.
This is called load tendering.
But Martin doesn't see a load tendering tool in the specs or project specifications.
Let's hear how he deals with this issue.
Well, it should be in there.
It's definitely something we need.
I know we discussed it, but honestly, I can't remember when.
In any case, it's pretty important.
Okay, so just to be clear here, load tendering tools weren't part of the initial specs, right?
It's clear that Liam and Zara want load tendering tools.
But, as you can hear, Martin is asking very clearly for confirmation that such tools were not part of the agreement.
Why is this important?
Well, one of the biggest problems in project management is scope creep.
This is when the project scope, or the complete list of work to be done, slowly changes or expands.
Scope creep usually happens when a client decides they need or want more than originally agreed to and when the project manager agrees to it without changing the agreement.
But scope creep can also happen when you find out that more work is required than you originally thought.
So how do you avoid scope creep from the client side?
As Martin has shown, the first thing you must do is clearly identify a change in scope.
Let's run through some more ways to do this.
That's certainly possible, but it was definitely not included in the original scope.
Just so I'm clear, you're asking for a change to the specs we agreed on originally, right?
So this is something additional that we're talking about and that will have an impact on delivery and cost.
If we do this, then you'll have to sign off on a change to the initial project description.
Now let's listen as Martin deals with the effects of the scope change.
Well, yes, I guess it looks like that.
But as Liam says, it's definitely something we need.
All right, no problem.
It's something we've done before.
But before we talk about a scope change, we need to look at the issue of cost.
The problem with scope creep is that you end up doing more work for the same amount of money.
That's why discussing scope changes should come with a discussion of added costs.
You also need to be able to bring up added costs any time a project is going to be more expensive than you originally thought.
Martin raises this issue of added costs very clearly.
In fact, he says they can't talk about the scope change without looking at costs first.
Let's practice some more ways of bringing up added costs, both because of client demands and natural cost overruns.
We've run into some issues with costs that I need to discuss with you.
It looks like this is going to be more expensive than originally anticipated.
I think we need to have another look at our original estimate.
Let's finish off the dialogue as Martin explains the reasons for the added costs which involve reworking or revising the database or backend.
This is going to have an impact on development time and we're going to have to rework some of the backend to make this work.
The back end?
You mean the database?
Yeah.
We're going to have to look at the database schema and probably a few other things.
Once we get done here, I'll take a closer look and get back to you before the end of the day.
All in all, Martin has done a good job of delivering this initial test build.
Most importantly, he's been very clear with the client about what to expect and how to do things, and about the proposed changes to the project.
Now let's practice some of the language we learned in today's lesson.
Imagine you are managing a software development project.
You are discussing the initial build and the first round of testing with your client.
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.
It'll be exciting to see the software in action.
Start by saying that this is only an initial version with limited functionality.
Answer.
For sure, but just remember this is only the initial version with limited functionality.
Alright, understood.
So, how do we go about testing?
Now say that staff will try it out for a week before providing feedback.
Answer.
Well, your staff will try it out for a week and then provide feedback.
Great.
And then you'll add the next set of features, right?
Next, emphasize that first you need to work with the staff on improving the design.
Answer.
First, we need to work closely with your staff on improving the design.
Further on in the conversation, the client brings up a new point.
One thing I don't see here is a tool for tracking time.
Now say that a time tracking tool was not in the original scope.
Answer I'm sorry, but a time tracking tool was not in the original scope.
Oh, well, that is definitely something we're going to need.
Finally, say that this will involve changes to the cost estimate.
Answer Okay, but this is going to involve changes to the cost estimate.
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, Once you exceed your storage, You can say Once you exceed your storage capacity, you'll need to buy more.
After each response, we'll provide the correct answer.
Let's begin.
Once you get past the learning, you'll see how easy this is.
Answer.
Once you get past the learning curve, you'll see how easy this is.
We plan to the interface to make it more user-friendly.
Answer.
We plan to rework the interface to make it more user-friendly.
Janet is going to work with your staff and them through the initial setup.
Answer.
Janet is going to work with your staff and coach them through the initial setup.
Before we go on, are we all on the same about the next steps?
Answer Before we go on, are we all on the same page about the next steps?
We've reached the end of this lesson, the third in our series on project management.
We've learned how to manage client expectations, emphasize collaboration and outline testing procedures.
We've also looked at how to clearly identify scope changes and bring up added costs.
Thanks for listening, and see you again soon.
