Requirement is the base of any project, cause you can’t (or shouldn’t anyway) create plans and schedule when you don’t know what to make. A definite and concise requirement is critical for a Project Manager to produce realistic and accurate (close enough, at least) project schedule. Therefore the teamwork of a Project Manager (PM) and Business Analyst (BA) is very crucial in a project.

When I started as a Junior PM, I had to learn things on my own by chasing down relevant seniors, sitting in a lot of requirement meetings and researching things. After 3 years, my BA friend and I were coaching and supervising the newcomers. We found that in most project, the two roles were often in conflict with each other.

Common Business Analyst prejudice against Project Managers

1. Do not have the initiative to understand high-level project requirement documents.

This was true with some PMs and I still don’t get why they do this. It is understandable to refer to your BAs when you are new, but when you are still doing that after months into a project, or into your employment in the company, then it is also understandable that your value is questionable.

These things can take time, but the least you can do to your own credibility is to appear that you know what you are selling in front of the customer who is paying for your services. You don’t have to know more than your BA, in fact, it is troubling if you know more than your BA. However, if you pass every little question to someone else, pretty soon people are going to bypass you.

2. Changes scope or business requirement without consulting the BA

This is more likely to happen when the PM has minimal understanding of the system/product, and also when they are easily intimidated by customers. The end result usually revolves around unrealistic deadline, agreement to deliver something out of the scope, or even conflicting features with the existing system.

BA is generally responsible for the requirements, so when this happens, it is very likely that the PM and BA will start putting blames on each other. Also, once something is agreed by the PM, the customer will hold on to it with all their might. You will find it difficult to fix any problems arising from this.

3. Lack of communication/leadership

I have met several PMs that established “I am your boss, you are to do what I tell you” mentality with their teams. Some of them barely communicated their plans, and goals to the team. Some expected people in other departments to immediately work on their requests, and just drop whatever they were doing at the moment. This usually ends up in ugly arguments, resentment and resulting in bad quality.

The way I see it, a PM is there to support his team in doing their work. He is not there just to tell them what to do, he is there to make their work easier. Managers need to understand that without their team, he/she can’t work. Unless you are a PM & BA & Programmer, but if that’s the case, then you don’t have a team anyway

Common Project Manager prejudice against Business Analyst

1. Do not actually analyze the requirements.

This more likely to happen with a timid BA or less knowledgeable ones. They don’t want to argue with the client or stakeholders and just parroting what was asked of them. If coupled with a PM who doesn’t understand the system or requirement, the result can be disastrous.

It is common for customers to ask for what they want, not what they need. It’s even more common that the customers do not actually know what they need or even want. That’s why they hired you. The BA should analyze what is the client’s actual business problem and build a solution to solve it, even if it might be totally different than what they asked

2. Their work are unusable by other project team members

There were some cases where the requirement documents were too general so that the system analyst or the programmer couldn’t understand the workflow. Some were inconsistent throughout different functions, or features were left out. The worst ones were the ones made without consulting the system analyst or the programmers, those tend to include some unavailable technology or require us to provide human sacrifice for a miracle to happen.

How to run a project team

1. Set expectations from both sides at the beginning of a project

I usually do this in the first team meeting. Three things that I expect from my team members: they get their task done when they say they will, they take pride in their work and they come to me when they have a problem, sooner than later. It is important for the team to understand that the sooner we acknowledge a problem, the more options that we have.

2. Be interested in learning

I made effort to sit in the business and technical requirement meeting as many as I could. Although I just sat with my mouth shut, I managed to grasp what our products do better than reading thick documentations. Take notes, and ask a lot of questions. A PM is not supposed to know everything, and he should know when to ask for help.

I am grateful that I made the effort. I was able to compensate newer BAs in meetings with customer, I earned more respect from the customer which in turn bolster my credibility when negotiating with them. Also it is important that my team members could not markup their mandays easily 😉

What are your experiences dealing with a PM or a BA? Do you have any suggestion for me to do better?

reference:

• Kiron Bondale – Project Times
• Kiron Bondale – Easy in Theory, Difficult in Practice
• Elizabeth Harrin – A Girl’s Guide to Project Management
• Stephanie Famuyide – Business Analyst Learnings