Skip to main content

Author: Brad Egeland

Delivering Excellence Even When You Dislike the Client

Ever had those times when you knew you were performing at your highest level and you just weren’t connecting with the project client? It is not easy, giving 100% to those who don’t seem to like you or don’t seem to appreciate the effort.


I’ve been there. I had one client who said they didn’t like me. My tech lead said, “You don’t even know Brad.” Their response? “We are paying $150 / hour (my company’s charge rate at the time for a PM on a project) and we have a limited budget.”

What did I do? I decreased the visibility of my role, cut my travel out of deliverables and onsite meetings and made them feel a whole lot more comfortable. I could still manage the project effectively and they saved money in the process. Then they loved me, and we finished the project under budget and with a nice high profit margin. Win-win.

So, I’m not so much looking at this from the angle of us not liking the client, but rather the relationship just not being  A+. Perhaps they are very difficult, and you just don’t like them. Whatever the case… how do you go forward, manage the project, team and customer effectively and eventually deliver a winning project? Let’s look at some steps or ideas on how to get there…

Go through the motions. This sounds bad, but it’s true. In this scenario you basically put your head down and run-on auto pilot using the best practices knowledge you’ve gained through years of experience and keep your eye on the prize of a successful project delivery despite the adversity and consider it a huge win if you do. This doesn’t mean you don’t think and manage and be strategic. It means you go solo with your team as much as possible and involve the customer as little as possible. This goes against my overall feelings that customer participation is a huge part of the successful project equation. But if this gets you through it, it’s better than any project confrontation if it helps avoid it.

Suck it up and be responsive. In this scenario, you put a smile on your face and put aside every difference you might have and pretend that the customer smells like roses… or just always picture them in their underwear… in a non-pervasive way. Sort of like they told you how to get through those first big presentations in your personal or professional life without fainting or wetting yourself. Remember that first college speech or whatever? Use that… you can make it!


Give some things away. You can take the high road, turn the other cheek, and kill them with niceness. You still will not like the customer, but they end up loving you and that’s half the battle. Give something or several things away for free knowing you probably end up winning in the end because of it. They (the customer) become more cooperative – if that was a problem – you get past some issues and get things accomplished. You do not have to give away a lot, but make sure it is known that it is being given away. There is nothing worse than suffering through a project – giving things away to make better things happen – only to keep the pain and suffering going because they don’t realize they are receiving a “gift.” The gift giver usually should not brag or boast or point this out – but in this case you need to in some not too subtle way, so you don’t keep pulling your hair out.

Never forget to rely on your support team. Finally, never forget to rely on your team. They are not the problem, and you must take the blinders off and managing the whole big picture, not just your frustrating situation with the client. Otherwise, you’ll end up taking it back to your wife and if she has to listen to it for too long she might kill you in your sleep! I’ve been there. Seriously, though… your team is assembled with pros who have felt this way themselves. If they say they haven’t ever – then they are probably lying. So, rely on them to keep you from getting too aggressive with the customer – let them step in when needed and take the lead so you don’t have to show frustration and can keep your game face on throughout the engagement. After all, the customer isn’t likely to feel too comfortable with a PM that basically wants to smack them every time they talk. You can think it, but do not let it show and hide behind your project team when necessary to make it through. They are your 10 step support group.

Summary / call for input

So there you have it. My opinions and steps and thoughts on how to make it work when you and the client – for whatever reason – are not really the best of friends. It can make for a long 3 months, or 6 months, or even 2 years depending on how long the engagement lasts… but just because you do not like each other doesn’t mean you can’t win on the project. If that were the case none of us would have very many Facebook friends from our high school days. And now some of those are the most fun Facebook friends to have, right? And now you get along!

Readers – what are your thoughts? Have you ever had those strained project relations that you have had to punch your way through and basically grin and bear it till the end no matter how the yucky customer treated you or no matter how much you didn’t like them? Life is not just always coming up roses and it can be hard. Managing projects is nearly always hard, not always fun, and sometimes it can be a nightmare. But there is usually a light at the end of the tunnel. Even a marathon ends after 26.2 miles even though you are sure you will fall dead first!

My Business Analyst Can Beat Up Your Business Analyst

There’s actually some truth to that statement. I was project lead for a project in Chicago a few years ago and there was pizza, burgers and beer involved and then it happened.

A simple discussion turned into a heated argument which turned into an actual throw down and my delivery team business analyst actually KO’d the customer business analyst in a not so memorable moment. I blamed myself for letting it get out of hand and figured we’d be pulled off the engagement. Thankfully the customer side team admitted it was actually their fault, replaced their business analyst and we moved on to a successful project from there and basically never spoke of it again. Lessons learned, project saved. Yeah!

I don’t recommend going this route on the project and that’s why I’ve tried to keep the alcohol aspect out of any offsite engagements with project customers, but sometimes it can’t be helped… though it’s very unlikely you’ll ever actually end up with a fist fight on your hands. If you have, please share your incident… I’m sure everyone would love to hear about it.

What is it your project manager, your project team, your project customer, and your senior management really wants from the business analyst? What key qualities are you looking for? A good right hook? Probably not. For me it comes down to these top 5 things…

Creates accurate estimates

Since I’m basically looking at the technical project management landscape because that’s where 90% of my project management experience has been, I’m talking here about a business analyst who can either put together a good tech estimate on his own or have enough detailed or high level technical expertise and experience to understand if the team is giving a good estimate. It also comes in handy when the business analyst and the project manager are working closely together on planning and estimating project tasks in the early versions of the project schedule. Fine tuning the schedule before the real work gets under way and having solid work estimates help drive the budget forecast and the resource management plan for the rest of the project with small weekly adjustments, of course.


Can create good, detailed requirements 

The business analyst who can comprehend customer business processes quickly and turn them into a functional design with the team and creates detailed requirements from that functional design is invaluable to the organization. It’s like a great football quarterback who can look at the defense and read the defense. He can see what they are planning for and respond accordingly. And win. Winning is good. I always say that detailed, complex, well documented requirements are the lifeblood of the project and getting started on design and development from great requirements is a major stepping stone to success. And those same requirements will be a major component of a successful user acceptance testing (UAT) session later in the project as you’re getting very close to a signed off deliverable project to the customer and end user community.

Can manage project teams effectively

Resource management, communication, conflict resolution, mentoring – these are all good qualities for a business analyst to possess in order to successfully lead teams on productive and winning projects. But it’s more than that. It’s high integrity, honesty, follow up and follow through, confidence, and the ability to make decisions and delegate tasks and not waiver, but still be open to team feedback and communication. Yes, you are leading the team, but not micromanaging them or oppressively managing the team. It’s a cohesive, collaborative process and a back and forth input, absorption and follow through process. The business analyst needs to be able to listen as well and as much as they speak – it will go miles toward successful leadership of the project team.

Exudes confidence

The effective and efficient business analyst also must exude confidence. That’s actually very important for any leader in order to be respected and followed. The business analyst often must make tough decisions without much data or info to back them up and if they are lacking confidence the team and the customer will sense that and be concerned about the business analyst’s ability to lead a successful Project. You don’t want to go there. Be confident, standby your actions, your decisions and task delegations even if there is pushback. But at the same time, recognize and admit your mistakes.

Cares about the customer

Customer passion, understanding and empathy are all good qualities of the effective and successful business analyst. Feeling accountable to the customer and living by my personal motto of “you’re only as successful as your last customer thinks you are…” will help the business analyst stay focused on one of the key ingredients of project success – customer satisfaction. Customers need and want a high level of communication and many touch points and frequent updates on most projects to stay confident in the delivery team and feel good about the project. And that’s ok – it’s their money you’re working with so they have that right.

Summary / call for input

The bottom line on the business analyst who will best serve the project, the team, the customer and the project manager is one who is experienced, has the right tech knowledge coming in, is confident and ready to make decisions and lead a team. He’s been around the block – knows when to act and when to get more info, knows how to lead a customer, knows how to maintain the productivity of a skilled team, and knows how to facilitate good and effective communication. Everyone has to start somewhere so all new business analysts are novices at some point, but most that I’ve worked with were either project managers or tech leads before becoming business analysts, so they were already a step ahead of everyone else.

Readers – what’s your take on this? If you’re a business analyst, where did you come from – and why be a business analyst? What drove you into the position… need, desire?

The Oppressive BA

Do you excel in your field? In everyone’s eyes or your own? Be careful how you answer that.

Seriously though – we want to excel, we are in the position we are in most likely because we are good at what we do. We excelled and made advances and gained leadership because we were good at leading. We were analytical, could document requirements, could lead teams into battle and translate things the customer said.

Are we still there? How do we solve the hard issues? Task management, ego clashes and conflict management, collaboration issues, communication breakdowns and missed dates… what’s the coverage and follow-up? Are we oppressive when the going gets tough?

What is oppressive? Here are some descriptions and definitions of “oppressive” …

  • Weighing heavily on the mind or spirits; causing depression or discomfort
  • Suggests causing mental as well as physical strain
  • Implies extreme harshness or severity in what is imposed

Is a great leader oppressive? Probably not – at least not in my opinion. Are you an oppressive business analyst? Or do you just lean that way when the pressure is high and the project or a deliverable is on the line? Do you really want to be that way – do you really want to go there? Probably not. Here are five ways to improve, avoid or at least mitigate that behavior (and if you’re a project manager or other project team member who is being oppressive, this is also for you!)


Count to 10… seriously.

I realize this one sounds simple but thinking before we react – while it sounds easy is not really an easy thing to do. I know, I’ve got 6 little ones aged 5 through 11 and after 10 minutes of what seems like silence I can walk into the next room where they are playing and find anything from them all playing together nicely to 2 inches of water to curtains pulled down from the rods above the windows. How did they do that so quietly? Everything can be dried up, washed, and fixed… but that initial reaction is one I’m not often good at… and certainly not as good as my wife is at it! When the going gets tough on the project and there are issues to deal with, staying calm and organized in your response and action can be very difficult… but it is critical for leadership, respect and project success. Becoming frustrated, reacting oppressively, pointing fingers and assigning blame is no way to move forward as a team to right size the project ship.

Put yourself in their place.

Yes, transpose yourself to the project team or the team member with issues. See things from their point of view. Were you clear in your initial direction? The actual fault in any issue may be your own communication skills. Communication is Job One for every project leader – project manager, business analyst, team lead, etc. Poor communication, miscommunication, lack of follow-up to ensure understanding, poor listening, and unclear directions are the key ingredients to a communication issue bringing down a project. Is that what happened? Also, is your oppressive behavior going to be received well and responded to or will it further delay appropriate forward and productive action and response? Will it get the project or task back on track or will it only cause further derailment? Usually it will be the latter.

Constructively consider the available options at the moment.

Take a deep breathe during times of stress and issues on the project. Don’t react to the moment, respond to the problem. Look for ways to mitigate and avoid, not over react, oppress and point fingers. Many mutinies have begun over leaders over-exerting powers and directing blame, punishment and humiliation in a public way. This shouldn’t even be done in private. It does no good. Collect the group, brainstorm solutions and workarounds and decisions with your team to present to the project client so as a delivery team you can – collaboratively together, get the off the rails project back on the rails.

Reach out for leadership assistance.

Don’t be afraid to ask for help. Lots of bullying and oppressive behavior is merely a result of not knowing what to do or say or the best way to react. The CEO or the guy to your left may have never gone through what you and your team are going through. But the guy to your right may have. In today’s real time communication possibilities there is no excuse for not trying to reach out for assistance somewhere – even outside your organization.

Sit down and do a roundtable discussion.

Great way to avoid being an over oppressive micromanaging jerk? Hold roundtable discussions with the team, with stakeholders… even involve the customer if the situation calls for it. You might get away with being oppressive with a team member or two but when you grab everyone involved and gather them to help work through a problem or issue that whole group isn’t likely going to let you get away with wasting their day with your demanding me-centric behavior. The first step in getting help is knowing you need help!

Summary / call for input

So – are you an oppressive BA? Probably not. But we all have those moments of control issues. If you find you have lots of those moments though, you might be an oppressive business analyst. Stop, take a very deep breath and then go take a nap and come back refreshed. Or don’t come back. Your team needs a leader, not a dictator. These steps or actions above will help you to stop, think, reach out to others and avoid a very negative reaction when leading a team. I realize there are more ways to calm down and avoid oppressive behavior – but it’s a start.

5 Common Business Analyst Pitfalls

What if you never dropped the ball as a team or project leader?

What if you could have every base covered? Wouldn’t that be amazing? You have all the information you need to make great decisions. All information and status updates you need to have the best and most accurate status reports and the most interesting and productive meetings possible?

Even though this seems to sound like it is focused on project managers, it is not. I am going to direct this at business analysts. One – because it’s my article and I often handle both roles and can do what I want AND Two – because business analysts in certain projects actually perform the more communicative and facilitator role than the more figurehead project manager. It depends on the project. But there are always those pitfalls. Those behaviors that can be detrimental to the project and we may not even know we are doing things wrong. Consider these five and then let me know what you think…

Micro managing resources.

Micromanaging is a huge mistake! You probably know that already and may just not realize you’re doing it. It serves no good purpose. Stop the oppressive behavior in your leadership style. You won’t be a respected and followed leader of projects and teams if the behavior continues. Your team members are in place because they are experts at what they do. Trust them until they have done something to break that trust. Expect the best and you’ll probably get the best. Help – don’t hinder – team progress, forward thinking, and innovation.

Canceling meetings.

I realize that sometimes it seems like the project is moving slowly and there is no need for that weekly team meeting or formal weekly status call with the customer. Plus, your desk is piled high with work on other hot projects and others on the project are probably in the same situation. So you’ll just do everyone a favor and cancel today’s regularly scheduled team or customer call on the slow project. Stop. This is not a good behavior. Why? Once you start to cancel meetings during slow times your stakeholders who have lots to do will start to consider your meetings to be of less importance and they won’t make your meetings a priority to attend in the future. You’ll be seen as an unreliable meeting facilitator. Even if you’re project is at a standstill, you should still proceed with the regular meeting. Even if all you do is give a quick status update and go around the room once to get any information about tasks that you can from each team member or stakeholder, it’s worth it. You’ve kept your meeting schedule intact. You also may have uncovered a small piece of important information from someone on the team that seemed inconsequential but could have been a big problem if it just fell through the cracks due to a cancelled meeting. You never know when the small things will become the big things. Don’t cancel meetings. Keep in touch, keep the communication flowing and the collaboration in place and the team cohesion strong. You will never regret it.


If I can do one thing great, then I can juggle two things at once pretty good and three things at once fairly well and four things at once sort of acceptably ok… You get the picture? At that point you’re only performing ok in your own mind. Others may be seeing you as a bumbling fool. Give it up! It’s not worth it. I’ve previously covered my methods of managing projects (if you manage than one at a time) in 60 minutes a day. Try it – you’ll be amazed at how much more you’ll excel and how much more you’ll accomplish. If you’re leading, say, 5-6 projects at once, take a very dedicated 60 minutes on each project and get things done on each project – then move on to the next once. You’ll be amazed at how clearer your head will be, how much more you will accomplish and you won’t feel like you just bounced around all day between projects like a rubber ball.


Not following up.

Communication is Job One for all project leaders…. business analysts, project managers, tech leads, etc. and a huge factor in project success or failure. And a big part of that communication is follow-up. After a key meeting or phone call, be sure to follow-up with notes to ensure everyone is still on the same page. Gaps can grow over time. Don’t leave any gaps or room for misunderstandings or mid-communications. They can eventually kill a project.

Keeping senior management at arm’s length.

While you may think it’s nice to not have senior management meddling in your project all the time, having them somewhat involved and up to date is a good thing. Need a new resource fast? Go to senior management and get one. If they know more about your project than others than they will be more likely to take a personal interest and get your request expedited. Need more funding or their presence in front of the customer to help resolve an issue. Same thing – they will understand the project, remember you and jump in more quickly and provide that necessary involvement. Keep them in the loop – and continue to send them regular status updates.

Summary / call for input

The bottom line is we all fall short. We all need help. We all go through repetitious behaviors and we don’t always realize that they aren’t working. We might even be working contrary to or project’s best interests, or team’s best interests and our customer’s best interest. It’s not too late to change how we do things. These may not pop up during a lessons learned session so if you’re continuing with any of these practices or pitfalls… then you’re welcome for the heads up. Stop now!

Ethics and the Business Analyst

Do you consider yourself an ethical person? How about an ethical professional? How about an ethical project leader and team representative?

You’re a business analyst operating in a project leadership role – working closely with four distinct entities or groups. You are working with the Project Manager, the Project Team, the Customer and all Key Stakeholders. Making decisions, meeting requirements, communicating constantly and keeping the project on track. Are you staying true to project leadership standards, corporate policies, and human resources rules of conduct on each and every project initiative?

For the most part, probably. And how well you match up with the corporate policy is not what I’m really concerned about because too many times that policy can get in the way of project success and your best practices of running the project and working with the project customer. So, what is considered ethical practices and standards in project leadership? From my 20+ years of consulting and leading projects and teams, my list comes down to these five. Let’s examine each…


One of my top ones – be transparent with your project customer, your team, your stakeholders. Everyone is in the game with you. There’s no need to go it alone, hide bad news or tough decisions. If you go it alone and fail, all fingers point at you. If you take it to the team and the customer, then everyone works together to solve the problem or issue. If you go down, you go down together. But it’s about transparency and communication. Committees may not be the best thing and they get made fun of enough. But project teams – and the customer is part of that project team and they are funding the project ultimately – are not a committee. They are a skilled group of individuals charged with delivering a successful project. Be transparent and use them when you run into a brick wall on the project and need help.

Ask questions. Lots is made of and discussed about feeling weak or showing weakness in asking directions or help making decisions or help solving problems. But it’s not weak to ask questions. Asking questions eliminates the bad info and gets you closer to a solution or root of the problem. Asking questions can give you the other half of the picture. Trying to solve a problem with only half of the information or half of the picture is nearly impossible. If we only saw the world through our view, we would all think the Earth was flat. We know it isn’t, but there are those that don’t believe it. They are only seeing things in their selfish view and ignoring the real information, the established facts.


Lead by example

The project team is going to need to take leadership and direction from both the project manager and the business analyst. We hope the project manager is a great, ethical leader. If not, you probably should do yourself, the customer and the team a favor and take him to task on it. If problems persist, go to his manager. But you, as the business analyst and co-project lead of sorts, have a responsibility to the team, customer and management to practice ethical project leadership behavior as well. So lead by example – always. Be above and beyond reproach – especially during team and client meetings and in front of these individuals on a daily and weekly basis. Follow through on your work and project commitments, and practice honesty. Don’t say bad things about others or the client behind their backs no matter what you might be thinking. It doesn’t need to be spoken. The project needs action not gossip. If you see something going on that is less than ethical or even illegal, consider yourself to be somewhat of a “mandatory reporter” and take it higher up in order to get action and not harm the project.

Golden rule and team management

The Golden Rule, of course, is “Treat others how you would want to be treated.” Would you want to know the issues? Yes. Would you want to be included in decisions and meetings and information sharing? Yes. So include the whole team and include the customer. And treat people honestly, ethically and like the peers they are. Respect their skills and levels of expertise. Expect much from them, but never be too quick to criticize. And respond, reward and recognize quickly and appropriately.

Your customer is YOUR customer

Remember the customer. Never forget the customer. Include the customer, be transparent and courteous to the customer and keep a professional relationship with them. My motto is always “You’re only as successful as your last customer thinks you are…” Live by that concept. And if you think management is pushing a customer approach that is damaging to the customer relationship or the project or team, tell them so. Management isn’t always right. They have priorities that may be different than yours or the customer’s or the project team. Respect your leadership, but if you think direction that is given will be harmful to the project or customer, say so.


The bottom line is more best practices. I believe that ethical, honest behavior and follow through fall under project management best practices. If we all try to stay above reproach, stay professional, stay focused on the client and team needs and the goals of the project and work toward their success, then we will be fine most of the time. Treat people fairly and equally and your role as a project leader will be an easier and more successful one. Avoid favoritism and open criticism. Conflict and issues happen, but not everything has to be public. Practice appropriate behavior and treat others how you want to be treated.