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 BA view of Project Managers:
1. Do not have the initiative to understand high-level project requirement documents.
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.
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.
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 PM view of BA
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
My Mental Checklist
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?