Transcription
[Music] Hello everyone and welcome to our channel career talk. I'm Suran Sharma, an agile consultant based in Netherlands, and in today's session, we will discuss some tricky, challenging situational project manager interview questions shared by our WhatsApp group member. And to help us, we have Apurwa with us. She is a familiar face on our channel. We have done six sessions with her so far. You can find the link to all sessions in the description box and in a pinned comment. So feel free to watch them later.
But friends, before we start, make sure to subscribe to our channel, career talk. You will find tons of valuable content, and we find this session helpful, which I'm sure you will. Please smash that like button. Okay. So without further delay, let's get started. Welcome, Apurwa. Thank you for joining today.
I'm good. How are you?
Okay, we are good. So let's jump to our question if you're sure.
Okay, so the very first question is, uh, you recently managed a project that was delivered late and did not meet the expected outcome. And during a postmortem meeting, some of your senior management asked us to analyze and, you know, what went wrong and explain like how you would have handled the situation differently. So what is your, uh, take on that, Apurwa?
Okay. So when it comes to root cause analysis or doing a postmortem, we'll have to see this, uh, situation from multiple angles. So, uh, starting off with probably scope creep. So during the, um, project duration, did we have any major scope creep that is adding new functionalities which were actually not part of the original plan? And if so, why was that? Uh, probably most common reasons could be like, uh, some competitor in the market is leaving it fast or adding certain features which might hamper our, um, uh, business. They may not buy our product, or couple of times, some critical stakeholders would not be included in the decision-making of the initial, um, scope of the project. So they would have pushed it through, uh, multiple such cases. And even if there was a scope creep, was an RCA done for that or the impact analysis done for that, um, like, uh, mainly the triple constraint analysis as we call it? How would it affect our schedule, our cost, and, uh, our timelines? Um, so if they have not done that, that would definitely be a problem.
And other one is, um, after scope creep, probably resource constraints. Have we faced a lot of people leaving the company recently? Or even if the headcount is still fine, are they well-trained and, uh, competent enough to do the work at hand? Or, uh, do they have all the tools needed? Sometimes due to budget constraints, the number of licenses will be less. So, so they'll be asking two, three people to share one license software, or initially, they'll say, you start off with the evaluation version, we'll get you the, um, licenses later on, or certificates may have expired, multiple such reasons. So, is there a resource constraint?
And one very important thing, communication gap. Uh, during the start of the project itself, was it decided like who are the stakeholders we should be communicating with and in what frequency? If we are sharing any status reports with them, is the format decided? What is going into that, um, uh, WSR or, uh, status reports? Is it decided beforehand, and is it making a value or an impact to the people who are receiving it, or is it just becoming a compliance, uh, week on week or month on month? Initially, lot of people or managers, whoever is sending it out, they put a lot of effort into it. After a couple of months, it becomes a ritual. So they just change a few stuffs, they change the rag and send it out. So, is it really making a difference to the stakeholders? So that is important. And if they are meeting for a cadence, like how often it is, who should be part of it, and what should be the agenda of it, that is also very important. If you just keep the floor open in a big project like this one, multiple topics will be there, and we just end up with, uh, nothing, no actionable items, no takeaways for anybody, and you get diverted very easily. So the communication channels also should be very clear. In some projects, we have seen like they'll be using WhatsApp, messenger, other things which are not actually authorized by the company. So we should probably, I feel, we should restrain such things. Just stick to your, uh, office, uh, mailbox or chats. Like if you're using Teams, Slack, whatever it is, go with the official channels, that's better. So that is all about communication.
And again, um, quality control. Were all the, uh, stages of quality control, uh, defined at the beginning of the project itself? Are they using any automated tools like, um, static code analyzer tools like SonarQube, these kind of things? And is the process clear? If they're using Jira or any other, uh, software, is the process set in that? Like, coming with it is in the design, then the stories or the requirement document is ready for the developers to pick it, then is it going for a peer review or a code review by a lead, however, uh, the project is, uh, uh, deciding? Then, uh, do you have a PR review? If it's an agile project, or, uh, is there a testing, integration testing? What exactly is the quality control process? Or if you're using a static code analysis tool, at least there should be a pass of 85% without any critical errors, do, is something like that set down? You need to check those kind of things. Or if, uh, there has been a scope creep or, um, unrealistic timelines, people might have just gone overboard and skipped some of the steps, which will definitely, uh, affect our quality. So these kind of things we'll have to check.
And metrics, a very important one again. Uh, have we decided the metrics at the beginning of the, uh, program? And is everybody aware as to how each of the metric is calculated? And while deciding the metrics, have we taken into consideration if this metric is actually useful for us while tracking it? Is it really going to give us a trend whether we are going in the right direction towards where we are headed, or we are just following it because it's one of the most favorite in the industry? So those kind of, uh, metrics creation, those also we should be careful.
Uh, so coming to what I would do differently, if it is a waterfall or a hybrid kind of project, having a project management plan at the beginning of the program is extremely important. Uh, you should set down the basic three baselines, that is the schedule baseline, the cost baseline, and, um, scope baseline. And any changes to any of them should go through a CR process. We call it the CAB approval, that is, uh, there's a change committee which looks into each of the changes that are suggested. They do the triple constraint analysis and give a go or no go, uh, or just park it for now kind of, um, decisions. So it is a well-known decision before we do a change to any of the constraints because it definitely impacts the entire, um, process.
And, uh, I forgot to tell you about the risk management part. During the beginning of the program or at, uh, or is there a plan to revisit the risk at, uh, given intervals of time, probably monthly once, in a quarter, whatever it is? Do we have a risk management process in place? Are all the major risks identified? If they are identified, how are you analyzing it? There's a qualitative analysis method and a quantitative one. Normally, everybody does the qualitative one, that is, uh, the impact into probability will give you the, uh, risk factor. So how probable is this risk going to happen, and what is the impact if it materializes? That gives you how, uh, critical this risk will be. The product of the number, whatever number you get, it is again up to the project's, uh, discretion how critical to, uh, realize it. Normally, they, um, measure it in terms of 1 to 10. 1 to 3 is a low risk, 3 to 7 is medium, 7 to 9 is high, above 9 is, uh, critical, kind of things. So, is it being done? And for every critical risk, is there a risk owner identified? And are they very clear what to do if the risk, uh, materializes? That is, you have a, do you have a contingency plan, a mitigation plan? So this also becomes important.
So what I would do differently is, whatever I mentioned, all of these has to be in place, and you have to, uh, streamline the processes. And along with this, how is the team morale, or, uh, how are they trained, how is their training plan? So considering all these, probably we can, uh, get to know what are the issues which the project faced and how we can avoid it in future.
Wonderful. Thank you for that elaborated answer. Thank you.
Great. Um, okay, let's move on to our next question. So let's say one of your team members, uh, approaches you and they're asking like, how they can get a promotion. So that particular person feels that, you know, um, he has been performing well but have not received that kind of recognition. So how would you guide him on their career growth within the project?
Okay. Uh, so if I'm not directly interacting with this person, he has just, uh, come to me because I'm a senior member or probably he feels I can guide. Then first, I would like to know what is his current role, what is his achievements, and in the last couple of months, has he done something significant for his role and his team? Like, if he's a developer, rather than just completing whatever is given to him, has he proactively picked something, or is he given some out-of-the-box ideas to the team? I would probably try to analyze first how, uh, important he is viewed from his team's perspective. Maybe if he, uh, if he's in my team, I would definitely know what he's doing. Otherwise, I would talk to his immediate manager to find out what are, what is his opinion on this particular candidate.
And then I would like to tell him like, what is the difference between an annual, uh, appraisal cycle and a promotion? He may be doing his current role really well, uh, that is why he's, he'll be getting good hikes if he is. So that it also becomes an important factor. How are his ratings or bands or hike percentages? That will clearly show that what the management or the organization as a whole thinks about him. Based on that, promotion is something not like, not like before. These days, you have so many years of experience, you're going to get the next promotion. It doesn't work that way. The management sees if this person is capable enough to take the next role. The next role won't be this similar as he's doing right now. It will be more responsibilities, more people handling, the canvas becomes wider. They'll see that if this guy now, as a good developer, will he be a good tech lead? Will he be able to support, uh, people in future? Is he a people's person? As we go up the ladder, even in the technical role, you should be good at talking to people, working as a team. So, are they viewing him like that?
And it's, uh, also it also depends on the business needs. They can't project or promote everybody who is actually eligible at a given point in time if they don't have enough roles at the next level. So you might, even if you're really worthy, sometimes you may have to just wait for your opportunity. But apart from this, what is in his hand? I would definitely, uh, encourage him to see, come up with a promotion plan. I would say, just like the way we do a project plan, you can come up with a, uh, promotion plan. Identify his skill gaps, try to tell him that you can do some certifications, or, uh, take part in any coding kind of, um, most companies have these, right? Codex competitions, hackathons. Be part of them. And whatever you are doing, your work, see to it that it is visible to your, uh, peers and seniors. Some people are kind of introverted. They may be doing their job, but they love to stay in the background. If you are like that, it's difficult to grow anywhere. It is the case. So I would try to tell him that it's not wrong to be proactive about what you have done. To boast about what you have not done may be wrong, but why not take the credit for what you have actually done? So I would suggest him to be more open. Ask your queries, give your suggestions openly in meetings where, uh, senior management are there and they are seeing you and hearing you. And, uh, I would especially when he is moving for promotion, just not his technical skills, where I said certifications and giving solutions. He should also build on his communication and leadership skills. He can get into some of the programs. Most organizations will have a learning platform, Pluralsight, Udemy, LinkedIn Learning, anything. So you get tons of, uh, leadership related courses there, which is not actually expensive, or it may even be free from your company side. Go through them. Sometimes it feels like it's just like that, telling so many stuffs. It's all theoretical. Whatever you feel is, uh, you can actually implement in your personal and professional life, try to implement them. Only then you'll get, um, a feel of those leadership kind of trainings. Do those trainings, present your work also. You can seek, uh, peer feedbacks. Be proactive. Go to your manager once in a while. It's like after the whole year, if the normally the, uh, organization's framework or the managers themselves come back like every once in a month or three months with feedback. In case that is not the case with your organization, you can go back proactively asking for a one-on-one, asking for feedback. That gives a pulse to your manager and your people that you are willing to change, you're willing to improve. So these kind of things will help you get a promotion. And, uh, on top of it, as we all know, there is some office politics, there is a lot of things which is not in our hand. So you can't do anything about it. We can do what is in our hand. Okay.
Yes, wonderful. Great. Uh, thank you, Apurwa, for this elaborated answer, one more time. Okay, let's move on. So the third question is on KPI. So let's say your track sponsor asked you to define the key performance indicator for a new project. So how would you decide which KPIs to track and how would you ensure that they reflect the project's true success?
Okay. So before we try to, uh, define any KPIs, we'll have to first understand what is the type of project it is. What is the objective? What is the goal of the project? Because the KPIs for a project which is doing support may be totally different from one which is creating a new product. Or a logistics company, all of their, uh, metrics will be very different, which when you track will, uh, indicate you towards success. So one, uh, one idea to come up with the best KPIs is, uh, following the SMART technique. S stands for Specific. You'll have to clearly define what you're looking for. Define the goals what you're looking for. That will lead you towards the required metrics because if you just Google KPIs, you get tons of KPIs these days. So you should be clear on what you want. Only then you can go searching for a proper, uh, KPI.
Then it has to be Measurable. You want to have a product which is 99% defect-free. How are you going to measure that? You'll have to start at grassroots level. Or even if your project is like creating 60 defects per month or per sprint, then tomorrow in the next month, they will not become 99% defect-free. So you should have a proper plan which is measurable. Okay, in the next month, we want to reduce by 10%. By the end of this quarter, we want to achieve, now we have 60 defects, it should come back, come down by 25%. So that gradual increase or incremental improvement, uh, should be me, uh, that should be measurable. So for that, you need to have a baseline. Baseline is what you are right now, and what's your target, and what is your plan to get at the target. So that is measurable.
And then Achievable. It has to be realistic. Again, every company can't be a Six Sigma project. A company or a project can't be Six Sigma. Everybody can't, uh, think in the terms that our logistics will be like Amazon on day one, or our delivery rates without, uh, any issues will be like McDonald's. They have really strived very hard to get there. So we need to understand that a new company or a new project, you can't expect that amount at this day. So you have to be realistic in probably the first release where we want to be, and after two years, where we want to be. So it has to be realistic.
And then it has to be Relevant. As I said initially, there are hundreds of KPIs which you can find on Google these days. You should see what is relevant for you. A logistic company may be interested in turnaround, but, uh, a product company may be interested in their velocity. So you should see what is more, uh, relevant for you.
And it has to be Time-bound. As I was saying, uh, in this much time, I want to get here. So you need to have the timeframe in mind. So using these SMART, uh, categories, couple of KPIs, um, again, you cannot just start giving out different KPIs ballparkly, just like that. There are, you have to first categorize, okay, in the process area, what cate, what KPIs I want, then, um, in the quality area, what I want, and in the end outcome, if I see, what I want, in the financial area, what I want. So, some of the KPIs in the process area could be cycle time, lead lag, throughput. These basically refer to the Kanban board. Support tickets or logistic kind of companies, they will be worried about these kind of things. Maybe velocity, as, as I said, these kind of things for, um, um, development projects.
Then outcome in the end, what do you want to see? Like CSAT. What your, uh, at the first release, like your MVP one or your first release, what do you want the outcome to be? At least I want a CSAT of 70%. You can't expect 95% on day one, right? So, at least 75%. Um, and what your, what should your real revenue realization be? When my first release goes out, at least I want to see this much percentage of profit of what I have spent today. And on-time delivery. I have, um, thought that my first delivery will be sometime around May, June. Then you, uh, solidify your dates, the first week of May. In that, ensure that you are sticking to that first week of May, if not May 3rd, at least first week of May. That makes a, a better sense.
Then coming to quality, how many defects? That's something I think all of us are tracking. How many defects per, how much? And what is the amount of effort we spend spending in rework? So those, uh, give you the quality. And then financial return on investment. I had spent $10,000. After my first release, how many people bought it? How much is my return I have got? And, um, budget variance. I decided, I had planned to spend $10,000. At the end, how much did I end up spending? If you are overrunning your budget, then you have more risk of making profits because you have spent more than you had planned. If it is too much under budget also, you should see why was it so under budget? Did I miss out on something important where I had to spend that money?
Then we'll also have to think about tracking and reporting these. How are we going to track? If you are going to use something static like Excel, that if people stop updating it properly, or they don't know how to update it, then you'll get erroneous outputs. So in the long run, you had to go to Bangalore, you'll end up in Mysore. So you'll have to be, uh, instead of tracking it statically, you can go with some tools like, uh, Jira, which will give you, when configured properly, uh, reports, um, as, uh, you had calculated and configured it. And, uh, periodic reviews, status reports. So these kind of things will definitely help us to, uh, track the KPIs if we are on track. I think that's it.
That's it. You have covered everything. That's it. Wonderful, Apurwa. Okay. Uh, let's move on. Yeah. So before we move on, um, we got a lot of comments that, okay, do we need these much elaborated answers in our actual interviews or not? So it's your choice, okay? We here try to give you as much as possible. It's your choice. You want to take extract from from that, that's, that's, it's up to you, okay? It's not like you have to just copy any of our guests like Apurwa or anyone. It's up to you, okay? So that's something. Anyway, uh, let's move on. So the next question is on the cultural difference, and when we are working with multiple teams, you know, across different geographies. So let's say in this kind of setup, one of your team members' working style clashes with others for sure. So how would you address these kind of differences and how do you ensure that the team works smoothly in in harmony?
Okay, first of all, if I feel there's a lot of people clashing with a lot of other people, then I would probably have a one-on-one with each of them to understand the basic issue they are facing. What is the root cause? Some of them may be feeling that the other people who are at other geographies, they are pushing them to work late in the night or get up too early in the morning, or, uh, they are not able to understand their language, as simple as that, or, uh, they just have an, uh, intimidated feeling about the other person, maybe because he is very senior. So first of all, I would go in and ask one-on-one why there is a clash, what is their problem. So after that, then, uh, I would encourage the team to build something called a team charter. The team charter is like a project charter. It'll give you a baseline of how the, uh, team works as a team. H, what is their baseline? Uh, something like, what is the common language? Some of them may be talking a lot of regional language. If there are eight people in the team and six of them belong to a same place, like if they're talking a regional language like Marathi or Hindi, and the other guy is not understanding, then there is definitely going to be a clash. So you create a baseline or a common language which is respectful and understandable to everybody in the team, and, uh, request and require everybody to, uh, communicate only in that language.
And then the communication channels, as I said, stick to the official communication channels, like mail for more formal ones, and pinging for like through Teams or Slack, whatever your, uh, company is providing, and make calls through the same. So instead of, uh, asking for others' personal phone numbers, through chats, creating WhatsApp groups, and nobody can really help you when you're doing these unofficial, uh, uh, communications because it is not within the purview of the company or professional work, uh, place. And, uh, you have to set clear roles and responsibilities. Sometimes a senior person is a developer. He may ask him to continue with the testing also, or ask him to do the integration where there's a DevOps engineer to do that. So set up clear roles and responsibilities for everybody in the team. So they know what is expected out of them and out of others. So they know what they can ask somebody else to do as well.
Um, and if there are a lot of people from different, different parts of the world, one big problem these days is, uh, the overlap hours. You have to ensure that you have a couple of, uh, core hours where the entire team is able to, uh, overlap their, uh, time and work. And during these hours, have your status updates or daily stand-ups, whatever, wherever you need the whole team to work, keep it in those hours. Let it not be too late for one, uh, team or, uh, one person, or too early for the other. Midnights, these kind of things is like you are, um, overstepping their professional boundary into their personal lives. So let's, we should definitely stop or try to avoid those.
And, uh, as I already said, if you're using, uh, tools like Jira, have standard workflows. Everybody should know after development, what happens next. Somebody may think I have only done the review, or my friend sitting next to me has done the review. I'll directly pass it to QA. But there is another step, peer review, in process in the middle. So even if you are sitting next to that person, ensure that you are passing that ticket in Jira into the next phase, then to the next phase, so that it's clear to everybody, uh, what exactly is happening to that ticket. So that common workflows will help people to work better.
With all these, I would definitely try to, uh, have some sessions on, uh, uh, the, uh, cross cultures, uh, how it works. And each of us will be having different types of holidays, different kinds of festivals. I would encourage them when we meet in, uh, team meetings to discuss about their cultures, so that you know what might hurt the other person. If you have probably a Muslim in the team, and somebody else is making fun, like the other person will wear a burqa and go, that will definitely be very irritating to this guy, right? So you should be very, uh, sensitive towards, uh, each of the team members and what their culture stands for. So that culture sensitization, you should do in the team. Don't talk more than required.
And, um, we can also try and during retros and things like that, you can celebrate, cross-celebrate all the cultures and festivals. We did some similar ones last year during Christmas. We had all our cameras on. We asked all our stateside people to show their Christmas trees, how they celebrated, or even during, uh, uh, these Black Fridays, what kind of, um, how they are decorating their homes. That way, you get to know, it's enriching your personal experience as well. You're getting to know other people's, um, uh, cultures and beliefs.
So with all these, uh, with after all these also, sometimes there still will remain some conflict between two personalities, just because it is their personality, or sometimes they both are the same personality, that's why it will be conflicting. Like both are strong-minded or, uh, strong-willed, they're not ready to give up. So that is a basic trait problem. So in such a case, you just get both of them together. You say, boss, we're in the same team, you know, you have to work together, at least for the good of the project. Come to a working agreement, at least. So once you have a working agreement, don't talk beyond this. If you, whenever you face a problem, bring it to the team's, uh, common table. Don't try to, uh, argue, uh, on it yourselves. Sometimes what happens is when you try to create, um, uh, dissolve this difference, if they really have a same personality trait, then they start exploring and getting to know that they also have a lot of things in common. So only if you douse the initial flame, the her inside or the diamonds inside gets shown. So that way, you can try to help, uh, the team members within also.
Okay, Apurwa, wonderful. Thank you.
Okay. Uh, let's move on. So the next question is, let's say your, uh, project is running two weeks behind schedule and has already exceeded its budget, let's say 15%, 20%. And the sponsor is unhappy. So what action would you take to bring the project back on track without, of course, compromising on quality?
Mhm. Okay. So basically, we'll have to assess the root cause. The main two areas which you will be analyzing is, there is it's going behind schedule. So you will see why there is a schedule overrun, and also it is beyond budget, why there is a budget overrun. As we already discussed earlier, we'll go for scope creep in terms of schedule. If there is more than what we planned has been stuffed into the team's bucket, that will definitely, uh, make you go beyond the schedule and also beyond your budget because more people are actually pushing your, their, uh, limits, or they're spending more time where they should not be. And, uh, maybe for a budget constraint, there's a poor initial estimate, probably because of which, um, they think that some work will take around, uh, five hours, and finally it takes around 25 hours. That is a very bad estimation, you can say. So then you'll have to, uh, improve the way you estimate it. And of course, with practice, it will improve, but you'll also have to give some training to the team on how to improve their estimates.
And, um, in many projects, there's a third-party supplier of something, or you would have handed over part of the work to them, and they are delaying because of that, you are also dependent. Everything starts delaying. So you'll have to find out if it is the supplier reason, and probably talk to the supplier, sort it out. That is another ball game, or if it's, uh, just not doable, try if you can change the supplier for the next time.
Uh, along with that, some things are really not in our hand, like unforeseen risks. Some, uh, natural calamity happens, one of your warehouses gets burnt out, or, uh, the logistic, where the raw material has to come, that road gets closed, something like that happens, causing you delays or, uh, losses and things like that. Has such things happened? In such a case, what have you done? Have you taken insurance? Have you, uh, tried to, uh, transfer that risk to another party? So you'll have to see those areas.
Uh, then now that, whatever is done is done, you have to continue. And as, uh, the scenario expects, we have to try to deliver without quality compromise. So what we have to do now is, see what are the out of the remaining tasks, which of them are critical tasks. How do you do a critical task? There is a, uh, method called that critical path analysis. There you create a network diagram. What is a network diagram? You, uh, you put all the activities in sequence, or if there is a parallel path, you just create all the activities from start to end with the all the dependencies or parallel tasks, whatever it is. There you create a network diagram, and from that, you'll have to find the critical path. The critical path is the longest duration in a network diagram where float is zero. What does float mean? That, uh, from the time that you start till end, how much can you delay a particular activity without actually affecting the overall schedule, that is called the float. So when you're doing a critical path analysis, the float will be zero. That is, you cannot have any delay in any of these activities. Those are the critical tasks.
How will you get them from start to end? When you traverse from the starting to the ending, you get two values called the, uh, early start and early finish. Which means like, uh, that's the best-case scenario. What is the best-case scenario? You start and best-case scenario, you end. Then the second time you traverse from finish to start, which is the worst-case scenario, late finish and late start. That is the latest time you can start an activity without affecting your schedule, and the latest time you can end the activity without affecting the schedule. So you get these four values: early start, early finish, late start, late finish. So, uh, an early start minus late start should be zero to get a float of zero. Early finish minus late finish should be also zero. I know it might be a little complicated. It makes more sense if you are drawing it, showing how it works mathematically, but, uh, you have a lot of Google stuff. You can just go through any, uh, network diagram with critical path, then you'll be able to probably make more sense.
Anyway, in a nutshell, you can say there is a way to do a critical path analysis. You get the, uh, critical items which you have to finish first. You have to prioritize these critical activities to be completed, hook or crook. The other items probably are, uh, happy to have, maybe even if delayed to the next release, will not have much of a, uh, problem. So once you have the critical, uh, activities, then you have something called fast tracking and crashing.
Fast tracking is a method where, um, you have already identified the critical tasks. You try to complete more than one task in parallel. Ideally, it should have been A after B after C. But if they don't have interdependencies, you try to somehow start B and C together and try to expedite that both the activities to complete on time. But you should be very careful. This can cause, uh, quality issues, or you might hit upon roadblocks. You should be very clear that they don't have interdependencies.
The other one is, uh, crashing. I think most of us would be crashing in our projects with or without knowing the terminology for it. You'll be adding more resources to the team at that point of time, just for the critical tasks to get over. You either borrow people from other, uh, teams, you, uh, work it out with other project managers, get more people, or you, worst cases, you are asking your team to burn out and extend their hours, or you get some extra budget from your manager to get some, uh, contractors. But in this case, we are already behind budget also. I don't think that will be approved. Only your relationships with other project managers. In some projects, it's not a very peak time. They'll have a lot of people, they don't know what to do with them, they don't want to give it back to the resource pool also. So then they'll be happy to loan them to you. So those kind of people you can use to crash.
After this, you will have to see what are the wasteful activities the team is doing. As we know, there are these seven wastes: like waiting waste, travel waste, um, overproduction, those kind of things. Where exactly the team is wasting time, energy, and all? Try to cut on, cut down on those processes. Probably if they're doing too much of documentation, you can ask them to stop that for the time being. Or you can have documentation over voice call. You can have voice, uh, um, audio files instead of written ones, because talking is easier. They'll run through the screen, record the screen, and the person will be talking in the background. This is what is happening. So that way, you can create a document faster. So try something like that.
And, uh, as we already discussed, negotiate vendor pricing or change the vendor if you are having a lot of problems with them. And, uh, in a hardware industry, probably you can look for a lesser, uh, cost material if it's not, probably costing you too much. In a, uh, textile industry, see if there is a thread which is a little more cheaper than the one which you're using, which without, without costing you much of a quality hassle. You can try that.
Um, and along with that, the most important thing is, you know, you are in a firefighting mode. Make sure that all the stakeholders, uh, your management, everybody is on board with you. Don't try to hide these things with them and give them a shock surprise in the end. Let them be there. They know there is a problem, and you also explain to them what are the steps you're taking to mitigate it, so that they know there is a criticality here, and they don't hold you responsible in the end. So throughout your mitigation plans, they will be there. They'll be guiding you what to do, what not to do. So even in the end, you end up with not so good, uh, outputs, they are also part of it. So you are keeping yourself safe, keeping them informed, and I think it's the best way to be transparent.
Wonderful, Apurwa. Great. So, uh, thank you, Apurwa. Uh, thank you for sharing your insights with us, and I'm sure our viewers have learned a lot. And friends, u please like and subscribe for more project manager interview questions. And until next time, stay inspired. This is Suran Sharma signing off. And thank you, Apurwa, one more time. Thank you. See you soon.