5 Common Challenges You Can Meet as a Project Manager and How to Overcome Them

PM has to ensure that difficult projects are handled and positive results are obtained. We have to take care of proper communication between the team and the Client. Challenges are part of our job too.

All of us heard similar stories, examples of projects going over budget, delivering less value, the struggle of meeting the deadline – basically, we hear them all the time. Yet some of us still fail to learn our lesson out of these stories.

So what can we do to become better at our jobs, and what challenges we can meet along the way? In this article, I will try to define the most common challenges and suggest solutions that may help you overcome them. All in all, it’s essential to know the risks and challenges you may approach, and no matter how many projects you’ve managed before or how experienced you are, you should never underestimate a good preparation.

1. Poorly defined or unclear goals

The first major challenge that the project manager and team members might come to is not knowing what exactly they are supposed to deliver. When the team does not know what to expect from the project and when objectives and goals are not clearly defined, the project is likely to fail. It can bring about confusion, miscommunication, missing important milestones. This, in turn, can lead to going over budget and overtime. You can compare it to going on a road trip without a plan or a map – how much gas and time you will waste until you get where you wished for?

So how to avoid it?

What steps can you take to counteract this project difficulty?

First of all, take some time to plan your kick-off with the Client. This is the meeting/call where you can define it all. Be prepared! Set the agenda and prepare a list of questions – try to define all the uncertainties. Ask your Client about goals, values, milestones, deadlines, priorities. Talk about short-term and long-term plans. It’s also good practice to send the list of questions to your Client in advance. This will prevent you from waiting for answers after the call, leaving them time to be prepared as well. Have your team aware of the meeting and the agenda. Ask them to prepare questions themselves. The developers would know best what kind of information they are missing. After the call, send the written summary and ask your Client to confirm it.

It should provide you with an overview of what to do next and you should be aware of priorities. If not, do not hesitate to ask follow-up questions or set more meetings or calls – if you are not sure about something, it's best to dispel all the uncertainties at the very beginning of the project.

Also, remember to do the goals check-up once in a while, especially if you have a longer project. Find some time to have seperate call about priorities or talk about it during sprint review or retrospective.

2. Tasks are not being well described

Your project should be up and running, but you do not have tasks described? You have only brief knowledge about what should be done and your Client is busy or reluctant to make some descriptions?

Educate!

Try to avoid it by setting the ground rules on your kick-off or following calls. Working on a project is a common responsibility – without your Client input you are not able to deliver the product they wish for. Focus on education and try to show how roles and responsibilities differ within a team.

Introduce them to Definition of Ready and Definition of Done. Help them understand it – it’s also a good idea to do it on separate, one on one call, so that they won’t feel ashamed or uncertain in front of the team (on separate call s/he might ask additional questions). Try to show it as a business value = if you do not have well described tasks, the team spends lots of time on debating, looking for answers, asking questions etc. Then, they deliver with bugs or “not what I wanted,'' fixing it takes additional time. And as we are all aware, when it comes to Time & Material, time really is money.

Still nothing?

Another option is to invite your Client to planning session and backlog refinement. Show how much work needs to be done before you start working on a task. Start asking questions about user stories, acceptance criteria. Debate, ask follow up questions. Hopefully this will show your Client how much of their input is needed. You can also invite your Client to daily stand up and try to grab some information there.

Try different approaches – do not give up on that. If not filling tickets in Jira, maybe create simplified spreadsheet, where you can track new functionalities?

Most important is to talk to your Client – make them understand, and see the value. At the end, it’s all for their sake.

3. The scope is constantly changing

Ok, you did the perfect kick-off. You set the priorities and had a plan for delivery, but… the scope has changed. And again. And again! Well, the only stable thing is change. Even in the best planned project, with kick-off meeting and priorities set on fleek, a change can happen, it was and always will be a part of Agile. It’s best to react as soon as you recognize it as a threat to your project. Remember, that changing scope can have very negative impact on your delivery, and, by extension on your estimated delivery time and your Client budget.

You can’t prevent it, but you can be prepared, so that changing scope has as little impact on your project as it can.

If you are unable to keep the plan of 2-week Sprint, try a 1-week. If that seems to be challenging, consider moving to Kanban board – it will take off your shoulders the need to plan your work a week or two in advance. In case of sudden changes, your team will just pick the task from the backlog. Remember though, that if you have such unstable plan, it’s better to go a few steps back and talk to your Client about vision and long-term plan for the product. A workshop can help as well.

If it’s not that radical, yet still makes you confused, or your sprint predictability is decreasing try to introduce a regular backlog refinement and planning ahead. On your backlog refinement: go through the tasks and separate those, which still need clarifying. If you perform the grooming with your Client – you can clarify them on the go, if not, create the space in Jira – it can be never started Sprint called “to be precised by Client” or something similar (this way, your Client will easily find tasks where he needs to add descriptions and you can keep an eye on them). Systematic backlog check-up will help your team and your Client understand how much work is to be done. After that, spend some time and try to plan next Sprint – take into account your Client priorities and propose tasks for next Sprint (do it a week ahead) – thanks to this, your Client will have time to decide if those are tasks that should be delivered or the Sprint goal and tasks should differ. It should decrease the possibility of tasks change during sprint. It will also give time to your Client to describe the tasks properly, if you struggle with lack of task descriptions.

Also, make sure your Client is aware, that adding tasks to scope is changing the estimated time of delivery. You can use Jira versions to mark tasks that should be delivered as MVP and POST MVP. Also, take a look on how to plan iterations with Jira.

4. Managing risk

If we do our job, deliver tasks of given scope in time and without going over budget we will be all good, right? Right, so nothing to worry about then? Not exactly. Risk management is often pushed back as a secondary thing to do, while it might be one of the crucial things that should be conducted. Otherwise you may have to deal with various situations you are not prepared for.

The project estimation seems incorrect, but you are half way through the project; Your Product Owner is suddenly off without any info when s/he will be back; cost forecast appears to be inaccurate or your developer needs to go for a 4-week sick-leave. Do you have a plan for those events, or you will act ad hoc?

Every project has multiple risks. It’s not a bad thing – it’s the nature of business. Bad thing is to not take it into account while starting a new project. After kick-off have a call with your team to discuss risks that can appear on your project. Try to think about risks connected with internal and external situations. Those you have influence on, those that are dependent on your Client, third-parties. Also, think about opportunities (helpful risk).

Spend some time to think – what this risk can cause? What actions we can take to prevent this risk from happening? What actions should be taken if that risk comes to life?

Have it all written down in some spreadsheet, do the check-up one in a while (you can separate 10-15 min of your retrospective to go though the risk and estimate if any probability changed). Taking care of risk will help you evaluate if you need to act, constant risk management will prevent you from sudden obstacle that can turn to a project fire.

“What if I have already my project ongoing?” – you ask? Do your risk management process. You may be surprised how many risks are waiting just behind a corner. Or maybe you will save yourself from fire?

5. Unrealised business value

The purpose of project management is executing work that results in delivering value to the business and a customer. We tend to think that if we deliver a quality scope in time and budget – then the project is successful. That can be a trap. To consider a project fully successful, you must be sure that it delivers a business value to a customer.

But how am I to deliver it, if my client didn’t tell me what is the business value for their project? Well, that’s the challenge.

Understanding it can take time, especially if you start a project with your Client from scratch. It requires lots of thought and time to identify what is the business value that should be always in the back of our head while working on the project. Business Value should be understood by the whole team and it should affect every decision you make in your project.

Don’t treat questions about business value as the tabu/hard/difficult questions. Don’t be afraid that Client will think that you stick your nose where it shouldn’t be. Talking about it should be a natural thing for you, your team and your Client. It may require more trust, it may require education – it definitely require proving to uncertain Client, that team aware of business value of the project will deliver a project that is tailored to specific Client needs.

Kick-off is a great place to start. Your whole team is there, your PO (Client is there), in some cases there are additional people, like CEO’s or other stakeholders that can give you more context, more valuable information about vision, about business value, future of the project, their concept on how the project should look like.

When you discuss new functionalities that you are to deliver – ask about their business context. What value should it bring to a customer? What is the vision behind it? How it corresponds with the general concept of the product?

If you feel that project business value is slipping and you don’t feel that it’s understood correctly – a workshop or even longer retrospective might be a good idea as well.

Remember, that business value can change in time. It’s important to keep track on it and talk about it freely and openly. I could write a separate blogpost about importance and good things that come from taking good care of business value. To keep it short, bare in mind that this is totally okay to not have it perfectly described at the beginning and not having KPIs to track right away. What is not okay, is not knowing the value of it and not trying. Your Client should also know this.

***

I’m sure you are aware that those are not the only challenges that you may have to deal with while working on a project. Treat everyone of them as a way to develop your project, your team, your Client and yourself. In every case - try to educate, not force. Think about a business context and how to show value. And don’t give up, nobody said it would be easy, but it’s definitely rewarding afterwards!